Creating State Diagrams from Scenarios

One other way to build your state diagrams is to check your sequence diagrams to see which events are important to the more dynamic objects in your system. You see whether a sequence diagram shows one object sending an event to another—and whether a second object, stimulated by that incoming event, must make a transition from its present state to another state.

To illustrate the process of creating a state diagram from a sequence diagram, consider an example from the retail air-filter order system. Order clerks interact with the order-entry system to review customer accounts.

Figure 16-3 illustrates a scenario interaction between Jim (an instance of Order Clerk), the account reviewer, and myDB (an instance of the DatabaseAccessor class). You notice that we have inserted thin vertical oval shapes into the diagram. These ovals are not part of UML. We placed them on the diagram to show you where the AccountReviewer object is in some state. Each incoming event causes the object to transition to a new state. Each oval corresponds to a state in Figure 16-4.

Figure 16-3: Sequence diagram for reviewing an account.

Figure 16-4: A state diagram for the Account Reviewer clas.

You can use the following process to create a state diagram from a sequence diagram:

Look at your sequence diagram and choose objects for which you want to build a state diagram.

Look for those objects that have a lot of events going into them. They have the most state transitions. So, we have to diagram them in order to understand their life cycle. For example instances of the AccountReviewer class receives a lot of events.
As always, start with placing an initial state in the upper left-hand corner of your new state diagram.
Get things started by adding a wait state.

This state will wait for the first event of your sequence diagram to arrive. Draw a simple transition line from the initial state to the wait state. You don’t have to name this transition because it represents a completion transition. (A completion transition happens automatically after a state completes its behavior. See Chapter 17 for more information.)
Find incoming events.

Look at the object lifeline (the dashed line) on the sequence diagram of your chosen object. Each event that comes into that object becomes an event transition in your state diagram.
Locate an event pair, which consists of an incoming event and the next incoming event.

You look at the first and second events that come into your object. It doesn’t matter where these events come from, whether from one or two other objects. In our example, Jim the order clerk sends the review event to the account reviewer. The second incoming event is customer(name).
Determine what your object is doing in response to the first incoming event.

Ask yourself, What is this object doing between the time it received the first event and the time it receives the next incoming event? Think of a name that captures this behavior of the object at this time.

In our example using Figure 16-3, the : AccountReviewer sends the customer event to Jim : Order Clerk. Then the : AccountReviewer waits for Jim : Order Clerk to return the name of the customer they are interested in reviewing. At about the same time, the : AccountReviewer object is creating and instance of the DatabaseAccessor class called myDB. We choose the name Wait for Customer Request because the : AccountReviewer is waiting for a request to review a specific customer.
Place a new state on the diagram

Give it the name you came up with in Step 6. In our example, you would add the Wait for Customer Request state to your diagram.
Draw a transition with the name of the first incoming event between your wait state and the new state you just placed on the diagram.

In our example, you add a transition line between the Waiting state and the Wait for Customer Request state. Then you give this transition the same name as the incoming event: review.
Add transitions and states:

In this step, you perform Steps 5, 6, 7, and 8 for each pair of incoming events. You take the second incoming event and pair it up with the third incoming event, assess the state, draw the next state, and show the second incoming event name as the transition between the previous state and the next state. The next pair of incoming events you look at is customer(name) and found(Customer).

The account reviewer is looking up the customer matching the name that comes from the database. It looks like the state is Finding Customer. The transition from Wait for Customer Request to Finding Customer is named customer(name).
Consider the last transition.

Your object ends up in some state after the last incoming transition. That state is often the final state (or the first wait state you placed in the diagram). Ask yourself, What happens to my object’s life after the last incoming transition? If it’s finished, then place a transition that leads to a final state. If your object starts all over again, then draw a transition that leads back to the first wait state. The account reviewer returns to its original wait state to wait for a clerk to ask it to review another customer account.

By following this procedure for converting a sequence diagram to a state diagram, we obtained the diagram in Figure 16-4. Notice that each transition has the same name as an incoming event on the sequence diagram (shown in Figure 16-3). The state names indicate what the account reviewer is doing as a result of the incoming event.

Remember Sequence diagrams help you develop state diagrams for objects that have a lot of incoming events.

You can start a state diagram based on one sequence diagram that contains our object of interest. Then you should look at the other scenarios that the object participates in, examine their sequence diagrams and determine how our object behaves differently in each alternative sequence. Ask yourself the following questions: Does the object receive different incoming events? Does it do different things? You can apply the same process of creating new states when you see an incoming event pair, but be careful you don’t come up with new names for existing states. You should do this until you’ve exhausted all the interesting scenarios that include your object of interest.