Concurrent State Diagrams

In addition to states of an order that are based on the availability of the items, there are also states that are based on payment authorization. If we look at these states, we might see a state diagram like the one in Figure 8-4.

Figure 8-4. Payment Authorization

Here we begin by doing an authorization. The "check payment" activity finishes by signaling that the payment is approved. If the payment is OK, the given order waits in the Authorized state until the "deliver" event occurs. Otherwise, the order enters the Rejected state.

The Order object exhibits a combination of the behaviors shown in Figure 8-1 and Figure 8-2. The associated states and the Cancelled state discussed earlier can be combined on a concurrent state diagram (see Figure 8-5).

Figure 8-5. Concurrent State Diagram

Note that in Figure 8-5, I left out details of the internal states.

The concurrent sections of the state diagram are places in which at any point, the given order is in two different states, one from each diagram. When the order leaves the concurrent states, it is in only a single state. We can see that an order starts off in both the Checking and Authorizing states. If the "check payment" activity of the Authorizing state completes successfully first, the order will be in the Checking and Authorized states. If the "cancel" event occurs, the order will be in only the Cancelled state.

Concurrent state diagrams are useful when a given object has sets of independent behaviors. Note, however, that you should not get too many concurrent sets of behaviors occurring in a single object. If you have several complicated concurrent state diagrams for an object, you should consider splitting the object into separate objects.