Use case Modeling

Use case
 Use case are written stories to fulfill some stakeholders goals
in order to discover and record functional requirements
 It must provide an observable user value
 In simple
 A use case is one usage of the system
 Actor appears, interacts, goes away

 It captures the required behaviour of the system

 What must happen within the system

 The business rules that must be followed

 It captures the final system state

 What’s changed

Unification 2
Use case Modeling

 Use-case modeling is a specialized type of

structural modeling concerned with modeling
the functionality of a system
 UP defines use case model within requirements
discipline, as a set of all use cases, that models
the system functionality and enjoinment

Unification 3
Elements of Use case

A use case is a collection of related success and

failure scenario that describe actors using the
system to support a goal. [Larman]

 Scenario
 Actors
 System
 Goal

Unification 4
Scenario

 A scenario is a sequence of steps describing an interaction

between a user and a system
 It is also called a use case instance, that is a specific sequence
of actions and interactions between actors and the system
under consideration
 Keep your focus on “how a bank works, not how a computer
program that simulates a bank, is used “

Unification 5
Actor
 An external entity (person or machine) that interacts with
or uses the system
 Things that the project cannot control
 An actor is external to a system, interacts with the system,
may be a human user or another system, and has goals
and responsibilities to satisfy in interacting with the system.
Actors address the question of who and what interacts with
a system.
 In the UML, an actor is shown as a "stick figure" icon.

Process Sale

Unification 6
Organisation
(Accounts Receivable
Tax Agency Device
Kitchen) (Drink
Dispenser
Cash Register
Role Door Lock)
(Employee
Customer
Guest) System
(Accounting Package
Product Inventory
Bar System)

Unification 7
Types of Actors

 Primary Actor
 To whom System provides services. (Customer)
 Secondary Actor
 Who help the System to provide the services.
(system Administrator or cash loader of ATM).
 Offstage Actor
 A stakeholder with interest in the outcome that
must be satisfied, but who is not playing an active
role in the use case. (Supplier)

Unification 8
System

 System
 Everything that the project has control over
 System Boundary
 System boundary can be a computer system, organization
boundary, or department boundary. The system functions
and actor may change depending on the system boundary
location.
 Understand the System
 Understand the limitations of the system
 Identify the relation of the actor with the system

Unification 9
Goals
 Goal
 Systems are built to meet certain stakeholder needs or goals;
these define what the system is supposed to do different tasks.

Unification 10
Finding Primary Actors, Goals,
and Use cases

Unification 11
Procedure

 Choose system boundary

 Identify primary actors
 Identify user goals
 Define use case that satisfy each use case

Unification 12
Step 1: System Boundary
 Organization Perspective:
 Understand the organization structure, behavior, business
processes and rules.
 System Perspective:
 Try to focus on what is in the scope of the system or what is
outside the scope of system
 Identify external and supporting actors

Business Processes
Customer External
System
Software/ Engineer

Hardware

Employee Manager
Business Supplier
Management
Unification 13
Team
Step 2&3: Find primary actors and Goals

 Identify who has direct intervention with the system and

drives the system
 Ask who need there goals to be fulfilled from our system
 Primary Actors and Goals depend upon system boundary
 The actor goal list

Actor <<Type>> Goal<<Type>>

Unification 14
Step 4: Define Use cases

 Identify one Use case for each user goal.

 Name the use case similar to the goal
 Try name to be start with a verb

Unification 15
Types of Use case
 Use cases are written in different formats
depending on the need. Such as
 Use case in function context
 Primary
 Secondary
 Use case in Detail level context
 High level/Black box use cases
 Expanded/White box use cases
 Use case in Description level context
 Essential
 Concrete/ Real
 Use case in Formality context
 Brief
 Casual
 Fully dressed
 One column
 Two column
Unification 16
Cont…

Use case in function context

 Primary - These functions are required and
are common main processes.
 Secondary - These functions are secondary to
the system or rarely occur. Don't need these
functions in this iteration. This type of use
case is rarely done.

Unification 17
Cont…

Use case in Detail level context

 High Level/Black box use cases
 Brief with no detail, they do not describe the system
internal functionality or its components.
 Expanded/White box use cases
 More detailed with information about every step in the
process. Don't describe how the system responds.

Unification 18
Cont…

Use case in Description level context

 Essential
 Design abstracted user interface.
 Concrete/ Real Use Case
 When user interface is involved, they often show screen
shots and discuss interaction with the widgets.

Unification 19
Cont…
Use case in Formality context
 Brief
 One paragraph summary usually of main success
scenario
 Casual
 Multiple paragraphs that covers various scenarios

 Fully dressed
 All steps and variants are written in detail, along
with supporting sections
 One column: System

 Two column: Actor system interaction

Unification 20
Unification 21
Use case
Writing Requirements
in Context

Unification 22
Elevator problem
A product is to be installed to control elevators in a building within 8 floors.
The problem concerns the logic required to move elevators between floors
according to the following constraints. Visitor have to pass through a security
system, in which he has to enter a card to get authenticate before entering
the elevator. There is only one elevator in the building.

Each floor , except the first floor and the top floor, has two buttons, one to
request an up elevator and one to request a down elevator. These
illuminates when pressed. The illumination is cancelled when an elevator
visits the floor and then moves in the desired direction
Each elevator has a set of m buttons, one for each floor. These illuminates
when pressed and cause the elevator to visit the corresponding floor. The
illumination is cancelled when corresponding floor is visited by the elevator
There is a display window that shows the current floor being visited by the
elevator
When an elevator has no request, it remains at its current floor with its door
closed

Unification 23
Identify Actor, Goals, Use cases

Elevator
Goals
•He get
Get authenticate authentication and
pass the security
system
•He visits the
Start elevator elevator and wants
to move to the
destination floor
Visitor without interruption
Visit Floor

Unification 24
Fully Dressed Example
 Use case name
 Use case UC1: Start Elevator
 Primary Actor
 Who calls on system services to fulfill a goal
 user: visitor
 Stakeholders and Interests
 Interacting with system, and have specific interests in
the system operation
 Visitor: he visits the elevator and wants to get in side
without interruption
 Elevator boy: he helps people in navigation and
elevator operation when asked
 Electrician: he solve elevator functionality related
problems
Unification 25
 Preconditions
 What must always be true before beginning of
a scenario, they are not tested in use case but
are considered true before hand
 Visitor is authenticated and is identified
 Success Guarantees (Post condition)
 What must be true on success completion of
the use case
 Visitor presses the button and get inside the
elevator and elevator door close's

Unification 26
 Main success Scenario
 Describes typical success path, it stores three
record,
 interaction between actors
 A validation
 A state change
1. Visitor A authenticate himself
2. Visitor A presses the Up floor button at floor 3
to request an elevator, he wishes to go to
floor 7
3. The up floor button turned on
4. An elevator arrives at floor 3
5. The up floor button turn off
6. The elevator doors open
7. The timer starts
8. Visitor A enters the elevator
9. The elevators door close after the time out
Unification 27
 Extensions (Alternative Flow)
 They indicates all the other scenarios or branches,
both success and failures
 An extension has two parts; the condition and the
handling
 At the end of the extension handling the scenario
merges back with the main scenario
 1a. Unauthorized Visitor

 System indicates error message

 Special requirements
 Any non functional requirement specific to use case
under consideration
 Language internationalization on the text display

Unification 28
 Technology and Data Variations list
 Technology constraints of customer
 Visitor identification by card system

 Open Issues
 Any other relevant information
 Department laws

Unification 29
Case study: Rent a car
In order to rent a car first of all customer provides the start
date and finish date for the rental and his personal details
(name, address and credit card number) as well. All rentals
are paid via cash.
Company also provides a facility that if a car is stolen proper
assistance and help should be provided to the customer; in
this regard they issue a notice that a car is stolen. A clerk
may alert the system that a car is now considered to be
stolen.
Each week, the clerk will provide a list of the rentals, which
have been initiated the previous week, as report to the
manager who monitors the over all system flows.
Clerks can also add cars to the system when new cars are
purchased by the Company. Store Managers are allowed to
delete cars from the system as well. A car is deleted from the
Unification 30
system when sold or destroyed in an accident
Use case diagram views

 System/Business level use case

diagram
 Analysis level use case diagram

Unification 31
System/Business level use case
diagram
 Show system level or black box use
cases
 Usually captured in Inception

Supermarket System

Buy Goods Produce Cash

Customer Flow Report Manager

Return Goods Update Stock Product

Database
Unification 32
Analysis/ Detail level use case diagram

 Show detail level or white box use cases

 Concrete, Abstract, Base and Addition
Use cases
 Add inclusion, extension and
generalization relation ships
 Usually captured in Elaboration iteration 2

Unification 33
Include Relationship
 Extract a common sequence of events or partial behaviour that
is common across several use cases
 From multiple use cases
 Create a new inclusion use case
 Modify the base use cases to include the inclusion
 Avoid repetition

For each product that the customer

Inclusion selects: the product is identified to the
Select Items system the system finds the product
and looks up its price the price is
supplied to the customer

<<include>> <<include>>

The use case starts when the customer

requests to buy goods. Include Select
Base Items use case. When there are no
Buy Goods Return Goods more products, . . .
Unification 34
 The appropriate application of
<<include>> is to eliminate
redundancy that would otherwise
make the set of use cases difficult to
understand. If two or more use cases
have a set of steps in common, than
rather than re-writing those steps we
can collect them into a common use
case.

Unification 35
Actor Generalization/Specialization

 Generic actors have use cases common to all

specialised actors
 Specialised actors have special use cases

Buy Goods

Customer
Returns Goods

Request
Saver Card

Registered
Customer Unification
Return 36
Saver Card
“The most important characteristic of
a good use case is that the stake
holders understand it.

Unification 37
Diagramming suggestions

 To categorize an element use stereotypes

 A stereotype represents the meta-classification of an
element
 New UML element based on standard ones

 Allows additional semantics to be defined

 New stereotypes may be added to the meta-model

 Stereotypes are then used in the domain model

<<include>>
Select Items

Buy Goods
Customer
<<Role>> <<extend>>

Unification
Buy Goods with Store Card
38
 Show computer system actors with an
alternate notation than a stick figure
 Put primary actor on left and supporting
actors on right

Unification 39
References

 Class Assignments
 Applying UML and Patterns by Craig Larman
 Chapter 6, Chapter 25

Unification 40