Use case diagrams consist of four primary elements with specific notation conventions. Understanding these building blocks is essential for creating clear requirement models.
Actor (Stick Figure): Represents a role that interacts with the system. Can be a person (Customer, Admin), another system (Payment Gateway), or a timer (Scheduled Task). Name should reflect the role, not a specific person.
Use Case (Oval): Represents a specific functionality or goal the system provides. Should be named with verb phrases (Park Vehicle, Generate Report, Cancel Booking). Each use case represents a complete interaction that provides value.
Association (Solid Line): Connects actors to use cases they interact with. Represents communication or participation. No arrowhead means bidirectional communication, but if Y, then an arrow indicates direction of initiation.
Include/Extend (Dashed Arrow): Shows relationships between use cases. <<include>> means mandatory sub-functionality. <<extend>> means optional or conditional behavior.
System Boundary: A rectangle that encloses all use cases, representing the system scope. Actors are placed outside this boundary. Label it with the system name (Parking Lot System, Library Management System).
Interview Tip: When drawing use case diagrams in interviews, always draw the system boundary first, then place actors outside and use cases inside. This shows you understand scope separation between the system and its environment.
Use Case Relationships in Detail:
<<include>>: Use when a use case always requires another use case's functionality. Example: "Book Parking Spot" always includes "Validate Payment Method". The arrow points from the base use case to the included use case.
<<extend>>: Use when a use case optionally adds behavior to another. Example: "Park Vehicle" can be extended by "Request Valet Service". The arrow points from the extending use case to the base use case. Include an extension point condition if needed.
Generalization: Use when use cases or actors share common behavior. Draw with a solid line and hollow triangle arrowhead pointing to the parent. Example: "Premium Customer" and "Regular Customer" both generalize to "Customer" actor.
✓Actors are external entities (stick figures) that interact with the system
✓Use cases are system functionalities (ovals) that provide value to actors
✓Association lines connect actors to the use cases they participate in
✓<<include>> represents mandatory sub-functionality always executed
✓<<extend>> represents optional behavior added conditionally
✓System boundary (rectangle) separates internal use cases from external actors