Activity Diagram
An activity diagram shows control flow through actions, guarded decisions, and outcomes. Use it to reason about conditions before committing side effects.
What you’ll understand
- An activity diagram shows control flow through actions, guarded decisions, and outcomes. Use it to reason about conditions before committing side effects.
- Put a stock guard before the payment and reservation actions, with a separate rejection outcome.
- Evaluate the tradeoff: Control-flow diagrams do not establish transaction isolation. Parallel forks and joins need precise completion semantics; avoid drawing concurrency when the implementation is sequential.
Useful first: Classes and Objects
The idea and when to recognize it
An activity diagram shows control flow through actions, guarded decisions, and outcomes. Use it to reason about conditions before committing side effects.
- Requirement: A checkout must decide whether stock is available before charging for an order.
- Change to anticipate: Show both the successful purchase path and the sold-out branch without accidentally charging on rejection.
- Design goal: Put a stock guard before the payment and reservation actions, with a separate rejection outcome.
Start with the concrete problem
A checkout must decide whether stock is available before charging for an order.
Show both the successful purchase path and the sold-out branch without accidentally charging on rejection.
| Direct implementation | Revised design |
|---|---|
| A decision placed after payment preserves the wrong side-effect ordering even if the final success flag is false. | Put a stock guard before the payment and reservation actions, with a separate rejection outcome. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Control-flow diagrams do not establish transaction isolation. Parallel forks and joins need precise completion semantics; avoid drawing concurrency when the implementation is sequential. |
Responsibilities and contracts
Put a stock guard before the payment and reservation actions, with a separate rejection outcome.
- CheckoutFacade: Coordinates one use case. Public operations: placeOrder()
- Inventory: Checks and reserves stock. Public operations: reserve()
- Payment: Records accepted charges. Public operations: charge()
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
An expense approval activity can branch by amount and join only after all required approvals finish.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Control-flow diagrams do not establish transaction isolation. Parallel forks and joins need precise completion semantics; avoid drawing concurrency when the implementation is sequential.
Common mistake: A decision placed after payment preserves the wrong side-effect ordering even if the final success flag is false.
- Explain the choice: Put a stock guard before the payment and reservation actions, with a separate rejection outcome.
- Challenge your choice: Control-flow diagrams do not establish transaction isolation. Parallel forks and joins need precise completion semantics; avoid drawing concurrency when the implementation is sequential.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…