Post on 22-Dec-2015
Copyright W. Howden 1
State Models and the State Pattern
Copyright W. Howden 2
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
Copyright W. Howden 3
Copyright W. Howden 4
Simple State Diagram
Breakfast InClass
Studying
Sleeping
Dinner
Alarm
ClassOver
DinnerTime
DinnerFinished
ClassTime
NextClassStartTime
Copyright W. Howden 5
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
Copyright W. Howden 6
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
Copyright W. Howden 7
Copyright W. Howden 8
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
Copyright W. Howden 9
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
Copyright W. Howden 10
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
Copyright W. Howden 11
Copyright W. Howden 12
Object State Model - Stack
Copyright W. Howden 13
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.
Copyright W. Howden 14
Copyright W. Howden 15
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
Copyright W. Howden 16
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
Copyright W. Howden 17
Copyright W. Howden 18
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
Copyright W. Howden 19
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
Copyright W. Howden 20
Copyright W. Howden 21
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
Copyright W. Howden 22
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
Copyright W. Howden 23
Copyright W. Howden 24
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
Copyright W. Howden 25
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
Copyright W. Howden 26
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)
Copyright W. Howden 27
Copyright W. Howden 28
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
Copyright W. Howden 29
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
Copyright W. Howden 30
•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);
• }
•}
Copyright W. Howden 31
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
Copyright W. Howden 32
Copyright W. Howden 33
+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:
Copyright W. Howden 34
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
Copyright W. Howden 35
Code for Member State Subtype
• Members are not allowed to delete members
public boolean deleteMember(DomainLogic dl, String name)
{ return false;
}
Copyright W. Howden 36
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
Copyright W. Howden 37
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