Transcript No Slide Title

Statecharts
Slide: 1
Objectives
 Learn the concepts for modeling object states
 Learn Statechart notation to depict object state models
 Do some modelling…
 Consider some issues…
Slide: 2
Statecharts history and purpose
 Statecharts are a form of state transition diagram (STD) that allow
for nesting, orthogonality (concurrency) and broadcasting, thus
reducing the complexity of many STDs.
 They were invented by Israeli computer scientist David Harel.
 A statechart is used to describe the complex internal behavior of a
class.
 It charts the possible lifecycles of objects from that class. (Similar to
Entity Life Histories)
Slide: 3
Statecharts usage
 A statechart is used to show the life cycle of the objects from
complex classes.
 Simple classes do not need to have statechart.
 The state of an object is related to the values of its variables.
 A statechart can also be used for a system overview.
 A statechart can also be used for interface design.
 A statechart can be used to describe a protocol
Slide: 4
State models - the basics
 State modelling uses a different set of concepts from Class
diagrams, Interaction diagrams etc
 We need to understand the concepts and learn notation

Phases of an object’s lifecycle (States)

How an object changes its state (Events, Transitions)

Behaviour in each state (Actions, Activities)

...
 Also need to tie up with known OO concepts

operations, attributes…
Slide: 5
State models - the basics
 State - “A condition or situation during the life of an object during which it
satisfies some condition, performs some activity, or waits for some event”
 Event - “A significant occurrence that has a location in time and space…a
stimulus that can trigger a state transition”
 Transition - “A relationship between two states indicating that an object in
the first state will perform certain actions and enter the second state when a
certain event occurs and conditions are satisfied”
state
event
click
Off
click
On
transition
Slide: 6
A simple Statechart (Door)
close
Open
open
lock
Closed
(unlocked)
unlock
Closed
(locked)
Slide: 7
Initial & Final States
Baby
Toddler
Initial State
Child
Teenager
Adult
Final State
Slide: 8
Thinking about Time
 For a class with a Statechart, each object is always in one of the
defined states - never between states
 Therefore events and transitions are regarded as having zero or
insignificant duration (ie there are no gaps between states)
LAMP
Off
On
Off
On
Off
TRAFFIC LIGHT (UK)
Time
Slide: 9
Actions
 Action - “An executable atomic computation that results in a change of state
of the system or the return of a value”
 Deemed to have insignificant duration & be non-interruptible
 Actions may appear on transitions, or inside states (internal transition).
Burglar Alarm System
code entered / beep
Idle
Armed
intruder detected
code entered/ beep
/ start alarm
test button pressed
test button pressed
code entered /
Ringing
silence alarm
Test Mode
intruder detected / beep
Slide: 10
Activities
 Activity - “ongoing non-atomic execution within a state machine”
 Has duration & is interruptible
 Can only be placed inside states (not on transitions).
 May be a sequence of actions or may name another state machine
 Indicated by keyword do/
Idle
Armed
code entered / beep
intruder detected
Counting
/ start alarm
Ringing
do / countdown
Slide: 11
Activity states
 States with ongoing activities are known as Activity States
 UML provides an alternative notation to visually distinguish them
 Activity States also used in Activity Diagrams
Ordinary State
Activity State
Slide: 12
Automatic transitions
 Aka Triggerless transition or Completion transition
 “Triggered implicitly when source state completes its activity”

so this activity cannot be an endless loop
Activity state
Counting
code entered / beep
Idle
Automatic transition
- requires no event
Ringing
Slide: 13
Useful Keywords
 entry/ - pseudo event inside a state, associated action(s) to be
performed whenever the object enters (or re-enters) the state.
 exit/ - pseudo event inside a state, associated action(s) to be
performed whenever the object leaves the state.
 do/ - inside a state, identifies an activity
 after/ - indicates a relative time. Eg after 2 seconds; after 1 ms
since exiting idle. (Default start time is entry to current state)
 when/ - indicates a condition becoming true (including absolute
times)
Eg when 11.30; when temp < 0.
 /defer - pseudo action inside a state, associated event(s) not
handled in current state, but not totally discarded either - queued for
handling in a subsequent state.
Slide: 14
Processing Sequence
 When event E occurs (and object is in state A):

Activity A is terminated.

Exit action K is performed.

Action X on the transition is performed.

Entry action P is performed.

Activity B is started.
State A
State B
event E / action X
do / activity A
do / activity B
entry / action J
exit / action K
entry / action P
exit / action Q
Slide: 15
Self Transitions
 Event E (self transition) =>

Stop activity A

Perform actions K, X, J

Start activity A
 Event F (internal transition) =>

Perform action Z
State A
event E / action X
do / activity A
entry / action J
exit / action K
event F / action Z
Slide: 16
Statecharts - advanced
Slide: 17
Guard conditions
 Qualifies whether to respond to event
 Boolean condition
 Evaluated when event is detected
 Actions/transition only occur if condition is true
 Allows same event to be associated with multiple responses
Spaces
Available
booking [delegates < capacity] /
add delagate
booking [delegates = capacity]
Full
A training course
Slide: 18
Sub-states
 A state can be decomposed into sub-states
 One of the sub-states can be the default initial state for that super-
state
 Transitions can go to & from super-state or sub-states

entry/exit actions performed in defined sequence
Super
Sub1
Sub2
Slide: 19
Concurrent sub-states
Overhead Projector
On Desk
Light Off
On Floor
Light On
Slide: 20
State explosions
A text item – most transitions not shown!
Bold on
Italics off
Underline off
U
B
Bold off
Italics off
Underline off
B
I
Bold off
Italics on
Underline off
U
Bold on
Italics off
Underline on
I
I
I
Bold on
Italics on
Underline on
U
U
B
B
Bold off
Italics off
Underline on
Bold off
Italics on
Underline on
Bold on
Italics on
Underline off
Slide: 21
Orthogonal states
Bold on
B
B
Bold off
Underline on
Italics on
I
Italics off
I
U
U
Underline off
Slide: 22
History states
B
A
interrupt
B1
C
resume
B2
H*
H
indicates a deep history
Slide: 23
Junction States
Junction states
entry / q
/b
/c
e /a
Source
f / a;b;c
Target
exit / p
Outcomes -
e / a; p; b; q; c
f / p; a; b; c; q
Slide: 24
Join and Fork
fork
A1
A2
B1
B2
join
Slide: 25
Implementing States
 Statechart concepts must be mapped to OO concepts
 Events, States, Actions, Activities, Transitions, Guards
Class
operations
attributes
A
B1
associations
Class
B2
Slide: 26
‘State’ Design Pattern (1)
 INTENT – Allow an object to alter its behaviour when its internal state
changes. The object will appear to change its class.
TCPConnection
Heuristic – normally an
object should not actually
change its class
TCPEstablished
open()
close()
acknowledge()
open()
close()
acknowledge()
X
TCPListening
TCPClosed
open()
close()
acknowledge()
open()
close()
acknowledge()
From Design Patterns
Gamma, Helm, Johnson, Vlissides
Slide: 27
‘State’ Design Pattern (2)
TCPConnection
TCPState
open()
close()
acknowledge()
open()
close()
acknowledge()
TCPEstablished
TCPListening
TCPClosed
open()
close()
acknowledge()
open()
close()
acknowledge()
state.Open()
open()
close()
acknowledge()
From Design Patterns
Gamma, Helm, Johnson, Vlissides
Slide: 28
Statechart example
Initial State
Final State
shutDown
Event (event parameter)
Idle
tooCold( desiredTemp )
atTemp
atTemp
tooHot( desiredTemp )
State
Heating
Cooling
tooCold( desiredTemp )
Activating
Transition
Action
ready / turnOn()
tooHot( desiredTemp )
Active
Nested State
Slide: 29
Object Constraint Language
Slide: 30
What is a constraint
{self.transaction -> forAll(t:Transaction | t.value > 100)}
Account
1
0..*
Transaction
An Account can only
hold transactions
worth more than £100
Slide: 31
Design by Contract
put (element: T, key: STRING) is
-- insert element with given key
require
count < capacity
do
.. insertion algorithm ...
ensure
count <= capacity;
item (key) = element;
count = old count + 1
end --put
Obligations
Benefits
Client
Call put only on a
non-full table
Get modified table
in which x is
associated with key
Contractor
Insert x so that it
may be retrieved
through key
No need to deal with
the case in which the
table is full before
insertion
Slide: 32
OCL requirements
 The OCL must enable us to express extra, necessary,
information on object models.
 The OCL must be a precise and unambiguous language
that can be easily read by developers and customers.
 The OCL must be a declarative language, its
expressions can have no side-effects.
 OCL must be a typed language so that OCL expressions
can be type checked for correctness.
Slide: 33
OC Language is ...
 OCL is a typed language
 The OCL is a language of expressions.
 An OCL expression is valid if it is written according to the rules
(formal grammar) of OCL.
 A constraint is a valid OCL expression of type Boolean.
 A constraint is a restriction on one or more values of (part of) an
object-oriented model or system.
Slide: 34
Boolean expressions
Customer
name: String
title: String
age: Integer
isMale: Boolean
title = if isMale then ‘Mr.’ else ‘Ms.’ endif
age >= 18 and age < 66
name.size < 100
Slide: 35
Context for a constraint
Vehicle
1..4
Wheel
Vehicle
self.wheelCount <= 4 and self.wheelCount >= 1
Slide: 36
Multiplicity constraints
Vocabulary
1
0..*
VocabElement
1
0..5
Hint
Equivalent constraints expressed on the classes
VocabElement
self.hint -> size >= 0 and self.hint -> size <= 5
VocabElement
self.vocabulary -> size = 1
Hint
self.vocabElement -> size = 1
Slide: 37
Subset constraint
pilot
Flight
crew
1..*
Person
0..*
flightAttendant
Flight
self.crew -> includes( self.pilot )
Flight
self.crew -> includesAll(self.flightAttendants)
Slide: 38
OCL collections
Collection
Set
minus
symmetricDifference
asSequence
asBag
Bag
asSequence
asSet
Sequence
first
last
at(int)
append
prepend
asBag
asSet
Slide: 39
OCL Summary
 Constraints are required in the UML because the notations can
never be sufficiently expressive to capture all we know.
 Constraints are one way to practice design by contract.
 The OCL is a formal notation for precisely specifying constraints in
object models.
Slide: 40
Module Summary
 Statecharts in UML are related to classes and
they describe the possible lifetimes of all the
possible objects from that class.
 Statecharts are an advance on earlier state
modeling notations because they allow
nesting and concurrency.
 Statecharts are only drawn for classes with
significant complexity.
 Statecharts can be used for more than object
lifecycle modeling.
Slide: 41
Questions or Comments?
Slide: 42