2.2 The Unified Modeling Language

Introducing . . . the Unified Modeling Language!

Use cases aren't a phenomenon unto themselves . They are part of a comprehensive language called the Unified Modeling Language, or UML. This language was brought into existence in January 1997 and has subsequently been adopted as a standard by the Object Management Group (OMG), an industry consortium.

The UML is a notation : a way to document system specifications. It is not a methodology, it is a language. A notation simply tells you how to structure your system documentation. It provides the nomenclature of the diagrams and specifications that you produce. A methodology , by contrast, consists of a step-by-step guide to building a system. Methodologies are much more complex and contentious. The UML is not dependent on a particular methodology, nor do methodologies need to be contingent on the UML. The UML requires only that the computer system being built has object-oriented components . In fact, several of the UML diagrams, including use cases, can be used for systems that are not based on object orientation. Methodologies that work with the UML include the Rational Unified Process, the Object Modeling Technique, the Booch method, Objectory, Schlaer-Mellor, FUSION, OPEN , and many others.

Of course, the UML did not appear magically from outer space. It was the result of collaborations between three famous object-oriented methodologists: Grady Booch, James Rumbaugh, and Ivar Jacobson (1999). The "Three Amigos," as they are called, combined their own modeling notations and also got plenty of ideas and unanimous buy-in from every other major methodologist in the industry. Through their efforts, the computer industry has a common language, ^[1] or notation, with which to specify object-oriented systems ”something this industry has never before experienced .

^[1] There is at least one other notation that we are aware of that is in competition with the UML. It is called OML or OPEN Modeling Language. The OML is part of a methodology called OPEN, or Object-Oriented Process, Environment, and Notation. OPEN and OML are being championed by Donald Firesmith, Brian Henderson-Sellers, Ian Graham, and Meilir Page-Jones ”an impressive roster to say the least. OML is billed as a "superset of the UML," however, it is likely to serve only as a set of recommendations to the OMG for future enhancements to the UML. We do not expect it to compete with the UML directly. SEE: http://www.markv.com/OPEN/

The UML is composed of nine diagrams.

• Use case diagram

• Sequence diagram

• Collaboration diagram

• Statechart diagram

• Activity diagram

• Class diagram

• Object diagram

• Component diagram

• Deployment diagram

These diagrams, used properly within the context of a solid methodology, can convey all the necessary views of a computer system and can provide the basis for constructing, configuring, and deploying the system. There are many interdependencies between these diagrams. Construction on one type of diagram means changes to others. Software tools ^[2] can help manage these interdependencies. The UML lends itself well to automated analysis and design tools and also provides many possibilities for generating code from design documentation and for reverse engineering (creating design from code).

^[2] Our favorite analysis and design tools that support the UML are MagicDraw UML, ArgoUML (an open source tool), and Rational Rose.

The UML is a well-thought-out notation that serves analysts, designers, and architects . It is comprehensive, especially when compared with earlier object-oriented notations. It is also the new standard for object-oriented systems notation, and that's the best reason of all to use it for all your documentation needs. But remember ”to be successful on your project, you must choose and implement a methodology along with the UML. Adopting the UML by itself is not enough.

This book is dedicated to explaining how use cases can solve problems in requirements gathering. It is not meant to provide a tutorial for the UML, but it is important that you understand how use cases fit into the context of the UML. Books on the UML include the following:

• The Unified Modeling Language Reference Manual (by James Rumbaugh, Ivar Jacobson, Grady Booch), Addison Wesley, 1998

• Applying UML and Patterns (by Craig Larman), Prentice-Hall PTR, 2001

• The Unified Modeling Language User Guide (by Grady Booch, James Rumbaugh, Ivar Jacobson), Addison Wesley, 1999

2.2.1 Nine Diagrams

In the following sections we take a look at the nine UML diagrams in some detail.

2.2.1.1 Use Case Diagram

Figure 2.1 shows an example of a use case diagram .

Figure 2.1. UML Use Case Diagram

Use cases, obviously, are a focus of this book. They are the driver for the rest of the diagrams. Although the UML is not a methodology and therefore does not prescribe steps, it makes the assumption that you diagram use cases before you start the other diagrams. Use cases form the basis of how the system interacts with the outside forces around it: users/actors, other systems, and other factors (date/time, special environmental conditions, and so on).

Use cases are text descriptions of the interaction between some outside actors and the computer system. Use case diagrams are graphical depictions of the relationships between actors and use cases and between a use case and another use case.

Use cases and use case diagrams should be documents that users can interpret easily. They are meant to be written in "user language," devoid of any "objectspeak" or implementation details. Inside each use case is a nice little package of requirements that effectively drives the rest of the system development process.

Use cases drive not only requirements gathering but also the entire software development cycle. Several methodologies, including the popular Rational Unified Process (RUP), are use-case-driven . Use cases have the simplicity to represent a computer system's essence, and yet they have the power to drive the entire methodology, in the process helping to solve problems such as requirements traceability.

2.2.1.2 Sequence and Collaboration Diagrams

Sequence diagrams (Figure 2.2) and collaboration diagrams (Figure 2.3) show the internal workings of a use case scenario (see Section 2.3.1.4). They present a dynamic view of a system, showing how messages pass between objects to satisfy a use case.

Figure 2.2. UML Sequence Diagram

Figure 2.3. UML Collaboration Diagram

Collaboration diagrams have the same function as sequence diagrams, but sequence diagrams are geared toward simple, linear interactions, whereas collaboration diagrams are geared toward more complex interactions such as multithreaded or conditional messaging.

2.2.1.3 State and Activity Diagrams

State and activity diagrams are also part of the dynamic view of a system. In contrast to sequence and collaboration diagrams, statecharts and activity diagrams concentrate on transition from one state to another rather than on the messages that pass between objects. State diagrams (Figure 2.4) are generally used for simpler state transition views and activity diagrams (Figure 2.5) are used for more complex views.

Figure 2.4. UML State Diagram

Figure 2.5. UML Activity Diagram

2.2.1.4 Class and Object Diagrams

Although the previous diagrams show the dynamic view of a computer system, class diagrams are geared toward the static view. Class diagrams (Figure 2.6) show how classes are constructed and list their names , attributes, and operations. They also show how classes are related to one another statically, using associations such as generalization and aggregation.

Figure 2.6. UML Class Diagram

Object diagrams show the relationships among objects , which are the instances created at runtime from the class templates. The structure of an object diagram is similar to that of a class diagram except that the focus is on the runtime instantiations of the classes.

2.2.1.5 Component Diagram

Component diagrams (Figure 2.7) help move the system from a collection of fine-grained objects to a collection of coarser-grained components, and they help show how these components relate to one another.

Figure 2.7. UML Component Diagram

2.2.1.6 Deployment Diagram

Deployment diagrams (Figure 2.8) show how components of the system will be deployed to different physical nodes, or machines, in the production environment.

Figure 2.8. UML Deployment Diagram

2.2.1.7 Packages

Another convenient UML mechanism is the package metaphor. Packages are a way to hide complexity. They can be used with use cases, classes, components, or deployment nodes. For more information on packages, see The Unified Modeling Language User Guide (Booch 1999). Figure 2.9 shows a UML package diagram.

Figure 2.9. UML Package Diagram

2.2.2 Extending the UML with Stereotyping

We hope that the UML will last for years and years . But how can a modeling language last in the computer field, where the only constant is change? And how can this general-purpose language be useful for each specific situation, when circumstances may require new types of elements or diagrams?

The UML addresses these issues with a feature called stereotypes . Stereotyping lets you extend the UML to represent new types of abstractions or concepts. Stereotyping is extremely powerful and enables you to customize the UML for your project. It also means that the UML will not go out of date as quickly as most modeling languages because it can be adapted to handle the changes it faces.

What are stereotypes ? Stereotypes are a way to classify UML building blocks (or elements) in a more specific way to add meaning to a diagram. Stereotypes let you group characteristics that are common among several use cases, for example, and thereby change the specification of a use case to a more specialized form, perhaps a mission-critical use case. The mission critical stereotype might specify that a requirement of all use cases of this stereotype is that they respond to the actor within three seconds on each interaction.

In addition to use cases, all other UML elements ”components, nodes, associations, and objects ”can be stereotyped. The most common UML element to be stereotyped is classes.

The UML has several built-in stereotypes. For example, on the use case diagram, associations between use cases are stereotyped as includes or extends to show special kinds of associations that are unique to the use case diagram.

This book uses several kinds of stereotypes to increase the relevance of use cases to requirements gathering. We discuss these stereotypes in later chapters.

Stereotypes can be introduced by anyone who uses the UML, including individual practitioners . For the purposes of this book, we use stereotyping to help clarify the concepts we are introducing. (You can read more about our new stereotypes in Section 3.8.2.)

In the sample use case diagram in Figure 2.10, the Enter Tenant Details use case is classified with the stereotype mission critical . This means that all use cases marked with this stereotype must meet certain criteria; in this case, the transaction must be secure and must have less than a ten-second response time. The definition for mission critical might be specified in a separate document that addresses all stereotypes.

Figure 2.10. UML Stereotypes