Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 10: Statecharts

Practical Object-Oriented Design with UML 2e Slide 1/2 ©The McGraw-Hill Companies, 2004 Specifying Behaviour ●Interaction diagrams –show how an object behaves in particular interactions –do not specify all the possible behaviours of an object. The order of messages is specific to particular interaction (e.g. a use case) ●Different notation is needed to summarize the overall behaviour of objects ●UML defines statecharts for this purpose

Practical Object-Oriented Design with UML 2e Slide 1/3 ©The McGraw-Hill Companies, 2004 State-dependent Behaviour ●Objects respond differently to the same stimulus at different times ●This is modelled by defining a set of states –an object can be in one state at any time –the state it is in determines how it responds to events detected or messages received –in particular, an event can cause the object to move from one state to another (a transition)

Practical Object-Oriented Design with UML 2e Slide 1/4 ©The McGraw-Hill Companies, 2004 States, Events and Transitions ●A simple statechart for a CD player:

Practical Object-Oriented Design with UML 2e Slide 1/5 ©The McGraw-Hill Companies, 2004 Statechart Semantics ●A statechart defines the behaviour of instances of a given class ●An object is in one active state at a time ●Events may be received at any time ●An event can trigger a transition –a transition from the active state will fire if it is labelled with the event just received ●The transition leads to the next active state

Practical Object-Oriented Design with UML 2e Slide 1/6 ©The McGraw-Hill Companies, 2004 Initial and Final States ●Model the creation and destruction of objects

Practical Object-Oriented Design with UML 2e Slide 1/7 ©The McGraw-Hill Companies, 2004 Non-determinism ●Sometimes there are two transitions with the same event label leaving a state ●Some systems are non-deterministic –but usually the non-determinism can be removed by adding more information

Practical Object-Oriented Design with UML 2e Slide 1/8 ©The McGraw-Hill Companies, 2004 Guard Conditions ●Conditions added to events indicate when a transition can fire

Practical Object-Oriented Design with UML 2e Slide 1/9 ©The McGraw-Hill Companies, 2004 Actions ●Actions are performed when a transition fires

Practical Object-Oriented Design with UML 2e Slide 1/10 ©The McGraw-Hill Companies, 2004 Entry and exit actions ●Entry and exit actions are properties of states –they are performed whenever an object arrives at or leaves the state, respectively

Practical Object-Oriented Design with UML 2e Slide 1/11 ©The McGraw-Hill Companies, 2004 Activities ●Activities are also properties of states –they are performed while the object is in a state –unlike actions, they can be interrupted by new events

Practical Object-Oriented Design with UML 2e Slide 1/12 ©The McGraw-Hill Companies, 2004 Completion Transitions ●If an activity completes uninterrupted it can trigger a completion transaction –these are transitions without event labels

Practical Object-Oriented Design with UML 2e Slide 1/13 ©The McGraw-Hill Companies, 2004 Internal Transitions ●Internal transitions do not change state –and so do not execute entry and exit actions

Practical Object-Oriented Design with UML 2e Slide 1/14 ©The McGraw-Hill Companies, 2004 Composite States ●Composite states group together states –this can simplify a statechart by grouping together states with similar behaviour ●An object still has one ‘bottom-level’ active state –but may be in a composite state as well

Practical Object-Oriented Design with UML 2e Slide 1/15 ©The McGraw-Hill Companies, 2004 A Composite State

Practical Object-Oriented Design with UML 2e Slide 1/16 ©The McGraw-Hill Companies, 2004 Properties of Composite States ●Transitions –from a composite state apply to all substates –to a composite state go to the state indicated by a nested initial state –can cross composite state boundaries ●Composite states can have activities and entry and exit actions ●A final state in a composite triggers a completion transition from the composite

Practical Object-Oriented Design with UML 2e Slide 1/17 ©The McGraw-Hill Companies, 2004 A Complex Composite State

Practical Object-Oriented Design with UML 2e Slide 1/18 ©The McGraw-Hill Companies, 2004 History States ●Often an object needs to ‘return to the previous state’ ●This can be done by defining conditions –such as ‘[if the last state was Playing]’ ●Composite states can have a history state –this ‘remembers’ the last active substate –a transition to a history state makes that substate active again

Practical Object-Oriented Design with UML 2e Slide 1/19 ©The McGraw-Hill Companies, 2004 Use of a History State

Practical Object-Oriented Design with UML 2e Slide 1/20 ©The McGraw-Hill Companies, 2004 Complete CD Player Statechart (Summary)

Practical Object-Oriented Design with UML 2e Slide 1/21 ©The McGraw-Hill Companies, 2004 Creating a Statechart ●It can be hard to identify all necessary states ●Statecharts can be developed incrementally –consider individual sequences of events received by an object –these might be specified on interaction diagrams –start with a statechart for one interaction –add states as required by additional interactions

Practical Object-Oriented Design with UML 2e Slide 1/22 ©The McGraw-Hill Companies, 2004 Ticket Machine ●Consider a ticket machine with two events –select a ticket type –enter a coin ●Basic interaction is to select a ticket and then enter coins –model this as a ‘linear’ statechart

Practical Object-Oriented Design with UML 2e Slide 1/23 ©The McGraw-Hill Companies, 2004 Refining the Statechart ●This can be improved by adding ‘loops’ –the number of coins entered will vary: entry will continue until the ticket is paid for –the whole transaction can be repeated

Practical Object-Oriented Design with UML 2e Slide 1/24 ©The McGraw-Hill Companies, 2004 Adding Another Interaction ●The user could enter a coin before selecting a ticket ●A ‘coin’ transition from the ‘Idle’ state is needed to handle this event –this transition can’t go to the ‘Paying for Ticket’ state as the ticket is not yet selected –so a new state ‘Inserting Coins’ is required ●The statechart is thus built up step-by-step

Practical Object-Oriented Design with UML 2e Slide 1/25 ©The McGraw-Hill Companies, 2004 Adding a Second Interaction ●If all coins are entered before ticket selected:

Practical Object-Oriented Design with UML 2e Slide 1/26 ©The McGraw-Hill Companies, 2004 Integrating the Interactions ●In fact, events can occur in any sequence:

Practical Object-Oriented Design with UML 2e Slide 1/27 ©The McGraw-Hill Companies, 2004 Time Events ●Suppose the ticket machine times out after 30 seconds –we need to fire a transition that is not triggered by a user-generated event –UML define time events to handle these cases

Practical Object-Oriented Design with UML 2e Slide 1/28 ©The McGraw-Hill Companies, 2004 Activity States ●Activity states defines periods of time when the object is carrying out internal processing –unlike normal activities, these cannot be interrupted by external events –only completion transitions leading from them –useful for simplifying the structure of complex statecharts

Practical Object-Oriented Design with UML 2e Slide 1/29 ©The McGraw-Hill Companies, 2004 Returning Change ●Use an activity state to calculate change

Practical Object-Oriented Design with UML 2e Slide 1/30 ©The McGraw-Hill Companies, 2004 Ticket Machine Statechart

Practical Object-Oriented Design with UML 2e Slide 1/31 ©The McGraw-Hill Companies, 2004 Statechart (Summary) ●What can be modelled?: In the UML, the term state machine refers to the technique used to model behavior in terms of states and transitions. A UML statechart diagram is a graphical representation of a state machine showing states, transitions and events. SC represents the life history of objects of a given class, rounded rectangles represent a states with directed transition lines between them. SC can be used to model anything where state change is considered important e.g. the state of a hospital ward could be empty or full.

Practical Object-Oriented Design with UML 2e Slide 1/32 ©The McGraw-Hill Companies, 2004 Statechart (Summary) ●The main components are:1) the states involved which are represented by the rectangles with rounded corners containing their names; and 2) the transitions which are represented by arrows and identified by the events thatgive rise to them. SC shows states, state transitions, and events. Transitions are said to be fired or triggered by events. The firing of a particular transition depends on the current state. In general a transition label can have three parts, all of which are optional: Event [Guard] / Action.Events can be Signals, calls, time, or state change. There can be entry events and exit events, action that is marked as linked to the entry event is executed whenever the given state is entered via a transition. The action associated with the exit event is executed whenever the state is left via a transition. A guard or [condition] is a logical condition that will return only “true” or “false.” A guarded transition occurs only if the guard resolves to “true.”

Practical Object-Oriented Design with UML 2e Slide 1/33 ©The McGraw-Hill Companies, 2004 Statechart (Summary) ●How can statecharts can used by the analyst? State diagrams are good at describing the behavior of a single object across several use cases. They are not very good at describing behavior that involves a number of objects collaborating together. As such, it is useful to combine state diagrams with other techniques. For instance, interaction diagrams are good at describing the behavior of several objects in a single use case, and activity diagrams are good at showing the general sequence of actions for several objects and use cases. Not needed for every class in the system. Use state diagrams only for those classes that exhibit interesting behavior, where building the state diagram helps you understand what is going on. UI and control objects have the kind of behavior that is useful to depict with a state diagram.