Other UML Diagrams

The UML contains several additional types of diagrams. And after the Object Management Group (www.omg.org/uml/) ratifies version 2.0 of the UML late in 2004, it will include several more (for the full list, see Chapter 1, “Introduction to the UML”). Although each diagram provides value, people use some of them more often than others. We focused the majority of this book on what software development teams have told us they most commonly use and the corresponding model elements so that you will be most familiar with those subjects and best able to communicate with your teams who are modeling with the UML.

In some cases, the diagrams covered so far in this book are appropriate for use by specific people and roles in an organization, such as developers, business analysts, and database designers, and in other cases, they are appropriate for the task at hand and are used by multiple groups in the organization. This section focuses on the “best of the rest”—which fall into both of the previous categories but primarily are used across different roles. These diagrams include statechart diagrams, collaboration diagrams, and object diagrams. We will explain what they consist of and how and when you would use them. These diagrams are valuable, but not as frequently used as the other diagrams discussed throughout the rest of this book.

Statechart Diagrams

A state is a condition during the life of an object or interaction during which it satisfies some condition, performs some action, or waits for some event. An object is an instance of a class. An object can move through many different states. An object can do any or all of the following in any specific state:

• Perform an activity (see Chapter 2, “Business Modeling,” for details on activity modeling)

• Wait for an event

• Satisfy one or more conditions

Statechart diagrams (known as “state machine diagrams” in UML 2.0) model the dynamic behavior of individual objects or any other instance of a modeling element. They show the sequences of states that an object goes through, the events that cause a transition from one state to another, and the actions that can result from a state change. (In UML 2.0, this type of state machine is known as a behavioral state machine. There are also protocol state machines, which depict how an object can be used by specifying the conditions and states in which the object's various methods can be called.)

Statechart diagrams are closely related to activity diagrams. The main difference between the two is that statechart diagrams focus on an object's state, whereas activity diagrams focus on the flow of activities to be performed. Typically, you use a statechart diagram to model the discrete stages of an object's lifetime, whereas you use an activity diagram to model the sequence of activities in a process. So, what does this really mean? You generally use a statechart diagram to model objects and the transitions between objects, based on the system and software design. Quite often, the state transitions are time-based. Activity diagrams are more business-like, and people often use them to describe a flow of events for satisfying a business process. Chapter 2 provides detail on activity diagrams and their usage.

Each state in a statechart diagram represents a named condition or state that occurs during an object's lifetime that satisfies some condition or waits for some event to occur. A 4 contains one start state and one or more end states. As with activity diagrams, statechart diagrams also can include decisions, synchronizations, and activities. [RATR1]

In the UML, you model a state as a rectangle with corners that are rounded off, as shown in Figure 8-1.

A state's name can contain letters, numbers, and punctuation marks (except for a colon, which in the UML describes separation between an element's name and its type). It can consist of multiple lines of text. In addition, a state's name should be descriptive. For example, if your statechart diagram describes how an automobile transmission works, it would be appropriate to name the states First Gear, Second Gear, Reverse, and so forth.

States are connected using relationships called transitions and transition descriptions called events. An event can cause a transition from one state to another. In an “event/action” pair, the action describes what is done in response to an event. Figure 8-2 shows an example of what a partial statechart diagram for an automobile transmission might look like. The transitions are the lines with arrows as in those connecting the first gear to second gear states, and the descriptions on those transitions, Upshift and Downshift, are the events.

As with an activity diagram, a statechart diagram contains a starting point, which begins the transition to a state. Unlike an activity diagram, a statechart diagram can contain several substates each with a starting point. A substate (or “nested state”) is one state that is nested within another state.

You can nest states to any depth in a statechart diagram A nested state is a state that takes part in and is embedded as part of another state, but it cannot be achieved without first satisfying the enclosing states, which are referred to as superstates. Everything that lies within the bounds of a superstate is the state's content. Figure 8-3 shows a statechart diagram similar to the one in Figure 8-2. However, the statechart diagram in Figure 8-3 includes additional states, substates, and superstates using nesting. Forward and Reverse are substates nested within the state of Movement. You will also see a transition whose description reads “transition to self,” which means exactly what it says—the state transitions to itself. In this example, the Movement state transitions from one direction to another (i.e., Forward and Reverse).

People usually use statechart diagrams to model real-time and embedded systems where architects and developers need to design the event-driven behavior of those systems. For instance, the telecom industry would use a statechart diagram for real-time embedded system development to show different switches reacting to network conditions. In such a scenario, the analyst or designer would need to determine timings, on and off activation, message sharing, and other events. If the developer didn't understand exactly when these events were to occur, he would find it difficult to develop software that could manage these systems, which require such precise actions.

Collaboration Diagrams

The UML contains two types of interaction diagrams. We discussed the first type, sequence diagrams, in Chapters 3, 4, and 7. The other type of interaction diagram is a collaboration diagram.

A collaboration diagram shows how objects interact and how they are organized. It also shows the links between those objects. Of all the diagrams in the UML, the collaboration diagram is one of the least complicated.

Figure 8-4 shows how the price of an order is calculated using the three basic elements of a collaboration diagram:

• Objects

• Links

• Messages (shown as text on a link)

You can create multiple messages on one link, and each message is numbered based on the order in which it will be executed. Figure 8-4 demonstrates this by showing that a product is added to an order before the order price is calculated.

Object Diagrams

An object diagram is a snapshot of the objects within a system at a particular point in time. Because an object diagram shows instances instead of classes, people sometimes refer to it as an instance diagram. Unlike a class, which shows attributes to further describe itself, an object uses values for the attributes in its definition, such as describing the attribute of “phoneNumber” with actual numbers rather than just the attribute name of phoneNumber. Figure 8-5 shows an object diagram. [BOOCH1] (Note that an object “Joe” of class “Customer” is shown as “Joe:Customer”.)

Although object diagrams aren't as popular as class diagrams, they do provide value to people who need to understand how the objects actually will exist when the software is executing. An object diagram helps the developer understand what type of data he can capture in the system because it defines not only the attributes, but also their values. Furthermore, a database team can understand the data, enabling them to determine data types as well as how to optimize for that data. You can more easily do validation with customers when you can point to not only the objects that are being created but also to expected data to be captured and their relationships. This provides a nice way to ensure you are building what the customer expects.