Sequence, state and activity diagrams

A class diagram shows what exists. It does not show what happens, in what order, or how an object changes over its life. Three more diagrams cover that. Use whichever answers the question in front of you.

A sequence diagram shows objects as vertical lifelines and messages as horizontal arrows, with time running downward. It answers: for this use case, which calls happen and in what order?

For Pay and exit: the driver gives the ticket to the gate, the gate asks the lot for the fee, and the lot asks the payment service to charge. The reply travels back along the same path.

Useful notation: a solid arrow is a call, a dashed arrow is a return, and boxes labeled alt and loop wrap alternatives and repetition (for example, alt payment fails, retry). Sequence diagrams expose design problems quickly. A lifeline with a flood of arrows is doing too much, and a long chain of calls suggests a Demeter violation.

Some objects behave differently depending on what has already happened. A state diagram (a state machine) shows the states an object can be in, the events that move it, and optional guards, conditions that must hold.

A ticket is issued, becomes paid once payment succeeds, and is exited when the gate opens. A refund can return it from paid to issued.

The value is in the missing arrows. There is no path from issued straight to exited, which states the rule that nobody leaves without paying. If you find yourself writing many boolean flags such as isPaid and isExited, you probably have a state machine hiding in the code. The State pattern, coming soon, implements it cleanly.

An activity diagram is a flowchart with extras. It has actions, decision diamonds with guard labels, and fork and join bars for steps that happen in parallel. It suits business processes and algorithms: Pay and exit might fork into "open gate" and "print receipt" and join afterwards.

Use it when the question is about the process as a whole, especially where branches and parallel work matter.

An object diagram is a snapshot of real instances at one moment, such as lot1 holding ticket42 for plate KA01AB1234. It is handy to check that a class diagram can actually represent a tricky example.

• What exists and how is it related? Class diagram.
• Who calls whom, in what order? Sequence diagram.
• How does one object change over time? State diagram.
• What is the overall flow, with branches and parallel work? Activity diagram.
• Does my structure fit a concrete case? Object diagram.

Draw fewer, better diagrams. One clear sequence diagram of the hardest use case teaches more than ten complete ones.