Where Is the Order Now? Choosing Among State, Activity, and Sequence Models
An online retailer processes 12,000 orders per hour. Fulfillment runs: validate inventory (200 ms), authorize payment (up to three retries with 2 s backoff, 5 s timeout per attempt), reserve stock (may partially succeed, e.g. 3 of 5 items), create shipment, notify customer. If all payment retries fail, the order enters PENDING_PAYMENT and a background job retries every 15 minutes for 24 hours. Operations staff ask 'where is the order now?' during incidents. Two teams disagree about the model: one wants a sequence diagram that shows every retry as a separate message; another wants an activity diagram with swimlanes for Order Service, Payment Gateway, Inventory, and Notification; an architect asks for a state machine. The review must also capture the payment contract used by a third-party gateway team that will implement against it.
1. For answering operations' 'where is the order now?' question, which behavioral diagram type is the best fit, and what should the other two diagram types be used for instead? Justify by the question each diagram answers.
Read the worked answer
The question is about a single order's current lifecycle state, so a state machine is the primary model. States such as CREATED, VALIDATING, PAYMENT_PENDING, STOCK_RESERVED, SHIPPED, and CANCELLED, with transitions for success, partial reservation, timeout, and retry, answer 'where is the order now?' directly. The activity diagram is better for the end-to-end process and hand-offs: swimlanes for Order Service, Payment Gateway, Inventory, and Notification show who does what and where decisions such as partial stock occur. It does not persist a current state for a given order. The sequence diagram is an interaction contract: it shows the order of messages and reply values between lifelines for one scenario. It answers 'in what order do these parties interact?' and is the right artifact for the third-party gateway. Using a sequence diagram to answer the operations question would force staff to infer state from message position, which is fragile. Use each diagram for the question it was designed to answer, and cross-reference them by name.
2. How do you model the 24-hour retry loop and the 5 s timeout without drawing 288 retry messages on a sequence diagram? Name the UML elements and show the reasoning.
Read the worked answer
On a sequence diagram, do not draw 96 retries (24 hours ÷ 15 minutes). Use a combined fragment loop(min, max) around the authorize/retry interaction, with a guard such as [attempts < 96 and not authorized], and place a duration constraint {5 s} on the authorize message. An alt fragment distinguishes success, decline, and timeout. The long-running policy is clearer in a state machine or activity: a state PENDING_PAYMENT with a time event after(15 min) and a guard on attempt count models the 24-hour window without enumerating messages. A sequence diagram is for a representative interaction, not for a 96-iteration schedule. If the retry policy is contractual, put it in the gateway interface specification or a separate state machine, and have the sequence diagram reference that policy by name. The reasoning: UML combined fragments express iteration and choice compactly; time events and duration constraints express timing; neither requires one symbol per real-world occurrence.
3. The third-party gateway team needs a contract. Which diagram do you give them, and which elements must be present? Explain why a state machine alone is insufficient.
Read the worked answer
Give the gateway team a sequence diagram (a communication diagram is acceptable if message order is less important, but here it is not). Required elements: lifelines for OrderService and PaymentGateway; synchronous messages authorize(orderId, amount, currency) and reply authResult; an alt fragment for approved, declined, and timeout; a loop for retries with the retry guard; duration constraints for the 5 s timeout; and the operation signatures on the interface. The diagram must state preconditions and postconditions or reference them. A state machine alone is insufficient because it describes OrderService's internal states, not the externally visible message order and reply values the gateway must implement. An activity diagram shows flow but not the two-party contract. The sequence diagram is the artifact the gateway team can implement against and test with mocks; the state machine remains the authority for OrderService's own lifecycle. Cross-reference the state names to the sequence's outcomes so the two do not contradict.