Use Case Diagrams and Scenarios

Use Case Diagrams and Capturing Use Case Scenarios

• Use case diagrams provide a common understanding for end-users, developers, and domain experts.
• They capture basic functionality (use cases) and users (actors) within a given problem statement.
• The lesson aims at identifying actors and use cases from a problem statement, associating use cases with relationships, and drawing use-case diagrams.

Introduction

• Use case diagrams are a type of behavioral UML diagram.
• They offer a graphical overview of system functionality.
• Use cases represent actions the system performs.
• Actors represent users or other systems interacting with the system.
• The diagrams show dependencies among these elements.

Actor

• An actor is an object or set of objects external to a system that interacts with it for a meaningful result.
• Actors can be human, devices, or other systems.
• An example includes a customer withdrawing cash from an ATM (a customer as a human actor).

Use Case Diagrams

• Use case diagrams belong to the behavioral category of UML diagrams.
• They display a graphical overview of a system's functionality.
• They portray the actions (use cases) a system performs and the actors involved.
• The diagrams show dependencies among these elements.

Use Case

• A use case represents a system's functionality.
• Use cases in ATM systems include cash withdrawal, checking account balance, changing a PIN, depositing cash, and transferring funds.
• Use cases can have both successful and unsuccessful scenarios.

Actor Classification

• Primary actors are the primary users of a system, achieving their goals using the system's services.
• Supporting actors provide services to the system (e.g., bank representatives replenishing ATM cash).
• Primary actors in a simple ATM case are the customers; supporting actors include bank representatives.

Use Case and Actor Associations

• Use cases are triggered by actors.
• Actors and use cases are connected by binary associations, indicating message passing between the two.
• Each actor must be associated with at least one use case.
• Each use case must be associated with at least one actor.
• Associations between actors are generally not displayed, but a class hierarchy can be depicted.

Use Case Relationships

• Three relationship types exist among use cases: include, extend, and generalization.

Include Relationship

• Include relationships show shared behaviors among use cases.
• They are analogous to functions in programming avoiding repetitive code.
• A common use case is a login use case, included in other use cases where login is necessary.
• The "include" relation is represented by a dashed arrow and the word <>.

Extend Relationship

• Extend relationships show variations in use cases.
• They describe changes to the use case when existing assumptions become false.
• Use Cases include ATM transaction modifications or optional steps.
• Extend is represented by a dashed arrow with the word <>.

Generalization Relationship

• Generalization relationships represent inheritance between use cases.
• Derived use cases specialize existing functionality.
• Examples are use cases like draw rectangle, and draw square which are specialized from Polygon use case.

Identifying Actors and Use Cases

• Identify actors by focusing on those who benefit from or operate the system, or interact with other systems or hardware.
• Identify use cases by focusing on the tasks the system performs, or required functions.

Guidelines for Use Case Diagrams

• Define the system boundary clearly.
• Make sure actors have clear purposes.
• Use cases should describe meaningful system actions.
• Connect actors and use cases to avoid ambiguity/ disconnected entities.
• Use include or extend relationships to encapsulate common behaviors.