3.6 State models
For objects with significant complex state it is useful to use UML state charts or state transition diagrams (STDs). These diagrams are used to capture the dynamics of individual objects and are related to the object model as effective specification of operations and their assertions. Statecharts represent possible sequences of state change from a particular point of view. Each transition is a realization of an action or use case. Depending on the domain. it is recommended that the technique is used sparingly during specification as we believe it will not always be of use for many objects that occur in MIS systems and that its prime benefits arise during physical design. On the other hand, the technique is a familiar, useful and possibly anodyne one for many workers in Telecommunications.
Another problem with over-zealous use of STDs is that they can be very complex very quickly. However, for some objects with complex life histories the technique is invaluable for capturing information about both the business and the system. A good example of an object where the technique is suitable is a loan application. However, the very act of representing this business process as a class is highly questionable in itself. It is often better to capture this kind of information in a use case model which then refers to classes such as loans. The individual circumstances will dictate the best approach.
Figure 22 States and transitions.
An object's significant states are determined by key arrangements of its attribute values. These and the valid transitions between them are captured by a state transition diagram. Figure 22 illustrates the basic notation. States, which can be regarded as Boolean attributes of the type or values of a particular 'state attribute', are represented by rounded rectangles labelled with their names. Transitions are labelled arrows connecting states.
Figure 23 An example.
Figure 24 STD notation.
Events that cause transitions to occur are written next to the arrows. Events may have attributes. For example, thinking of a calculator object, the event of pressing a key may have the attribute key_number. This avoids the need to have a separate event for each key. Events may have guards or pre-conditions. A guard determines a logical condition that must be true before the transition can take place. An action is a function that is executed - effectively instantaneously - after the transition occurs. States may have activities. These are functions that begin execution as soon as the state is entered and continue executing until completion or until the state is left, whichever is the earlier. A guard may mandate that the state may not be left until an activity is completed.
Henderson-Sellers (private communication) points out that novices often misuse and overuse activities. They effectively use their STDs as DFDs in this way. The use of activities is therefore not encouraged.
Figure 23 gives a simple example showing part of the life history of a pop-up menu. Initial and final states are shown as filled circles and ringed filled circles respectively as shown in this example. Start and End (Selected here) are not states but represent the creation and destruction of instances, so that the attributes become undefined.
States may be nested and partitioned into concurrent states to make the structure neater. Figure 24 summarizes most of the rest of the notation. We have omitted some details such as start and end states to avoid clutter that would add little in the way of understanding the basic ideas.
Subtypes inherit the state models of their supertypes as illustrated in Figure 25, where the context is a simple graphical editor.
Figure 25 States and subtypes.
Sometimes it is useful to represent the states of a type as bona fide types; so that rather than considering people as employed or unemployed we could create types for employees and so on. These can be considered as rôles, as discussed earlier, or as stative types. The latter view is useful when the attributes and behaviour are very different.
State charts, along with sequence diagrams, are useful for exploring and documenting use case refinements and making explicit the way a particular business process is implemented.
STDs describe the local dynamics of each object in the system. We still need some techniques to describe global behaviour. However, the use of rulesets helps to encapsulate locally some aspects of global behaviour, as we have seen. Statecharts provide an additional way to visualize the problem and usually expose use cases that one has missed on the first pass. It is therefore important to cross-reference them against use cases. They make clear which action sequences are permissible.