|
|
|
|
|
Keeping Your Sanity with UML The Unified Modeling Language (UML) is a notation for expressing object-oriented concepts, and the interactions of system components. With the release of UML version 2.0 in July 2005, this de facto standard for modeling object-oriented concepts achieved a new level of complexity. Groups that had been following the nine diagrams in UML version 1 now found subtle changes in semantics, name changes to familiar diagrams, and four new diagrams. Groups new to UML were presented 13 diagrams of diverse syntax and semantics, and little information on where to begin, or how to profitably produce, these diagrams. When confronted with an industry standard like UML 2, it is too easy to presume that a software project should use all of the standard in order to be in correct compliance. Fortunately, this is not a requirement for success with UML. Not every project needs even most of UML, and most projects require more than UML offers. The main criterion for adding UML diagramming to your project artifacts is that a given diagram will move your project forward. Many practitioners of UML use only a “sane subset” of UML on most projects. This paper presents this group of core UML diagrams, a brief explanation of each, and a discussion of the value that diagram provides. UML 2 Overview UML 2 consists of 13 diagrams divided into two categories: structural diagrams, and behavioral diagrams. Structural diagrams illustrate the static aspects of a system: what classes are in the system, how objects are related, and the major groupings of elements in your discourse about your project. The behavioral diagrams illustrate the dynamic aspects of a system: how it acts over time. These diagrams denote how objects interact to accomplish the goals of the system, the state spaces in which objects spend their lives, how users interact with system services, and more. UML 2 defines 6 structural diagrams:
and 7 behavioral diagrams:
Details on all of these diagrams, and much more in UML, can be found at www.omg.org, or go directly to www.uml.org. There you will find the latest specifications on UML. These specifications come in two separate, and very formal, documents. The UML Infrastructure Specification defines the basic and low-level syntax and semantics of the foundational elements in UML. The Infrastructure Specification is the gold standard that all UML software tool vendors must follow to assure compliance to UML, and interoperability of model files among different vendors. The UML Superstructure Specification is the one that defines the diagramming and modeling elements that human beings need to know in order to use UML profitably. Neither is an easy read. The Infrastructure Specification PDF for UML 2.1.2 is only 1.7 MB, but the Superstructure Specification weighs in at a hefty 6.1 MB. If you are a language lawyer, a UML tool vendor, or an object-oriented software consultant, you need to be familiar with, if not fluent in, both of these specifications. If you are simply interested in how to use UML for analysis and design in your project, quite a few good modeling books have been published since 2007. Search your favorite book seller and you should find several that will meet your needs. The remainder of this paper describes the most valuable UML diagrams: those that yield the biggest bang for the buck on most projects. This core set consists of the:
Class Diagram The UML class diagram is the centerpiece of most modeling efforts. The class diagram describes the major entities (i.e. classes) in the system, and the static relationships among those entities. Here is a class diagram example from an Airline Reservation domain:
The classes on this diagram are represented as rectangles. The names in these class boxes are all nouns, and that is what you will usually have, although it is possible to have special classes with special names that are verbs: e.g., Query (a class that constructs a query to a database), or Search (a class that constructs search criteria). For 99% of classes, the names are nouns. The class rectangles can contain 3 sets of information in 3 separate sub-compartments: the class name, the data members belonging to the class, and the operations (methods) that provide the class’s services to client objects. The lines and symbols between the classes represent relationships that define our business domain and many business rules. A major benefit of UML modeling is that a single diagram can efficiently and unambiguously convey information that would take many pages of text to express. The class diagram is part of the core subset of UML because the structural perspective it offers is tied to all the other core diagrams. Customers and end-users can appreciate the class diagram and learn how to read one in 30 minutes. It can be easily tailored to convey either an analysis perspective, or a design perspective. A simple analysis class diagram like the example above allows your end-users to validate your understanding of their business domain, so you and they can achieve consensus on the project goals. Developers benefit directly from constructing design-level class diagrams. Modeling tools can generate object-oriented language code from the class diagram, and the code they generate is the “scaffolding” code to support the classes, relationships and multiplicities shown on the class diagram. Every project must produce one or more class diagrams. Unfortunately, too many projects produce only the class diagram and completely ignore the benefits of the core UML behavioral diagrams which I discuss next. Sequence Diagram The sequence diagram, or SQD (pronounced “squid”), describes the interactions over time among two or more objects. In my consulting and modeling experience the SQDs are the single most important diagrams you will do on a project. The class diagram is essential, but the SQDs let you visually confirm that your classes are defined properly to carry-out the work of your system as specified in your use cases or user stories. Here is a simple SQD for a use case called Make a Reservation:
The vertical lines are called object lifelines. You will notice that the top of each lifeline is an object name, consisting of a colon “:” followed by the name of a class. The stick-figure represents an actor, in this case a user called Reservation Maker. The horizontal arrows are called messages. These messages become method calls in the system code. The text on the left margin is called the sequence diagram script. The script is usually a very terse transcription of the steps in a use case. The script can also describe one or more user stories if your project is using that requirements approach. Business analysts construct sequence diagrams to convey to developers how the major entities in the business interact with each other in various business scenarios. Developers can produce sequence diagrams to thoroughly explore the implementation classes they need, and how these classes invoke each others’ methods to produce correct system behavior. State Machine Diagram The state machine diagram describes the set of states defined for a single class, the events which trigger transitions from one state to another, and the major activities which are performed in each state. It has been around for decades under other names. The notation was developed in the 1980’s by Prof. David Harel, and has been part of UML, OMT, Booch and every other object-oriented notation. Interestingly, the Harel state diagram has been part of all major structured analysis and structured design approaches as well, yet this diagram is, unfortunately, little-used in our industry. Here is an example state machine describing the “state space” for the Reservation class in our Airline domain.
In the example the states are represented by rounded rectangles, and transitions between states are shown as arrows. The transitions are normally labeled with the event that denotes an occurrence that motivates the transition from the source state to a destination state. Within each state you can specify actions and activities that occur within the state. One of the most interesting properties of the state machine, and one of the most challenging to grasp when first learning this diagram, is its support for specifying either instantaneous or time-bound behavior. This peculiar accommodation is invaluable for designers and implementers who must decide if a function must run to completion or be interruptible. The state machine diagram benefits business analysts because it allows them to unambiguously specify events that represent business rules and constraints, and how system behavior should be partitioned across the various states in the class’s state space. Developers benefit because the state machine allows for discovery of operations (methods) in the class being modeled. In particular, state machines are a rich source of discovering private methods on the class being modeled. Activity Diagram An activity diagram is like a flowchart – but on serious steroids. Not only can an activity diagram model sequential processes, it is especially adept at showing concurrent (parallel) behavior among business entities or classes in your system. This ability to illustrate concurrency is a singular advantage of the activity diagram. Here is an example activity diagram for my Airline domain:
Activities are shown as rounded rectangles, appropriately named “lozenges”. Transitions between activities are shown as arrows. The bold bars allow you to show that one thread of control “forks” into multiple threads, or that multiple threads “join” together to form one thread. Analysts familiar with Business Process Modeling Notation (BPMN) should readily appreciate this notation, as well as the partitions that let us allocate activities to specific business units or domains. Activity diagrams are very useful for modeling interactions in business workflows involving multiple business domains acting in parallel. Developers benefit from activity diagrams as a tool to represent interacting processes or threads running concurrently. Use Case Diagram The use case diagram describes the major services provided by the system being modeled, and the external entities (i.e. actors) that interact with the system. I have listed this diagram last because it has rather limited business value on most projects, but it does offer a concise means of illustrating the major services provided by a system, and the groups of users and collaborators interacting with that system. Here is a use case diagram for our Airline domain:
The use cases are shown as simple ovals with the name of the use case inside the graphic. Actors (users and collaborators) are shown as stick figures, and a line connects each actor with the use case with which that actor interacts. The use case diagram is done normally at the beginning of a project as part of initial requirements specification. It benefits all project stakeholders by illustrating the major services in the system, as well as offering a simple specification of user categories, as well as external systems and components that will collaborate to support the goals of your system. Conclusion These five diagrams are the core UML diagrams you should consider using on your projects. The class diagram, sequence diagram and the state machine diagram are the “inner core”, if you will. I develop these on every project. The use case diagram provides benefit for organizing our thinking about users, services and external components, but is replaced rather quickly by the actual use case descriptions. The activity diagram is always ready to be used when we need to describe a specific algorithm, or when concurrency is part of our system design. When we do not have concurrency we may not need the activity diagram at all. UML is all about communication, not just drawing “lines and bubbles, or lines and boxes” as consultant Scott Ambler has quipped about UML. These five diagrams are the core for communicating your system’s goals and design to your project constituencies. But visit the UML website (www.uml.org) or read a good UML overview so you can enlist any of the other eight diagrams when you need their specific value on your project. |
|
