12.2 Reworking the Class Diagram

The process of developing statechart diagrams often reveals the need for additional attributes, associations, and even new classes. It can also reveal errors and inconsistencies in an apparently reasonable class diagram.

We cannot emphasize enough that the process of building Executable UML models is incremental and iterative. Systems are developed incrementally, starting from simple models with limited capabilities; additional capabilities are added incrementally. Within each increment, we iterate over the various models. Writing the statechart diagrams and their state procedures may reveal insufficiencies that can best be corrected by reworking the class diagram.

Do not fall into the trap of trying to build the perfect class diagram before looking at the statechart diagrams; and do not treat the class diagram as immutable when working on the statechart diagrams

On the other hand, after several models, you will develop more confidence that your class diagram is correct, and be able to produce good class diagrams before you spend much time on statechart diagrams.

12.2.1 Refactoring Behavior

As you iterate over the models, developing increasingly sophisticated models of a domain, consider opportunities to keep the individual classes simple by refactoring the behavior in one class diagram into separate classes.

The Order as shown in Figure 9.10 on page 163 comes into existence when a Customer selects the first item. Its lifecycle encompasses the entire product selection, purchase, shipping, and delivery processes.

We could refactor so that a different kind of Order is not created until the product selections are complete and the payment has been accepted. This requires a separate class that collects the selections and arranges payment: a Shopping Cart. Figure 12.9 shows how the Shopping Cart class relates to the product and to the order.

Figure 12.9. Shopping Cart Class and Related Associations

A Shopping Cart is created when the customer starts shopping. Selections can then be added to the cart. When the customer checks out, the charge is attempted against the customer's account, and an order is created.

This approach leads to a simple Shopping Cart statechart diagram and a simpler Order statechart diagram, as shown in Figure 12.10 and Figure 12.11.

Figure 12.10. Shopping Cart Statechart Diagram

Figure 12.11. Simpler Order Statechart Diagram

The Shopping Cart is distinct from the Order. The Shopping Cart has Product Selections added to and removed from it. The Order, on the other hand, is not placed until the Shopping Cart is checked out.

12.2.2 Saving Signals in Data

When a state machine instance executes a procedure, the procedure runs to completion before any outstanding signal is processed. Signals are never saved for a later time by the machinery of Executable UML.

In some situations, an object needs to complete a sequence of states before it can process new requests. For each shipment, the shipping clerk should select the books to be shipped, pack the box, seal it, attach the shipping label, and deposit the box at the loading dock. But while the clerk is working on one shipment, other shipments can be created.

In the model, when a shipment is created, it signals the Shipping Clerk shipmentReady so that the clerk can pack and ship the shipment. In every state except Clerk Idle, the clerk is busy and cannot readily respond to the signal.

One option is to add a new transition from every non-idle state to start up a new packaging activity. (This is the cause of those shipments you receive with somebody else's stuff.) Of course, that new packaging activity can also be interrupted, requiring never-ending epicycles of interrupted shipments.

A better solution is for the Clerk to ignore the signal in all but the Idle state and then check for any unpacked shipments upon re-entry to the Idle state. Figure 12.12 shows the Shipping Clerk statechart diagram and the state transition table for the signal shipmentReady.

Figure 12.12. Statechart Diagram and State Transition Table for Shipping Clerk

The column for the shipmentReady event shows the event ignored in all but the Idle state.

The Shipment not only records information about the shipment, but it also represents the request: The shipment is a trace of the signal sent to the clerk. When created, the shipment sets its own waitingToBePacked attribute to true and signals the Shipping Clerk by sending the shipmentReady signal. If the Shipping Clerk is idle, it^[1] transitions out of the Idle state and starts working. But if the ShippingClerk is not idle, it ignores the shipmentReady, thus continuing to process its current Shipment. Only when the Shipping Clerk completes the current shipment upon re-entry to the Idle state does it look for another Shipment to process. Any shipment that has come into existence during the time the shipping clerk was busy will have waitingToBePacked set to true.

^[1] The impersonal pronoun "it" is used here intentionally to indicate that we are talking about the Shipping Clerk state machine, not the shipping clerk person.

We see this pattern most commonly in systems in which there is competition for a resource: many shipments all trying to be packed by a shipping clerk, many movement requests all trying to be serviced by an elevator, and so on.

When an object cannot respond to a signal because it is in the midst of a sequence of states, use a separate class to represent the request. The request then signals the requested object. The requested object is then responsible for checking for more unserviced instances of the request and processing that request.

This is a special case of contention because there is but one shipping clerk and the contention is managed by that single control point, the single shipping clerk. When there are multiple clerks (i.e., multiple servers for a request), there must be some mechanism to manage the contention, which we describe in the next chapter, Chapter 13: Relationship Dynamics, along with more strategies for dealing with such contention issues.