UML 2.0 in a Nutshell

Modeling

It should go without saying that the focus of UML is modeling. However, what that means, exactly, can be an open-ended question. Modeling is a means to capture ideas, relationships, decisions, and requirements in a well-defined notation that can be applied to many different domains. Modeling not only means different things to different people, but also it can use different pieces of UML depending on what you are trying to convey.

In general a UML model is made up of one or more diagrams. A diagram graphically represents things, and the relationships between these things. These things can be representations of real-world objects, pure software constructs, or a description of the behavior of some other object. It is common for an individual thing to show up on multiple diagrams; each diagram represents a particular interest, or view, of the thing being modeled.

Diagrams

UML 2.0 divides diagrams into two categories: structural diagrams and behavioral diagrams. Structural diagrams are used to capture the physical organization of the things in your system—i.e., how one object relates to another. There are several structural diagrams in UML 2.0:

Class diagrams

Class diagrams use classes and interfaces to capture details about the entities that make up your system and the static relationships between them. Class diagrams are one of the most commonly used UML diagrams, and they vary in detail from fully fleshed-out and able to generate source code to quick sketches on whiteboards and napkins. Class diagrams are discussed in Chapter 2.

Component diagrams

Component diagrams show the organization and dependencies involved in the implementation of a system. They can group smaller elements, such as classes, into larger, deployable pieces. How much detail you use in component diagrams varies depending on what you are trying to show. Some people simply show the final, deployable version of a system, and others show what functionality is provided by a particular component and how it realizes its functionality internally. Component diagrams are discussed in Chapter 5.

Composite structure diagrams

Composite structure diagrams are new to UML 2.0. As systems become more complex, the relationships between elements grow in complexity as well. Conceptually, composite structure diagrams link class diagrams and component diagrams; they don't emphasize the design detail that class diagrams do or the implementation detail that composite structures do. Instead, composite structures show how elements in the system combine to realize complex patterns. Composite structures are discussed in Chapter 4.

Deployment diagrams

Deployment diagrams show how your system is actually executed and assigned to various pieces of hardware. You typically use deployment diagrams to show how components are configured at runtime. Deployment diagrams are discussed in Chapter 6.

Package diagrams

Package diagrams are really special types of class diagrams. They use the same notation but their focus is on how classes and interfaces are grouped together. Package diagrams are discussed in Chapter 3.

Object diagrams

Object diagrams use the same syntax as class diagrams and show how actual instances of classes are related at a specific instance of time. You use object diagrams to show snapshots of the relationships in your system at runtime. Object diagrams are discussed as part of class diagrams in Chapter 2.

Behavioral diagrams focus on the behavior of elements in a system. For example, you can use behavioral diagrams to capture requirements, operations, and internal state changes for elements. The behavioral diagrams are:

Activity diagrams

Activity diagrams capture the flow from one behavior or activity, to the next. They are similar in concept to a classic flowchart, but are much more expressive. Activity diagrams are discussed in Chapter 9.

Communication diagrams

Communication diagrams are a type of interaction diagram that focuses on the elements involved in a particular behavior and what messages they pass back and forth. Communication diagrams emphasize the objects involved more than the order and nature of the messages exchanged. Communication diagrams are discussed as part of interaction diagrams in Chapter 10.

Interaction overview diagrams

Interaction overview diagrams are simplified versions of activity diagrams. Instead of emphasizing the activity at each step, interaction overview diagrams emphasize which element or elements are involved in performing that activity. The UML specification describes interaction diagrams as emphasizing who has the focus of control throughout the execution of a system. Interaction overview diagrams are discussed as part of interaction diagrams in Chapter 10.

Sequence diagrams

Sequence diagrams are a type of interaction diagram that emphasize the type and order of messages passed between elements during execution. Sequence diagrams are the most common type of interaction diagram and are very intuitive to new users of UML. Sequence diagrams are discussed as part of interaction diagrams in Chapter 10.

State machine diagrams

State machine diagrams capture the internal state transitions of an element. The element could be as small as a single class or as large as the entire system. State machine diagrams are commonly used to model embedded systems and protocol specifications or implementations. State machine diagrams are discussed in Chapter 8.

Timing diagrams

Timing diagrams are a type of interaction diagram that emphasize detailed timing specifications for messages. They are often used to model real-time systems such as satellite communication or hardware handshaking. They have specific notation to indicate how long a system has to process or respond to messages, and how external interruptions are factored into execution. Timing diagrams are discussed as part of interaction diagrams in Chapter 10.

Use case diagrams

Use case diagrams capture functional requirements for a system. They provide an implementation-independent view of what a system is supposed to do and allow the modeler to focus on user needs rather than realization details. Use case diagrams are discussed in Chapter 7.

Views

While not strictly part of UML itself, the concept of views of a system helps the modeler choose diagrams that help convey the correct information depending on his goals. Specifically, models are often divided into what is called the 4+1 views of a system. The 4+1 notation represents four distinct views of a system and one overview of how everything fits together. The four views are:

Design view

The design view captures the classes, interfaces, and patterns that describe the representation of the problem domain and how the software will be built to address it. The design view almost always uses class diagrams, object diagrams, activity diagrams, composite structure diagrams, and sequence diagrams to convey the design of a system. The design view typically doesn't address how the system will be implemented or executed.

Deployment view

The deployment view captures how a system is configured, installed, and executed. It often consists of component diagrams, deployment diagrams, and interaction diagrams. The deployment view captures how the physical layout of the hardware communicates to execute the system, and can be used to show failover, redundancy, and network topology.

Implementation view

The implementation view emphasizes the components, files, and resources used by a system. Typically the implementation view focuses on the configuration management of a system; what components depend on what, what source files implement what classes, etc. Implementation views almost always use one or more component diagrams and may include interaction diagrams, statechart diagrams, and composite structure diagrams.

Process view

The process view of a system is intended to capture concurrency, performance, and scalability information. Process views often use some form of interaction diagrams and activity diagrams to show how a system actually behaves at runtime.

The four distinct views of a system are brought together with the final view:

Use case view

The use case view captures the functionality required by the end users. The concept of end users is deliberately broad in the use case view; they include the primary stakeholders, the system administrator, the testers, and potentially the developers themselves. The use case view is often broken down into collaborations that link a use case with one or more of the four basic views. The use case view includes use case diagrams and typically uses several interaction diagrams to show use case details.

Notes

UML provides a catchall element, or note, for adding information to your diagram. The note symbol is a dog-eared rectangle with an optional dashed line to link it to some element. Figure 1-1 shows a simple note.

Figure 1-1. A simple note

In general, you can use notes to capture just about anything in your diagram. Notes are often used to express additional information that either doesn't have its own notation or would clutter a diagram if you drew it right on the element. Some tools allow you to embed URL links in notes, providing an easy way to navigate from one diagram to the next, or to HTML documents, etc.

Classifiers and Adornments

The basic modeling element in UML is the classifier. A classifier represents a group of things with common properties. Remember, at the level of classifier, we are discussing UML itself, not a particular system. So, when we say a class is a classifier, we mean that classes are things that have common properties: methods, attributes, exceptions, visibility, etc. A specific class, such as Automobile, isn't a UML classifier; it's an instance of a classifier, or a class.

Tip

For the truly self-abusing, this is a glimpse into the UML meta-model. The full metamodel is quite complex and begins with the UML infrastructure specification.

A classifier's generic notation is a rectangle that can be divided into compartments to show classifier-specific information, such as operations, attributes, or state activities. However, many UML classifiers such as states, activities, objects, etc., have custom notations to help distinguish them visually.

A classifier can have several types of extra information attached to it via a UML mechanism called adornments . For example, classifiers can have restrictions placed on the values a feature of the classifier can take. In general, constraints are written near the classifier or in an attached note. See the specific diagram types for details on what notation to use for a constraint when writing it near the classifier.

Another type of adornment is a stereotype. Just as you would expect, a stereotype is intended to give the reader a general idea of what a particular classifier represents. Stereotypes are usually associated with implementation concepts, such as «transactional» or «singleton», though that isn't required by the UML specification.