Use Cases

1
Use Cases
2
Introduction

• A use case ...
• Specifies the behavior of a system or some subset
  of a system.
• Is a system-level function.
• Does not indicative how the specified behavior is
  implemented, only what the behavior is.
• Performs a service for some user of the system.
• A user of the system is known as an actor.
• An actor can be a person or another system.
• During the analysis phase, facilitates
  communication between the users of the system and
  the developers of the system.

3
Introduction
4
Introduction

• A use case ...
• Represents a functional requirement of the system
  as a whole.
• Is graphically represented as an oval with the
  name of its functionality written inside.
• Functionality is always expressed as a verb or a
  verb phrase.
• An actor is most typically represented as a stick
  figure of a person labeled with its role name.
• Individual use cases can exist in relationships
  with other use cases much in the same way as
  classes maintain relationships with other classes.

5
Terms and Concepts

• Names are used to distinguish one use case from
  another.
• Actors
• May be drawn as a stick figure, stereotyped class
  or a graphical image of your own design.
• Are connected to use cases by associations.
• May be involved in generalization relationships
  with other actors.
• Exist outside the system boundaries.

6
Terms and Concepts
7
Terms and Concepts

• Use cases and Flow of Events
• A use case, by itself, does not describe the flow
  of events needed to carry out the use case.
• Flow of events can be described using informal
  text, pseudocode, or activity diagrams.
• Be sure to address exception handling when
  describing flow of events.
• Use a note to attach flow of events documentation
  to a use case.

8
Use cases and CollaborationsCollaboration
diagrams show which classes are involved in
implementing a particular use case.
9
Terms and Concepts

• Organizing Use Cases
• Packages may be used to organize (group) use
  cases.
• Generalization between use cases is used to
  extend the behavior of a parent use case.
• An ltltincludegtgt relationship between use cases
  means that the base use case explicitly
  incorporates the behavior of another use case at
  a location specified in the base.
• Sometimes the ltltusesgt stereotype is used instead
  of ltltincludegtgt.

10
Terms and Concepts

• Organizing Use Cases
• An ltltextendgtgt relationship between use cases
  means that the base use case implicitly
  incorporates the behavior of another use case at
  a location specified indirectly by the extending
  use case.
• Extended behavior is optional behavior, while
  included behavior is required behavior.

11
Use Case Relationships
12
Use Case Relationships
13
Use Case Diagrams
14
Introduction

• Use case diagrams
• Show a set of actors, use cases, and their
  relationships.
• Facilitate communication between non-technical
  customers and developers due to their simplistic
  nature.
• Show the functionality of the system from the
  prospective of each user of the system.
• Model the context of the system.
• Model the requirements of the system.

15
Use Case Diagram
16
Modeling System Requirements

• A requirement
• Is a design feature, property, or behavior of a
  system.
• States what needs to be done, but not how it is
  to be done.
• Is a contract between the customer and the
  developer.
• Can be expressed in various forms, including use
  cases.

17
Modeling System Requirements

• To model the requirements of a system
• Identify all actors (users of the system).
• Identify the needs, from the system, of each
  individual actor.
• Make each need a use case.
• Identify redundant behavior within your set of
  use cases, and factor it into common base-class
  use cases. In other words, look for
  opportunities to use generalization.
• Do the same for actors.
• Show the relationships between actors and use
  cases.

18
Modeling System Context