Creating Use Cases

1
Creating Use Cases

• A use case is our construct for a business
  process. It shows the course of events.
• A use case is a sequence of transactions in a
  system whose task is to yield a result of
  measurable value to an individual actor of the
  system.
• - Ivar Jacobson

2
Overview

• Use cases describe domain processes in a
  structured prose format.
• We explore basic skills.
• Definitions.
• Notation.
• Guidelines.
• Practice.

3
Objectives

• Identify actors and use cases.
• Read and create high-level and expanded format
  use cases.
• Distinguish between essential and real use cases.

4
A Partial Sample Process
5
Artifact Influence

• Use cases are dependent on at least some
  preliminary functional requirements.
• Conversely, requirements can be clarified by
  investigating use cases.

6
Use Cases

• Describe the sequence of events of an actor using
  a system to complete a process.
• Represent business or domain processes.
• Are a narrative description of a business
  process.
• Are expressed in structured prose.
• Are not directly related to object technology.

7
A High-Level Use Case

• High level use cases briefly describe major
  processes in the organization.
• Name Borrow Resources
• Actors Patron (initiator), Librarian
• Description The use case begins when the Patron
  arrives at the check-out with books and videos to
  borrow and submits them to the Librarian, who
  records the resources borrowed. The Patron then
  leaves with the resources.

8
Actors

• An actor in a use case is an external agent that
  uses or interacts with the system.
• There is one initiator actor and possibly several
  participating actors.

9
Actors

• Actors can be
• Roles of humans.Example A Patron.
• Other computer systems.Example The Visa
  network.
• Inanimate physical objects, such as
  electro-mechanical devices. Example A robot.

10
Use Case Diagrams
11
Choosing the System Boundary

• A use case describes events upon a system.
• This implies a system boundary is chosen.
• Typically boundaries.
• Hardware/software boundary of a device or
  computer system.
• Department of an organization.
• Entire organization.

12
Choosing the System Boundary
13
Identifying Use Cases

• 1. Define the system boundary.
• 2. Identify actors.
• External entities participating in domain
  processes.
• Examples Customers, clerks, managers,
  technicians, external computer systems.

14
Identifying Use Cases

• 3. For each actor, determine
• What fundamentally different processes/actions
  does it participate in?
• What initial event does an actor perform to start
  a process?
• Each fundamentally different process of each
  actor is a use case.

15
Sample High-Level Primary Use Cases

• Name Borrow Resources.
• Actors Patron (initiator), Librarian.
• Description The use case begins when the Patron
  arrives at the check-out with books and videos
  to borrow and submits them to the Librarian,
  who records the resources borrowed. The Patron
  then leaves with the resources.

16
Sample High-Level Primary Use Cases

• Name Add Resources.
• Actors Librarian.
• Description The use case begins when the
  Librarian receives new resources (books and
  videos) to add to the catalog. The title, call
  number, and other information are recorded. Then
  the resources are placed on a shelf organized
  by resource type and call numbers.

17
Sample High-Level Primary Use Cases

• Other possible use cases.
• Return a Resource.
• Delete a Resource.
• Notify Overdue Patrons.
• Collect Fines.

18
A Common Mistake

• A common error in identifying use cases is to
  represent individual steps, operations, or
  transactions as use cases.
• A use case is a relatively large end-to-end
  process that typically includes many steps or
  transactions it is not normally an individual
  step or activity in a process.
• It is possible to break down portions of a use
  case into subordinate use cases (called abstract
  use cases), but this is not the norm.

19
Exercises

• For the course project
• Identify the system boundary.
• Identify actors and use cases.
• Draw a use-case diagram.
• Write high-level use cases as indicated by the
  instructor.

20
Use-Case-Driven Development Cycles

• The reality of scheduling is more complex,
  especially with parallel teams.
• But, use cases can help organize work.

21
WARNING
MEMORY TEST COMING UP!
22
Categories of Use Cases

• In practice, use cases are categorized in many
  dimensions.

23
Detail Level of Use Cases
24
Task Levels of Use Cases

• The special includes relationship can relate some
  use cases (not all).
• If A includes B, we can say A is a superprocess
  and B is a subprocess.

25
Importance Levels of Use Cases
26
Abstraction Levels of Use Cases
27
Essential versus Real Use Cases
28
Exercises

• Individually, describe (write) all use-case
  categories.

29
Expanded Format Use Cases

• Describe the use case in greater detail.
• Can be written essential or real.
• Have the following components
• Name.
• Starts with a verb.
• Description.
• From the high-level use case.
• Actors.
• Initiator and participants from high-level use
  case.
• Type.
• If decomposed, then super / sub (abstract).
• Also, primary / secondary, and essential / real.

30
Expanded Format Use Cases (continued)

• Have the following components (continued)
• Cross-references.
• Related use cases and system functions.
• Preconditions.
• Assumptions that must hold true.
• Typical Course of Events.
• Most important section describes regular flow of
  events.
• Alternatives.
• Exceptional alternatives that might arise.

31
Expanded Use Case Example

• Name Borrow Resources.
• Description (As in high-level use case.)
• Actors Patron (initiator), Librarian.
• Type Primary, essential.
• Cross-references System functions R1.1, R1.2,
  R1.3, R3.1.
• Preconditions Patron has a library card.

32
Typical Course of Events
33
Typical Course of Events (continued)

• Alternatives.
• Alternative at 4 If the Patron card is invalid,
  do not allow borrowing.
• Alternative at 5 If the Resource is missing a
  call number, set it aside for repair and do not
  allow borrowing.

34
What to Describe in a Use Case

• Emphasize events between actors and the system
  without decomposing the internal processing of
  the system.
• Orient toward things that the actors can
  perceive.
• Discussion of internal processing or design
  decisions is permissible, but should be done with
  knowledge of the consequences.
• Example Early design commitments.

35
Use-Case Miscellany

• The first line of a use case course of events
  should describe the event that starts the use
  case.
• Example This use case begins when the ltactorgt
  ltgenerates an input eventgt
• Start the use-case name with a verb.
• Purchase
• Borrow

36
Exercises

• Write expanded format essential-oriented use
  cases for those indicated by the instructor.

37
What We Learned Reflection

• Use cases.
• Narrative descriptions of processes.
• Different categories.
• High/expanded.
• Essential/real.
• Others.
• Reflection
• How might you use these at work?
• Relationship to other artifacts?

38
Skill and Objectives Evaluation
39
Readings

• Applying UML and Patterns, Larman, C.
  Prentice-Hall (1997).
• Object-Oriented Software Engineering, Jacobson,
  I. Addison Wesley.
• The Object Advantage, Jacobson, I. Addison
  Wesley.