14.4 Input Conditioning

Partitioning control into concurrently executing state machine instances requires their synchronization, but this can introduce more complexity than was removed by the original partitioning of control.

Consider, as an example, the synchronization between the selection and the shopping cart. Broadly:

• Creation of a selection requires the prior creation of a cart.

• Several selections can be made at once because objects execute concurrently, requiring interselection coordination.

• After checkout, no more selections can be made, which requires coordination with the cart.

• Cancellation of the order must prohibit further selections.

The difficulty is that these rules are not trivial to enforce in the general case. Worse, in reality, the customer is actually only doing one thing at a time, so preventing all this concurrent behavior is a waste of time.

14.4.1 Input Sequencing

Realistically, the customer is going to be doing only one thing at a time and will do those things in a particular order: create a cart, make a sequence of selections, and check out. As long as the inputs are presented this way, the statechart diagrams will remain simple.

We can construct the models for the bookstore domain subject to the assumption that the signals are presented in this general order. This assumption is a requirement on the domain(s) that provide(s) the signals, in this example, on the user interface domain. By making these sets of assumptions requirement pairs across the bridges between the domains, the problem of sequencing is pushed out of the application domain and down to the domains that provide the signals. This is feasible only because the customer will do only one thing at a time.

The assumption can be formalized by constructing an activity diagram for the use case (Figure 14.10), showing the order in which the application domain accepts the signals. The activity diagram assumes that each activity terminates before the customer is able to start the next one. Should these sequencing assumptions not be realized, the state machines will not operate as hoped.

Figure 14.10. Activity Diagram Showing Input Sequencing

Any server domain that provides the signals according to the order specified on the activity diagram will work: a web GUI, a Windows GUI, a command-line interface, or an XML document parser. The application domain does not say how the signals are obtained, only the order in which they must be provided.

14.4.2 Distributing the Inputs

The inverse of sequencing the inputs to simplify the state machines is the distribution of the inputs from a form or other user interface mechanism across multiple state machines.

It is not unusual for a form to provide values that describe several classes, such as Selection.quantity and Charge.chargeNumber. Intuitively, these inputs arrive at once with a single signal directed to a single state machine. The receiving state machine passes on unused data items as signal parameters to other state machines, which may in turn pass on further data items to other state machines. The overall pattern is to single-thread the signal through the several state machines, effectively sequencing them unnecessarily. In addition, the state machines are unnecessarily coupled by the signal parameters that must be passed on through state actions. Note, for example, how the checkOut signal to the Order carries shipping information that is simply stored in the Order until the charge is approved.

An alternative approach is to distribute a set of signals to the state machines that use the associated signal parameters and thereby reduce the coupling. Once the form is accepted, all the signals become available to all the state machines, and there is once again a synchronization problem.

The solution is the same as above: Condition the inputs so that each signal is completely processed before the next is accepted. This rule becomes an assumption placed on the bridge to the user interface, which can readily meet the requirement by treating acceptance of the form as a sequence of signals, each treated as a single system interaction. The pattern for that interaction is also defined by the activity diagram in Figure 14.10.