Use Case Diagrams: Actors and Interactions

Use Case Diagram

• A graphical depiction of a user's possible interactions with a system
• Demonstrates the different ways a user might interact with a system
• It summarizes the details of a system's users (actors) and their interactions (use cases) with the system

Key Concepts

• A fundamental concept of many object-oriented development methods
• Expresses the expectations of the customers/stakeholders essential for a detailed design
• Used during the entire analysis and design process.
• Describes the possible usage scenarios (use cases) that a system is developed for
• Expresses what a system should do
• Does not address any realization details like data structures, attributes, or algorithms

Questions Answered

• What is being described? (the system)
• Who interacts with the system? (the actors)
• What can the actors do? (the use cases)

Identifying Actors

• Use Use-cases
• Actors initiate the execution of use cases
• Actors provide functionality for the execution of use cases

Identifying Actors - Key Questions

• Who uses the main use cases?
• Who needs support for their daily work?
• Who is responsible for system administration?
• What are the external devices or software systems that the system must communicate with?
• Who has an interest in the results of the system?
• Actors represent roles that users adopt, not specific users.
• Actors are always clearly outside the system and never part of it, so they are never implemented

Actor Types

• Human (e.g., Student or Professor)
• Non-Human (e.g., E-mail Server)
• Active: An actor that initiates the execution of use cases.
• Passive: An actor that provides functionality for the execution of use cases.
• Primary: An actor that takes an actual benefit from the execution of the use case
• Secondary: An actor receives no direct benefit from the execution of the use case.

Representing Actors

• Stick figures
• Rectangles (containing the stereotype «actor»)
• Freely definable symbol

Identifying Relationships Between Actors

• Actors may have common properties (using the same use cases)
• Actors may be depicted in an inheritance relationship (generalization) with one another.
• Generalization expresses an “is a” relationship
• Multiple inheritance is permitted
• Abstract actors are possible
• Actor A inherits from actor B
• Actor A can communicate with use-cases X and Y
• Actor B can only communicate with the use-case Y

Identifying Use Cases

• The functionality expected from the system to be developed
• Model use cases iteratively and incrementally, starting with the “top level" requirements that reflect the business objectives.
• Describes functionality expected from the system under development
• Provides tangible benefit for one or more actors that communicate with this use case
• Derived from collected customer wishes
• Set of all use cases describes the functionality that a system shall provide
• Documents the functionality that a system offers

Identifying Use Cases - Key Questions

• What are the main tasks that an actor must perform?
• Does an actor want to query or even modify information contained in the system?
• Does an actor want to inform the system about changes in other systems?
• Should an actor be informed about unexpected events within the system?

Relationships Between Use Cases

• Inclusion (the «include» Relationship):
• The behavior of one use-case (included use case) is integrated into the behavior of another use case (base use case).
• Base use-case requires the behavior of the included use case to be able to offer its functionality
• Included use-case may be executed on its own.
• Extension (the «extend» Relationship):
  • The behavior of one use-case (extending use case) may be integrated into the behavior of another use case (base use case) but does not have to be
  • Both use cases may also be executed independently of each other
  • A decides if B is executed, and conditions define under which circumstances the behavior is integrated.

Extension Points

• A condition that must be fulfilled for the base use-case to insert the behavior of the extending use-case is to be specified for every <> relationship
  • Conditions are specified, within curly brackets, in notes, each is connected to the corresponding «extend» relationship (or the extending use-case)
• An extension point identifies the point in the base use-case where the behavior of an extension use-case must be inserted
  • The extension point is specified for a base use-case which can have several extension points
  • Extension points are written in a separate section within the use-case, identified by the keyword extension points
  • If a use-case has multiple extension points, these can be assigned to the corresponding «extend» relationship via specification in a note (as in a condition).

Generalization of Use Cases

• Use case A generalizes use case B
• B inherits the behavior of A and may either extend or overwrite it
• B also inherits all relationships from A
• B adopts the basic functionality of A but decides itself what part of A is executed or changed.
• A may be labeled {abstract}
  • Cannot be executed directly.
  • Only B is executable.

Identifying Associations

• An actor is connected with the use cases via associations (solid lines)
• Associations express that the actor communicates with the system and uses this certain functionality
• Every actor must communicate with at least one use-case
• An association is always binary (i.e., it is always specified between one use case and one actor)
• Multiplicities may be specified for the association ends
• If no multiplicity is specified for the actor's association end, 1 is assumed as the default value

Describing Use Cases

• ID Number – Name
• Short-Description / Goal
• Preconditions: Prerequisite for successful execution.
• Postconditions: System state after successful execution.
• Error Situations – System State in the Event of an Error: Errors relevant to the problem domain + System state on the occurrence of an error.
• Actor(s) / Initiator(s): Actors that communicate with the use case.
• Trigger: Events which initiate/start the use case.
• Standard Process (Main Success Scenario): Individual steps to be taken.
• Alternative Processes (Alternative/Other Scenarios): Deviations from the standard process.

Common Errors to Avoid

• Modelling Processes - Use case diagrams do not model processes/workflows
• Setting System Boundaries Incorrectly - Actors are not part of the system; hence, they are positioned outside the system boundaries!
• Mixing Abstraction Levels - Avoid representing “top level" use cases with technically oriented use cases in the same diagram.
• Functional Decomposition - Various steps are part of the use case, not separate use cases themselves!
• Incorrect Associations - a use case is associated with two actors, this does not mean that either one or the other actor is involved in the execution of the use case: it means that both are necessary for its execution
• Modelling Redundant Use-Cases - Many small use cases that have the same objective may be grouped to form one use case when modelling real applications

Summary of Notation Elements

• System & System Boundary: Boundaries between the system and the users of the system.
• Use case: Unit of functionality of the system.
• Actor: Role of the users of the system.
• Association: Relationship between use-cases and actors.
• Generalization (Use-Cases): Inheritance relationship between use-cases (B inherits all of A's properties & its entire behaviour).
• Generalization (Actors): Inheritance relationship between actors (Y participates in all use-cases in which X participates).
• Extensions (Extend) Relationship: B extends A: Optional (i.e., conditional) use of use-case B by use-case A.
• Inclusions (Include) Relationship: A includes B: Required (i.e., unconditional) use of use-case B by use-case A.