5
Completing the Essential Model – the Upper Levels

5.1 Introduction

The transformation and data schemas derived from the event list, while accurate representations of system requirements, are often unpresentable. For a reasonably complex system, both models consist of masses of interrelated details with no obvious large-scale organization. To facilitate presentation, the model will be repackaged from a “flat” form to a hierarchical form, using the notation for leveling described in Chapter 12 of Volume 1. In this chapter, we’ll concentrate on packaging the transformation schema, from which the data schema organization can be derived.

The leveling considered here is strictly upward leveling – the grouping of event responses and associated flows and stores into larger units. The partitioning of single event responses into groups of lower-level transformations will be dealt with in the next chapter. Although most examples will focus on one-level-upward groupings, remember that for a large system several layers of intermediate groupings may be required.

Leveling, of course, imposes an additional type of organization on top of that derived from the event list. The unleveled transformation schema has a “natural” organization in the sense that it springs from the structure of the environment and is subject-matter-driven. It is important that we don’t impose undesirable characteristics on the model as a result of the leveling process. We’ll therefore introduce two guidelines for grouping the preliminary model into larger units.

The first guideline is that the upper-level groupings, like the event responses, must continue to reflect the structure of the environment in which the system will function. The essential model is intended to serve as a benchmark for the designer. Any reorganization required to meet implementation constraints will be evaluated in terms of how much the reorganization distorts the natural structure of the problem. For this reason, the essential model should reflect the structure of the environment at all levels of organization.

The second guideline is that the model should be as easy to understand and verify as possible. The success of a systems development project depends on effective quality control. Quality control, in turn, depends on the specifier’s ability to understand what is to be built. A model that is difficult to comprehend will frustrate the quality control process.

Both of the preceding guidelines will assist in preserving the long-term use of the model as a vehicle for specifying changes after the system is built. If the model is faithful to the system’s subject matter and easy to understand as a specification, it can be used to evaluate potential modifications to the system’s functioning.

In the following sections, we will examine a number of heuristics for upward leveling. These were chosen because they tend to create models that meet the guidelines just described. In many cases several heuristics suggest the same choice of upward leveling. When two heuristics point to two different upward groupings, a choice must be made as to which grouping best preserves the desirable characteristics of the model.

5.2 Partitioning to Minimize Interfaces

This heuristic states that the best grouping of transformations, flows, and stores is the one with the simplest, loosest connections. For this purpose, we consider event flow connections as tighter than stored data connections, since event flow connections require synchronization (see the discussion in Volume 1, Chapter 6, Modeling Transformations). We won’t discuss data flows here – a model built using the rules in the previous chapter shouldn’t have internal data flow connections.

Minimizing interfaces is important because the understandability of a section of the model is proportional to its independence from other sections. If the reader must frequently refer to other sections of the model to make sense of the one being examined, much of the value of the partitioning is lost.

Consider Figures 5.1 and 5.2, which illustrate two alternatives for upward grouping of the Cruise Control transformation schema (Appendix A). In Figure 5.1, the data transformations dealing with the throttle control loop have been grouped into one upper-level transformation, with the remaining transformations lumped into another grouping. The overall interface complexity of the partitioning is relatively high (15.5 tokens per transformation). In addition, the inter-transformation interface is particularly complex, requiring eight event flows to maintain synchronization.

Figure 5.2 was created from Figure 5.1 by simply moving the Control Cruise Control Engagement transformation into the throttle control loop grouping. This partitioning has a much lower interface complexity (9.5 tokens per transformation) and requires only two event flows for internal synchronization.

Figure 5.1 Essential Process Grouping with Complex Interfaces.

Imagine verifying the operation of the Cruise Control System using the lower levels of each of the two figures in turn. With Figure 5.1, the verifier must continually refer back and forth between the lower levels to see how each of the control loop modes is activated. This cross-referencing is unnecessary with the partitioning of Figure 5.2.

Please note that the control transformations of the original transformation schema may need to be reorganized (by repartitioning their state diagrams) to achieve the best grouping.

Figure 5.2 Essential Process Grouping with Simple Interfaces.

5.3 Identifying Hierarchies of Control

As we mentioned in Volume 1, Chapter 12 (Organizing the Model), it’s possible to use the leveling notation to make a control hierarchy coincide with the levels of the system. Incorporating a control hierarchy into the leveling is useful because it allows grouping together processes that are activated and deactivated all at once. This permits the model reader to understand the details of a group without having to refer continually to the activation/deactivation mechanism.

In Figure 5.3, the partitioning of Figure 5.2 has been modified to separate the levels of control. (The partitioning of the two lowest-level figures is consistent with the two transformations of Figure 5.2.) Notice that the transformations at the Mode Selection Level are relevant only if the engine is on, the transformations on the Manage Control Mode schema are relevant only if the cruise control itself is on, and so on.

Using the idea of a hierarchy of control often requires separating out near-trivial transformations at relatively high levels of the system. This uneven distribution of details is not a disadvantage if it simplifies the overall interpretation of the model.

5.4 Using Response-Related Groupings

Since the basic structure of the essential model is based on stimuli and responses, it is helpful to maintain this perspective when choosing upper-level groupings. For example, if an event recognizer transformation is necessary for the system to identify some event, the recognizer and the response should normally be in the same upper-level grouping.

It’s also possible to use the stimulus-response idea in a broader sense. A group of transformations comprising several responses will often coalesce into a single response if the scope of the system is broadened. Figure 5.4 shows some transformations from the Bottle-Filling system (Appendix B). Consider the effect of expanding Figure 5.4 to take in the actual bottle-filling and labeling technology. This expansion makes the Release Bottle, Bottle Removed, and related event flows, and the Weight and Bottle Contact data flows, internal to the set of transformations. The expanded schema can now be considered as a single response, which reacts to the availability of a bottle by producing a filled, labeled bottle (Figure 5.5).

Figure 5.3 Modification of Figure 5.2 to Introduce Control Hierarchy.

Figure 5.4 Transformations from Bottling System.

The group of transformations in Figure 5.4 has a close relationship derived from the system’s subject matter, and thus forms a natural upper-level grouping.

Figure 5.5 Single Response for Broader Scope Bottling System.

5.5 Using Terminator-Related Groupings

The terminators on the context diagram provide an obvious source of information about a system’s environment. Because of this, it is sometimes helpful to group together transformations whose inputs and outputs connect to a single terminator. Figure 5.6 shows a partitioning of the SILLY system (Appendix C) based on the context schema terminators.

In a system with a large number of terminators, it may be necessary to bundle together related terminators to achieve a reasonable number of upper-level groupings.

Figure 5.6 Upward Leveled Essential Model.

5.6 Nameability of Groupings

A very general criterion for a reasonable upper-level grouping is the ability to assign a subject-matter-specific name. It’s almost inevitable that names for upper-level subsystems can’t be as specific as those of lower-level transformations. However, if the modeler is forced to choose an unspecific name not related to the system’s subject matter, the choice of grouping itself is suspect.

5.7 Summary

In order to create a presentable essential model, it’s usually necessary to reorganize the preliminary schema derived from the event list. In this chapter, we have provided some guidelines for choosing the best organization for the upper levels. In the next chapter, we’ll look at the requirements for organizing the lower levels of the essential model.