Building Web Applications with UML Second Edition part1

Chapter 1. Introduction

What This Book Is About Simply put, this book is about building model-driven Web applications. It is not a book on how to use a particular tool, a step-by-step recipe, or new methodology. It is simply a guide for the project manager, architect, analyst/designer, and implementer of Web applications梐nyone who wants to build robust, scalable, and feature-rich Web applications using the proven object-oriented techniques that traditional client/server applications have been built with for years now. This book builds on the techniques of object-oriented application development rather than defining its own. I say model-driven because the models are the fundamental driving factor in the evolution of the system's development artifacts. Most of the ideas expressed in this book are not original, and for good reason. Many of the concepts and methods described in this book have developed and evolved over years of practice in multiple domains. These object-oriented practices have enabled projects to be delivered on time and on budget and, most important, have made them predictable. For the most part, the object-oriented principles described in this book are based on the collective works of Grady Booch, Jim Rumbaugh, and Ivar Jacobson, who are also known as the "three amigos." The amigos are the principal creators of the Unified Modeling Language (UML), a notation for visually expressing the models of software-intensive systems. For many, UML also represents a method, although technically this is incorrect. UML is just a language but like any language expresses things with certain biases. In particular, UML expresses system models and designs in an object-oriented fashion, even though it is being used to express system types as varied as generic business organizational structures and processes to real-time embedded system designs. The term UML is included in this book's title because it is at the heart of all the discussions of building Web applications in this book. Most of the original work in this text is in the Web Application Extension for UML (WAE). In it, the UML notation is extended with additional semantics and constraints to permit the modeling of Web-specific architectural elements as a part of the system's model. A major theme in this book is that it is critical to model all of a system's business logic, regardless of where or how it is being implemented in the system. For Web applications, this means that in our UML models, we need to capture the execution of business logic in Web pages, in client-side scripts, and in Web components. By having a single central model of all the business logic in a system, we are better able to understand it and eventually to elaborate on it in future releases of the system. The first edition of this book was for the most part written before I joined Rational Software Corporation. At the time, I was an independent consultant specializing in Web applications. The ideas expressed in the first edition of the book were not, of course, supported by any vendor's tool. Rational Rose was and is my modeling tool of choice; with its extensibility interface, I managed to get some specialized icons in the tool and even create some scripts that would forward engineer ASP components from class diagrams. I am proud to say that since then, the Rose development team has included round-trip engineering of both ASP and JSP components. Full support of the WAE specification is not, however, in the current version of the product; nor will it ever be. Some things simply are not appropriate for round-trip engineering. They may not be suitable for automation, but they are still important to model since the real goal of modeling is understanding and comprehension, not automation. This book lays out the entire specification with some recommendations on what is important and what is not. But in the end, it will be up to you and your team to decide how much detail you'll need in your models. Because this is a book about building model-driven Web applications, it focuses on three key topics. Modeling, process, and Web architectures are discussed in the remainder of this chapter.

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.

Role of Process The process provides a framework and a context to understand things in. Models make it easier to understand complex things, but because multiple models are made for any given system, exactly how and when they are created is just as important as the models themselves. This book describes in some detail the process of creating Web applications, but it is not meant to be a complete process handbook. The process of developing software is such a large topic that the vast majority of the material in it would have very little Web application杝pecific material. Instead of creating a complete process manual for Web application development, I decided to create a book that introduces the basics of the process, just enough to set the context for the Web application杝pecific discussions.[4] In this way, you can identify and understand the important aspects of Web application development without its being tied too closely to a specific software development process. This separation of Web application development material from the process makes it easier for those with specialized and customized development processes to use the material in this book. [4] For a book that details the process specifically for J2EE enterprise applications, see Peter Eeles, Kelli Houston, and Wojek Kozaczynski, Building J2EE Applications with the Rational Unified Process (Boston, MA: Addison-Wesley, 2002).

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.