Lecture08

Computer Engineering Department

Object Oriented Software Modeling and Design

CE 350Abdel-Karim Al-Tamimi, Ph.D.

[email protected]://faculty.yu.edu.jo/altamimi

Al-Tamimi 2011 © 1

mailto:[email protected]

Overview

• State Machine Diagram

Al-Tamimi 2011 © 2

State Machine Diagram

• The behavior of an entity is not only a direct consequence of its inputs, but it also depends on its preceding state

• The past history of an entity can best be modeled by a finite state chart diagram traditionally named “automata”

• Statechart diagrams (or sometimes referred to as state diagrams) show the different states of an entity

• Statechart diagrams can also show how an entity responds to various events by changing from one state to another (what states should our system be)

Al-Tamimi 2011 © 3

What is a State?

• According to Rumbaugh et al. “A state is an abstraction of the attribute values and links of an object. Sets of values are grouped together into a state according to properties that affect the gross behavior of the object”

• For example, consider you have $100,000 in a bank account. The behavior of the withdraw function would be: – balance := balance – withdrawAmount; provided that

the balance after the withdrawal is not less than $0; – However, if the account balance becomes negative

after a withdrawal, the behavior of the withdraw function would be quite different

Al-Tamimi 2011 © 4

State Characteristics

• There are several characteristics of states:– A state occupies an interval of time– A state is often associated with an abstraction of

attribute values of an entity satisfying some condition(s)

– An entity changes its state not only as a direct consequence of the current input, but it is also dependent on some past history of its inputs

• State Machine diagram is used in the design phase of the product

Al-Tamimi 2011 © 5

State Diagrams

Al-Tamimi 2011 © 6

Example

Al-Tamimi 2011 © 7

Example

Al-Tamimi 2011 © 8

Composite State

Al-Tamimi 2011 © 9

State UML Notations

Al-Tamimi 2011 © 10

State Name

Internal Activities

Internal Transitions

State Conditions


Action or activity Description

entry/ action 1; …; action n Upon entry to the state, the specified actions are performed.

exit/ action 1; …; action n Upon exit from the state, the specified actions are performed.

do/ activity The specified activity is performed continuously while in this state.

event-name(parameters) [guard-condition] / action 1 ; …; action n

An internal transition is fired when the specified event occurs and the specified guard condition is true. The specified actions are performed when the transition is fired.

Introduction to States

• A state can be active or inactive, once the object enters the state due to a transition the state becomes active, and turned to inactive when it leaves it

• There are three types of states:• Simple states

– Has no sub-states

• Composite states– Has one or more regions (containers) of sub-states, if it has two or more

regions it is called orthogonal

• Submachine states– Can be reused in other state machine (similar in context to composite state)– The way UML uses to encapsulate states for reuse


State Transition

• A transition from one state to another takes place instantaneously in response to some external events or internal stimuli


(Event/Trigger) [guard condition]/(Action/Effect)

State Transition

• A transition is fired when the following conditions are satisfied:– The entity is in the state of the source state.– An event specified in the label occurs.– The guard condition specified in the label is evaluated

to be true.

• When a transition is fired, the actions associated with it are executed


Self-Transition


Composite State


Concurrent Composite State


Initial pseudo- state May finish at

different times

Submachine State


Name of State : Name of Submachine

Entry Point


Exit Point


Choice Pseudo-StateDynamic Conditional Branch


Junction Pseudo-StateStatic Conditional Branch


Junction Pseudo-State


Receiving Signal


Sending Signal


Terminate Pseudo-State


History States

• A history state is used to remember the previous state of a state machine when it was interrupted. – Deep history state– Shallow history state

• A shallow history "remembers" only the outermost nested state that the given object was in before it left the enclosing composite state. – You can use shallow history, then, to allow an event to interrupt

an activity and then let the object pick up where it left off once it's handled that event

• A deep history "remembers" the innermost nested state at any depth within a composite state


Shallow History State


Shallow History State


When the activities associated with that state are finished, the system puts the Order back into the Retrieving Books state and the substate in which the Order resided when activity was interrupted, and the Order resumes performing the interrupted activity. (in this case Accumulating from Inventory)

When a query event comes in while an Order object is in the Retrieving Books state, the system puts the current activity hold and puts the object into the Checking Status state.

Deep History State


In this case, that execution should resume with the object in the Waiting for Back Order substate.

Fork and Join


State Diagram UML Notations


Initial stateFinal stateState

Shallow History stateDeep History stateConcurrent composite stateTransition

State Diagram UML Notations


Exit PointEntry PointChoice

Join and Fork

Junction stateTransition

Resources

• Chapter 4, Object-Oriented Technology: From diagram to code with Visual Paradigm for UML

• UML 2 Certification Guide• UML-2 in a nutshell, chapter 8• http://www.sparxsystems.com.au/resources/um

l2_tutorial/uml2_statediagram.html


Lecture08

Documents

Transcript of Lecture08