State Charts

Actions are described in terms of their effects on objects. They can be defined with postconditions (or state charts, as we ll see later) and illustrated with snapshots (see Section 1.1.1). 

We dealt with the static model in Chapter 2 we next want to specify actions in a way that abstracts from the model s many possible implementations. An action is specified by its effect on the state of the object and any information exchanged in the course of that action. This state is described as a type model of the object and of its in/out parameters the effect is specified as a precondition/postcondition pair. Effects can either be written textually or depicted as transitions on a state chart. 

State charts, and their simpler cousins, flat state diagrams, can be useful modeling tools. In Catalysis, states and transitions that appear in a state chart are directly related to the attributes and actions in a type specification. The state chart merely provides an alternative view of the spec. 

States are often drawn in a state chart showing the states and the relationships between them, as in Figure 3.21. Each state is a Boolean attribute17 an object either is or is not in that state at any time. The structure of states in the state chart defines invariants across these attributes. 

States in a simple state chart are mutually exclusive, with exactly one state true at a time, such as within sold this is what the xor invariants mean. 

State chart States implicitly define attributes Attributes and invariants... 

Figure 3.21 A state chart defines state attributes and invariants.

A state chart can be nested inside a state. While the containing state is false, none of the nested states is true while it is true, the nested state chart is live, meaning that one of its states (or one from each of its concurrent sections) must be true. This is the or invariant defining sold. 

A state chart can be divided into concurrent sections by a dashed line. Each of these sections is a separate simple state chart. The object is simultaneously in one state from each of the sections. No explicit invariants are needed because the two sets of states are independent. There is no paradox in this, nor necessarily any concurrent processing in the usual sense if s just that a state simply represents a Boolean expression, and there is no reason that two such statements should not be hue at the same time. 

In addition to defining state attributes and their invariants, state charts depict transitions between states. An example state chart for Session is shown in Figure 3.22 A session can be confirmed, tentative, or delivered changing the dates might switch between tentative and confirmed. 

A state chart is part of the model of a type. The elements of state chart notation are shown in Figure 3.23. 

The arrows indicate the sequences of transitions that are possible. indicates the state that is first entered when the state predicates first become well defined. This can mean when the object is first created or when this nested state chart is entered. indicates where state predicates become undefined when the nested state chart is exited or the object is no longer of any interest. Until reaching the black hole, all the predicates for the states in the diagram should be well defined, either true or false. 

If there are several transitions involving one event, the effects are conjoined. State charts give a different way of factoring the description of an action, and a good tool would move readily between two views state chart and textual action specification. Each state must be defined in terms of other attributes. 

When you re drawing state charts, be aware of the primary type that is being modeled. In simple cases the states and transitions are directly of the primary type being modeled. If we are trying to specify the behavior of a gas pump, the states and actions labeling the transitions are those of the pump itself. It translates directly into action specs such as these ... 

But when the primary type being modeled is complex, its states cannot necessarily be enumerated in the simple form required for representing it as a single state chart. The behavior of a Scheduler component such as the one in Figure 3.13 cannot be described on a single state chart (except with the most trivial states, exists, and all the interesting effects described in text on the transitions). This is because the state of the scheduler is defined by the states of its multiple sessions, instructors, and courses. 

Instead, you should draw separate state charts for the specification types that constitute the type model of Scheduler. In reality, we are defining the states of the scheduler in terms of the states of its specification types. The transitions in the individual state charts show what happens to those objects for each of the scheduler s operations (see Figure 3.24). 

Each individual state chart effectively specifies how every action on the primary type affects that one specification type. In contrast, a complete action specification defines how one action on the primary type affects any specification type member. The composition of all change dates transitions, on ary and all specification types, constitutes change dates operation specification for the scheduler. Do not confuse this state chart view with internal design, when we will actually decide internal interactions between objects within the scheduler, the primary types whose behavior we describe will be these internal objects. 

A useful technique in specifying a large component is to draw a state chart that focuses on all the elements of a particular type within a larger model—for example, showing what happens to the shapes in a drawing editor for each of the editors operations, select(self) is a shorthand for select(s) [s=self]. It s important to realize that this is really a state chart for the editor, in which the states are defined in terms of the states of its shapes. 

Sometimes a state chart is deliberately vague about the outcome of an action. The reason is usually to allow subtypes to make different choices, within broad constaints given by the supertype, or simply to define a minimal partial constraint. 

At any moment, a transition is said to be feasible if, before the current action began, the system was in the state at the arrow s source end and if any precondition it is labeled with was true. You are allowed to write a state chart for which there are several feasible transitions at any moment this is called an underdetermined set of transitions. When this is the case, what state will you end up in ... 

Perhaps that s tme in this case. But indeterminate state charts will be important when we discuss components. This component may be combined with a wide variety of others, including ones not yet known of so we actually don t know what the causes are, only what the possible outcomes can be. This situation might happen if we allowed our phone instrument to be connected to a new kind of switching system. As long as we have a way of reusing this underspecified model and adding to it in another context, it is worthwhile to make this separation. 

State charts themselves provide a useful view of behavior that is different from the view provided by action specifications. State charts focus on how all actions affect one specification type, highlighting sequences of transitions, as opposed to focusing on the complete... 

First, a state chart can be represented by a state transition matrix, as shown in Figure 3.26. In the matrix, X means shouldn t happen means nothing happens and [ ] means determined in subtypes. Writing the matrix is a valuable cross-check to ensure that each action has been considered in each state. This matrix can be generated automatically from the state charts themselves it better highlights combinations that may have been overlooked. 

By using the full apparatus of state charts, we can specify linear, branching, and concurrent sequences. 

Sequential outputs are sometimes better dealt with as refinements, as described in Chapter 6, Abstraction, Refinement, and Testing. State charts are also used to describe a collaboration refinement (in which zooming in on an action shows it to be a dialog of smaller ones). 

Occasionally it is useful to write a sequencing constraint in text form, although it could usually be described using the preferred state chart technique from the preceding section. 

The refinement relation between the two levels of description documents this mapping. The state chart shows how the parameters and state changes in the detailed action sequence translate to the abstract action and its parameters. In this example we use a counter attribute to define this mapping it is an attribute of a specification type representing a restocking in progress at the more detailed level (Pattern 14.13, Action Reification). 

You can draw a state chart showing in what order it makes sense for the actions to occur. This isn t as concrete as a program, because there may be factors abstracted away that permit different paths, and intermediate steps, to be chosen a program usually spells out every step in a sequence. The state chart is a visual representation of sensible orderings that could equally, if less visibly, be described by the pre- and postconditions of the actions. 

This is not the same thing as a state chart showing how different orderings actually result in achieving different abstract actions. The actions of a collaboration may have many possible sequences in which they can sensibly be used, but each abstract action consists of only certain combinations of them. For example, there are many combinations in which it makes sense to press the keys of a UNIX terminal. The keystrokes and the responses you get on the screen are a collaboration. But there is a more abstract collaboration in which the actions are the UNIX commands. To form any one of these commands, you press the keys in a certain sequence given by the syntax of the shell language. The overall sensible-sequences state chart is more permissive than the state chart that realizes any one abstract command. 

Specifications A specification describes actions using postconditions (perhaps drawn with state charts) the postconditions are written in terms of a vocabulary of objects and their static relationships, which is described in a type model. These documents must be inspected at external design reviews. Types, rather than classes, are the main focus. 

A state chart in a component spec refers to the component s behavior (see Figure 5.11). It can focus on one of the component s model types, but again, there is no guarantee that such a class will exist in an implementation, only that the information it represents will be implemented. 

Action Describes a complex protocol of interaction between objects as a single action, again characterized by the effect it has on the participants. What sequences of detailed actions will realize the effect of the abstract action Use state charts, sequence or activity diagrams. 

---