Implementation

1
PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e
Chapter 10 Statecharts
2
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

3
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)

4
States, Events and Transitions

• A simple statechart for a CD player

5
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

6
Initial and Final States

• Model the creation and destruction of objects

7
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

8
Guard Conditions

• Conditions added to events indicate when a
  transition can fire

9
Actions

• Actions are performed when a transition fires

10
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

11
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

12
Completion Transitions

• If an activity completes uninterrupted it can
  trigger a completion transaction
• these are transitions without event labels

13
Internal Transitions

• Internal transitions do not change state
• and so do not execute entry and exit actions

14
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

15
A Composite State
16
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

17
A Complex Composite State
18
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

19
Use of a History State
20
Complete CD Player Statechart (Summary)
21
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

22
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

23
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

24
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 cant 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

25
Adding a Second Interaction

• If all coins are entered before ticket selected

26
Integrating the Interactions

• In fact, events can occur in any sequence

27
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

28
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

29
Returning Change

• Use an activity state to calculate change

30
Ticket Machine Statechart
31
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.

32
Statechart (Summary)

• The main components are1) 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.

33
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.