Copyright W. Howden1 State Models and the State Pattern.

Copyright W. Howden 1

State Models and the State Pattern


State Models

• Components– States: a condition of an object– Events: a state changing occurrence– Transitions: from one state to the next, occur

when the associated event occurs

Applications

• Class Design and Analysis

• User Interface design– easy to use understandable designs

• State Pattern– basic design pattern that facilitates change



Simple State Diagram

Breakfast InClass

Studying

Sleeping

Dinner

Alarm

ClassOver

DinnerTime

DinnerFinished

ClassTime

NextClassStartTime


Augmented Diagrams

• Constraints/guards– Format: [c] e

• If event e occurs, transition takes place only if condition c is satisfied

• Actions– Format: [c] e /a

• If event e occurs, and c holds, then action a is performed during the transition


Student Example with Conditions

ClassOver [>=DinnerTime &NoMoreClasses]

BreakfastOverBreakfast

InClass

Studying

Sleeping

Dinner

Alarm

ClassOver [<DinnerTime orMore Classes]

DinnerTime [NoMoreClasses]

DinnerFinished

ClassTime

UML State Charts

• Augmented state diagrams

• We will look at some additional features in subsequent examples



State Model Representation

• Graphical: useful for small systems

• Tables• Better for larger models, easier to build up

incrementally

• Event/state table• For state x in row 1 column j, if there is a state y in

row i column j, the event in row i column 1 causes a transition from state x to state y


Event/State Model TableState Event

Sleeping Dinner In

Class

Breakfast Studying

Alarm Breakfast

BreakfastOver Studying

ClassTime InClass

Dinner

Over

Sleeping

ClassOver [<DinnerTime or MoreClasses]

Studying;

[>= DinnerTime &

NoMoreEvents]

Dinner

Dinner

Time

[NoMoreClasses]

Dinner

State Models and Class Behavior Description

• Class instance/object states• different combinations of class variable values

correspond to different object states

• abstract states correspond to sets of combinations of values

• A class instance may behave differently depending on what (abstract) state it is in


Modes of Behavior – Stack Example

• Following diagram has three abstract states– empty, partial and full

• State diagram indicates that the mode of behavior for the stack is different depending on what state it is in– note the use of the action /a notation– bug? what if max = 1 and you try 2 push()’s



Object State Model - Stack


State Models and GUI Interface Design

• Screens correspond to states– e.g. DS: LogOn, MemberOptions,

AdminOptions, DatePrefs, DateeData, etc.

• Current state = visible screen/dialog• Events correspond to user actions

– e.g. DS: enter button for LogOn dialog– non-modeled events: mouse movements, etc.


State Charts –Augmented Notation in GUIFrame Example

• Nested Models – one model inside another

• Black circles: model entry point

• Transfer of control to nested submodel

• Transfer of control from nested substates to common superstate

• e.g. OK Button events in Admin substates to Start/End in higher level state


Additional Notation – Concurrent Sub- models

• Every submodel has its own set of states

• Compound model: states correspond to all possible combinations of states of submodels

• E.g. 4 combinational substates in following model


Additional Notation –History Substates

• Abstract state A can be in multiple substates• An event occurs which causes an exit from

A (and hence its current substate)• When abstract state A is re-entered, entry is

made to the substate it was in when the exit event occurred, rather than the designated initial state of A

Student History Model

– At entry to Student&Professor state,– denoted combination of submodel states is entered

» i.e.StudentAwake/ProfessorLookingAtNotes

– If event FireAlarm occurs– transition from Student&Professor substate to

Student&ProfessorOutsideBuilding

– When AlarmOver occurs, – transition back to the combinational substate of

Student&Professor that the model was in when the FireAlarm event occurred



State Model Pitfalls

• Danger of constructing a flow chart which is not really a state model– i.e. construction of model in which states are

actions instead of states, and transitions have conditions based on values of state variables rather than external state changing events


DS Flow Chart in Disguised in State Model Notation

State Pattern

• Used in OO design to – model different modes of behavior– facilitate change: change, add or delete modes

• Appropriate for situation where the behavior of an object can change after its creation, during program execution



State Classes

• Object x from class A can be in different states

• Create a state class S– S has abstract methods that mirror the state

sensitive methods in A– define subtypes of S for each of the states of A,

that have definitions that describe the different state sensitive method behaviors


State Variables

• Suppose A:x is a state sensitive object• Define a corresponding state class S for A

• Include a state variable S:s in A whose value will be an instance of the appropriate subtype of S

• When a method x.m() in x is invoked, it executes s.m()

– include x as a parameter in s() in case m it needs to refer back to properties of the principal object x

Current DS Design

• GUI presents different options screens for different classes of users

• members cannot opt to add or delete members

• admin can not opt to get a date

• unauthorized users are immediately blocked

• Drawback: Business logic embedded in control part of GUI

• i.e. what to allow for current classes of users


Possible Alternative Design

• Any kind of user could request any action. GUI would send it to DL. DL would respond according to the state it was in, which would correspond to the user-type of the current user (member, admin, unauthorized)



State Class for DL

• Domain Logic subsystem interface class called DomainLogic.

• DomainLogic contains an inner class that defines a state class DomainLogicState

• DomainLogicState has subtypes for each type of user

• DomainLogic interface class has a class variable called currentState that is set to an instance of a subtype of DomainLogicState


DL – Setting the State Variable

• GUI calls logOn(name) in the DomainLogic instance dL

• dL.logOn(name) creates a LogOn instance which is then “executed”

• logOn.execute() determines user type based on • name (administrator has a special name) and• whether member with this name in member data base

• execute() sets the the currentState variable for the DomainLogic instance


•public int execute()

•{ if (userName.equals(administrator))

• { userType = Constants.ADMIN;

• currentState = new DomainLogicAdminState();

• return(Constants.ADMIN);

• }

• b = dataBase.isMember(userName);

• if (dataBase.isMember(userName))

• { userType = Constants.MEMBER;

• currentState = new DomainLogicMemberState();

• return Constants.MEMBER;

• }

• else

• { userType = Constants.UNAUTH;

• currentState = new DomainLogicUnauthState();

• return (Constants.UNAUTH);

• }

•}


DS - State Dependent Behavior

• Suppose dL gets a message (i.e. one of its methods is performed), such as deleteMember(name)

• dL calls the corresponding state method in in its state variable object

DS/DL Example

• Consider the deleteMember() method in the DomainLogic interface

• Different definitions of this for each of the subclasses of the associated state class for DomainLogic



+getADate()-state

DomainLogic

+getADate()

«metaclass»DomainLogicState

+getADate()

MemberState

dL:DomainLogic :DomainLogicState

+getADate()

UnauthUserState

+getADate()

AdminState

getADate(props, dL)getADate(props)Object1

Abstract class and methods:

Method of current substate subtype object is invoked:


DomainLogic Code

public boolean deleteMember(String name)

{ return currentState.deleteMember(this, name);

}

Note: a parameter has been added to the method for the subtype in order to pass along the identity of the object that can be in different states


Code for Member State Subtype

• Members are not allowed to delete members

public boolean deleteMember(DomainLogic dl, String name)

{ return false;

}


Code for AdminState Subtype

• Assume DataBase is built with a delete capability so DL just passes it through

public boolean deleteMember(DomainLogic dl, String name)

{ return dl.dataBase.deleteMember(name);

}

State Pattern AlternativeDesign Evaluation

• Pro: • can add or change behaviors for each class of user

by adding or changing state subtype definitions

• Con• have to write a lot of extra code (need method

definitions for all subtypes)

• Results in a GUI interface where a member could try to, say, delete a member and then be told that it was not allowed based on user type


Assignment 10

• Construct state diagrams for your user interface

• Can use graphical or tables

• May split up based on actor

• Consider the use of the state model for your program

• Find a sample place to use it. If you choose not to, explain why you did not think it suitable

Copyright W. Howden1 State Models and the State Pattern.

Documents

Transcript of Copyright W. Howden1 State Models and the State Pattern.