1. CS3773 Software Engineering Lecture 06 UML State Machines

2. UTSA CS3773 2 State Diagram  Recall the delays in a sequence diagram, between when an object receives a message and when it outputs another message  State diagram shows what the object does in between the receiving and the sending of messages  Show the behavior of an object across several use cases  One state diagram per class to describes possible behavior for each instance of the class

3. UTSA CS3773 3 State Diagram  State diagram shows how a system or an object's behavior changes over time depending on the input, rather than represent end-to-end behavior  Shows how a system or an object reacts to messages received – Which state the object shall go to – When it outputs messages to other objects – How an object changes the values of its attributes by assignments

4. UTSA CS3773 4 State Diagram – An Example

5. UTSA CS3773 5 State Diagram  Elements of a state diagram – State represents the mode of the system Always an initial state (starting state) Sometimes a final state – Transition describes a change in state due to the occurrence of an event From one state to another state

6. UTSA CS3773 6 State  Partitions object behavior e.g., not being able to check out a borrowed book  Represents the history of inputs so far  Affects what input the object will react to e.g., ignoring most input in the state “lost”  Is an assignment to a collection of attributes

7. UTSA CS3773 7 Transition  Elements of a transition – event(s) – [condition] – /activities  Each of these parts is optional  Form

8. UTSA CS3773 8 Event  An event triggers the transition – A change in the environment e.g., offHook – A message from another object (operation call) – A change in a condition: going from “false” to “true” e.g., when(temperature > 100 degrees – An occurrence of a specific date/time or passage of time e.g., after (20 minutes)

9. UTSA CS3773 9 Event  An event occurs instantaneously and it doesn’t persist  Events make an object change state  If the object is in a state and there is no outgoing transition triggered by an event, the event is ignored  Multiple events on a transition label are ORed together

10. UTSA CS3773 10 Condition  A condition is a Boolean expression  The value of a condition persists until the variables involved in the condition change their values  The transition cannot fire unless the guard condition is “true”,  Examples – x > 10 – patronHasNoOverdueFine

11. UTSA CS3773 11 Activity  An activity is what an object does in response to events  An activity is simple, fast, non-interruptible  Most common activities are – variable assignment – send a message to an object  Multiple activities on a transition are separated by “;” and executed sequentially

12. UTSA CS3773 12 State Activities  A state can have activities associated with it  Two types of state activities can manipulate object attributes or other variables – Activity: simple, non-interruptible Associated with a transition or a state Performed on state entry or exit or event – Do activity: interruptible; may require much computation Associated with a state Interrupted by a transition

13. UTSA CS3773 13 State Activities  States can be annotated with entry or exit activities, internal activities, and do activities:  entry/activity  event/activity (way to describe reactions to events that don't cause a state change -- internal transitions)  exit/activity  do/activity

14. UTSA CS3773 14 State Activities  In a transition, the order of effects: – Exit activities of source – Transition activities – Entry activities of destination, and – State activities

15. UTSA CS3773 15 Self-Transition  A self-transition will cause reactivation of exit and then entry events  If you want a self-transition that does not activate these events, you can use an internal transition, labeled with the event and the associated activity e.g., “req/reply” in state “S”

16. UTSA CS3773 16 Self-Transition  Compared to an activity on a transition, one could achieve the same behavior – as activity in state – as activity in another, special state

17. UTSA CS3773 17 More on Transition  If a transition has no event label, it can occur once any activity associated with the state is complete  Guards on transitions (triggered by the same event) leaving a state should be mutually exclusive

18. UTSA CS3773 18 Summary on State and Transition

19. UTSA CS3773 19 State Hierarchy  Composite state: a state can contain other states  Composite combines states and transitions that work together towards a common goal  If a transition leaves a composite state, this transition applies to all the sub-states  The sub-states “inherit” the transitions of the composite state  Basic state: a state do not contain other states

20. UTSA CS3773 20 State Diagram Without Composite State

21. UTSA CS3773 21 State Diagram with Composite State

22. UTSA CS3773 22 Orthogonal Composite State  An orthogonal state captures two or more behaviors of the object that happen concurrently each with its own control thread  If there are many orthogonal states for one object, you should consider dividing the behavior between more objects

23. UTSA CS3773 23 Orthogonal State – An Example

24. UTSA CS3773 24 Types of Orthogonal States  Aggregation concurrency – State diagram for an aggregate object is a collection of state diagrams, each of which corresponds to a constituent object  Synchronization of concurrent activities within one object – Object performs two or more activities concurrently – Object completes both activities before it progress to anther state

25. UTSA CS3773 25 History  History is a mechanism by which a re-entered composite state can continue executing from the sub-state that was current when control last transitioned out of the composite state  Deep history  Shallow history

26. UTSA CS3773 26 History  History is a pseudostate whose meaning is to designate the immediate sub-states at this level in the hierarchy that system was in when the immediate parent state was last exited  History state can be the destination state of a transition  A transition leaving a history state indicates what sub- states to enter if the system has ever been in this state  Syntax H

27. UTSA CS3773 27 Deep History  Apply history at all levels in the hierarchy below the history pseudostate  Enter the sub-states that an object was last in when the state was exited  Syntax H*

28. UTSA CS3773 28 History State – An Example

29. UTSA CS3773 29 Process for Making State Diagram  Decide what the states of an object are  Determine what transitions can move the system from states to states  Represent effect of the execution of a transition – Variable value changes – State changes – Messages sent

30. UTSA CS3773 30 Validation of State Diagram  Consistency: multiple transitions leave same state under the same event should have mutually exclusive conditions Problem in hierarchical state machine  Completeness: all possible inputs should be considered  Compatibleness: state diagrams have the same behavior with the sequence diagrams

31. UTSA CS3773 31 Reading Assignments  UML and The Unified Process – Chapter 21, “Basic state machines” – Chapter 22, “Advanced state machines”