CS3773 Software Engineering

Lecture 06UML State Machines

2 UTSA CS3773

State Diagram

Recall the delays in a sequence diagram, between when an object receives a message and when it outputs another message

State diagram shows what the object does in between the receiving and the sending of messages

Show the behavior of an object across several use cases

One state diagram per class to describes possible behavior for each instance of the class

UTSA CS37733

State Diagram

State diagram shows how a system or an object's behavior changes over time depending on the input, rather than represent end-to-end behavior

Shows how a system or an object reacts to messages received

– Which state the object shall go to– When it outputs messages to other objects– How an object changes the values of its attributes by

assignments

UTSA CS37734

State Diagram – An Example

UTSA CS37735

State Diagram

Elements of a state diagram – State represents the mode of the system

Always an initial state (starting state)

Sometimes a final state– Transition describes a change in state due to the

occurrence of an event

From one state to another state

UTSA CS37736

State

Partitions object behavior

e.g., not being able to check out a borrowed book Represents the history of inputs so far Affects what input the object will react to

e.g., ignoring most input in the state “lost” Is an assignment to a collection of attributes

UTSA CS37737

Transition

Elements of a transition– event(s)– [condition]– /activities

Each of these parts is optional Form

srcevent [cond]/activity

dest

UTSA CS37738

Event

An event triggers the transition– A change in the environment

e.g., offHook– A message from another object (operation call)– A change in a condition: going from “false” to “true”

e.g., when(temperature > 100 degrees– An occurrence of a specific date/time or passage of time

e.g., after (20 minutes)

UTSA CS37739

Event

An event occurs instantaneously and it doesn’t persist Events make an object change state If the object is in a state and there is no outgoing

transition triggered by an event, the event is ignored Multiple events on a transition label are ORed

together

UTSA CS377310

Condition

A condition is a Boolean expression The value of a condition persists until the variables

involved in the condition change their values The transition cannot fire unless the guard condition is

“true”, Examples

– x > 10 – patronHasNoOverdueFine

UTSA CS377311

Activity

An activity is what an object does in response to events An activity is simple, fast, non-interruptible Most common activities are

– variable assignment– send a message to an object

Multiple activities on a transition are separated by “;” and executed sequentially

UTSA CS377312

State Activities

A state can have activities associated with it Two types of state activities can manipulate object

attributes or other variables– Activity: simple, non-interruptible

Associated with a transition or a state Performed on state entry or exit or event

– Do activity: interruptible; may require much computation Associated with a state Interrupted by a transition

UTSA CS377313

State Activities

States can be annotated with entry or exit activities, internal activities, and do activities:

entry/activity event/activity (way to describe reactions to events

that don't cause a state change -- internal transitions) exit/activity do/activity

UTSA CS377314

State Activities

In a transition, the order of effects: – Exit activities of source– Transition activities– Entry activities of destination, and– State activities

UTSA CS377315

Self-Transition

A self-transition will cause reactivation of exit and then entry events

If you want a self-transition that does not activate these events, you can use an internal transition, labeled with the event and the associated activity

e.g., “req/reply” in state “S”

UTSA CS377316

Self-Transition

Compared to an activity on a transition, one could achieve the same behavior

– as activity in state– as activity in another, special state

UTSA CS377317

More on Transition

If a transition has no event label, it can occur once any activity associated with the state is complete

Guards on transitions (triggered by the same event) leaving a state should be mutually exclusive

UTSA CS377318

Summary on State and Transition

State Name____________

Entry/activityExit/activity

Event/activitydo/activity

State Nameevent1 [condition] / activity1; activity2

UTSA CS377319

State Hierarchy

Composite state: a state can contain other states Composite combines states and transitions that work

together towards a common goal If a transition leaves a composite state, this transition

applies to all the sub-states The sub-states “inherit” the transitions of the

composite state Basic state: a state do not contain other states

UTSA CS377320

State Diagram Without Composite State

UTSA CS377321

State Diagram with Composite State

UTSA CS377322

Orthogonal Composite State

An orthogonal state captures two or more behaviors of the object that happen concurrently each with its own control thread

If there are many orthogonal states for one object, you should consider dividing the behavior between more objects

UTSA CS377323

Orthogonal State – An Example

UTSA CS377324

Types of Orthogonal States

Aggregation concurrency– State diagram for an aggregate object is a collection of

state diagrams, each of which corresponds to a constituent object

Synchronization of concurrent activities within one object

– Object performs two or more activities concurrently– Object completes both activities before it progress to

anther state

UTSA CS377325

History

History is a mechanism by which a re-entered composite state can continue executing from the sub-state that was current when control last transitioned out of the composite state

Deep history Shallow history

UTSA CS377326

History

History is a pseudostate whose meaning is to designate the immediate sub-states at this level in the hierarchy that system was in when the immediate parent state was last exited

History state can be the destination state of a transition

A transition leaving a history state indicates what sub-states to enter if the system has ever been in this state

Syntax

H

UTSA CS377327

Deep History

Apply history at all levels in the hierarchy below the history pseudostate

Enter the sub-states that an object was last in when the state was exited

Syntax H*

UTSA CS377328

History State – An Example

UTSA CS377329

Process for Making State Diagram

Decide what the states of an object are Determine what transitions can move the system

from states to states Represent effect of the execution of a transition

– Variable value changes– State changes– Messages sent

UTSA CS377330

Validation of State Diagram

Consistency: multiple transitions leave same state under the same event should have mutually exclusive conditions

Problem in hierarchical state machine Completeness: all possible inputs should be

considered Compatibleness: state diagrams have the same

behavior with the sequence diagrams

UTSA CS377331

Reading Assignments

UML and The Unified Process– Chapter 21, “Basic state machines”– Chapter 22, “Advanced state machines”