Modeling behavior with Sequence diagrams

Session 5:Modeling Behavior with UML Sequence Diagrams
Analysis and Specification of Information Systems
Spring 2008
Eran Toch
http://www.technion.ac.il/~erant

Outline
Introduction
Basic notation
Alternating paths
Modularity

Modeling Process
Introduction | Basics | Alternations | Modularity

Why to Model Behavior?
How do we use the SMS Server interface? What is the order of executing the operations?
sendMessage, getStatus, Resend?
getStatus, sendMessage, checkForMessages?
When do we use resend?

Behavioral Modeling
[if getStutus == err]
Send message
Resend
Resend
Get Status
Adds a new msg
Message queue

Outline
Introduction
Basic elements
Alternating paths
Modularity

Building a Sequence Diagrams
Sequence diagrams capture the use-case behavior using the foundation of the classes.
Use Case 1
Class C
Class A
Use Case 3
Use Case 2
Class D
Class B
Objects
Sequence =
+
messages

Sequence Diagrams
A simple sequence diagram:
objects
sd Product Buying
Diagram Name
p : Product
: ShooppingCart
customer
display()
message
getPrice()
activation (focus of control)
addProduct (p)
checkout ()
Lifeline

Object Control
obj1 : Class1
Illustration
obj2 : Class2
obj1 : Class1
user
Object Creation
operate()
do (…)
create (…)
: Class3
Return Message
foo()
Messages to self
Object Destruction

Illustration
Corresponding Class Diagram
Notice that a dependency exists whenever messages are passed between instances of the class
Dependencies can be overridden by associations, aggregations etc.

Sequences and Use-Cases
p : Product
: ShooppingCart
customer
display()
getPrice()
addProduct (p)
checkout ()
create (…)
: Order
Hidden part
Visible part

Full Message Attributes
sequence number
[sequence-expression]
[return-value :=] [message-name] [(argument-list)]
C3.1: res := getLocation (fig)
message name
argument list
return value

Different Kinds of Messages
Synchronous Message
asynchronousMessage
Return Message

Synchronous & Asynchronous Messages
Example
Example
Nested Flow
Asynchronous Flow
manager
sensor
eye
sensor
manager
alarm
check
unknown
unknown
ring
check
operate
log
Price need to be finished, before teller can do another operation (getName)
Ring is executed, while the control flow is returned to err handle and appl

Outline
Introduction
Basic elements
Alternating paths
Modularity

Flow Constructs
If
Loop
Else
Repeat
Jump
When we tell a scenario, which types of alternatives do we need?

Options
Example
msg : Message
: Database
Fragment
opt
Condition
[msg.status=confirmed]
archive(msg)
Used for modeling simple optional blocks.
Has one operand; no "else" guard.
Do something...

Alternatives
msg : Message
: Database
: Admin
alt
Alternative Fragment group
[msg.status=confirmed]
archive(msg)
Condition
[msg.status=error]
notify(msg.getID())
[else]
Execution regions. At most one will execute.
wait()
Else condition
(optional)

Loops
: OS
: Folder
: File
loop
[for each Folder]
Loop Fragment
Display()
loop
[for each File]
Condition
Display()
Nested Loop Fragment

Breaks
: Policy
: User
: User Manager
isLooged = login(name,pass)
If the condition is met, the break fragment is executed, and the reminder of the sequence is ignored
break
[¬isLooged]
addBadLogin(name)
Do something…
Handy in model exception handling
Do something …

Examples of Guards
[for each Object]
[5]
[i=1..5]
[status = okay]
No guard means an infinite loop

Outline
Introduction
Basic elements
Alternating paths
Modularity

MODULARITY
We need ways to create modular scenarios

Referencing a diagram
: Policy
: User
: User Manager
login(name,pass)
ref
Login Handling(user,pass) :bool
Reference Gate
Do something…
Do something …

Referenced Diagram
sd Login Handling
Diagram name
: User Manager
: UserAccount
loop
Input message
login(name,pass)
[for each UserAccount]
cName -= getUseNamer()
cName -= getUseNamer()
Output message
opt
[cName = name]
isInSystem(true)
true
false

Summary