Behavioral modeling 2: state machine and activity diagrams

On the first page you saw how objects exchange messages with each other. On this page there are two different views. The state machine diagram shows the states a single object goes through during its life: a book copy on the shelf, set aside, on loan, overdue, lost. The activity diagram shows the steps, decisions and parallel tasks of a process: how a food order flows from the customer to the kitchen and from the kitchen to the courier. On the exam both come as “draw” questions; marks come from the details: the transition label pattern, the difference between fork and decision, swimlanes.

Golden rules:

1. A state machine is for an object, an activity diagram is for a process.
2. Transition label: event [guard] / action. All three are optional but the order is fixed.
3. Diamond = choose one path (decision/merge). Thick bar = all in parallel (fork/join).
4. Swimlane = responsibility. Every action must be in the right lane.

The state machine diagram

Elements

Three kinds of line can be written inside a state: entry / ... (on entering), do / ... (while in the state), exit / ... (on leaving).

Kinds of event: call event (an operation call: pickUp()), time event (after 48h), change event (when dueDate < today), signal event (an external signal).

Worked example: Copy (a book copy)

Scenario: “When a new copy is added to the catalog it is available. If a student reserves it, it is set aside for 48 hours; if the student comes and picks it up it is lent out, and if not it becomes available again. An available copy can also be lent directly. If the return date passes, the copy is considered overdue. When returned, it becomes available; if it is overdue, a fine is charged on return. A copy that is 30 days overdue is considered lost and is removed from the catalog.”

Step 1: States. Available, On Hold, On Loan, Overdue, Lost.

Step 2: Transitions.

Step 3: The drawing.

 ●
 | addToCatalog
 v
+-----------+  reserve /         +---------+
| Available |  startHoldTimer()  | On Hold |
|           |------------------->|         |
|           |<-------------------|         |
+-----------+   after 48h        +---------+
  ^  ^  |                           |
  |  |  | checkOut /               | pickUp /
  |  |  | setDueDate()             | setDueDate()
  |  |  v                           v
  |  | +---------+<-----------------+
  |  +-| On Loan |
  |    +---------+
  | return  | when today > dueDate
  |         v
  |    +---------+  after 30 days  +------+
  +----| Overdue |---------------->| Lost |
return/+---------+  / markLost()   +------+
chargeFine()                          |
                    removeFromCatalog v ◉

Count: 5 states, 10 transitions (including the initial and final arrows).

PITFALL · confusing a state with an action. “Charge a fine” is not a state, it is an action (/ chargeFine() on the transition). A state is a condition the object stays in for a while, and it usually expresses an adjective or a condition: Available, Overdue.

The activity diagram

An activity diagram shows a business process or the flow of a use case. It resembles a flowchart but adds parallelism (fork/join) and responsibility (swimlane). In the textbook’s framework it is also part of functional modeling; it is used to visualize the inside of use cases.

Elements

Worked example: a food order (with swimlanes)

Scenario: “The customer places an order and pays. If the payment is declined, they try another card. The restaurant evaluates the order; if it rejects, the customer is notified and the process ends. If it accepts, while the food is being prepared a courier is assigned at the same time. When both are done, the courier picks up the order and delivers it; the customer confirms the delivery.”

 Customer      | Restaurant     | Courier
---------------+----------------+-------------
 ●             |                |
 |             |                |
 [Place Order] |                |
 |             |                |
 [Pay]<----+   |                |
 |         |   |                |
 <dec>-----+   |                |
 |  [declined] |                |
 | [paid]      |                |
 +------------>[Review Order]   |
               |   |            |
 [Get notice]<-+--<dec>         |
 |  [rejected] |   | [accepted] |
 ◉             |   |            |
               | ==+== (fork)   |
               | |       |      |
               |[Prepare]+----->[Assign
               | Food]   |      | Courier]
               | |       |      |  |
               | ======= (join)<---+
               |    |           |
               |    +---------->[Pick Up]
               |                |  |
               |                [Deliver]
 [Confirm      |                |  |
  Receipt]<----+----------------+--+
 |             |                |
 ◉             |                |

Reading:

• 3 swimlanes: Customer, Restaurant, Courier.
• 2 decisions: the payment result ([paid] / [declined]) and the restaurant’s decision ([accepted] / [rejected]).
• 1 fork, 1 join: Prepare Food and Assign Courier are in parallel; Pick Up waits for both to finish.
• 2 activity finals: the rejected order and the normal end.

TIP · a merge after a decision. If the paths split by a decision will come together again, use a merge diamond. In the payment loop, the declined path returns to “Pay”; it is neater if this return is drawn with a merge before Pay.

PITFALL · decision instead of fork. The words “at the same time” in “while the food is being prepared a courier is assigned at the same time” mean fork. If you use a decision, only one of the two happens.

Which diagram when?

Common mistakes