CPSC 333: Modeling State Information

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Modeling State Information


This material was covered during lectures on February 7, 1997.


Another Example: Traffic Light Simulator

Now, consider a system that simulates the behaviour of a traffic light, that is either ``off,'' or shows one of three colours (red, green, or yellow) - so it simulates a traffic light that works in one direction only. Assume that a user of the system can request that the light be turned on or off, or that its colour can be changed.

A more complete description of this system is also available.

If you were to try to analyze and specify this problem, by creating an entity-relationship diagram and set of data flow diagrams, you'd probably discover that the ERD was ``empty,'' but that you'd need to add a ``data store'' to your data flow diagrams - and that you'd (only) use this data store to remember whether the light was currently ``off,'' ``showing red,'' ``showing green,'' or ``showing yellow.''

The system's operations behave differently in the above four cases (and the operations' behaviours are easy to describe in each case), and each operation can cause one ``case'' to stop being applicable and another to start, in a reasonably easily-described way.

Another feature of this system is that the user requests that various operations are performed by doing something analogous to ``making a menu choice'' or ``pressing a button'' - no data is supplied when the operations are requested; either they're been requested, or they haven't.

Now, while you could model this system using what's been presented already, there are specialized symbols and notation that will be presented now, that will allow you to present some of the above ``special features'' of this system more clearly and more easily.

System State

A system state is a condition that persists for a non-negligible period of time - generally, between execution of system functions - that influences the behaviour of system's operations, and that can be changed by the execution of these operations.

The above ``traffic simulation'' system is an example of a system that has four discrete states, which we can call ``Off,'' ``Red,'' ``Green,'' and ``Yellow.'' It is always in exactly one of these four states.

This system also has the feature that its state is changed, in a predictable (and deterministic) way, when each one of two ``buttons are pushed'' or ``selections are made;'' the state that the system moves to doesn't depend on anything more than which of these two ``buttons'' are pushed, and the state that the system was in when this happened. (So, for example, the state change doesn't depend on any additional data that was supplied ``when the button was pushed,'' or that is in the system's data tables.'')

State-Transition Diagrams

A state-transition diagram is a diagram that shows a system's states - when (as in the above case) a finite, fixed, number of states for the system can be identified - as well as the ``transitions'' or ``changes'' between states that are possible, the specific ``control signals'' (or ``buttons being pushed'') that trigger each state change, and the additional ``controls signals'' that are generated in order to provide information to the rest of the system, when the state change occurs.

Here is a state-transition diagram for the above ``traffic light simulation'' system:

State-Transition Diagram

As this diagram should suggest, system states are shown as rectangles, with the name of the corresponding state shown inside each.

Possible state changes are shown by arrows, pointing from a state you can change from towards a state you change to (that is, in the direction you'd expect). Each is labeled by the name of an ``incoming'' control signal (which can trigger the given state change), shown above a horizontal line, that is shown above the name of an ``outgoing'' control signal (which should be sent out when the state change occurs).

For example, the above diagram shows that it is possible to change from state ``Red'' to state ``Green,'' when the control signal ``change'' is received from the rest of the system - and that the control signal ``is green'' should be sent back out again, when this change occurs.

We generally want our systems to be ``deterministic.'' Therefore, you should avoid including two or more state transitions that lead out of the same state and correspond to (or are triggered by) the same ``incoming control signal'' - if you do include these, then it won't be clear which state you should move to (and what control signal should be sent out), if this incoming control signal is received when the system is in this (initial) state.

It isn't necessary to include a transition for every possible combination of initial state and incoming control signal; you can assume that, if a control signal is received while the system is in some state, and there's no transition shown for that combination, then the state is not changed, and no control signal is sent out again. You can draw a transition from the state back to itself (as shown above, for the state ``Off' and incoming control signal ``change'') if you want to show that some control signal is to be sent out to the rest of the system, when this happens.

There will often be one (and only one) unlabeled arrow that seems to come ``from nowhere'' and that points to one of the system's states. This identifies a state that the system is in when it's first activated. For example, the above diagram shows that the traffic light simulation's ``start state'' is ``Off'' (meaning that the traffic light will be off, whenever the system is started up).

Augmented Data Flow Diagrams

Now, we can add ``control flows'' and ``control processes'' to data flow diagrams, to represent the same kind of information.

A control flow is a flow of information on a data flow diagram that corresponds to a ``button being pushed'' or a ``menu item being selected;'' either the control flow is ``active'' or it isn't, and no other information is conveyed by it. In other words, a ``control flow'' on a data flow diagram represents the possible transmission of one of the ``control signals'' mentioned above (in the discussion of state-transition diagrams), between a terminator and a process, or between two processes, on the diagram.

A control process is a process that can only receive control signals as inputs and send control signals back as outputs. A control process generally represents the system's state - and is ``specified'' by a state-transition diagram, instead of a process specification or a lower level data flow diagram.

Control flows are drawn as dashed arrows, and control processes are drawn as dashed circles. So, the following data flow diagram, which represents the ``traffic light simulation'' system, includes three ``regular'' processes, and one ``control process. The control process is ``specified by'' the state-transition diagram that is given above.

The data flow diagrams for systems (shown in this course, anyway) will generally include at most one control process, in total. Each control process should be specified by a state-transition diagram, and each state-transition should have a corresponding control process on the system's (``augmented'') data flow diagram(s), that it specifies.

Data Dictionary Entries

Control flows on augmented data flow diagrams should have data dictionary entries (and control processes don't need to). You can list the ``kind'' of a control flow as ``CF,'' and leave its ``type'' blank (there's really no information to add beyond the fact that it's a control signal). In the ``description,'' you might possibly state whether the control flow goes to, or comes from, a terminator.

The Example, Continued

A more complete specification of the traffic light simulation, including process specifications for the three ``regular'' processes, and a data dictionary, is available. You can view the process specifications by clicking on the corresponding processes on the data flow diagram that this includes.

[CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Modeling State Information


Department of Computer Science
University of Calgary

Office: (403) 220-5073
Fax: (403) 284-4707

eberly@cpsc.ucalgary.ca