Use Case Diagram
A use-case diagram describes the goals external actors pursue through a system boundary. Actors represent roles, and use cases describe externally meaningful outcomes rather than internal methods.
What you’ll understand
- A use-case diagram describes the goals external actors pursue through a system boundary. Actors represent roles, and use cases describe externally meaningful outcomes rather than internal methods.
- Show the customer role outside the checkout boundary, connect it to Place order, and use the interaction to inspect the resulting contract.
- Evaluate the tradeoff: Use cases explain scope and stakeholders but do not show class ownership or execution order. Pair the view with a sequence or activity diagram when discussing implementation.
Useful first: Classes and Objects
The idea and when to recognize it
A use-case diagram describes the goals external actors pursue through a system boundary. Actors represent roles, and use cases describe externally meaningful outcomes rather than internal methods.
- Requirement: A customer wants to place an order, and the system must coordinate inventory and payment.
- Change to anticipate: Distinguish the customer’s checkout goal from the internal steps that fulfill it.
- Design goal: Show the customer role outside the checkout boundary, connect it to Place order, and use the interaction to inspect the resulting contract.
Start with the concrete problem
A customer wants to place an order, and the system must coordinate inventory and payment.
Distinguish the customer’s checkout goal from the internal steps that fulfill it.
| Direct implementation | Revised design |
|---|---|
| Treating every internal helper call as a separate actor-facing use case makes the scope diagram unreadable. | Show the customer role outside the checkout boundary, connect it to Place order, and use the interaction to inspect the resulting contract. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Use cases explain scope and stakeholders but do not show class ownership or execution order. Pair the view with a sequence or activity diagram when discussing implementation. |
Responsibilities and contracts
Show the customer role outside the checkout boundary, connect it to Place order, and use the interaction to inspect the resulting contract.
- 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
A library use-case view can connect Member to Borrow copy and Librarian to Register copy without deciding the database schema.
- 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
Use cases explain scope and stakeholders but do not show class ownership or execution order. Pair the view with a sequence or activity diagram when discussing implementation.
Common mistake: Treating every internal helper call as a separate actor-facing use case makes the scope diagram unreadable.
- Explain the choice: Show the customer role outside the checkout boundary, connect it to Place order, and use the interaction to inspect the resulting contract.
- Challenge your choice: Use cases explain scope and stakeholders but do not show class ownership or execution order. Pair the view with a sequence or activity diagram when discussing implementation.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…