THE OBJECT-ORIENTED DESIGN WORKFLOWStatechart Diagrams

Statechart Diagrams

Activity diagram versus a statechart diagram– Both model DYNAMIC behavior of a system– Activity diagrams are a special case of a statechart

diagram where the states are actions and the transitions are triggered automatically by the completion of a state’s action and activities

– Activity diagrams tend to be used for modeling business processes where several objects participate

– Statechart diagrams tend to be used for modeling the lifecyle history of a single reactive object (respond to external events, have states and transitions)

– Statechart most commonly used to model dynamic behavior of classes

Statechart Diagrams

Statechart Diagram– Statecharts (state diagrams) show the lifetime

behavior of a single object– Used to capture dynamic behavior by describing

all possible states and state changes as a result of events that reach the object

Finite State Machine (FSM)

A finite state machine is a conceptual machine with a finite number of states

It can be in only one of the states at any specific time

A state transition is a change in state that is caused by an input event

The next state depends on the current state as well as the input event

In UML, a state transition diagram is called a state chart

State Machines

States

The UML Reference Manual defines a state as, “a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event”.

The state of an object varies over time, but at any particular point it is determined by:– the object attribute values– the relationship it has to other objects– the activities it is performing

Key to successful statechart modeling is identifying the states that make a difference in your system

States

State Syntax

EnteringPassword

entry/display passwordexit/validate

alphaKeypress/echo “*”help/display

do/get

state name

entry and exit actions

internal transitions

internal activity

• Each state may contain zero or more actions and activities• Actions are instantaneous and uninterruptible• Activities take a finite amount of time and can be interrupted

Simple Example – Light Bulb

Off

On

turnOff turnOn

event trigger

Simple Example – Bank Account

Actions & Activities

Two special actions:– Entry action (associated with entry event)– Entry event occurs instantaneously and automatically on

entry into the state» It is the first thing that happens when the state is entered» Causes the associated entry action to execute

– Exit event is the last that happens instantaneously and automatically on exit from the state» Causes the associated exit action to execute

Activities take a finite time and may be interrupted by the receipt of an event– Keyword do indicates an activity– May not finish due to interruption

Transitions

UML Syntax

anEvent – this is an external or internal occurrence that triggers the transition

guardCondition – this is a Boolean expression the must evaluate to TRUE before a transition can occur

anAction – this is a piece of work associated with the transition and occurs when the transition fires

A BanEvent [guardCondition] / anAction

UML Transition Syntax

Transitions

Events and External Actions

State transitions occur in response to events If there is more than one transition out of a state, a guard

condition determines which transition is fired An action may occur when the transition fires (multiple

actions should be expressed in a comma separated list) If there is no action associated with a transition, the event

only causes the change of state, and there is no observable response from the object unless it has internal actions

State_1

State_2

entry / entry_actionexit / exit_action

do / activity

event [guard] / action

Types of Events

Call event– simplest type of event– the receipt of a call

event is a request for a set of actions to occur

– Really just a request for a specific method to be invoked

Call Events

deposit(m)/balance:=balance+mwithdraw(n)/balance:=balance-n;return balance

InCredit

deposit(m)/balance:=balance+mwithdraw(n)/balance:=balance-n;return balance

Overdrawn

[balance < 0] [balance >=0]

Bank Acccount

Types of Events

Signal Event– Package of information that is

sent asynchronously between objects

– Modeled as a stereotyped class that contains all of the communication information as its attributes

Signal Events

in date : charin accountNumber : longin amountOverdrawn : double

«signal»OverdrawnAccount

Types of Events

Change events– has the keyword

when, and then a Boolean expression

– action associated with the event is performed when the Boolean expression is true

– All values in the Boolean expression must be attributes of the context class

InCredit

when(balance<overdraftLimit/notifyManager

Overdrawn

[balance < 0] [balance >= 0]

Change event

keyword

Boolean expressionaction

Time Events

Time events are denoted by the keywords when and after– keyword when specifies a

particular moment in time that the event triggered

– keyword after specifies a threshold time after the event triggered» e.g. after (3 months) and

when (date = 08/04/04)

when(balance<overdraftLimit)/notifyManager

Overdrawn

Frozen

[after (3 months)]

Time events

Methods and attributes

The state of an object will be determined by the values of the attributes of the class– in many cases, only a subset of the attributes will be relevant for

modelling the state– looking at the attributes should help identify possible states– an event causing a change of state leads to a change in the object’s

attribute values Events can be implemented as public methods

– the object is notified of an event by receiving a message from another object

Actions and activities should be implemented as private methods– it should not be possible for actions to be invoked without a valid

event occurring Entry, exit and internal actions should also be private

methods

Guidelines for Developing Statecharts

Guidelines for Developing Statecharts

A state name must reflect an identifiable situation or an interval of time when something is happening in the system.

Each state must have a unique name. It must be possible to exit from every state. On a flat (not hierarchical, composite) statechart, the system

is in one state at a time. An event is the cause of the state transition. An action is the

effect of the state transition. An event happens at a moment of time; an action happens

instantaneously; an activity executes throughout a state. Actions, activities and conditions are optional. Use only as

necessary.

Developing Statecharts from Use Cases

To develop a statechart from a use case, start with a typical scenario given by the use case.– This scenario should be the most typical path through the

use case, involving the most usual sequence of interactions between the actor(s) and the system.

Then consider the sequence of external events given in the scenario.– In each case, an input event from the external

environment causes a transition to a new state.– An action or an activity may associate with the transition.– Actions and activities are determined by considering the

response of the system to the input event, as given in the use case description.

Developing Statecharts from Use Cases

Initially, a flat statechart is developed following the event sequence given in the scenario.

To complete the statechart, determine all the possible external events that could be input to the statechart.– You do this by considering the description of alternative

paths given in the use case.

Example of Developing a Statechart from a Use Case

Actor: Driver Summary: This use case describes the automated cruise

control of the car, given the driver inputs via the cruise control lever, brake, and engine external input devices.

Precondition: Driver has switched on the engine and is operating the car manually.

Description:– 1. Driver releases the cruise control lever in order to cruise at a

constant speed. The system stops automatic acceleration and starts maintaining the speed of the car at the cruising speed. The cruising speed is stored for future reference.

– 2. Driver presses the brake to disable cruise control. The system disables cruise control so that the car is once more under manual operation.

– 3. Driver moves the cruise control lever to the ACCEL position and holds the lever in this position. The system initiates automated acceleration so that the car automatically accelerates.

Example of Developing a Statechart from a Use Case

Description (continued):– 4. Driver moves the cruise control lever to the RESUME

position in order to resume cruising. The system initiates acceleration (or deceleration) toward the previously stored cruising speed.

– 5. When the system detects that the cruising speed has been reached, it stops automatic acceleration (or deceleration) and starts maintaining the speed of the car at the cruising speed.

– 6. Driver moves the cruise control lever to the OFF position. The system disables cruise control, so the car is once more under manual operation.

– 7. The driver stops the car and switches off the engine.

Example of Developing a Statechart from a Use Case

Alternatives:– 1. The Accel, Cruise, Resume, and Off external events from the cruise

control lever. The Accel event causes automated acceleration, providing the brake is not pressed. The Cruise event may only follow an Accel event. The Resume event may only occur after cruising has been disabled and the desired cruising speed has been stored. The Off event always disables cruise control.

– 2. The Brake Pressed and Brake Released external events from the brake. The Brake Pressed event always disables cruise control. Automated vehicle control is not possible as long as the brake is pressed. After the brake is released, automated vehicle control may be enabled.

– 3. The Engine On and Engine Off external events from the engine. The Engine Off event disables any activity in the system.

Postcondition:– The car is stationary, with the engine switched off.

Cruise Control Statechart

Statechart Example – SSN Pin Validation

ATM Example

ATM Example – Single Session

Loan Approval Example

ISP Dial-UP Example

Modeling the Lifetime of an Object