The State Diagram

Of the UML diagrams, the state diagram has probably been around the longest. Its initial uses had nothing to do with object-oriented concepts. In the design and development of complex integrated circuits, a model was needed that minimized the complexity of the various states in which the system could exist at any specified moment in time. More importantly, the model needed to show the events to which the system responded when in a given state, and the type of work to be performed when the system changed states.

The state diagram can be a valuable tool. Today we use state diagrams to model the lifecycles of one class (although UML also supports the notion of sending events to other classes while modeling a class as to state). Think of the state diagram as the model that follows an object from birth to death (its final conclusion). As mentioned previously, many classes are uninteresting concerning state.

For example, most of Remulak Productions' classes are rather mundane regarding their various states. Consider Customer. What states could it be in? Maybe prospective, active, and inactive? Could we learn very much about the domain of Customer by modeling it in a state diagram and observing the work that the system needs to carry out as an object makes the transition from state to state? Probably not.

The Order class is a little different. An Order object will go through many different states in its lifetime and will be influenced by many dif ferent events in the system. In addition, quite a bit of work needs to be done as an Order arrives at a given state, stays in a given state, and finally moves on to another state. In this section, we create a state diagram for the Order class, modeled for Remulak Productions.

In its simplest form, a state diagram consists of a set of states connected by transition lines (the subtleties of nested states and concurrent models are outside the scope of this book). On each transition line are captured (usually) events that stimulate an object to move from one state to another. In addition, work also occurs during a transition (when the object enters or exits a state) and while the object stays in a given state. This work takes the form of actions (uninterruptible tasks) and activities (interruptible tasks). Finally, a state diagram can capture state variables that are needed for implementing the diagram (we don't do this for our example).

The steps for modeling the state of a class are quite straightforward:

Not all classes warrant a state diagram—for example, those in most business-oriented applications. (Although this conclusion is a very broad generalization, I have found it to be fairly consistent.) The following are some of the types of classes that usually warrant further exploration with a state diagram:

• A class that takes on the role of “controller” (it might be quite dynamic in nature)

• A class that appears to generate and/or receive high volumes of messages (as identified by the sequence or collaboration diagram)

• A class that takes on the role of “interface” (such as an interface that represents a facade to a complex subsystem)

• A class that has many different states that the domain is interested in capturing and that are relevant to the context of the application

Modeling the State Diagram of the Remulak Order Class

Figure 7-12 shows the state diagram for the Remulak Productions Order class. We can learn much from this state diagram. The event “Initiate order” gets the ball started. It then moves the Order object to the “Empty Order” state. Upon entry, the system must perform an action: “initialize order.” Table 7-1 depicts the different types of work that can be performed and the different ways to model them.

As soon as the first line item has been added (“Add item(1)”) the Order object moves to the “Adding Body” state. Notice that there is a self-transition back to the same state as additional items are added (“Add item(n)”). Next note that we use a guard condition: “[no more items].” Recall from the earlier discussion about the sequence diagram that a guard condition is a means to show condition checking and branching. The authors of UML kindly used similar syntax constructs across many of the models.

Next if the credit check fails (“[credit failed]”), a special format is used to communicate with another object: ^Customer.reject. This is an event directed to the given Order object's Customer object. This is the UML mechanism for signaling other objects while modeling the state of another class.

Note, too, how the Order object eventually falls off the “radar screen”; that is, it reaches the final state, as noted by the bull's-eye in the figure. Assuming all goes well, once the guard condition is met (i.e., 60 days have transpired since shipment), the Order reaches its final state and will be purged. (The object also can reach its final state by being rejected because of bad credit.)

Modeling a class with a state diagram reveals the following:

• Many of the events will result in the modeling of operations in the class.

• All work (actions and activities) will result in the modeling of operations in the class. Many of the operations will be private to the class.

• All messages to other objects (^Class.event) will result in an operation's being defined on the target class.

• Any state variables identified will end up as member variables in the class that is being modeled. However, many of the variables will not be persisted during a single use of the system. Their purpose might be only to sustain a given state.

Alternative View of State Diagrams

A state diagram can be viewed in an alternative way: as a table. Al though not an official UML view, the table represents the same information. Some practitioners prefer the table to a state diagram, especially when the state diagram is very complex and therefore becomes difficult to read. Table 7-2 is a table form of the state diagram in Figure 7-12.

The table form also is a great way to document the dynamic nature of the Java screens that will implement the user interface. The big difference is that the events are very user interface oriented (button-clicked) and the actions are geared to the user interface (e.g., load list box or disable text field).