State Transition Diagrams

Behavioral Diagrams Interaction Diagrams

– Use case
– Sequence;
Communication
– Statechart
– Activity – Interaction Overview
– Timing

1
 State Transitions
• State machine - event-ordered behavior that specifies the sequences of states
an object/instance (of class/interface/collaboration/…/system) goes through
during its lifetime; events trigger transitions and cause responses.
(StateChart is one particular kind of state machine by David Harel)

• State - condition or situation during which an object/instance may perform some

activity; The state of an object is characterized by the value of one or more of its
attributes.

• Activity - ongoing non-atomic execution within a state machine.

• Action - executable atomic computation that results in a change in state of the
model or the return of a value.

event name [guard condition] / action 15 sec

event name (a:T) [guard condition] / action
^object/className.event

send 2
 State Transitions
❑ Each diagram must have one and only one start state
❑ A diagram may have one or more stop states
❑ Automatic transition - occurs when the activity of one state completes
❑ Non-automatic transition - caused by a named event

initialization
event trigger action send signal
add student/ set count=0;^CourseRoster.create(course)
add student
[count<10] [count=10]
guard open closed
triggerless transition
cancel cancel

canceled ^CourseRoster.delete
3
State Transitions – notational variation
[count=10] closed
open
cancel
canceled

[count=10] closed
open
cancel

canceled

not cancel and [count=10] closed

open
cancel

canceled
4
 Advanced States
❑ Entry & exit actions - actions that always occur upon entry into or
exit away from a state regardless of transition.
❑ Internal Transitions - triggered by events but don’t change state.
❑ Activities - ongoing behavior which continues until interrupted.
❑ Deferred events - events ignored by the current state, but postponed
for later processing.
name

Tracking
entry action entry / setMode( onTrack )
exit action exit / setMode( offTrack )
internal transition newTarget / tracker.Acquire()
activity do / followTarget
deferred event selfTest / defer

5
 Substates
❑ Substate -- state nested inside of another state.
❑ Sequential substates (then a nonorthogonal state)
❑ Concurrent substates (then an orthogonal state)

composite state sequential substate

cardInserted Active Initial state/ pseudostate

Idle
Validating [continue]
cancel
maintain Selecting Processing
[not continue] fork Idle
join
Maintenance entry / readCard Printing
exit / ejectCard maintain

Maintenance composite state

Testing
Testing Self
diagnosis H
devices
concurrent
substate Commanding [continue]

Waiting Command H
6
keyPress [not continue]
 Modular Submachines
http://www.xpdian.com/UML2.0changes.html

invoked VerifyCard ATM

submachine
acceptCard usage of
exit point
outOfService ReadAmount :
OutOfService ReadAmountSM aborted

again
rejectTransaction
usage of releaseCard
entry point ReleaseCard
VerifyTransaction

Submachine
ReadAmountSM definition

abort
EXIT point
selectAmount otherAmount

abort
amount EnterAmount
aborted

ok
7
ENTRY point again
 Specialization
• Redefinition as part of standard class specialization

ATM
Behaviour
Statemachine
acceptCard()
outOfService()
amount()

<<Redefine>>

FlexibleATM Behaviour
Statemachine
otherAmount()
rejectTransaction()

8
 Events – External vs. Internal Events
❑ Events can be categorized into external or internal events.
❑ External events are those that pass between the Actors and the system.

System

❑ Internal events pass between objects residing within the application system.

1
NetworkElement NetworkController

elementPort: Port consolePort[2..*] : Port

9
 Events – 4 Kinds: Signals; Calls; Passing of Time; Change in State
• Signal - kind of event that represents the specification of an
asynchronous stimulus communicated between instances.
• Modeled as a class
• Dispatched (thrown) by one object and continues flow of execution
• Received (caught) by another object at some future point in time.

• Can be sent as:

– Action of a state transition
– Message in an object interaction
– Dependencies <<send>> show signals sent by a class

signal MovementAgent
TroubleManager position
<<signal>> <<send>> velocity
Collision
Signals moveTo
force : float
collision( force : float ) send dependency
powerLoss
powerDown Signal parameters
10
• Modeling Signal Receiver: as an active class; Consider 4th compartment for signals.
Events – 4 Kinds: Signals; Calls; Passing of Time; Change in State
Call Events Time & Change Event
❑ Represents the dispatch of an operation • Time event - represents the passage of time:
after( periodOfTime )
❑ Synchronous
• Change event - represents a change in state
or the satisfaction of some condition:
when( booleanExpr )
event

change event

when( 11:49pm ) / selfTest()

startAutopilot( normal )
Manual Automatic time event

Idle

parameter
after( 2 sec ) / dropConnection()

Active
11
 Protocol State Machine
▪ Protocol state machine is a specialization of behavioral state
machine and is used to express usage protocol or life cycle of a
class.
▪ It specifies which operations of the classifier can be called in
which state and under which condition.
▪ It majorly consists of Protocol state transitions
▪ The keyword {protocol} is used to distinguish protocol state
diagram.

12
 Protocol State
▪ The protocol state presents an external view of the state that is
exposed to its clients.
▪ The states of protocol state machines are exposed to the users
of their context class.
▪ States of a protocol state machine can not have entry, exit, or do
activity actions.

13
 Protocol State
▪ Protocol state machines can have submachine states, composite
states and current region.
▪ Concurrent regions make it possible to express protocol where
an instance can have several active states simultaneously

14
The Elevator

15
The Elevator: States

16
 Protocol Transition
▪ A protocol transition is specialization of (behavioral) transition
used for the protocol state machines which specifies a legal
transition for an operation.
▪ Protocol transition has the following features: a precondition
(guard), trigger, and a post condition.
▪ Compound transitions can be used for protocol state machines.
▪ Notation: Transition arrow from the source vertex to the target
vertex, with optional text describing transition.

17
 Protocol Transition
▪ The textual notation for a protocol transition:
▪ Protocol -transition ::= [pre-condition] trigger ‘/’ [post-condition].
▪ Pre-condition ::= ‘[‘ constraint ‘]’
▪ Post-condition ::= ‘[‘ constraint ‘]’

18
Activity Diagrams

Behavioral Diagrams Interaction Diagrams

– Use case
– Sequence;
– Statechart Communication

– Activity – Interaction Overview

– Timing

19
 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] 20
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
21
 Object Flows and Pins

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

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

22
 A Simple Example – Order Processing

activity
parameter
node =
object
node

<<precondition>> Order complete

<<postcondition>> Order closed

23
A Simple Example – Order Processing Using sub-activity

24
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

25
 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. 26
 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
27
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.

28
 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.

29
 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)

30
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.

31