The document discusses state machine diagrams and state modeling in object-oriented software design. It defines states as abstractions of an object's attribute values and links that affect its behavior. State machine diagrams show an entity's different states and how it responds to events by transitioning between states. The characteristics of states and various state modeling concepts and notations in UML like composite states, submachine states, history states, and transitions are explained.

1. Object Oriented Software Modeling and Design CE 350 Abdel-Karim Al-Tamimi, Ph.D. [email_address] http://faculty.yu.edu.jo/altamimi Al-Tamimi 2011 ©

2. Overview State Machine Diagram Al-Tamimi 2011 ©

3. State Machine Diagram The behavior of an entity is not only a direct consequence of its inputs, but it also depends on its preceding state The past history of an entity can best be modeled by a finite state chart diagram traditionally named “automata” Statechart diagrams (or sometimes referred to as state diagrams ) show the different states of an entity Statechart diagrams can also show how an entity responds to various events by changing from one state to another (what states should our system be) Al-Tamimi 2011 ©

4. What is a State? According to Rumbaugh et al. “ A state is an abstraction of the attribute values and links of an object. Sets of values are grouped together into a state according to properties that affect the gross behavior of the object ” For example, consider you have $100,000 in a bank account. The behavior of the withdraw function would be: balance := balance – withdrawAmount; provided that the balance after the withdrawal is not less than $0; However, if the account balance becomes negative after a withdrawal, the behavior of the withdraw function would be quite different Al-Tamimi 2011 ©

5. State Characteristics There are several characteristics of states: A state occupies an interval of time A state is often associated with an abstraction of attribute values of an entity satisfying some condition(s) An entity changes its state not only as a direct consequence of the current input, but it is also dependent on some past history of its inputs State Machine diagram is used in the design phase of the product Al-Tamimi 2011 ©

6. State Diagrams Al-Tamimi 2011 ©

7. Example Al-Tamimi 2011 ©

8. Example Al-Tamimi 2011 ©

9. Composite State Al-Tamimi 2011 ©

10. State UML Notations Al-Tamimi 2011 © State Name Internal Activities Internal Transitions

11. State Conditions Al-Tamimi 2011 © Action or activity Description entry/ action 1; …; action n Upon entry to the state, the specified actions are performed. exit/ action 1; …; action n Upon exit from the state, the specified actions are performed. do/ activity The specified activity is performed continuously while in this state . event-name(parameters) [guard-condition] / action 1 ; …; action n An internal transition is fired when the specified event occurs and the specified guard condition is true . The specified actions are performed when the transition is fired.

12. Introduction to States A state can be active or inactive, once the object enters the state due to a transition the state becomes active, and turned to inactive when it leaves it There are three types of states: Simple states Has no sub-states Composite states Has one or more regions (containers) of sub-states, if it has two or more regions it is called orthogonal Submachine states Can be reused in other state machine (similar in context to composite state) The way UML uses to encapsulate states for reuse Al-Tamimi 2011 ©

13. State Transition A transition from one state to another takes place instantaneously in response to some external events or internal stimuli Al-Tamimi 2011 © (Event/Trigger) [guard condition]/(Action/Effect)

14. State Transition A transition is fired when the following conditions are satisfied: The entity is in the state of the source state. An event specified in the label occurs. The guard condition specified in the label is evaluated to be true. When a transition is fired, the actions associated with it are executed Al-Tamimi 2011 ©

15. Self-Transition Al-Tamimi 2011 ©

16. Composite State Al-Tamimi 2011 ©

17. Composite State Al-Tamimi 2011 ©

18. Concurrent Composite State Al-Tamimi 2011 © Initial pseudo- state May finish at different times

19. Submachine State Al-Tamimi 2011 © Name of State : Name of Submachine

20. Entry Point Al-Tamimi 2011 ©

21. Entry Point Al-Tamimi 2011 ©

22. Exit Point Al-Tamimi 2011 ©

23. Choice Pseudo-State Dynamic Conditional Branch Al-Tamimi 2011 ©

24. Choice Pseudo-State Dynamic Conditional Branch Al-Tamimi 2011 ©

25. Junction Pseudo-State Static Conditional Branch Al-Tamimi 2011 ©

26. Junction Pseudo-State Al-Tamimi 2011 ©

27. Receiving Signal Al-Tamimi 2011 ©

28. Sending Signal Al-Tamimi 2011 ©

29. Terminate Pseudo-State Al-Tamimi 2011 ©

30. History States A history state is used to remember the previous state of a state machine when it was interrupted. Deep history state Shallow history state A shallow history "remembers" only the outermost nested state that the given object was in before it left the enclosing composite state. You can use shallow history, then, to allow an event to interrupt an activity and then let the object pick up where it left off once it's handled that event A deep history "remembers" the innermost nested state at any depth within a composite state Al-Tamimi 2011 ©

31. Shallow History State Al-Tamimi 2011 ©

32. Shallow History State Al-Tamimi 2011 © When the activities associated with that state are finished, the system puts the Order back into the Retrieving Books state and the substate in which the Order resided when activity was interrupted, and the Order resumes performing the interrupted activity. (in this case Accumulating from Inventory) When a query event comes in while an Order object is in the Retrieving Books state, the system puts the current activity hold and puts the object into the Checking Status state.

33. Deep History State Al-Tamimi 2011 © In this case, that execution should resume with the object in the Waiting for Back Order substate.

34. Fork and Join Al-Tamimi 2011 ©

35. State Diagram UML Notations Al-Tamimi 2011 © Initial state Final state State Shallow History state Deep History state Concurrent composite state Transition

36. State Diagram UML Notations Al-Tamimi 2011 © Exit Point Entry Point Choice Join and Fork Junction state Transition

37. Resources Chapter 4, Object-Oriented Technology: From diagram to code with Visual Paradigm for UML UML 2 Certification Guide UML-2 in a nutshell, chapter 8 http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_statediagram.html Al-Tamimi 2011 ©