38
Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

  • View
    227

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

Mastering the Unified Modeling Language

-- State Transition Diagrams --

© Josef Schiefer, IBM Watson

Page 2: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Outline

Combinatorial Explosion

Diagram Elements

Statecharts

UML State Machines

UMLState Diagrams

12/7/2000 - v2

States & Transitions

Solution: Statecharts

states

transitions

events

actions

guards

conditions

nested state diagrams

concurrent state machines

messages

...

Stubbed Transitions

Synchronization

Concurrency vs. Orthogonality

History Indicator

Sending Messages

Compound Transitions

Page 3: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Introduction to State Diagrams

Interaction diagrams are very good for communication– between clients and designers

– between designers and other designers

– between designers and implementors

But they are not part of the constructive core– Constructive core means that part from which an actual implementation

could be generated

The constructive core of the UML is– class diagrams (for the static part)

– state diagrams (for the dynamic part)

State diagrams can bescribe very complex dynamic behavior

Page 4: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Elements of State Diagrams

The basic elements of state diagrams are– states – the state in which the object finds itself at any moment– transitions – take the object from one state to another– events – cause the transition from one state to another– actions – take place as a result of a transition

In the UML, many other extensions have been added, such as:– generalization/Inheritance among events (i.e. a mouse click and keyboard

input as subclasses of user interface events)– hierarchical diagrams for managing complexity (from StateCharts)– guards – conditions on transitions

State Diagrams should only be used for objects with significant dynamic behavior

Page 5: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Types of Events

ChangeEvent (i.e.: when(x>y))– A change event models an event that occurs when an explicit boolean expression

becomes true as a result of a change in value of one or more attributes or associations. – A change event is raised implicitly and is not the result of some explicit change event

action.

CallEvent (i.e.: conflictsWith(Appointment))– A call event represents the reception of a request to synchronously invoke a specific

operation.– Note that a call event instance is distinct from the call action that caused it.

SignalEvent (i.e.: leftButtonDown)– A signal event represents the reception of a particular (asynchronous) signal.

TimeEvent (i.e.: after(1 second))– A TimeEvent models the expiration of a specific deadline. Note that the time of

occurrence of a time event instance (i.e., the expiration of the deadline) is the same as the time of its reception.

Page 6: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

States and Transitions

On FirstFloor

MovingUp

IdleMovingDown

Moving toFirst Floor

up floor

arrive atfloor

up floor

arrive at floor

down floor

time-out

arrive atfirst floor

transition state

An Elevator

Page 7: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Basic UML State Diagram Syntax

A state is drawn with a round box, with three compartments for– name

– state variables (if any)

– actions to be performed

A transition is drawn with an arrow, possibly labeled with– event causing the transaction

– guard condition

– Action to perform

Name

state variables

actions

sometimesleft out whenempty

AnEvent [guard] / SomeAction

Page 8: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

State Diagram for Seminar Registration

AddParticipant / Set count = 0

cancel seminar

event action, taken duringtransition

Setup

do/initialize seminarAvailable

do/initialize seminar

Full

do/finalize seminar

[ count = 20 ]

guard

Canceled

do/refund payments

cancel seminar

multipleexits

cancelseminar

aktivity, carried outwhile in that state

Page 9: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Predefined Action Labels

“entry/”– identifies an action, specified by the corresponding action expression,

which is performed upon entry to the state (entry action)

“exit/”– identifies an action, specified by the corresponding action expression, that

is performed upon exit from the state (exit action)

“do/”– identifies an ongoing activity (“do activity”) that is performed as long as

the modeled element is in the state or until the computation specified by the action expression is completed (the latter may result in a completion event being generated).

“include/” – is used to identify a submachine invocation. The action expression contains

the name of the submachine that is to be invoked.

Page 10: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Simple Diagram for Heart Monitor Applications

Startup

Alarm

Operational

Off

Switch on

Switch off

Switch off

StartupComplete

Problemdetected

Problemdetected

Page 11: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Full Diagram for Heart Monitor Applications

StartupBattery

OffStartupMains

OperationalBattery

OperationalMains

etc.

AlarmBattery

AlarmMains

The number ofstates andtransitions hasgrown quickly

Why does thediagram growso fast?

Page 12: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Independent State Components

We can explore the phenomenon of rapid state diagram growth by examining a typical class with three attributes

Each combination of values of the attributes of this class constitute a different state for the class

Note that the attributes are effectively independent of each other– any combination is valid

Widget

Color (red, blue, green)Mode (Normal, Startup, Demo)Status (Ok, Error)

SetColor()SetMode()SetStatus()

Number of States = 3 x 3 x 2 = 18!!Number of States = 3 x 3 x 2 = 18!!

Page 13: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Combinatorial Explosion

The number of states and the number of transitions grows very quickly as you model complex state machines ( combinatorial explosion)

This is the Achilles Heel of finite state machines– It has prevented the widespread use of

state machines in the past

Page 14: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Some State Diagram History

Traditional state diagrams are called Mealy-Moore diagrams after their “inventors”

They have small differences– Mealy FSMs allow actions only when

a transition is taken

– Moore FSMs allow actions only upon state entry

But they did not solve the problem of combinatorial explosion– Something new was needed if state

diagrams were to survive

State Diagrams - Mealy - Moore - ?

Page 15: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Statecharts

1983: A new visual formalism extending the language of state diagrams – Statecharts

Developed by David Harel– Professor at Weizmann Institute,

Israel

– Complexity theory, logic, reactive systems engineering, …

– Popular educator, author, wroteAlgorithmics, the Spirit of Computing

– Founded company I-Logix (www.ilogix.com) to create tool support for Statecharts (Statemate, Rhapsody)

Page 16: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Features of Statecharts

Harel statecharts directly address the problems of traditional state diagrams

Two major features are introduced for controlling complexity and combinatorial explosion– nested state diagrams

– concurrent state diagrams

Many other features are also added– propagated transitions

– broadcast messages

– actions on state entry, exit

– …

S2

S1

Nested State Diagrams

Concurrent State Diagrams

Page 17: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

UML Statechart Diagrams

Harel statecharts are the basis for the UML state diagram notation– formally “UML statechart diagrams” in the UML documentation

– informally usually just referred to as “state diagrams”

Original statechart notation was not object-oriented– based on traditional function-oriented, structured analysis paradigm

UML added features to support object orientation– Support of inheritance (of events, transitions, etc.)

– Delegation of messages within composite objects

– Etc.

Page 18: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Nested State Diagrams

Hierarchical organization is a classic way to control complexity– of programs– of documentation– of objects– …

Even diagrams can be hierarchical– Traditional data flow diagrams are

hierarchical

Why not state diagrams?– superstates– substates

superstate

substates

Page 19: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Superstates and Substates

State model fortelephone dialing

Digit(n)

substates

LiftReceiver

entry/ start dial toneexit/ stop dial tone

self-transition

enclosing superstate

LiftReceiver

entry/ AddDigit

TheNumber: int

Digit(n)

terminal state

Dialing

name of superstate

Page 20: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Stubbed Transitions

Nested states may be suppressed

Subsumed transitions that do not come from an unlabeled final state or go to an unlabeled initial pseudostate may (but need not) be shown as coming from or going to stubs

A stub is shown as a small vertical line (bar) drawn inside the boundary of the enclosing state

may be abstracted as

S

C

D

E

F

A

B

SE

F

A

B

Page 21: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Some More UML State Diagram Notation

Nested states are show by an enclosing rectangle– The name of the superstate is indicated in

the upper left-hand corner

A middle compartment can contain state variables (if any)

Entry, exit, do actions may be defined– ‘entry’, ‘exit’, ‘do’ are reserved words

Self-transitions may occur– from the state back to itself

– the entry and exit conditions are performed in that case

Login

entry/ type 'login'exit/ login(user name, password)do/ get user namedo/ get passwordhelp/ display help

Login time = Current Time

user-defined eventand action

Page 22: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Eliminating Duplicated Transitions

Transitions are often duplicated when there is some transition that can happen from every state– “error”

– “quit”

– “abort”

These duplicates can be combined into a single transition– a transition from a superstate is

valid for all of its substates!

Quit

Quit

Page 23: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

The Heart Monitor Revisited

Startup

Alarm

Operational

Off

Switch on

Switch off StartupComplete

Problemdetected

Runningtransition fromsuperstate

transition tosubstate

The duplicatetransitios havebeen elimiated!

Page 24: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Transitions to and from Nested States

Transitions can be specific– A transition can be from a specific

substate (T1)

– A transition can be to a specific substate inside the nested state (T2)

Transitions can be general– We saw that a transition from the

superstate is valid for all substates (T3)

– A transition into the superstate (T4) normally goes to the default initial state (start state leading to F)

T1

S

A B

E

F

CD

T2T4

T3

Page 25: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Handling Interrupted States

Sometimes it is necessary to interrupt a complicated procedure and then resume where you stopped

Consider an “install” program on your computer– “Out of memory: please delete some files and hit

continue”

Any situation in which a normal course of events is interrupted and then resumed– How can this be handled in a nested state diagram?

Page 26: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

The State History Indicator

Suppose an interrupt transition occurs from any one of the substates (A1, A2, A3) out of the Install superstate

The rescue transition takes it back into the Install superstate

The history indicator is show with an “H” inside a circle

– it means “return to the last state you were in before leaving”

‘H*’ indicates deep history. This indicates that the object resumes the state it last had at any depth within the composite region, rather than being restricted to the state at the same level as the history indicator.

Install

A

A1 A2

Pause

A3H

Resume Interrupt

Page 27: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Concurrent State Machines

Complex systems usually have concurrency– “subsystems” that operate (mostly)

independently

Back to the heart monitor device– The power supply and the heart

monitoring application are really concurrent subsystems

– They should be modeled that way!!

– They are mostly independent: the monitoring application doesn’t care where it gets its power

Heart Monitor

MonitoringSubsystem

PowerSubsystem

Page 28: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Heart Monitor as Concurrent State Machine

Startup

Alarm

Operational

Off

Switch on

Switch offStartup

Complete

Problemdetected

Running

Monitoring Subsystem

MainsBattery

Mains off

Mains on

Dotted lineseparatesconcurrent statemachines

Power Subsystem

Page 29: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Complex Transitions

Concurrent state machines sometimes need to be synchronized with each other– start together

– run through independently until their terminal state

– re-sychronize at the end

Complex transitions allow this kind of synchronization– Petri net notation

T1

Cleanup

A1 B1

A2 B2

Startup

Page 30: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Cooperating Independent State Machines

Concurrent and independent state machines will normally have to communicate with each other if they are cooperating

Example: remote control of television and VCR– three independent systems

– three independent state machines

– but clearly they cooperate with each other

How to model this in UML?

Page 31: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Sending Messages Between State Diagrams

state machines can sendmessages to each othe

VCR

Stop

Play

Off

Toogle

Toggle Stop

On

Play

Remote Control

Control VCR Control TV

Toogle

Stop Play

Toogle

Toogle Stop PlayTV

Off

On

ToggleToogle

Toogle

Page 32: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Orthogonal Components

The concurrent state machine notation can control combinatorial of states

The three components of our widget class (color, mode, status) are orthogonal– they change states independently

Their orthogonality can be modeled explicitly with statechart notation

Color

Blue

Red Green

Error

OK

Normal

Startup

Demo

Mode

Status

Page 33: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Concurrency and Orthogonality

The heart monitor is an example of two concurrent subobjects– the internal battery and the heart monitoring application are two

(almost) independent FSMs– they exhibit true concurrency

The widget is an example of an object with orthogonal components– it is a single object with a complex specification logic– there are not concurrent threads of execution

The are NOT the same thing– but the UML notation is useful for handling the complexity

introduced by each of them

Page 34: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Compound Transitions

A compound transition is an acyclical unbroken chain of transitions joined via join, junction, choice, or fork pseudostates that define path from a set of source states to a set of destination states

S Te / a / b / c

f / d

M N

exit / p entry / q

junction point

Page 35: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Dynamic Choice Points

The outgoing transition whose guard is true at the time the choice point is reached, will be taken

If multiple transitions have guards that are true, one transition from this set is chosen

If multiple transitions have guards that are true, one transition from this set is chosen

If no guards are true after the choice point has been reached, the model is ill formed

S T

U

e / a:=a+1 [a>0] / b

[else] / c

Page 36: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

Sync State

P2P1

Producer

C2C1

Consumer*

Vertex used for synchronizing the concurrent regions of a state machine

It is different from a state in the sense that it is not mapped to a boolean value (active, not active), but an integer

Is used in conjunction with forks and joins to insure that one region leaves a particular state or states before another region can enter a particular state or states

Page 37: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

When to Use State Diagrams

Interaction diagrams (collaboration & sequence) are most appropriate for describing inter-object behavior

State diagrams are particularly intended for describing intra-object behavior– precise description of behavior inside a single class with

complex behavior

But there are sometimes exceptions– the remote control example showed that state diagrams are

sometimes useful to model interaction among objects

– they are sometimes useful to describe complicated behavior inside a use case

Page 38: Mastering the Unified Modeling Language -- State Transition Diagrams -- © Josef Schiefer, IBM Watson

UML State Machines

UML Literature (for State Diagrams)

Rational Software Corp. - UML Documentation: http://www.omg.org/uml

OMG – UML Documentation: http://www.omg.org/uml

James Rumbaugh, Ivar Jacobson, Grady Booch: The Unified Modeling Language Reference Manual

D. Harel: Statecharts: A Visual Formalism for Complex Szstems

D. Harel: On Modeling and Analyzing System Behavior: Myths, Facts and Challenges