What you should be able to do
- Separate actors from the system boundary.
- Use include only for required reusable behaviour.
- Use extend only for optional or conditional behaviour.
- Turn one use case into a defensible activity flow.
02 / REQUIREMENT ENGINEERING AND ANALYSIS MODELING / L10
Use Case and Activity Diagrams
Use cases frame the goal outside the boundary. Activities show the work, choices and parallel paths inside the workflow.
What does a user want, and what workflow makes that goal happen?
Terms to use precisely
Common mistakes
- Calling every outside entity a primary actor.
- Drawing login as an include relationship for every use case.
- Using an activity diagram as a list of screens.
INTERACTIVE UML LAB
Take this idea into the diagram.
The lab uses familiar systems so you can inspect every actor, relationship, message and ownership handoff.
CHECKED LEARNING LINKS
Watch the part that solves the gap.
Each link is matched to this lesson. Start with a quick video when available. Open the full lecture when you need the academic explanation.
WATCH FIRSTquick video
UML use case diagrams: Everything you need to know
Review actors, boundaries, associations, include and extend before opening the studio.
GO DEEPERfull lecture
Lecture 31: Use Case Modelling
Review actor goals, the system boundary and use-case relationships.
GO DEEPERquick video
UML activity diagram tutorial
Review action flow, decisions, guards, forks, joins and swimlanes in a short worked tutorial.