Department of Computer Science Department of Computer ScienceAn important aspect of many systems is their dynamic behaviour; this is to do with behaviour over time, with how the system responds to external events or stimuli; it often involves state-dependent behaviour.
For example, a Video Cassette Recorder responds to various stimuli, corresponding to its user controlling it via buttons on the remote-control. It behaves differently (in terms of what stimuli it responds to, and how it responds) if it is in the recording state, or in the playback state, or in the idle state.
Systems for which this is important are event driven, or reactive. If stimuli have to be detected and dealt with inside time constraints, then it is a real-time system.
An important special case of dynamic behaviour is the interaction between human users and a system, in which user inputs (keyboard, mouse, etc.) are the events.
In what follows, we might be considering the dynamic behaviour of the whole system, or of some clearly defined component or subsystem (e.g. of its user interface, or of an entity, of a class of objects). There is always something outside, with which this thing of interest interacts.
Modelling techniques used in this area include:
- the sequence and collaboration diagrams described in the last lecture
- state transition diagrams and statecharts, described below
- entity life histories, which model the 'lifecycle' of an entity from an ER model
- process algebras (CCS, CSP), mathematical formalisms for representing events and states.
State transition diagrams are the most widely used, and the following section defines their main components.
An event is something which happens outside the thing which is being considered, possibly requiring some action to be taken. Events may be caused by the arrival of some data, or some simple stimulus which may be due to human activity or some other part of the system. Event names normally contain verbs, as in `Bus arrives’ or `Sun goes in’, or `Punch lands on jaw’. Events may also be caused by the passage of time (e.g. "it's 25ms since the reactor temperature was checked, so it’s time to do it again").
Events are atomic or instantaneous (at the chosen level of abstraction; for example, the Battle of Waterloo might be regarded as an event in European history). That is, an event just happens - there is no beginning or end associated with it. Some events may convey data as input. This could be shown as a list in brackets after the event name
Actions are what is done by the thing being modelled in response to an event. Imagine yourself as a boxer in the ring. The other boxer’s punches are events as far as you are concerned, but actions as far as they are concerned. Your punches are actions from your point of view, but events from your opponent’s viewpoint. So the distinction between the two partly depends on what it is that is being modelled. Actions are usually summarised by short active verb phrases like `Throw a left hook’, `Duck’, or `Buy a ticket’. Like events, actions are assumed to be instantaneous.
A state is a condition in which the thing being modelled stays for some period of time, during which it behaves in the same way.
Names of states are usually adjectives like `Idle’, `Busy’ or phrases like `Shopping’ or `Out for the count’. In a state transition diagram, states are represented by boxes, usually rectangular with rounded corners.
A transition is a change of state, usually caused by some particular event. Thus normally a state corresponds to the period of time between two significant events.
Transitions are shown in state transition diagrams by lines with arrowheads, leading from the old state to the new. Each transition is labelled with one or more events, separated by commas, and some actions. Event(s) and action(s) are separated by a '/', or the action is written under the event.
An activity is something which is done by the thing being modelled, while it is in a particular state. Usually an activity continues as long as the thing is in this state (which is what makes an activity different from an action).
A guard on a transition is some condition which must be be true for the event to cause a transition. The condition may be as complex as is needed, but might typically be a check that some value is above or below some limit, or that some data are valid. Guards should be written in square brackets after the event name.
These are the most widely used notations for dynamic modelling. As usual, there are several varieties. In our version, the most general annotation for a transition is:
event(list of input data) [guard] / action
Any of these may be absent for a particular transition.
Here is a simple example, a STD for a digital watch. There are two buttons on the watch called the ModeButton and the IncButton; pressing either of these generates an event, which may cause a transition between two states. There are three states called Display, Set Hours and Set Minutes. Display is the start state, indicated by the arrow from the black dot. In the Set Hours state, event ModeButton causes a transition to the Set Minutes state, whereas event IncButton causes the action Increase Hours to occur (with no state change).
State Transition Diagram for a Digital Watch
Each state has an activity, below the horizontal line, after the keyword do.
A more complicated example is given below. Here we use a STD to model the 'life history' of a BOOKING in the Willowbank case study.
The black circle denotes the start state for the diagram. In this case, there is a Create event which creates an occurrence and leaves it in state New.
The bullseye denotes the end state for the diagram. Cancelled, Played and NeverPlayed all have eventless transitions to it, so they are effectively end states for a BOOKING (it is clearer to show it this way, rather than having arrows into a state with no arrows out).
The transitions from New and Paid to NeverPlayed have conditions but no events. Here it is the passage of time which triggers the transition, so we could think of this as a temporal event.
State Transition Diagram for BOOKING entity
State transition diagrams suffer from a ‘state explosion’, in which the number of states and transitions becomes unmanageable, for all but the simplest systems. A particular problem (as usual!) is the modelling of exceptions, where an 'error event' may cause a transition from a number of states (e.g. a user abort or undo).
A number of extensions to the conventional diagrams are due to David Harel, and called by him ‘Statecharts’. The major step forward is to allow nesting of states; this immediately introduces hierarchy into diagrams, and allows behavior to be understood at different levels. For example, a simplified STD for a telephone line might be as follows:
We could now decompose the Making Call state into a more detailed state transition diagram. A phone line which is in its Making Call state will be in exactly one of the states Dialling, Connecting, etc, at any one time.
Normally a lower level diagram like this one would have a start state and an end state (black circle and bullseye). The transition into the state on the higher level diagram puts it into the start state on the lower level one. This happens here: the lifts receiver event causes a transition from Idle to Dialling in Making Call.
Similarly, when the end state of the lower level diagram is reached, the transition back on the higher diagram takes place on the appropriate event.
However, in this example, there is no explicit stop state (bullseye) in Making Call; the transition back to Idle takes place if the event hang up occurs in any of Making Calls substates. This is an additional novelty introduced with state charts; it is rather as if the substates inherit the hangs up event from the superstate; this is a very useful convention for modelling asynchronous events such as interrupts; without this convention, we would need a transition out of each substate of Making Call for hang up.
There are a number of other extensions to state transition diagrams in Statecharts, although the idea of nesting diagrams is the most useful. Harel's notation has been widely accepted, and is incorporated into a number of object-oriented techniques. See the bibliography for further details.
Statecharts are used in the UML Dynamic Model to show the dynamic behaviour of a single class (concept), if this is found to be interesting enough. For example, here is a high-level state chart for our Scanner, which goes through a regular cycle of being in the panel waiting to be selected, being used by a customer, and being at the checkout.
Exercise
Decompose the InPanel, InUse and AtCheckout states into substates. Refer back to the original problem description given out in tutorials. Model temporal events using timers; for example, pair the ReturnToPanel event with a StartTimer action. The scanner will stay in this Charging state until a 5MinsUp event occurs.
Staecharts attempt to model all of the behaviour of a class, whereas sequence and collaboration diagrams only deal with a snapshot of that behaviour - a single transaction or use case. Nevertheless, sequence or collaboration diagrams should be consistent with the state chart; we should be able to find a route through the state chart for each possible sequence diagram. For example, here is a sequence diagram for a card-controlled entry system for a car park: there is a card reader, plus a pressure-sensitive car detector pad on each side of a barrier. The Gate class controls entry, in conjunction with an external EventManager which validates the Card.
This diagram only shows one possible scenario, in which the card is valid. The state chart for the Gate below deals with this case, and the one in which the card is not valid.
Statechart for Gate Class
Notice that each incoming message to the
Gate in the sequence diagram (CarDetected, CardDetected, Valid) appears here as an event. This diagram also shows the UML convention for actions which correspond to messages (events) being sent from this object to other objects: these takes the form
^object_name.event_name
For example: ^CardReader.CardValid ^Barrier.Raise
If CardReader has a state chart, CardValid should appear as an event in it.
Events in a state diagram for a class would normally correspond to operations (routines or methods) on the class in its implementation.
David Harel Statecharts:a visual formalism for complex systems. Science of Computer Programming 8 (1987)
(Harel's original paper)James Rumbaugh et al Object-oriented Modeling and Design Prentice-Hall 1991
(probably the most accessible account of dynamic modelling and the use of statecharts, in an object-oriented framework).
Last Updated: 24/11/98 by M.Wood@herts.ac.uk
© University of Hertfordshire Higher Education Corporation (1998)
