The Unified Modeling Language

The Object Management Group (OMG) adopted UML (version 1.0) in November 1997 (the most current release, version 1.4, was adopted in February 2001). This was a remarkable, unprecedented event because it marked the acceptance of a standard modeling language based on the best current practices for the analysis, design, and development of object-oriented software.

UML sprang from the combined efforts of the “three amigos”: Grady Booch with his Booch method, James Rumbaugh with his Object Modeling Technique (OMT), and Ivar Jacobson with his Object-Oriented Software Engineering (OOSE) method. As mentioned earlier, some of the terminology and philosophy found in the Synergy Process is based on Jacobson's Objectory Process (later to be called Rational's Unified Process).

Beginning in 1994, under the auspices of Rational Software, UML began to take shape. Although UML clearly reflects the three amigos' combined approaches, it also includes the best practices of many others. Other contributions include insights from such organizations as Hewlett-Packard, IBM, and Microsoft, as well as other industry practitioners, such as Shlaer/Mellor, Coad/Yourdon, and Martin/Odell. UML was also submitted as a formal response to the OMG's Request for Proposal (RFP) for a standard object-oriented modeling notation.

The ramifications of the OMG's adoption of UML cannot be overestimated. Those of us who grew up in the Structured Analysis and Structured Design (SA/SD) world had numerous diagramming notations from which to choose and several software process models to apply. Wouldn't it have been wonderful if the likes of Ed Yourdon, James Martin, and Tom DeMarco, to name a few, had sat down one day in the late 1970s and agreed to put aside any and all egos and adopt one notation for the SA/SD approach to software development? Had there been only one way to express the application domain, many organizations would have benefited significantly. Not only would all of the organization's models have been similar, but also an individual moving from company to company or from application domain to application domain would have had a common notation as a baseline.

UML, then, is the first notation that has garnered consensus among most practitioners, software vendors, and academics as the de facto standard for expressing a business domain of the accompanying software solution.

The Place of UML in a Software Process

UML is not a software process model or a systems development methodology; it is a notation, a mechanism to “pen the problem” in such a way as to uncover the essence of an application domain. The combination of UML with a sound process model (Rational's Unified Process, Ernst and Young's Fusion, or the Synergy Process presented in this book) results in a powerful combination for building successful applications.

The goal of UML is twofold: One aim is to provide consistency in giving feedback to the project sponsor that the problem domain is well understood. The other is to provide a consistent model for proper software implementation. However, if you attempt to use UML without a sound process model and project plan (discussed throughout this book and fully presented in the appendices), your project will fail.

All of the artifacts that UML delivers are traceable. If developed in conjunction with a sound process, like the Unified Process, the UML models will build on one another. This element of traceability is key to the project. With UML, the project will not only produce less useless and “go-nowhere” deliverables, but it will serve as a checkpoint of the previous model's soundness. Because the UML models are interlocked in their creation, identifying when a component is missing or potentially incorrect is easier.

Some artifacts used in this book are not UML diagrams, nor are they covered in the Unified Process. As is explored later in the book, UML doesn't directly address some aspects of a project, including these:

• Graphical user interface (GUI)

• Process distribution

• Data distribution

In all cases, though, the information needed from these vital areas is based on knowledge gained from the UML diagrams. For example, one artifact useful in distributed systems is the object/location matrix. This matrix details geographically interested locations in the domain and assesses the kind of usage that they perceive for the objects in the system. Its input consists of the classes identified on the class diagram and the locations uncovered in the use-cases. Again, all artifacts must be traceable; otherwise, they aren't worth creating.

The Essence of Modeling

A key benefit of modeling is that it provides a communication pipeline for project team members. Without sound models, team members render their knowledge of the system from their own perspectives. A project can't tolerate individualized perspectives of, for example, requirements. If it did, the project would end up not meeting “perceived” requirements. And regardless of what the project charter says, the project team would be blamed for not meeting someone else's agenda.

Booch says that modeling should accomplish the following four goals:

All of these goals echo the common theme of maintaining good communication. Without good communication, the project will fail. UML meets these goals, and more.

The UML Diagrams

UML consists of nine different, interlocking diagrams of a system:

The package diagram is also an important diagram in UML, but not one of the nine key diagrams. It was formerly called the subsystem diagram in other notations and can contain any and all of the diagrams listed here.

The diagrams are evolutionary in their construction. Nevertheless, they are merely different views of the domain. Because people have different backgrounds in modeling, categorizing the diagrams according to multiple perspectives can be helpful. (Figure 1-11 maps the nine diagrams to the five views of the software architecture, to be discussed shortly, for a given project.) The nine diagrams are divided into three categories: static, dynamic, and architectural.

A static diagram depicts the system's structure and responsibilities. Static diagrams are similar to the building contractor's “as-built” drawings, which depict multiple subsystems, all interacting within the framework of the physical structure. The static diagrams are

• Class

• Object

• Use-case

A dynamic diagram depicts the live interactions that the system supports. Dynamic diagrams detail the interaction among structural artifacts from the static diagrams (classes). These dynamic interactions are discovered in the use-cases as pathways performed in response to an external system stimulus. Dynamic diagrams also provide a much clearer picture of the intended, realized behavior of the system. The dynamic diagrams are

• Activity

• Collaboration

• Sequence

• State

• Use-case

An architectural diagram categorizes the system into running and executable components. Architectural diagrams also distinguish the physical location of execution and storage nodes and a framework within which they can interact. They often are produced very early in the project (e.g., during project scoping) to indicate the intended physical architecture. They are further detailed during the Construction and Transition phases to clarify early assumptions that will be physically implemented. The architectural diagrams are

• Component

• Deployment

UML and the 4+1 View of Architecture

An interesting perspective of a project's architecture and the UML modeling artifacts used to describe the system comes from the “4+1” view of software architecture. Developed by Philippe Kruchten and covered in his book The Rational Unified Process: An Introduction (published by Addison-Wesley), this view involves, in fact, five different views, as illustrated in Figure 1-11:

• Use-case

• Logical

• Implementation

• Process

• Deployment

The use-case view describes the functionality that the system should deliver as perceived by the external “actors and the requirements of the system. Intended for users, analysts, designers, developers, and testers, the use-case view is central to all the other views because its contents drive the development of the other views. The use-case should be technology neutral, contain no object-speak, and focus on the what rather than the how of the system solution.

The logical view describes how the system functionality is provided. Intended mainly for designers and developers, it looks inside of the system, in contrast to the more macro use-case view. It describes both the static structure (classes, objects, and relationships) and the dynamic collaborations that occur when objects send messages in response to an external or internal event.

The implementation view describes the implementation modules and their dependencies. The modules can provide for cross-checks back to the other deliverables to ensure that all requirements are eventually actualized into code. It is mainly for developers and consists of the component diagram.

The process view (also called the concurrency view) describes the division of the system into processes and processors. This division allows for efficient resource usage, parallel execution, and the handling of asynchronous events. Intended for developers and integrators, it consists of the state, sequence, collaboration, and activity diagrams, as well as the component and deployment diagrams.

The deployment view describes the physical deployment of the system via the component and deployment diagrams. Developers, integrators, and testers utilize this view.

Using the UML Diagrams in Context

Although nine diagrams might seem a bit overwhelming, not every project will use all of them. For example, many projects might not require state or activity diagrams. A state diagram is used to model the lifecycle of instances of one class, and then only when that class exhibits complex or interesting dynamic behavior. Such classes are prevalent in embedded real-time applications but are not as common in business-oriented applications. Activity diagrams are useful for modeling complex steps within a use-case or an operation found in a class.

Other diagrams offer complementary views of the same thing, such as those found in the sequence and collaboration diagrams. Actually, many visual modeling tools allow you to create the collaboration diagram from the sequence diagram.

In practice, projects will always produce the following diagrams at a minimum:

• Class/collaboration

• Sequence

• Use-case

Projects would also be well served if they produced component and deployment diagrams. In my consulting work, I have encountered the recurring problem of the project team's not taking enough time to visualize and model the design's physical realization. The team assumes a cavalier attitude toward component assembly and, more importantly, the assignment of components to actual processors. Often the requirements are realized and the design is elegant, but response times are poor or ongoing issues of component distribution affect the application's supportability. Many of these issues can be resolved by the use of rich and expressive syntax of the component and deployment diagrams.

This book offers hints regarding when to apply which diagrams. It also stresses the importance of traceability between the diagrams. Early in my career, success as an analyst or designer depended on the weight and thickness of the requirements and design documents. I would like to think that after finishing this book, you will know better when to use which diagrams and will end up with project documentation that is as light as possible and yet complete.