Building Web Applications with UML Second Edition part1

Role of Modeling

We model to understand complex things. Software today is more complex than ever. As a result, we model software. Our models describe what we want to build, what we are building, and what we have built. Models are used throughout the development life cycle and are key artifacts. Models often connect different types of artifacts梪se case specifications to database tables梐nd provide a chain of responsibility and traceability.

These models are simplifications of reality. Models exist at various levels of abstraction. A level of abstraction indicates how far removed from the reality a model is. High levels of abstraction represent the most simplified models.^[1] Low levels of abstraction have close and near 1:1 correspondence with the things they are modeling. An exact 1:1 correspondence is no longer a model but rather a transformation of something in one form to another.

^[1] PowerPoint slides and your favorite clip art represent the highest levels of abstraction a system can have.

The real value of a model is not in what it contains but rather what is hidden. Class diagrams in a UML model, for example, do not include the individual statements of each class operation. These details are hidden in the model and are available only in the source code.^[2] Class diagrams further hide things by not exposing all a class's operations, attributes, and associations. The choice of elements to suppress in a diagram is determined by its goal. Each class diagram is created for a reason: to communicate or to explain something. Details that don't help in communicating or explaining don't belong in the diagram. So most diagrams contain classes that have only the relevant details exposed.

^[2] I consider source code itself a model, with the choice of variable names and comments the prime source of added value.

Many models are involved in the development process. Each model has its viewpoint. In fact, part of a model's definition^[3] is that it is a semantically complete view of a system. Each model is at a different level of abstraction. Because they model the same system, the mappings between the models of the same system are of immense importance. The mappings establish chains of traceability and dependency that help us connect the various and sometimes confusing artifacts of the development process. A user profile screen definition can be traced to the JSP code that implements it, and the state change behavior of a purchase order can be traced to a use case specification that defined it梐ll done through the various UML models of the system.

^[3] See James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual (Boston, MA: Addison-Wesley, 1998).

In addition to understanding, modeling has other benefits. It is a communication mechanism, allowing one group to communicate to another in a common language. Modeling encourages us to break the problem into manageable pieces. Because of its object-oriented roots, UML modeling in particular encourages us to think of things in terms of objects and to encapsulate properties and behaviors in objectlike concepts. Modeling with computer-aided software engineering (CASE) tools can help us generate source code and components directly from the models.

Before we go on, I need to make one point very clear. The role of modeling is not to produce code through automation or to produce documentation through reverse engineering. These are simply handy by-products of modeling software systems with CASE tools. All too often, we become obsessed with a particular tool's ability to round-trip engineer code and models, and we often miss the whole point of modeling. Automated round-trip engineering will make it easier to connect the abstractions in the model to source code artifacts, but it will not be able to construct a diagram that communicates a point. It won't be able to selectively hide or expose key properties that make understanding easier. Most reverse-engineering tools can reverse engineer only a source code structure. The few tools that attempt to reverse engineer behavioral diagrams usually end up with diagrams so large and complex that they aren't even worth printing.

The real value in models and modeling is the ability to look at a simplification of a system through a particular viewpoint where the system becomes easier to understand. If the models are as complex as what is being modeled, there is little point in modeling.

Influences of Architecture

Architecture influences just about everything in the process of developing software. Architecture gives us the rules and regulations by which we must construct the software and, to some degree, how we even think about the problem. In the early days of computing, we thought of our problems in terms of batch processing. The business problem had to be thought of in terms of assembling a lot of information, formatting it appropriately, and then submitting it to the system for processing. Today, we have interactive systems that can prompt us, walk us through the collection of data, and process that data at much greater speeds than ever before.

The Web has given us a new variation on the standard client/server system. With the proliferation of networks and HTML browsers as standard software,^[5] it is now possible to deliver and to deploy a system to users almost anywhere. There are limitations, however, to Web architectures. Their fundamental paradigm of interaction is stimulus/response. The server doesn't control the client directly, and as a general rule, all interaction with the system must be initiated by the client. When this is not the desired behavior, additional elements must be added to the architecture, and the result is a more complex, sometimes brittle system.

^[5] Even my phone is capable of browsing Web pages over the Internet.

Web architectures are evolving. In the first edition of this book, most of my experience was with applications based on Microsoft's Active Server Pages (ASP) and the first version of JavaServer Pages. Because these technologies were relatively new, the systems they were used in had relatively simple architectures. The mappings between components and Web pages were simple, and the types of functionality found in the pages' scripts were straightforward. There were drawbacks to these simple architectures. They had a tendency to evolve into difficult-to-maintain monsters.

Today, more and more teams are adopting Web-centric architectures. Collectively, the industry is gaining more and more experience with Web systems. More and more technologies are being applied to Web architectures. The use of patterns and common mechanisms is gaining momentum.^[6] All these factors are resulting in Web systems with relatively complex architectures as the norm.

^[6] In my opinion, patterns and reusable assets are where the future of software development in general is heading.

In the first edition of this book, the Web Application Extension for UML (WAE) profile was introduced and was suitable for the majority of Web architectures in use at the time. When the first version of the Java Pet Store came out, I used it as a tool for understanding J2EE systems. At first, I had a lot of difficulty making the connections between the documentation supplied by the Blueprints book^[7] and the source code. At the time, unfortunately it did not come with UML models,^[8] which would have bridged the gap between the high-level text and the source. So I set about creating a UML model of the application. Along the way, I discovered a number of new architectural elements that made it difficult to model with the current version of the WAE. What was well suited to modeling the relatively simple applications of many Active Server Page朾ased Web applications was unsuited for the relatively complex architectural elements I found in the Java Pet Store.

^[7] Mark Johnson, Inderjeet Singh, and Beth Stearns, Designing Enterprise Applications with the J2EE™Platform, Second Edition (Boston, MA: Addison-Wesley, 2002).

^[8] The current release of the Pet Store example does come with a very simple UML model; however, the version I have is little more than a summary of the key Java classes in the application and not a rich model as prescribed by this book.

It wasn't as though the Java Pet Store introduced anything new that couldn't be done with any other Web development platform.^[9] It's just that this application used so much of the J2EE API (application programming interface) set and created a well thought-out and robust architecture that it exposed many limitations of the first version of the WAE. The results of that effort have in part contributed to the WAE's evolution into this second version (WAE2-UML).

^[9] I'm sure that the marketing folk at Sun Microsystems would argue this point, however.

As a companion resource to this book, I have created a WAE-UML portal on the Internet at www.wae-uml.org. It's my intention to maintain this portal as a resource to those interested in the details of Web modeling and who are looking for additional examples or discussions related to the topic. For the time being, this Web site is hosted by a spare computer I keep in my closet. If for any reason the traffic and activity increase significantly, I'll find a suitable host.

This book, the Web site, reference applications, and models are all intended to help development teams understand the issues involved in building Web-centric applications. The information in this book is presented at varying levels of detail. It is not expected that every reader will use or be interested in every chapter; rather, the entirety of this text is intended for the team as a whole. This book is meant to be a companion to other fine application development books, that address specific aspects of the development process or technology. The reference applications and models are the most detailed source of information applied to a specific example and a great resource for those of us who learn best by example. The Web site is an attempt to keep this information as current as possible, to actively engage practitioners, and to elicit real-world experiences so that the entire community of Web application developers, especially modelers, will be successful in developing applications that work well.