Scribd
Upload
120 views19 pages

UML State Machine Diagrams and Modeling

UML state machine diagrams are used to model the states and behavior of objects. The document discusses key elements of state machine diagrams including states, transitions, events. It provides examples of modeling different types of state-dependent objects and sequences of operations. The State pattern can be used to implement state-dependent behavior by encapsulating state-specific logic in state classes that the context object delegates to.

Uploaded by

rishikarthick
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
120 views19 pages

UML State Machine Diagrams and Modeling

UML state machine diagrams are used to model the states and behavior of objects. The document discusses key elements of state machine diagrams including states, transitions, events. It provides examples of modeling different types of state-dependent objects and sequences of operations. The State pattern can be used to implement state-dependent behavior by encapsulating state-specific logic in state classes that the context object delegates to.

Uploaded by

rishikarthick
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 19

Chapter 29

UML State Machine Diagrams and Modeling

State Machine Diagram Illustrates the interesting events and states of an object and the behavior of an object in reaction to an event.
Event: significant or noteworthy occurrence.
E.g., telephone receiver taken off hook.

State: the condition of an object at a moment in time (between events). Transition: a relationship between two states; when an event occurs, the object moves from the current state to a related state.

UML State Machine Diagram States shown as rounded rectangles. Transitions shown as arrows. Events shown as labels on transition arrows. Initial pseudo-state automatically transitions to a particular state on object instantiation. Events with no corresponding transitions are ignored.

Fig. 29.1 State machine diagram for a telephone


Telephone

initial state

off hook Idle on hook Active

state

transition

event

Transition Actions and Guards A transition can cause an action to fire.


In software implementation, a method of the class of the state machine is invoked.

A transition may have a conditional guard.


The transition occurs only if the test passes.

Fig. 29.2 Transition action and guard notation

transition action

off hook / play dial tone Idle [valid subscriber] on hook guard condition Active

Nested States A state may be represented as nested substates.


In UML, substates are shown by nesting them in a superstate box.

A substate inherits the transitions of its superstate.


Allows succinct state machine diagrams.

Fig. 29.3 Nested states

off hook / play dial tone

[valid subscriber] Idle PlayingDialTone

Active

Talking

on h ook

digit

digit

connected complete

Dialing

Connecting

State-Independent vs. State-Dependent State-independent (modeless) type of object that always responds the same way to an event. State-dependent (modal) type of object that reacts differently to events depending on its state or mode.
Use state machine diagrams for modeling state-dependent objects with complex behavior, or to model legal sequences of operations.

Modeling State-dependent Objects Complex reactive objects


Physical devices controlled by software
E.g., phone, microwave oven, thermostat

Transactions and related business objects

Protocols and legal sequences


Communication protocols (e.g., TCP) UI page/window flow or navigation UI flow controllers or sessions Use case system operations

Fig. 29.4 Web page navigation modeling

Fig. 29.5 Legal sequence of use case operations


Process Sale

WatingForSale

makeNewSale

EnteringItems enterItem

endSale

authorized

makeCashPayment

WaitingForPayment

makeCreditPayment AuthorizingPayment makeCheckPayment

GoF State Pattern Problem:


An objects behavior is dependent on its state, and its methods contain case logic reflecting conditional state-dependent actions.

Solution:
Create a state class for each state, implementing a common interface. Delegate state-dependent operations from the context object to its current state object. Ensure context object always points to a state object reflecting its current state.

Example: Transactional States A transactional support system typically keeps track of the state of each persistent object.
Modifying a persistent object does not cause an immediate database update an explicit commit operation must be performed. A delete or save causes change of state, not an immediate database delete or save. A commit operation updates the database if an object was modified (dirty), but does nothing if the object is clean.

Fig. 38.12 Statechart for PersistentObject


State chart: PersistentObject [new (not from DB)] commit / insert [ from DB] save rollback / reload commit / update

New

OldClean

OldDirty

delete Legend: New--newly created; not in DB Old--retrieved from DB Clean--unmodified Dirty--modified Deleted delete rollback / reload OldDelete

commit / delete

Fig. 38.13 Persistent Objects

Assume all persistent object classes extend a PersistentObject class that provides common technical services for persistence.
Domain ProductSpecification ...

Persistence PersistentObject oid : OID timeStamp: DateTime commit() delete() rollback() save() ...

Case-logic Structure Using case logic, commit and rollback methods perform different actions, but have a similar logic structure.
public void commit() { switch ( state ) { case OLD_DIRTY: // . . . break; case OLD_CLEAN: // . . . break; . . .

State Transition Model using State Pattern

Implementing transactional states:


Create static singleton objects for each state that are specializations of PObjectState.
The commit method is implemented differently in each state object.

PersistentObject is the context object.


Keeps a reference to a state object representing the current state. Methods in the state objects call setState() to cause a transistion to the next state.

No case logic is needed.

{ state.delete( this ) }

{ state.rollback( this ) }

{ state.commit( this ) } { state.save( this ) }

PersistentObject oid : OID state : PObjectState commit() delete() rollback() save() setState(PObjectState) ... PObjectState { commit(obj : PersistentObject) delete(obj : PersistentObject) rollback(obj : PersistentObject) save(obj : PersistentObject) // default no-op // bodies for // each method }

OldDirty State Product Specification ... ... ... ... commit(...) delete(...) rollback(...) Sale

OldClean State

New State

OldDelete State

delete(...) save(...)

commit(...)

commit(...) rollback(...)

{ // commit PersistenceFacade.getInstance().update( obj ) obj.setState( OldCleanState.getInstance() ) } { // rollback PersistenceFacade.getInstance().reload( obj ) obj.setState( OldCleanState.getInstance() ) } { // delete obj.setState( OldDeleteState.getInstance() ) { // save obj.setState( OldDirtyState.getInstance() )

{ // commit PersistenceFacade.getInstance().insert( obj ) obj.setState( OldCleanState.getInstance() ) } { // commit PersistenceFacade.getInstance().delete( obj ) obj.setState( DeletedState.getInstance() ) }

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy