1. CSIS3600 System Analysis and Design Statechart Diagrams

2. Statecharts or State Transition Diagram A Statechart Diagram (SCD) depicts a finite-state- machine that describes how the class responds to different external stimuli (events). These stimuli are the receipt of messages by instances of the class, in the form of calls of the class’s operations. Given this statement, does it surprise you that statecharts are the most complex elements of object-oriented development?

4. Statechart Diagrams The statechart diagram shows the different states of the object and what events cause the object to change from one state to another. PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

5. PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Example Statechart Diagram

6. Purpose of the Statechart Diagrams To put it simply, the purpose of a statechart diagram is to describe the internal workings of the objects. Each class in the class diagram has its own unique statechart diagram.

8. When to use Statecharts When you have a complex object –and are not sure how it is going to function. When you REALLY need to know the states of an object –because it is vital to the success of the application you are working on. –Statecharts are brilliant for modeling the behavior of user interface objects so that you can easily code from them.

9. Understandings of State Each object is an instance of a class and has a complete life cycle, from creation to destruction. An object comes into existence within the system. During the period of its existence, it is “in” certain states and makes transitions from state to state.

10. Object States A stable state represents a condition in which an object may exist for some identifiable period of time. When an event occurs, the object may transition from state to state. These events may also trigger self- and internal transitions, in which the source and the target of the transition are the same state. In reaction to an event or a state change, the object may respond by dispatching an action. States of an object depend on its attributes’ values and links to other objects.

11. Some Notes Events are noteworthy occurrences that trigger a state transition. An Action is an activity that the object performs while in a state. Example Computer monitor is in the ON state with the action of display. During the development of the Statechart, more detailed analysis is done to determine the logic required to send the messages and what happens when an object receives a message.

12. More Notes States are represented as attributes on the class diagram But note that a state of an object does not necessarily change whenever an attribute changes its value. –Example: Fluctuations in a customer’s bank account balance may not trigger an event. (However, if the amount falls below a certain threshold, an event may occur [bounced check].)

13. Identifying States Identify “states of being.” Think about status conditions (shipped, on hold, etc.)

14. Object Transitions A transition is the mechanism that causes an object to leave a state and change to a new state. Transitions are short in duration and cannot be interrupted. Once the transition begins, it runs to completion by taking the object to the new state. Origin State ----------------  TRANSITION -----------  Destination State

16. Internal Transitions Normally, a transition causes an object to leave a state and move to a new state or return to the same state. An internal transition is a special kind of transition that does not cause the object to leave the state. Paid entry/calculate balance do/display balance exit/pay balance

17. Internal Transitions Three versions of an internal transition are: Entry/action expression –The entry/ internal transition is activated at the moment the object enters the state. do/action expression –The do/ executes while the object is within the state. exit/action expression –The exit/ is activated just before the object leaves the state. Paid entry/calculate balance do/display balance exit/pay balance

18. Modeling States  A statechart diagram has one initial state and one (or possibly more) final states. When modeling the behavior of a reactive object with statecharts you are essentially specifying: 1. The stable state in which that object may live. 2. The events that trigger a transition from state to state. 3. The actions that occur on each state change.  You can also model the creation and destruction of the object.

19. PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Statechart Diagram Syntax A STATE AN INITIAL STATE A FINAL STATE AN EVENT A TRANSITION aState anEvent

20. PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Components of Statechart Diagrams States Events Transitions Actions Activities

21. Statechart Diagrams  States and the changes an object makes from state to state are shown in a state chart diagram.

22. Statechart Symbols

23. State A state is graphically symbolized as a rounded box as shown above. This illustrates a condition during the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event.

24. State Names States are named. The name should depict the state – often verb phrases (if the name for your state is a noun then you probably have an incorrect idea about the state). State names are placed inside the rounded box.

25. State Actions Actions that must be performed during the period the state is active are placed beneath the state name. The details of a state’s actions are shown as a set of lines of the form: condition/operation in which the conditions entry, exit, and do are, by convention, used to represent processing an entry to a state, processing whilst in a state, and processing on exit from a state. Paid entry/calculate balance do/display balance exit/pay balance

26. Initial State An initial state is symbolized by a solid circle and line connected to a directional arrowhead This illustrates a condition at the beginning of the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event.

27. Transition A transition is graphically symbolized as a line with a standard directional arrowhead. This illustrates a relationship between two states, indicating that an object in the first state will enter the second state and perform certain specified actions when a specified event occurs, if specified conditions are satisfied. Transitions are named. The name is the message event that triggers the transition.

28. Transition Labels The full transition label consists of: Transition-name (parameters,…) [guard condition] /action-expression –Parameter list identifies parameters that the message is to pass to the object –Guard-condition is a true/false test to see whether a transition can be taken. (There are some transitions that only have a guard-condition and no event trigger. In these cases, the event is constantly firing and whenever the guard becomes true, the transition fires.) –Action-expression is a procedural expression that executes when the transition fires. It is the activity that occurs during the transition. Any of the three components may be empty. It is common practice to use the same name and parameter list for a message and a transition.

29. Transition Label Examples Transition name only: DeleteOrder() No guard condition: Order item (ItemID,qty)/resest register Guard condition only: [Credit no good] Multiple actions: CreateOrder(Order Information) /Build order information;Associate with Customer All components: PullNextItem(ItemID)[Item not Available]/ Mark line ‘Backorder’

30. Internal Transition Labels For an internal transition, the appropriate transitions are noted within the transition box using the format: –entry/action expression –do/action expression –exit/action expression Paid entry/calculate balance do/display balance exit/pay balance Checked entry/calculate order total do/display order total Verify Payment do/Calculate total; Verify credit Using multiple action expressions

31. Dot Notation The dot notation is used for messages sent by an object. Using dot notation, the object or class to which the message will be directed is placed first, then a dot, then the name of the message: ControlPanel.UpdateStatus(status) ControlPanel is the object to which the message UpdateStatus with a parameter of status is sent.

32. Final State An final state is symbolized by a solid circle inside an empty circle and is placed at the end of a directional arrowhead This illustrates a condition at the end of the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event.

33. Surrounding Rectangle - Superstate Rectangles are used as borders to identify groups of associated states. They make up a superstate. Generally any state outside a rectangle can be triggered at any time from within the superstate.

34. PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

35. Nesting of States Statechart diagrams can be expanded to show more detail – this is referenced as superstates and substates. A superstate may have superstates nested within it, each of which may in turn contain states and transitions, and possibly other superstates. As such, it is possible to create a hierarchy of states within a statechart diagram by nesting states inside superstates, and then nesting superstates inside other superstates.

36. Nested in Statecharts At each level of state nesting, there may be any number of superstates. For example, a statechart diagram may contain some states and two superstates, each with states nested inside it. A transition may be to a superstate, in which case the flow of control begins at the initial state symbol nested within the superstate.

37. State Diagram for Student Object

38. Nested State Diagram for Matriculated State of Student Object

39. Nested State Diagram for the Accepts Admission Offer Event

40. Concurrent States A superstate may contain more than one set of nested states and transitions, each set separated from all other sets, and each set having its own initial state and final state(s) symbols. These sets are considered to run concurrently. Concurrent state is the condition of being in more than one state at a time. These are represented as two separate paths. These paths are independent.

42. Modeling Rules Remember the rules on modeling. Show only what needs to be shown.  Not all attributes are important in determining the state of an object. Only those attributes which effect its gross behavior are considered important.  Student Class – student’s phone number may not be important in state of the object.  i.e., a change to a student’s phone number may not impact the state of the object.

43. Steps to Get Started Step 1: Review the class diagram and select the classes that will require statecharts. (Start with the assumption all classes need statecharts). Begin with the classes that appear to have the simplest statecharts.

44. Step 2 Identify all the input messages across all sequence diagrams from the selected cases. The use cases and scenarios and sequence diagrams provide the basis for identifying messages into and out of a class. One good assumption is that each message will be the trigger for a transition. Then you may add other transitions later on but this gives you a good starting point.

45. Step 3 For each selected class in the group, make a list of all the states you can identify. Begin by brainstromming. One effective way to start is to note that each transition identified in Step 2 requires at least one origin state and one destination state. Remember a state is a semipermanent condition or state of being of an object. Sometimes it is helpful to think of the physical object and translate those that are appropriate into corresponding system states. It is also helpful to think of the life of the object. –How does it come into existence? –When and how is it deleted? –Does it have active states? –Does it have inactive states? –Does it have states where it is waiting? Think of activities done to the object or by the object. Begin associating activities with states.

46. Step 4 Build statechart fragments and sequence the fragments in the correct order. From steps 2 and 3, you should have a fairly complete set of transitions and states. Build these individual states and transitions into statechart fragments. Build the life cycle path from these fragments and fill in missing pieces.

47. Step 5 Review the paths and look for independent, concurrent paths. Take different pairings of states and ask the question “Can the object be in both of these states at the same time? Or does one state naturally follow another state? These are dependent states and cannot be on current paths.

48. Concurrent vs Composite When an item can be in two states concurrently, there are two possibilities – either the two states are on independent paths, or one state in reality should be a composite state and the two states should be nested, one inside the other. One way to identify a candidate as a composite state is if it is concurrent with several other states. For example – a customer will be active and have outstanding orders. But what about the customer whose order has been shipped and they have no outstanding orders? If this customer is also considered active, then the active state is concurrent with multiple other state and is a composite state.

49. Step 6 Expand upon each transition with the appropriate message event, guard-condition, and action- expression. Include with each state appropriate internal transitions and action-expressions. (Much of this may have been done as the statechart fragments were being built.) Ensure that every output message identified is somewhere within an action-expression for a state or transition.

50. Step 7 Review and test each statechart by doing each of the following: –a. Make sure your states are really states of the object in the class. –b. Follow the life cycle and be sure all combinations are covered and the paths are accurate. –c. Be sure your diagram covers all exceptions as well as the normal course of action. –d. For each transition, ask is it really permissible for the object to go from state A to state B? –e. Review messages and make sure they are handled somewhere in the statechart. –f. Review all possible actions and activities and make sure they are included correctly in the statechart.

51. Once again the operative word is iterative. As with the other forms of OOA modeling, statechart modeling is iterative. The statechart diagram will initially show only terse details for states, but as iterative development progresses, the contents of statechart diagrams and their states will become increasingly detailed.