Sequence Diagrams

Behavioral Diagrams Interaction Diagrams

– Use case

– Statechart
– Sequence;
– Activity Communication

– Interaction Overview
– Timing 1
 Interaction Diagrams (sd and cd)
❑ show the interaction of any kind of instance (classes, interfaces, components,
nodes and subsystems);

❑ messages sent/received by those objects/instances (invocation,

construction/destruction, of an operation)

❑ realizes use cases to model a scenario

❑ Interaction types
– Sequence diagram —emphasizes the time ordering of messages.

– Communication (Collaboration) diagram — emphasizes the structural organization of objects

that directly send and receive messages.

❑ Objects within an interaction can be:

– Concrete: something from the real world. (e.g., John: Person)
– Prototypical: representative instance of something from the real world
(e.g., p: Person)
• Communication diagrams use (strictly) prototypical things.
2
• Prototypical instances of interfaces and abstract types are valid.
Interaction Diagram: sequence vs communication
objects
object
p : StockQuotePublisher s1 : StockQuoteSubscriber s2 : StockQuoteSubscriber role:ClassName
classifiers or their in
use cases or actors
attach(s1)
attach(s2) Procedure call, RMI, JDBC, …
Observer
design
Time notify() pattern
update()
{update < 1 minutes} Activations
getState()
- Show duration of execution
update() - Shows call stack
- Return message
getState() Implicit at end of activation
Explicit with a dashed arrow

3 : notify() 4 : update()
s1 : StockQuoteSubscriber
1 : attach(s1)
6 : getState()
p : StockQuotePublisher 5 : update()

2 : attach(s2) s2 : StockQuoteSubscriber 3
7 : getState()
 Interactions - Modeling Actions
• Simple asynchronous in 2.0 (stick arrowhead) – no return value expected at end of callee activation

• Call activation of caller may end before callee’s

(response)
• Return
half arrow in 1.x
• Send

c : Client 1
p : PlanningAgent

<<create>> : TicketAgent

actual parameter
setItenerary( i )
calculateRoute()
loop return
route return value
call on self

for each conference

<<destroy>>
X end of object life
notify() send

destroy: e.g., in C++ manual garbage collection; in Java/C#, unnecessary natural death/
self destruction

4
 Sequence Diagrams – Generic vs. Instance
❑ 2 forms of sd:
❑ Instance sd: describes a specific scenario in detail; no conditions, branches or loops.
❑ Generic sd: a use case description with alternative courses.

ob3:C3 ob3:C3 ob3:C3 ob3:C3

op1
ob1:C1
[x>0] foo(x) concurrent lifelines
conditional ob2:C2 - for conditionals
[x<0] bar(x) - for concurrency
do(z)
do(w)
[z=0] jar(z) [z=0] jar(z)

linking sequence diagrams

recurse()
Here, conditional or concurrency?
recursion
5
 Timing constraints
❑ Useful in real-time applications
❑ useful to specify race condition behaviour
❑ Two ways to specify (in 1.x)

6
Interactions - Procedural Sequencing vs. Flat Sequencing
Flat Sequencing Procedural Sequencing
• Infrequent: Not recommended for most
situations. (Dewey decimal system)
• Each message is numbered sequentially • Most common.
in order of timing.
• Rendered with stick arrowhead. • Each message within the same operation is
numbered sequentially.
• Nested messages are prefixed with the
sequence number of the invoking operation.
• Rendered with filled solid arrow.

x x x.k
y
c : Client c : Client

1 4 8
2 5 9 1 1.1 1.1.1
6 2 1.2 1.1.2
7 3.1
3.1.1
3
3

CAN’T TELL RELATIONSHIPS 7

Interactions – conditional paths, asynchronous message
[Craig Larman] [http://www.phptr.com/articles/article.asp?p=360441&seqNum=6&rl=1]

unconditional :E 1a and 1b are mutually

exclusive conditional paths

2: msg7
a.2:update( p )
1: msg1 1a [test1]:msg2 :F
:A :B

1b [not test1]:msg3

asynchrous message 1c: msg4 a.1:<<create>>

1c.1: msg5
:C :D
active object

8
 Modeling Different Levels of Abstraction
◼ Establish trace dependencies between high and low levels of abstraction
◼ Loosely couple different levels of abstraction
• Use Cases trace to Collaborations in the Design Model, to a society of classes
•Components trace to the elements in the design model, then to Nodes

Interaction Diagram at a High Level of Abstraction

model

Use Case <<trace>> : Order Clerk

: Order Taker : Order
Fulfillment
submitOrder
placeOrder

Order Clerk
acknowledgeOrder
Place Order

<<trace>>
Interaction Diagram at a Lower Level of Abstraction

: Order Taker : CreditCard : Order : Billing Agent

: Order Clerk Agen Fulfillment
submitOrder
processCard
placeOrder triggerBill
acknowledgeOrder
9
Sequence Diagrams & Some Programming
:Selection :Purchase

purchase
buyMajor

buyMinor

create(cashTender)
:Payment

public Class Selection

{ private Purchase myPurchase = new Purchase();
private Payment myPayment;
public void purchase()
{ myPurchase.buyMajor();
myPurchase.buyMinor():
myPayment = new Payment( cashTender );
//. .
}
10
// . .
}
 Frames: References sd Authenticate

:User :ATM :Bank

sd Withdrawal
Idle
:User :ATM :Bank cardId(cid)

ref EnterPIN
ref
Authenticate
loop(0,3)
operator

alt continuation PIN NOK

PIN OK msg (“try again”)

withdraw ref EnterPIN

msg (“amount”)
amount (a) chkAcct (a)
nested fragment
alt enough bal sd EnterPIN
money
receipt :User :ATM :Bank
not enough bal Digit[4]
msg(“amount too big”)
operands

Code(cid,pin)

alt pin-nok

PIN NOK PIN NOK

msg (“illegal entry”)
pin-ok
msg (“card”)
PIN OK 11
 Interaction Overview Diagram
sd Withdrawal

ref
Authenticate

PIN OK PIN NOK

sd sd

:User :ATM :Bank :User :ATM

withdraw
msg (“illegal entry”)
msg (“amount”)
amount (a) chkAcct (a)

sd sd

:User :ATM :Bank :User :ATM :Bank

enough bal
money msg(“amount too big”) not enough bal
receipt

sd

:User :ATM
12
Relationship with Sequence Diagram? msg (“card”)
 Frames & Interaction Fragment Operators
Frame: as the graphical boundary, and a labeling mechanism
Frame name: “frame type name[(param type: param name)] [: return type: return name]”

Flow of Control
– sd: named sequence diagram ref: reference to “interaction fragment”
Naming
– loop: repeat interaction fragment
[guard condition] can appear
– opt: optional “exemplar” (cf. break) as the first item underneath
– alt: selection
– par: concurrent (parallel) regions (e.g., mo.cookFood -> par(nukeFood, rotateFood)
Ordering
– seq: partial ordering (default) (aka “weak”)
– strict: strict ordering
– criticalRegion: identifies “atomic” fragments
Causality
– assert: required (i.e. causal)
– neg: “can’t happen” or a negative specification
– Ignore/consider: messages outside/inside causal stream
13
 What can be in the top boxes?
(http://www.agilemodeling.com/artifacts/sequenceDiagram.htm)

Outputting
transcripts

Boundary/interface elements: software elements such as screens, reports, HTML pages, or

system interfaces that actors interact with.

Control/process elements (controllers): These serve as the glue between boundary elements
and entity elements, implementing the logic required to manage the various elements and their
interactions. Often implemented using objects, but simple ones using methods of an entity or boundary
class.
14
Entity elements
 Modeling Protocols - Associating Protocols with Ports

❑ By a set of interconnected interfaces, invoked according to a formal

behavioral specification.
state machine spec

initial

Operator Assisted Call

connecting
«interface» «interface»
Caller Callee connected

Interaction specs

caller operator callee

«provides»
«uses»
«interface»
Operator ClassX
«uses»

15
Protocols: Reusable Interaction Sequences
(http://cot.uni-mb.si/ots2003/ppt/Selic-UML2.0-tutorial.030504.pdf)

❑ Communication sequences that

❑ always follow a pre-defined dynamic order
❑ occur in different contexts with different specific participants (i.e., instances)

Caller Operator Callee Interfaces

call

ack

number
call

ack
transfer
talk

16
 From Diagrams to Objects
Collect all messages to define object’s methods and state transitions !

Phone
Directory

17
Activity Diagrams

Behavioral Diagrams Interaction Diagrams

– Use case
– Sequence;
– Statechart Communication

– Activity – Interaction Overview

– Timing

18
 Activity Diagram Basics
• Activity Diagram – a special kind of Statechart diagram, but showing the flow from activity to
activity (not from state to state).
• Activity state –non-atomic execution, ultimately result in some action; a composite made up of
other activity/action states; can be represented by other activity diagrams
• Action state –atomic execution, results in a change in state of the system or the return of a value
(i.e., calling another operation, sending a signal, creating or destroying an object, or some
computation); non-decomposable
No notational distinction between
initial state action and activity states!
optional
Select site But, activity states can have certain
triggerless transition types of parts
action state do construct()
Commission
architect Entry/ setLock()

Develop plan sequential branch/decision merge (unbranch)

one incoming, several outgoing multiple incoming, one outgoing
Bid plan guard expression (for alternative threads) OR

[not accepted] concurrent fork

[else]
activity state with submachine

Do trade concurrent join AND

Do site work work()
object flow

Finish : CertificateOfOccupancy
final state construction [completed] 19
0..*
 Swimlanes & Object Flow
• A swimlane is a kind of package.
• Every activity belongs to exactly one swimlane, but transitions may cross lanes.

• Object flow – objects connected using a dependency to the activity or transition that
creates, destroys, or modifies them

Customer Sales Stockroom

object flow
swimlane
Request service
Order
[placed] Take order Order
[entered]

Pay Order Fill order

? [filled]
sub-activity indicator
Deliver order
Order
[delivered]

Collect order
flow final
the process stops at this point for this
part of the activity diagram
20
 Object Flows and Pins

Invoice inv;
inv = new Invoice;
FillOrder(inv);

A shorthand notation: use input pins and output pins (parameters).

21
 A Simple Example – Order Processing

activity
parameter
node =
object
node

<<precondition>> Order complete

<<postcondition>> Order closed

22
A Simple Example – Order Processing Using sub-activity

23
Is this the same as the previous one?
 Activity Diagram even as Method
POEmployee

sortMail()
deliverMail(k: Key)

ad POEmployee.sort-deliverMail

POEmployee.sortMail POEmployee.deliverMail

ad POEmployee.deliverMail

Check Out Truck Put Mail in Boxes

key

24
 Interruptible Activity Region
• An interruptible activity region surrounds a group of actions that can be
interrupted.

• the Process Order action will execute until completion, then pass
control to the Close Order action, unless a Cancel Request interrupt is
received which will pass control to the Cancel Order action.
25
 An Activity Diagram – Distributing schedules
http://www.agilemodeling.com/artifacts/activityDiagram.htm

<<signal>>

pin parameter

redundant constraint

hour-glass symbol represents time object

send receive
26
send receive
 Pins, Parameters, Effects
(www.jot.fm/issues/issue_2004_01/column3.pdf )

❑ effect that their actions have on objects that move through the pin:
one of the four values create, read, update, or delete.

❑ Take Order creates an instance of Order and Fill Order reads it.

❑ The create effect is only possible on outputs; and

the delete effect is only possible on inputs.

27
 Multiple Tokens
❑ Object nodes can hold more than one value at a time, and some of these values can be the
same.
❑ Upper bound: the maximum number of tokens an object node can hold, including any duplicate
values.
❑ At runtime, when the number of values in an object node reaches its upper bound, it cannot
accept any more.
❑ If painting is delayed too much for some reason, the input pin will reach its upper bound, and
parts from polishing will not be able to move downstream;
If painting is delayed further, the output pin of polishing will fill up and the polishing behavior will
not be able to transfer out polished parts;
Unless the polishing behavior has an object node internal to it that buffers output parts, it will not
be able to take parts from its input pin, which will likewise fill up and propagate the backup; Only
when the input pin to PAINT goes below its upper bound will parts be able to flow again.

28
 Multiple Tokens - Ordering
• Object nodes holding multiple values can specify the order in which
values move downstream.
• The default is FIFO (a pipe); users can change this to LIFO (a stack),
or specify their own behavior to select which value is passed out first.

Non-Determinism
(http://www.jot.fm/issues/issue_2004_01/column3.pdf)

29
Parameter Multiplicity & Object Flow Weight

• Minimum multiplicity on an input parameter means a behavior or operation

cannot be invoked by an action until the number of values available at each of its
input pins reaches the minimum for the corresponding parameter, which might
be zero

❑ Weight on object flow edges specifies the minimum number of values that can
traverse an object flow edge at one time.

30
Interaction Overview Diagrams

Behavioral Diagrams Interaction Diagrams

– Use case
– Sequence;
– Statechart Communication
– Activity

– Interaction
Overview
– Timing 31
 Interaction Overview Diagram
(http://www.agilemodeling.com/artifacts/interactionOverviewDiagram.htm)

❑ variants on UML activity diagrams which overview control flow.

❑The nodes within the diagram are frames, not activities
❑Two types of frame shown:
❑ interaction frames depicting any type of UML interaction diagram (sequence diagram: sd,
communication diagram: cd, timing diagram: td , interaction overview diagram: iod )
❑ interaction occurrence frames (ref; typically anonymous) which indicate an activity or
operation to invoke.

sd Enroll in Seminar lifelines :Student :Seminar :Course :Enrollment

ref sd Determine Eligibility
Select Seminar()
:Student :Seminar :Course {0..7msec}
[not eligible] isEligible(std)
getPrereq ()

cd Determine Seat Availability

[seat available]
Number enrolled
:Seminar :Enrollment
[no seat]

ref
AddToWaitingList()
ref
Enroll in Seminar()
32
 Interaction Overview Diagram
sd Withdrawal

ref
Authenticate

PIN OK PIN NOK

sd sd

:User :ATM :Bank :User :ATM

withdraw
msg (“illegal entry”)
msg (“amount”)
amount (a) chkAcct (a)

sd sd

:User :ATM :Bank :User :ATM :Bank

enough bal
money msg(“amount too big”) not enough bal
receipt

sd

:User :ATM
33
Relationship with Sequence Diagram? msg (“card”)