1. THE OBJECT-ORIENTED DESIGN WORKFLOW Statechart Diagrams

2. l Activity diagram versus a statechart diagram –Both model DYNAMIC behavior of a system –Activity diagrams are a special case of a statechart diagram where the states are actions and the transitions are triggered automatically by the completion of a state’s action and activities –Activity diagrams tend to be used for modeling business processes where several objects participate –Statechart diagrams tend to be used for modeling the lifecyle history of a single reactive object (respond to external events, have states and transitions) –Statechart most commonly used to model dynamic behavior of classes

3. Statechart Diagrams l Statechart Diagram –Statecharts (state diagrams) show the lifetime behavior of a single object –Used to capture dynamic behavior by describing all possible states and state changes as a result of events that reach the object

4. Finite State Machine (FSM) l A finite state machine is a conceptual machine with a finite number of states l It can be in only one of the states at any specific time l A state transition is a change in state that is caused by an input event l The next state depends on the current state as well as the input event l In UML, a state transition diagram is called a state chart

5. State Machines

6. States l The UML Reference Manual defines a state as, “a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event”. l The state of an object varies over time, but at any particular point it is determined by: –the object attribute values –the relationship it has to other objects –the activities it is performing l Key to successful statechart modeling is identifying the states that make a difference in your system

7. States

8. State Syntax EnteringPassword entry/display password exit/validate alphaKeypress/echo “*” help/display do/get state name entry and exit actions internal transitions internal activity Each state may contain zero or more actions and activities Actions are instantaneous and uninterruptible Activities take a finite amount of time and can be interrupted

9. Simple Example – Light Bulb Off On turnOffturnOn event trigger

10. Simple Example – Bank Account

11. Actions & Activities l Two special actions: –Entry action (associated with entry event) –Entry event occurs instantaneously and automatically on entry into the state »It is the first thing that happens when the state is entered »Causes the associated entry action to execute –Exit event is the last that happens instantaneously and automatically on exit from the state »Causes the associated exit action to execute l Activities take a finite time and may be interrupted by the receipt of an event –Keyword do indicates an activity –May not finish due to interruption

12. Transitions l UML Syntax l anEvent – this is an external or internal occurrence that triggers the transition l guardCondition – this is a Boolean expression the must evaluate to TRUE before a transition can occur l anAction – this is a piece of work associated with the transition and occurs when the transition fires

13. Transitions

14. Events and External Actions l State transitions occur in response to events l If there is more than one transition out of a state, a guard condition determines which transition is fired l An action may occur when the transition fires (multiple actions should be expressed in a comma separated list) l If there is no action associated with a transition, the event only causes the change of state, and there is no observable response from the object unless it has internal actions State_1 State_2 entry / entry_action exit / exit_action do / activity event [guard] / action

15. Types of Events l Call event –simplest type of event –the receipt of a call event is a request for a set of actions to occur –Really just a request for a specific method to be invoked Bank Acccount

16. Types of Events l Signal Event –Package of information that is sent asynchronously between objects –Modeled as a stereotyped class that contains all of the communication information as its attributes

17. Types of Events l Change events –has the keyword when, and then a Boolean expression –action associated with the event is performed when the Boolean expression is true –All values in the Boolean expression must be attributes of the context class

18. Time Events l Time events are denoted by the keywords when and after –keyword when specifies a particular moment in time that the event triggered –keyword after specifies a threshold time after the event triggered »e.g. after (3 months) and when (date = 08/04/04)

19. Methods and attributes l The state of an object will be determined by the values of the attributes of the class –in many cases, only a subset of the attributes will be relevant for modelling the state –looking at the attributes should help identify possible states –an event causing a change of state leads to a change in the object’s attribute values l Events can be implemented as public methods –the object is notified of an event by receiving a message from another object l Actions and activities should be implemented as private methods –it should not be possible for actions to be invoked without a valid event occurring l Entry, exit and internal actions should also be private methods

20. Guidelines for Developing Statecharts l A state name must reflect an identifiable situation or an interval of time when something is happening in the system. l Each state must have a unique name. l It must be possible to exit from every state. l On a flat (not hierarchical, composite) statechart, the system is in one state at a time. l An event is the cause of the state transition. An action is the effect of the state transition. l An event happens at a moment of time; an action happens instantaneously; an activity executes throughout a state. l Actions, activities and conditions are optional. Use only as necessary.

21. Developing Statecharts from Use Cases l To develop a statechart from a use case, start with a typical scenario given by the use case. –This scenario should be the most typical path through the use case, involving the most usual sequence of interactions between the actor(s) and the system. l Then consider the sequence of external events given in the scenario. –In each case, an input event from the external environment causes a transition to a new state. –An action or an activity may associate with the transition. –Actions and activities are determined by considering the response of the system to the input event, as given in the use case description.

22. Developing Statecharts from Use Cases l Initially, a flat statechart is developed following the event sequence given in the scenario. l To complete the statechart, determine all the possible external events that could be input to the statechart. –You do this by considering the description of alternative paths given in the use case.

23. Example of Developing a Statechart from a Use Case l Actor: Driver l Summary: This use case describes the automated cruise control of the car, given the driver inputs via the cruise control lever, brake, and engine external input devices. l Precondition: Driver has switched on the engine and is operating the car manually. l Description: –1. Driver releases the cruise control lever in order to cruise at a constant speed. The system stops automatic acceleration and starts maintaining the speed of the car at the cruising speed. The cruising speed is stored for future reference. –2. Driver presses the brake to disable cruise control. The system disables cruise control so that the car is once more under manual operation. –3. Driver moves the cruise control lever to the ACCEL position and holds the lever in this position. The system initiates automated acceleration so that the car automatically accelerates.

24. Example of Developing a Statechart from a Use Case l Description (continued): –4. Driver moves the cruise control lever to the RESUME position in order to resume cruising. The system initiates acceleration (or deceleration) toward the previously stored cruising speed. –5. When the system detects that the cruising speed has been reached, it stops automatic acceleration (or deceleration) and starts maintaining the speed of the car at the cruising speed. –6. Driver moves the cruise control lever to the OFF position. The system disables cruise control, so the car is once more under manual operation. –7. The driver stops the car and switches off the engine.

25. Example of Developing a Statechart from a Use Case l Alternatives: –1. The Accel, Cruise, Resume, and Off external events from the cruise control lever. The Accel event causes automated acceleration, providing the brake is not pressed. The Cruise event may only follow an Accel event. The Resume event may only occur after cruising has been disabled and the desired cruising speed has been stored. The Off event always disables cruise control. –2. The Brake Pressed and Brake Released external events from the brake. The Brake Pressed event always disables cruise control. Automated vehicle control is not possible as long as the brake is pressed. After the brake is released, automated vehicle control may be enabled. –3. The Engine On and Engine Off external events from the engine. The Engine Off event disables any activity in the system. l Postcondition: –The car is stationary, with the engine switched off.

26. Cruise Control Statechart

27. Statechart Example – SSN Pin Validation

28. ATM Example

29. ATM Example – Single Session

30. Loan Approval Example

31. ISP Dial-UP Example

32. Modeling the Lifetime of an Object