Use-case Modeling

Outline
• Introduction
• Use case model
• Unified Modeling Language
• Actor
• Use cases
• UC Description Properties
• Relationships between Actors
• Use Case Relationships
Sharif Univ. of Tech. 2
 Elements of Use-case Model
• The components of a Use-case model are:
– System Modeled/ System Boundary System Name

– Actors
name

– Use-cases Use-case
– Stimulus
– Relationships
• Among usecases
• Between actor and usecase
• Among actors

3
 System and Its Boundary
• As a part of the use-case modeling, the boundaries
of the system are developed.
• System lies within the boundary and outside the
boundary is environment of the system
• System in the use-case diagram is a box with the
name appearing on left top corner pentagon.
• Define the scope of the system that you are going to
design
• Actors are not part of the system. They lie outside
the boundary of the system
5
 Actors
• An actor is something or someone or device or
another system that interacts with the system.
• Actor communicates with the system by sending
and receiving messages.
• An actor activates the system.
• Actors can be primary/secondary; passive/active.
• Actor is a role not an individual instance.
• Actor is source and sink for a system means gives
input to system or consumes output from the
system

6
Notations for Actor in UML
 Finding Actors
• The actors of a system can be identified by answering
a number of questions:
– Who will use the functionality of the system?
– Who will maintain the system?
– What devices does the system need to handle?
– What other system does this system need to interact?
– Who or what has interest in the results of this system?
 Use-cases
• A Use-case in UML is defined as a set of sequences of
actions a system performs that yield an observable result
of value to a particular actor.
• Actions can involve communicating with number of actors
as well as performing calculations and work inside the
system.
• A Use-case
– is always initiated by an actor.
– provides a value to an actor.
– must always be connected to at least one actor.
– must be a complete description.
 Finding Use-cases
• For each actor ask these questions:
– Which functions does the actor require from the system?
– What does the actor need to do?
– Could the actor’s work be simplified or made efficient by
new functions in the system?
– What events are needed in the system?
– What are the problems with the existing systems?
– What are the inputs and outputs of the system?
 Relationships among usecases
• Generalization
• Includes
• Extends
Generalization relationship among
usecases
Include relationship between use cases
Extend relationship between use cases
Extend relationship between use cases
Interaction Modeling
 Interaction Diagrams
• It describes the dynamic behavior of a system.
– A set of messages exchanged among a set of
objects within a context to accomplish a purpose.
• It models the way a use case is realized
through a sequence of messages between
objects.

Sequence Diagrams 18
 Interaction Diagrams in UML
– Sequence Diagram
– Collaboration Diagrams

19
 Sequence Diagram
• It illustrates how objects interact with each
other.
• Emphasizes time ordering of messages.
• Can model simple sequential flow, branching,
iteration, recursion and concurrency.

20
 Elements of Sequence Diagram
• Object
• Lifeline
• Activation box
• Messages
– Synchronous message
– Asynchronous message
– Constructor
– Destructor

21
 Object

• Object naming: radhesham

:Student
– syntax: [ObjectName][:className]
– Name classes should be consistent with class
diagram
– Include object names when objects are
referred to in messages or when several
objects of the same type exist in the diagram.
• The Life-Line represents the object’s life
during the interaction
 Elements of a Sequence Diagram
X-Axis (objects)

user: :Book
book:Book
LibraryMember Copy

borrow(book) Object
Life
ok = mayBorrow()
Y-Axis (time)

Line
message
Activation
[ok] borrow(member)
setTaken(member) box
condition

23
 Messages

• An interaction between two objects is

performed as a message sent from one
object to another
• A message is represented by an arrow between
the life lines of two objects.
– Self calls are also allowed
– The time required by the receiver object to process
the message is denoted by an activation-box.

24
 Messages
• A message is labeled with its name.
• Arguments and control information are optional.
• Return values are optionally indicated using a dashed arrow

– Don’t model a return value when it is obvious

what is being returned, e.g. getTotal()
– Prefer modeling return values as part of a method
invocation, e.g.
ok = isValid()

25
 Synchronous Messages
• A message which returns value is called
synchronous message.

:A :B

areYouReady()
return
yes (optional)
 Object Creation (constructor
Message)
• An object may create another object via a
<<create>> message.

Preferred
:A :B :A

<<create>> <<create>>
:B
 Object Destruction message

• An object may destroy another object via a

<<destroy>> message.
– An object may destroy itself.

:A :B
<<destroy>>
 Control information

• Condition
– syntax: ‘[‘ expression ’]’ message-label
[ok] ejectMoney(Card)

– The message is sent only if the condition is true

• Iteration
– syntax: * [ ‘[‘ expression ‘]’ ] message-label
 Control Information

• Iteration examples:

:playgroundShape :Shape :Driver :Car

draw()
*draw() *[until full] insert()
 Sequence Diagram
:Printer
:PrintServer :Queue
Proxy
Client
print(doc,client) enqueue(job)

job=dequeue()

[job]print(job.doc)

status
[job] done(status)
 Activity Modeling
• Outcome of activity modeling is activity
diagram.
• Activity diagrams consists of nodes and arcs
• Activity diagram can be called object-oriented
flowchart
 Elements of Activity Diagram
• Nodes: Three types of nodes
1. Action Node (four types)
– Call node
– Send signal node
– Accept Event node
– Accept time event node
 Elements of Activity Diagram
• Nodes: Three types of nodes
2. Control Node (seven types)
– Initial node
– final node
– Flow final node
– Decision node
– Merge node
– Fork node
– Join node
 Elements of Activity Diagram
• Nodes: Three types of nodes
3. Object Node
Flows in activity diagram (two types)
– Control flow
– Object flow
 References
1. Grady Booch, James Rumbaugh, Ivar Jacobson,
The Unified Modeling Language User Guide,
Pearson Education
2. Michael Blaha, James Rumbaugh: Object-
Oriented Modeling and Design with UML, 2nd
Edition, Pearson Education, 2005.
3. J. Rambaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen,
Object-Oriented Modeling and Design, Prentice Hall of India
4. Satzinger, Jackson, Burd, Object-Oriented Analysis & Design
with the Unified Process, Thomson.
5. Grady Booch, Object Oriented Analysis & Design, Pearson
Education