1. Copyright W. Howden1 State Models and the State Pattern

2. Copyright W. Howden2 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

3. Applications Class Design and Analysis User Interface design –easy to use understandable designs State Pattern –basic design pattern that facilitates change Copyright W. Howden3

4. 4 Simple State Diagram

5. Copyright W. Howden5 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

6. Copyright W. Howden6 Student Example with Conditions

7. UML State Charts Augmented state diagrams We will look at some additional features in subsequent examples Copyright W. Howden7

8. 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

9. Copyright W. Howden9 Event/State Model Table State  Event  SleepingDinnerIn Class BreakfastStudying AlarmBreakfast BreakfastOverStudying ClassTimeInClass Dinner Over Sleeping ClassOver[<DinnerTime or MoreClasses] Studying; [>= DinnerTime & NoMoreEvents] Dinner Time [NoMoreClasses] Dinner

10. 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. Howden10

11. 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. Howden11

12. Copyright W. Howden12 Object State Model - Stack

13. Copyright W. Howden13 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.

14. Copyright W. Howden14

15. Copyright W. Howden15 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

16. Copyright W. Howden16 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

17. Copyright W. Howden17

18. Copyright W. Howden18 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

19. Copyright W. Howden19

20. 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. Howden20

21. Copyright W. Howden21 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

22. Copyright W. Howden22 DS Flow Chart in Disguised in State Model Notation

23. 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. Howden23

24. Copyright W. Howden24 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

25. Copyright W. Howden25 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

26. 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. Howden26

27. 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. Howden27

28. Copyright W. Howden28 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

29. Copyright W. Howden29 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

30. Copyright W. Howden30 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); }

31. Copyright W. Howden31 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

32. 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. Howden32

33. Copyright W. Howden33

34. Copyright W. Howden34 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

35. Copyright W. Howden35 Code for Member State Subtype Members are not allowed to delete members public boolean deleteMember(DomainLogic dl, String name) {return false; }

36. Copyright W. Howden36 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); }

37. State Pattern Alternative Design 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. Howden37

38. 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