State Machine Model. C-S 5462 State Machine View describes the dynamic behavior of objects over time –each object is treated in isolation –the view describes.

State Machine ModelState Machine Model

C-S 546 2

State Machine View

• describes the dynamic behavior of objects over time– each object is treated in isolation– the view describes the events and operations

that manipulate the object• the state view of the entire system is described by

a collection of state diagrams, one corresponding to each class in the system

C-S 546 3

About State Diagram

• one state diagram per class in the class diagram• one logical state diagram may be spread out into

one or more physical diagrams for space considerations

• enrichment of the finite state machine model• based on David Harel’s State charts, tailored

towards object-orientation

C-S 546 4

Main components of a state diagram

• a collection of states of the object under consideration

• a collection of actions while entering a state, existing a state or within a state

• a collection of transitions between the states of the object

• a collection of events that trigger transitions • a collection of conditions (optional) that might

constrain the triggering of events, or implementations of transitions

C-S 546 5

State diagram – basic syntax

initial

final

State name

Unnamed states

entry/ …

exit/ …

do/

event (params) [guard] /

action (params)

actions

actions

event (params)

event (params)

C-S 546 6

State diagram - semantics• there must be exactly one initial state and

one or more final states

• a transition between states is represented by the event that triggers the transition (a more concrete definition given later)

• transitions may have guards or conditions under which the transitions fire

• the actions associated with a transition will be executed as soon as the transition fires

C-S 546 7

State diagram – semantics (continued)

• a state may optionally have a label

• every state may have – an entry action – executed as soon as the state is

entered– an exit action – executed just before leaving the

state– a “do” action – executed while the object is in

this state; may be ongoing until the object leaves the state

C-S 546 8

State – a formal definition• is a condition during the life of an object during

which the object performs an action or waits for some event

• is represented by the collection of attributes and their corresponding values

• an object after being created must be at one particular state at any instant– unless otherwise mentioned, an object remains in a state

for a finite time– UML allows modeling of transient states (states that exist

only for a very short and insignificant duration)

C-S 546 9

State – a formal definition (continued)

• (directly or indirectly) includes links (instances of associations) connected with the object at that instant

• may be decomposed into concurrent substates (AND relationship)

• may be composed using mutually exclusive disjoint substates (OR relationship)

C-S 546 10

Event – a formal definition

• a noteworthy occurrence– UML manual

• something that happens within the system or interacting with the system at an instant

• something that has a significant impact on the system• examples

– sending a signal or data– receiving a signal or data– making a request for execution– a Boolean condition becoming true– a timeout condition becoming true– …

C-S 546 11

Four types of events in UML

• signal event– occurs when an object sends a signal to another object

• call event– occurs when a method or operation in an object is

invoked

• change event– occurs when a Boolean condition is changed

• time event– occurs when a time limit has reached

C-S 546 12

Representation of events

• events are represented by unique labels in the diagram

• sometimes the transitions that are fired by the occurrence of the event is also represented by the same label

• change event labels are preceded by the keyword “when”

• time event labels are preceded by the keyword “after”

C-S 546 13

Generating an Event

• an event is generated by the runtime system– asking for inputs– producing outputs– execution of a method– transfer control of execution from one object to

another (sending messages or receiving messages)

– abnormal termination– error handling, exceptions

C-S 546 14

Temporal properties of Events

• an event is considered to be instantaneous– occurrence of an event causes negligible time

– this time is not included in the modeling

• events may have precedence relationships among them– “opening an account” precedes “depositing into

account”

– “graduation” occurs only after “finishing all requirements” and “clearing pending dues”

C-S 546 15

Transition

• represents the change of states of an object– switch from “Joined University” to “Registered

for Fall”

• is an abstraction of an operation– registering for a course

• has finite and significant duration– time taken to complete registration of one

course

C-S 546 16

Transition (continued)

• may have parameters– a transition corresponding to the registration process

may have “course name” and “prerequisites” as parameters.

• is triggered/invoked/fired by the occurrence of an event– change of semester from “Summer” to “Fall” may

initiate the registration process– request by administration or department may initiate

the registration process

C-S 546 17

Transition (continued)• may have a guard/condition

– transition for registration may require that the student must have his/her ID validated

– transition for graduation may require previous library dues to be paid off

– transition to admit new students may require that the students can register only after officially admitted into the program

• an event may cause several transitions to fire– completion of registration process may cause the course

object to update its enrolment and at the same time, the account object to update the tuition fees to be paid

C-S 546 18

Transition (continued)• is normally identified by the same label as

the event that fires the transition– “register”, “withdraw”, …

• may be associated with an action– different from actions associated with the states – “register” may have an action to check the

validity of parameters, to check that no previous registration has been done for the same set of parameters etc.

C-S 546 19

Example 1 – State of a “Student”

Student

name : String

id : Integer

courses : set of CourseID

Class definition

: Student

name = “John”

id = 1514601

courses = {CS546, CS742}

The state of a student object

: Student

name = “John”

id = 1514601

courses = {CS546, CS742, CS551}

Another state of the student object

C-S 546 20

Example 1 – simplified representation

Student

courses : set of CourseID

: Student

courses = {CS546,CS742}

: Student

courses = {CS546, CS742, CS551}

Indicate only those attributes that define change of state

C-S 546 21

Example 1 – state diagram for Student class

Initial continuing

completed

register[#courses < minRequired] / updateCourses()

register [#courses < minRequired] / updateCourses()

register [#courses >= minRequired] / updateCourses()graduated

entry/ initializeCourses()

C-S 546 22

Example 1 - Exercise

• The given state diagram for the student class is incomplete. Complete the diagram to include all the transitions and also include transitions that correspond to withdrawing from a course

C-S 546 23

Example 2 – State diagram for Account class in ATM

initial Normal

Overdraft

deposit / deposit()

withdraw [amt = balance] / withdraw()

deposit/ deposit()

withdrawNormal [amt < balance] / withdraw()

withdrawInitial / withdraw()

open/ open()

clos

e/

clos

e()

closeAC [amt=-balance] / deposit()

depositOP [amt=-balance]/ deposit()

depositOP [amt < -balance] / deposit()

withdrawOP / withdraw()

C-S 546 24

Example 2 - Exercise

• Complete the state diagram for the Account class in ATM, by including any missing transitions.

• The diagram assumes that there is no limit on overdraft protection. Make changes to the diagram assuming that there is an overdraft limit of $N.

C-S 546 25

Communications between objects

• Objects communicate by sending messages to each other.

• A message is realized as an event/transition in a state diagram.

• The object that sends the message is said to generate an event.– Modeled by the action associated with the transition

• The object that receives the message is said to realize / accept that event.

C-S 546 26

Example – A user object in ATM

Deposit / deposit_User()

Withdraw / withdraw_User ()

Using Machine

C-S 546 27

Documentation• State: Using Machine

– This is the only state for this object and hence no need to enumerate the variables by which this state is defined

• Transitions– Event : Deposit

• Parameters : amount• Conditions : None• Action: deposit_User (amount)• Events generated: deposit OR depositOP• Communicating objects : Account

– Event : Withdraw• Parameters : amount• Conditions : None• Action: withdraw_User (amount)• Events generated : withdraw OR withdrawOP OR withdrawInitial or

withdrawNormal• Communicating objects : Account

C-S 546 28

Documentation – alternate style

• State: Using Machine

– This is the only state for this object and hence no need to enumerate the variables by which this state is defined

• Transitions– Deposit (amount) / deposit_User (amount);

Account.deposit (amount) OR Account.depositOP (amount)

– Withdraw (amount) / withdraw_User (amount);

Account.withdraw (amount) OR

Account.withdrawOP (amount)

Account.withdrawNormal (amount)

Account.withdrawInitial (amount)

C-S 546 29

Simple and composite states

• A state is composite, in contrast to a simple state, if it has a graphical decomposition– UML Manual version 1.5

• A diagram for a composite state has two or more sub-diagrams connected by simple and/or concurrent transitions– Example: concurrent states

• The word “superstate” is used sometimes to refer to a composite state

C-S 546 30

Composite State – basic syntaxSimple State Simple State

C-S 546 31

Composite State – Transparent Transitions

Simple State Simple State

C-S 546 32

Composite State - Example

CD drawer closed

CD drawer open

No CD Loaded

CD loaded

CD playing

CD paused

CD stopped

Power ON [no CD]

Power ON [CD in]

Power OFF

Power OFF

Eject

Eject [no CD]

EjectEject [CD in]

Pause

Pause or Play

Stop

Play

Stop

C-S 546 33

Observations

• The state diagram for the CD player example indicates a composite state that includes two MUTUALLY EXCLUSIVE states– The player will be in only one of these two substates at

any time, but not in both at the same time

• The guard condition on the initial state chooses the appropriate substate upon Power ON

• There is only one terminal state that is common to both the substates

C-S 546 34

Abstract view of the CD player

No CD loaded

CD loaded

Power OFF

Power ON [no CD]

Power ON [CD in]

Eject [CD in]

Eject

C-S 546 35

Composite State with Concurrent Transitions

Composite State

Concurrent transition

Concurrent transition

C-S 546 36

Concurrent States - example

Incomplete

passed

failed

Lab 1 Lab 2

Project

Final exam

Lab done

Lab done

Project done

pass

fail

Student attending a course

C-S 546 37

Observations• If a composite state has concurrent

substates,– an entry point to the composite state represents

a concurrent transition, even if it is not represented

– an exit point from the composite state represents a concurrent transition, even if it is not represented

– all concurrent substates start at the same time – the composite state terminates only when all the

concurrent substates terminate

C-S 546 38

Observations (continued)

– if there is a transition from any one of the substates that lead to a state outside the composite state, then all the other concurrent substates terminate prematurely

• the transition “fail” in the third substate illustrates this situation

C-S 546 39

Composite State - Exercise

• Draw a composite state diagram for the following problem:– Show the state of 3 phones when all of them are

in use in a conference call• Hint: First identify the various values for the status

of a phone

C-S 546 40

State diagrams and specialization

• Inheritance mechanism allows to redefine only behaviors of a superclass and not the structure of the superclassThe structure of a subclass must be the same or

a superset of the structure of the superclassEvery state of a superclass object is also a valid

state of the subclass objectThe state diagram of a superclass can be

inherited into the state diagram of a subclass