F27SB2 Software Development 2

1. F27SB2 Software Development 2 Lecture 7: State Diagrams

2. State and Interaction • view a system as a sequence of events and associated actions • event ==> something that indicates the need for change • e.g. switch setting, button selection • action ==> something that causes change • e.g. switch is set ==> light goes on • e.g. button is selected ==> method is invoked to respond to event

3. State and Interaction • identify distinct system states • characterise state as: • current configuration • i.e. status of things in system that may change • valid events/actions for current configuration • i.e. how change is indicated/what may be changed and how • think of entire system as a set of states

4. State and Interaction • system execution consists of series of state transitions • in current state: • event occurs • action is triggered • configuration is changed • new state is entered

5. State and Interaction • e.g. light circuit • ON STATE • configuration - light is on • event - switch set to off • action - light goes off • now in OFF STATE • OFF STATE • configuration - light is off • event - switch set to on • action - light goes on • now in ON STATE

6. State and Interaction • e.g. text editor • INITIAL STATE • configuration - nothing available to edit • event - select open file • action - contents from file available for editing • now in EDIT STATE • event - select open new • action - empty contents available for editing • now in EDIT STATE • event - select exit

7. State and Interaction • EDIT STATE • configuration - file open for edit • event - select edit operation • action - file contents changed • now in EDIT STATE • event - select save file • action - contents copied back to file • now in EDIT STATE • event - select close file • action - contents copied back to file • now in INITIAL STATE

8. State Transition Diagrams • also known as state charts • closely related to finite state machines • state: • box with its name in it • transition: • arc from a state to a state • labelled with event and action

9. State Transition Diagrams • e.g. light switch set switch off/ light goes off ON OFF set switch on/ light goes on

10. State Transition Diagrams • e.g. editor select open/ file contents editable EDIT INITIAL select new/ empty contents editable select close/ contents written to file select exit/ return to host system select edit/ contents changes select save/ contents written to file

11. State Transition Diagrams • e.g. traffic lights READY time signal 2/ red & amber off; green on time signal 1/ amber on GO STOP SLOW time signal 4/ amber off; green on time signal 3/ green off; amber on

12. State Transition Diagrams • system may only have 1 state • e.g. timer TIMER select increment/ add 1 to count display select clear/ set count display to 0 select go/ decrement count display to 0

13. State Transition Diagrams • can attach a guard to a state: [guard] • guard must be true for transition to occur CHECK INPUT check input [input OK]/ process input check input [bad input]/ request re-enter input

14. State and Interactive System Design • very useful to think about interactive systems in terms of sequences of states • user’s view of system state is not same as developer’s view of system state • user interprets system behaviour in terms of their conceptual model of what system is for • developer knows about underlying programming constructs • e.g. to use editor, user doesn’t need to know how interface or file system are actually

15. State and Interactive System Design • user characterises a state by properties of entities in problem domain as shown by what’s on the display • current configuration ==> entities in problem domain represented by constructs in display • events ==> interact with entities in problem domain by selecting appropriate display constructs • actions ==> changes to entities in problem domain reflected by changes in display organisation

16. State and Interactive System Design • e.g. editor • user thinks about documents in files represented by scrollable text on screen • developer characterises a state by implementation-level entities: • current configuration ==> variables values; open files; JFrameComponents • events ==> Java Events • actions ==> methods

17. State and Interactive System Design • e.g. editor • developer thinks about character positions in arrays of Strings etc • developer should construct system to: • reflect user’s conceptual model • enable effective system use e.g. in editor, if file is open can’t exit

18. State and Interactive System Design • in any system, in any given state, only some of all possible events and actions are appropriate • e.g. if light is off then can turn it on but can’t turn it off because it’s off already • e.g. in editor, if file is open can’t exit • often, when the state changes the appropriate events and actions change • e.g. after turning light on can turn it off but can’t turn it on because it’s on already • e.g. in editor, after closing file, can’t close it again

19. State and Interactive System Design • important to constrain available events and actions to prevent action sequences which might damage system (and user) • e.g. can’t open washing machine door during wash cycle • e.g. can’t exit editor without closing file • important to constrain available actions to prevent user confusion • e.g. can’t close file which is already closed

20. State and Interactive System Design • for effective system use, user always needs to know what state the system is in • hidden mode • in some state but no way to tell which one • avoid hidden modes • ensure user always knows current system state • unambiguous display content • explicit statement of mode • e.g. MS Word always indicates current style, font etc

21. From State Transition Diagram to Java • idealised stages: • draw state transition diagram • will realise: • events as Events with Componentsources • guards as if/while • actions as methods • design and implement interface • implement actions as methods

22. From State Transition Diagram to Java • implement state transitions in actionPerformed • if only one state then: • no transitions • only need to identify events • if more than one state then: • need to keep track of current state when reacting to event • to ensure that event is valid for state

23. From State Transition Diagram to Java • maintain state variable • value reflects current state • for simplicity, represent states as integers • could use enumerated types? • actionPerformed must: • have separate cases for each state • within each state, identify and react to appropriate events

24. From State Transition Diagram to Java intstate variable = initial state; ... public void actionPerformed(ActionEvent e) { switch(state variable) { case state1: if(e.getSource()==Component11) { state 1 action for this event state variable = next state; } else if(e.getSource()==Component12) { ... } else ...

25. From State Transition Diagram to Java case state2: if(e.getSource()==Component21) { state 2 action for this event state variable = next state; } else ... } }

26. Example: password control • system access controlled by password • file of user names and passwords • user must enter name and password • verify name and password from file • don’t worry about encryption, hiding password etc here JFrame JTextField prompt entry JLabel

27. Example: password control .../ request login get login [invalid]/ request login CHECK LOGIN get login [valid]/ request password CHECK PASSWORD get password [invalid]/ request password get password[valid]/ ...

28. Example: password control import java.awt.*; import java.awt.event.*; import java.io.*; import javax.swing.*; class ID { String login, password; ID(String l,String p) { login = l; password = p; } }

29. Example: password control class Login extends JFrameimplements ActionListener { JLabelprompt; JTextFieldentry; ID [] details; int n = 0; static intidno; • define state variable & constants intstate; final int LCHECK = 0; final int PCHECK = 1; final int SUCCESS = 2;

30. Example: password control final int MAXID = 100; Login() { setLayout(new FlowLayout()); prompt = new JLabel("Please enter login: "); prompt.setFont(new Font("SanSerif",Font.BOLD,18)); add(prompt); entry = new JTextField(12); entry.setFont(new Font("SanSerif",Font.BOLD,18)); add(entry); entry.addActionListener(this); }

31. Example: password control • read login/password as strings from file void getDetails(String f) throws IOException { String l,p; BufferedReader file = new BufferedReader(new FileReader(f)); details = new ID[MAXID]; l = file.readLine(); while(l!=null) { p = file.readLine(); details[n] = new ID(l,p); n++; l = file.readLine(); } }

32. Example: password control • find login in file intcheckLogin(String l) { for(int i=0;i<n;i++) if(details[i].login.equals(l)) return i; return -1; } • check password for legal login booleancheckPassword(String p) { return details[idno].password.equals(p); }

33. Example: password control public void actionPerformed(ActionEvent e) { switch(state) • check login state { case LCHECK: if(e.getSource()==entry) { idno = checkLogin(entry.getText()); if(idno==-1) prompt.setForeground(Color.red);

34. Example: password control • invalid login so don’t change state else { prompt.setForeground(Color.black); prompt. setText("Please enter password:"); • valid login so change state state = PCHECK; } } entry.setText(""); return;

35. Example: password control • check password state case PCHECK: if(e.getSource()==entry) { if(!checkPassword(entry.getText())) prompt.setForeground(Color.red);

36. Example: password control • invalid password so don’t change state else { prompt.setForeground(Color.black); prompt.setText("Login successful"); • valid password so change state state = SUCCESS; } } entry.setText(""); return; } } }

37. Example: password control class TestLogin { public static void main(String [] args) throws IOException { Login l = new Login(); l.setTitle("Login"); l.setSize(450,80); l.setVisible(true); l.addWindowListener(...) l.getDetails("users.txt"); • set intitial state l.state = LCHECK; } }

38. Example: password control

39. Example: password control • Swing provides specialised JPasswordField • like JTextField but: • can set to not show password as typed • returns array of char not String