The document discusses use case diagrams and their components. It defines use cases, actors, and associations. It explains how to structure use cases using generalization, include, and extend relationships. The include relationship extracts common behaviors, while extend adds optional or conditional behaviors. Well-structured use case diagrams can form the basis for software requirements.

1. Computer Engineering Department
Object Oriented Software Modeling and
Design
g
CE 350
Abdel-Karim Al-Tamimi, Ph.D.
altamimi@yu.edu.jo
http://faculty.yu.edu.jo/altamimi
Al-Tamimi 2011 © 1

2. Overview
• Use case Diagrams
Use-case
Al-Tamimi 2011 © 2

3. Use-Case Diagrams
Use Case
Al-Tamimi 2011 © 3

4. Why We Use Use-case Diagrams
Use case
Al-Tamimi 2011 © 4

5. Why We Use Use-case Diagrams
Use case
• Answers the main questions about your
system:
– Who’s your system s for?
Who s system’s
– What must it do?
– Why build it in the first place?
• System users: Actors
• System normal situations: use-cases
Al-Tamimi 2011 © 5

6. Why We Use Use-case Diagrams
Use case
• Stay focus on your client s goals
client’s
• A good use case must represent the point
of view of the people who will use or
interact with the system
• A complete set of use cases = system
l f
requirements
Al-Tamimi 2011 © 6

7. Use-Case Diagram
Use Case
g g
• A use-case model is a diagram or set of diagrams
that together with some additional documentation
show what the proposed software system is
designed to do. A use case diagram consists of
do use-case
three main components:
– Actors
– Use-cases, and their communications
– some additional documentation such as use-case
descriptions for elaborating use cases and problem
use-cases
statements that are initially used for identifying use
cases
Al-Tamimi 2011 © 7

8. Use-Case Diagram: Actors
Use Case
• Usually represented
with a stick figure
• An actor may b
y be:
– People
– Computer hardware
and devices
– External systems
Al-Tamimi 2011 © 8

9. Use-Case Diagram: Actors
Use Case
• An actor represents a role that a user can play,
but NOT a specific user
• Primary actors are those who use the system’s main
functions, deri ing
f nctions deriving benefits from it directl
directly.
– Primary actors are completely outside the system and drive the
system requirements
– Primary actors use the system to achieve an observable user goal
• Secondary actors play a supporting role to facilitate
the primary actors to achieve their goals.
– Secondary actors often appear to be more inside the system than
outside
– Secondary actors are usually not derived directly from the
statement of requirements. Hence, the designer can have more
freedom in specifying the roles of these actors
– Usually found on the right of the system (primary on the left)
Al-Tamimi 2011 © 9

10. Use-Case Diagrams: Actors
Use Case
• Actors are treated like classes and thus can
be generalized
Student
MasterStudent BAStudent
Al-Tamimi 2011 © 10

11. Use-Case Diagrams: Actors and
l
Goals
1. Start by identifying the actors of the
1
system
2.
2 See if the actors can be generalized or not
3. Define the goals of the system and how
they can b achieved using the systems’
h be hi d i h ’
actors
4. Illustrate these goals and actors actions
using use-case diagram(s)
Al-Tamimi 2011 © 11

12. Use-case Diagram: Use-case
Use case Use case
• A use case describes a sequence of actions a system
performs to yield an observable result or value to a
f i ld b bl l l
particular actor
• Naming convention = verb + noun (or) verb + noun-
phrase,
h
– e.g. withdraw cash
• A good use case should:
– Describe a sequence of transactions performed by a system that
produces a measurable result (goal) for a particular actor
– Describe the behavior expected of a system from a user's
perspective
– Enable the system analyst to understand and model a system
from a high-level business viewpoint
– Represent the interfaces that a system makes visible to the
external entities and the interrelationships between the actors
and the system Al-Tamimi 2011 © 12

13. EBP Test for Use-Cases
Use Cases
• Elementary Business Process (EBP) is a
term from the business process
engineering field defined as:
• A task performed by one person in one
place at one time in response to a
time,
business event, which adds a measurable
business value and leaves the data in a
consistent state
– E Approve Credit or Cancel O d
E.g. A C dit C l Order
Al-Tamimi 2011 © 13

14. Use-Case Diagram: Use-Case
Use Case Use Case
Al-Tamimi 2011 © 14

15. Use-Case Diagram: Use-Case
Use Case Use Case
Al-Tamimi 2011 © 15

16. Use-Case Diagram: Use-Case
Use Case Use Case
Al-Tamimi 2011 © 16

17. Use-Case Diagram: Example
Use Case
System name
Actor Use-case
Use case
Association System boundary
Al-Tamimi 2011 © 17

18. Use-Case Diagram: Example
Use Case
p
• Let us consider a simple hotel information
system for two types of customers:
– Tour Group customers and Individual
customers
– Tour Group customers are those who have
made reservations through a tour operator in
advance, while I di id l customers make
d hil Individual t k
their reservations directly with the hotel
– Both types of customers can book, cancel,
o ypes o cus o e s ca boo , ca ce ,
check-in and check-out of a room by
phone or via the Internet
Al-Tamimi 2011 © 18

19. Use-Case Diagram: Example
Use Case
Al-Tamimi 2011 © 19

20. Structuring Use-cases with Relationships
Use cases
• In the p p g
process of developing a use case
model, we may discover that some use
cases share common behaviors
• Th
There are also situations where some use
l i i h
cases are very similar but they have some
additional behaviors
• For example, Withdraw Money and
Deposit Money both require the user to
p y q
log-on to an ATM system
Al-Tamimi 2011 © 20

21. Structuring Use-cases with Relationships
Use cases
Use Case: Withdraw Money Use Case: Deposit Money
Flow of Events: Flow of Events:
1. The user inserts an ATM card. The 1. The user inserts an ATM card. The
system prompts the user to enter a
y p p system prompts the user to enter a
y p p
password. password.
2. The user enters the password. The 2. The user enters the password. The
system validates the user password. system validates the user password.
.... ....
…. ….
…. ….
Common Behavior
Al-Tamimi 2011 © 21

22. Structuring Use-cases with Relationships
Use cases
Use Case: Withdraw Money Use Case: Deposit Money
Flow of Events: Flow of Events:
1.
1 include (Login Account) 1.
1 include (Login Account)
.... ….
…. ….
…. …..
Use Case: Login Account
Flow of Events:
1. The user inserts an ATM card. The
system prompts the user to enter a
password.
d
2. The user enters the password. The
system validates the user password.
Al-Tamimi 2011 © 22

23. The <<include>> Relationship
p
• Include relationships are used when two
or more use cases share some common
portion in a flow of events
• Thi common portion is then grouped and
This i i h d d
extracted to form an inclusion use case for
sharing among two or more use cases
• Most use cases in the ATM system
example, such as Withdraw Money,
p , y,
Deposit Money or Check Balance, share
the inclusion use-case Login Account
Al-Tamimi 2011 © 23

24. The <<include>> Relationship
Withdraw Money
(Base use case) Login Account
(Included use case)
Al-Tamimi 2011 © 24

25. The <<include>> Relationship
• When to use include
relationship:
– The behavior of the
inclusion use case is
common to two or
more use cases
– The result of the
behavior that the
inclusion use case
specifies, not the
behavior itself, is
,
important to the base
use case Al-Tamimi 2011 © 25

26. The <<include>> Relationship: Example
Al-Tamimi 2011 © 26

27. The <<include>> Relationship: Example
Al-Tamimi 2011 © 27

28. The <<extend>> Relationship
• In UML modeling, you can use an extend
modeling
relationship to specify that one use case
(extension) extends the behavior of
another use case (base)
• This type of relationship reveals details
about a system or application that are
typically hidden in a use case
Al-Tamimi 2011 © 28

29. The <<extend>> Relationship
• The extend relationship specifies that the
incorporation of the extension use case is
dependent on what happens when the
base use case executes
• The extension use case owns the extend
relationship. You can specify several
extend relationships for a single base use
case
Al-Tamimi 2011 © 29

30. The <<extend>> Relationship
• While the base use case is defined independently
and is meaningful by itself, the extension use
case is not meaningful on its own
• The extension use case consists of one or several
behavior sequences (segments) that describe
additional behavior that can incrementally
augment the behavior of the base use-case
• Each segment can b inserted i
h be i d into the b
h base use
case at a different point, called an extension
point
Al-Tamimi 2011 © 30

31. The <<extend>> Relationship
Withdraw Money
(Base use case) Process Excess Amount
(Extending use case)
If conditional guard is true, extending flow is executed
Al-Tamimi 2011 © 31

32. The <<extend>> Relationship
• The extension use case can access and
modify the attributes of the base use case;
however,
however the base use case is not aware of
the extension use case and, therefore,
cannot access or modify the attributes and
operations of the extension use case
Al-Tamimi 2011 © 32

33. The <<extend>> Relationship
• You can add extend
relationships to a model
to show the following
situations:
– A part of a use case that is
optional system behavior
– A subflow i executed only
bfl is d l
under certain conditions
– A set of behavior segments
that may b inserted i a
h be i d in
base use case
Al-Tamimi 2011 © 33

34. The <<extend>> Relationship
Al-Tamimi 2011 © 34

35. The <<extend>> Relationship
Al-Tamimi 2011 © 35

36. The <<extend>> Relationship
Al-Tamimi 2011 © 36

37. Al-Tamimi 2011 © 37

38. The Generalization Relationship
• A child use-case can inherit the behaviors, ,
relationships and communication links of a
parent use-case (like Actor generalization)
• In other words, it is valid to put the child use
words use-
case at a place wherever a parent use-case
appears
• Th relationship b t
The l ti hi between th child use-case and
the hild d
the parent use-case is the generalization
relationship
• For example: suppose the ATM system can be
used to pay bills. Pay Bill has two child use cases:
Pay Credit Card Bill and Pay Utility Bill
38

39. The Generalization Relationship
39

40. The Generalization Relationship
40

41. Use-Case Scope
Use Case
• A use case must be initiated by an actor
• When a use case is considered complete,
there are no further inputs or outputs; the
desired functionality has been performed,
or an error has occurred
• After a use case has completed, the system
is in
i i a state where the use case can b
h h be
started again, or the system is in an error
state
41

42. Base Use-Case vs. Abstract Use-Case
Use Case Use Case
y y
• Base use case – invoked directly by actor
to achieve an observable goal
• Abstract use case – invoked by other use
cases and is not a complete goal f
di l l from
user’s perspective
• e g withdraw cash (concrete use case) vs
e.g. vs.
login (abstract use case)
42

43. Use-Case Scope
Use Case
43

44. Use-Case Scope
Use Case
44

45. Summary of Notations
Construct Description Notation
Use-case A sequence of transactions
performed by a system that produces
a measurable result for a particular
actor
Actor A coherent set of roles that users play
when interacting with these use cases
System The boundary between the physical
Boundary system and the actors who interact
with the physical system
45

46. Summary of Notations
Construct Description Notation
Association The participation of an actor in a
use case, i.e. an instance of an
actor and instances of a use case
communicating with each other
Generalization A taxonomic relationship between
a general use case and a more
l d
specific use case. The arrow head
points to the general use case
Extend
E t d A relationship b t
l ti hi between an
extension use case and a base use
case, specifying how the behavior
of the extension use case can be
inserted into the behavior defined
for the base use case. The arrow
head points to the base use case 46

47. Summary of Notations
Construct Description Notation
Include A relationship between a base use
case and an inclusion use case,
specifying how the behavior for the
inclusion use case is inserted into the
behavior defined for the base use
case. The arrow head points to the
inclusion use case
47

48. Resources
• Chapter 3 from “Object-Oriented
Object Oriented
Technology: From diagram to code with
Visual Paradigm for UML”
UML
• UML 2 for dummies, chapters 8-10
• UML 2 certification guide, chapter 2
ifi i id h
• Chapter 6 from “Applying UML and
Patterns”
Al-Tamimi 2011 © 48