UML Lecture Series

1
UML Lecture Series
Requirements Modeling (Use Case Diagram Use
Case Description)
Requirements Modeling (Use Case Diagram Use
Case Description)
UML Lecture Series
UML SIG
2
Session Objectives

• At the end of this lecture You will be able to
• Draw a use case diagram to depict functional
• requirements of a system.
• Expose typical mistakes by students.
• Write use case description for a use case.

3
Keywords used in this lecture

• use case
• use case diagram
• functional requirements
• non-functional requirements
• actor
• include
• extend
• use case specification/definition/description
• flow of events
• alternate flow of events / alternate pathway
• exception flow of events / exception pathway
• basic flow of events / happy pathway
• non-functional requirements / shadow use cases

4
Thoughts to Ponder
To my knowledge, no other software engineering
language construct as significant as use cases
has been adopted so quickly and so widely among
practitioners. I believe this is because use
cases play a role in so many different aspects of
software engineering. Ivar Jacobson Founding
Father of UML and Creator of Use Case Diagram
5
Functional vs. Non-Functional
Functional
Requirements
Non-Functional
Functional requirement are user visible
features and are typically initiated by
stakeholders of the system generate report,
login, etc.
Non-functional requirements are non-visible
features and but required for a effective
running of an application security, backup,
etc.
6
Session Objectives

• At the end of this lecture You will be able to
• Draw a use case diagram to depict functional
• requirements of a system.
• Expose typical mistakes by students.
• Write use case description for a use case.

7
Use Case Diagram
Definition A diagram that shows a set of use
cases and actors and their relationships.
Use cases represent system functionality, the
requirements of the system from the users
perspective.
8
Notations
use case A description of a set of sequences of
actions, including variants, that system performs
that yields an observable value to an actor.
actor The people or systems that provide or
receive information from the system they are
among the stakeholders of a system.
include Specifies that the source use case
explicitly incorporates the behaviour of another
use case at a location specified by the source
ltltincludegtgt
extend Specifies that the target use case
extends the behaviour of the source.
ltltextendgtgt
9
Actors
Could be human beings, other systems, timers and
clocks or hardware devices.
Actors
Actors that stimulate the system and are the
initiators of events are called primary actors
(active) Actors that only receive stimuli from
the system are called secondary actors (passive)
10
Actors
Who/what will be interested in the system?
Who/what will want to change the data in the
system?
Actors
Who/what will want to interface with the system?
Who/what will want information from the system?
11
Use Case Diagram Guidelines Caution

• Use cases should ideally begin with a verb i.e
  generate
• report. Use cases should NOT be open ended
  i.e Register (instead should be named as Register
  New User)

2. Avoid showing communication between actors.

• Actors should be named as singular. i.e student
  and NOT students. NO names should be used i.e
  John, Sam, etc.

4. Do NOT show behaviour in a use case diagram
instead only depict only system functionality.
5. Use case diagram does not show sequence
unlike DFDs.
12
Example Include and Extend
13
Include and Extend
The use of include and extend is discouraged
simply because they add unnecessary complexity to
a Use Case diagram.
Since the primary purpose of use cases is to show
user centred functionality, the precedence of use
cases takes little importance.
14
Quiz 1
Which use case is NOT valid?
15
Quiz 2
Identify TWO(2) mistakes
16
Granularity of Use Cases
Add reference
Remove reference
User
Search for reference
Fine Grained or Course Grained?
List references
17
Granularity of Use Cases
Manage Reference
User
Generally, a use case should embody sufficient
levels of granularity without which the use case
may not be rendered as useful.
18
Session Objectives

• At the end of this lecture You will be able to
• Draw a use case diagram to depict functional
• requirements of a system.
• Expose typical mistakes by students.
• Write use case description for a use case.

19
Mistake 1
20
Mistake 2
21
Mistake 3
22
Mistake 4
23
Mistake 5
24
Discussion Exercise
Draw a use case diagram for the scenario below
Inventory System In order to generate
an invoice a clerk must log in. If a clerk is a
first time user, one must have themselves
registered. There should be an option for a user
to register oneself within the login page. Any
user can use the system to view products
online. The option of login is also provided when
a user views products online.
25
Exercise - Solution
26
Session Objectives

• At the end of this lecture You will be able to
• Draw a use case diagram to depict functional
• requirements of a system.
• Expose typical mistakes by students.
• Write use case description for a use case.

27
Use Case Specification
Is a use case diagram alone sufficient in
capturing user requirements?
28
Use Case Specification
29
Use Case Specification
Use case specification is synonymous to use case
description and use case definition and can used
interchangeably. Use case specification defines
information that pertains to a particular use
case which is important in understanding the
purpose behind the use case. Use case
specification is written for every use case. A
use case specification has one or more flow of
events or pathways association with it.
30
Flow of Events / Pathways
A flow of events or pathway is a textual
description embodying sequence of events with
regards to the use case and is part of the use
case specification. Flow of events is understood
by the customer. A detailed description is
necessary so that one can better understand the
complexity that might be involved in realising
the use cases.
31
Flow of Events / Pathways
Flow of events describes how and when the use
case starts and ends, when the use case
interacts with the actors, and the information
exchanged between an actor and the use
case. Flow of events is derived from a what
perspective, NOT how perspective. Hence,
specific information like interface details and
technical specifications should NOT be included
in a use case description. Use case
description serves as a bridge
between stakeholders of a system and the
development team.
32
Flow of Events / Pathways
Use case description serves as a bridge
between stakeholders of a system and the
development team.
Systems analyst produce use case diagram use
case specification in consultation with end
users
Use Case Specification
Use Case Diagram
Programmers look at use case specification to
understand complete requirements - SRS
33
Flow of Events / Pathways
Describes how and when use case starts and ends.
Does NOT describe user interface details.
Flow of Events
Is generally a text-based file that is included
under its use case in Rational Rose/Visual
Paradigm
34
Types Flow of Events / Pathways
Basic Flow of Events_at_ Happy Path - is the most
common pathway. It usually depicts a perfect
situation, in which nothing goes wrong.
Alternate Flow of Events _at_ Alternate Pathway -
is a pathway that is still considered a good
pathway its just not the most heavily travelled
one
Types of Flow of Events
Exception Flow of Events _at_ Exception Pathways _at_
Unhappy Pathway things dont always go as
planned. An exception is an error condition that
is important enough to the application to capture.
35
Types Flow of Events / Pathways
Basic Flow of Events_at_ Happy Path You get to the
ATM and successfully withdraw money
Alternate Flow of Events _at_ Alternate Pathway -
You get to the ATM but could not withdraw money
due to insufficient funds in your account.
Exception Flow of Events _at_ Exception Pathways _at_
Unhappy Pathway You get to the ATM machine but
your valid pin number is not accepted.
36
See Example Word Document on Use Case
Specification based on Remulak Productions
Use Case Specifications - Example
37
Review Questions
38
Review Question
A use case specification cannot be done for an
included use case.
True
False
39
Review Question
Use case specification together with a use case
diagram become part of what is know as system
requirements specification (SRS)
True
False
40
Review Question
Although non-functional requirements (i.e shadow
use cases) are not technically speaking a use
case, are still considered a use case to
acknowledge the importance it has in the overall
system.
True
False
41
Review Question
Basic Flow of Events _at_ Happy Path is a series of
events that happens some of the time
True
False
42
Review Question
Alternate Flow of Events _at_ Alternate Pathway is a
series of events that happens all the time
True
False
43
Review Question
Exception Flow of Events _at_ Exception Pathway is a
series of events that is impossible to happen.
True
False
44
Review Question
Both use case diagram and use case specification
should not be too detailed.
True
False
45
Use Case Diagram - In Class Exercise
Write use case specification based on the case
diagram for Inventory System.
46
Summary

• Use Case Diagram as a means to model functional
  requirements of a system.
• Awareness of typical mistakes by students.
• Write use case description for a use case.

47
Further Reading
Use Case FAQs
http//download.boulder.ibm.com/ibmdl/pub/software
/dw/rationaledge/jan03/UseCaseFAQS_TheRationalEdge
_Jan2003.pdf
48
Reference
Jacobson I. 2003, Use Case Yesterday, Today
and Tomorrow, The Rational Edge, IBM