7
Essential Model Traceability
7.1 Introduction
The modeling tools presented in Volume 1 were organized around two major views of a system, the transformation view and the data view. This idea is not restricted to models of systems to be developed. It can also be applied at a higher level to the model-building environment itself. In this sense, the current volume has given a transformation view of the building of an essential model. Information about the environment in which a proposed system will operate is transformed into an environmental model. The environmental model, together with further information about the proposed system, is transformed into a behavioral model.
Figure 7.1 shows a common variation of this model-building process in which some of the preliminary information takes the form of a narrative specification document containing statements of requirements. The Narrative Specification Document, Environmental Model, and Behavioral Model are shown as stores since they must be maintained over time and are created by or made accessible to other transformations. For our purposes, the data compositions of the stores should be thought of as:
narrative specification document = {narrative requirements statement}
environmental model = {terminator} + {store} + {flow} + {event}
behavioral model = {transformation} + {flow} + {store}
The approach to model building represented by Figure 7.1 has a major deficiency. Although data is stored about the successive transformation products (models) no data is stored about the linkage between a product and its predecessors. This does not prevent the models from being built, but it does prevent tracing the connections between successive models after the fact. To correct the problem, the transformations of Figure 7.1 must create stored data showing the connections between elements of the input model and the elements of the output model. However, let’s pursue the subject by shifting our point of view and looking at the stored data exclusive of the transformations (Figure 7.2).
The schema of Figure 7.2 deliberately omits the internal connections among the elements of the environmental and behavioral models to emphasize the inter-model connections. It specifies a data base that will permit tracing connections among the narrative specification document, the environmental model, and the behavioral model. Traceability of this kind is in fact required by some development standards (for example, the standards of the U.S. Department of Defense.) Whether or not it is a formal requirement, traceability is vital to effective quality assurance of the systems development process.
Figure 7.1 Essential Model Building Transformation Schema.
Figure 7.2 Essential Model Building Data Schema.
In the remaining sections of the chapter, we will examine traceability between the narrative requirements statement and the components of the essential model, and between the sections of the essential model. Traceability is best implemented by an automated system that is integrated with a computer-readable representation of the essential model. The tracing information could be stored in a database, then sorted and printed in a variety of formats; ad-hoc enquiries could also be supported. However, we will illustrate the basics of establishing traceability by means of simple tables.
7.2 Traceability between Narrative Requirements and the Environmental Model
The elements of the environmental model – events on the external event list and terminators, flows, and stores on the context schema – each have their origin in a need for the proposed system to deal with some aspect of its environment. A simple tracing table can be constructed that cross-references these environmental elements to their justification in a narrative requirements document. Table 7.1 shows a portion of a tracing table for the Cruise Control System (Appendix A).
Table 7.1 Environmental Model Tracing Table for Cruise Control System.
In certain cases the correspondence between the narrative and the model is straightforward and obvious. The identification of “Driver” as a terminator, for example, is motivated by a number of references and only the first reference is included in the table. There are other cases in which the correspondence is not quite so obvious. The terminator associated with the speed control output was chosen to be Throttle rather than Valve, for instance. The choice is motivated by the fact that the valve, suction apparatus, and chain serve as a transmission mechanism for the throttle control signal. The detailed operation of the control loop may be sensitive to quantitative characteristics of the transmission mechanism, such as the delay introduced. However, the essential model as defined here is compatible with many possible linkages to the throttle. This does not mean that the linkage description in the narrative will be ignored, merely that it relates to the implementation rather than to the essential model.
Notice also that the Brake Pedal, rather than the Driver, was chosen as the source of the Brake flow, even though the driver actually manipulates the brake pedal and is in a sense the source of the input. The narrative is quite specific in stating that the system is to respond to the driver’s manipulation of the brake pedal rather than directly to the driver. It would be possible to define a system in which the driver directly requested that the current speed be remembered for future reference, but that system would have a different essential model.
Both of the decisions just mentioned – the exclusion of the specifics of the throttle linkage and the tieing of speed maintenance interruption to use of the brake pedal – might be challenged and debated by the writers of the narrative, assuming that the writers are not the essential model builders. The tracing table is serving a very important function if it fosters such challenge and debate, by making visible the thought processes involved in model building and enhancing the effectiveness of the model verification process. Visibility of the thought process is even more important if there are elements of the essential model that are not directly drawn from the narrative but rather are assumed by the model builders to be implied by the narrative. As an example, a careful reading of the background information for the SILLY system (Appendix C) discloses that nowhere is it stated that the collected logic states are to be displayed! The inclusion of an output flow to display the states is an obvious inference. However, it is not strictly impossible that the writers of the narrative intended the states to be stored for later display by some other system, and simply neglected to include that information. The absence of a specific trace from an essential model element to the narrative (indicated by a table entry with “derived” or “inferred” in the source column) is thus an important piece of information and invites close examination by a reviewer.
7.3 Traceability to the Behavioral Model
The elements of the behavioral model – transformations, flows and stores in addition to those on the context schema, and object types and relationships – may have their origins in the environmental model, the narrative requirements document, or both. Table 7.2 shows a partial tracing table for the Cruise Control System (Appendix A).
Table 7.2 Partial Tracing Table for the Cruise Control System in Appendix A.
In general, the transformations of the behavioral model fall into three types; those that recognize events, those that respond to events, and those that control the interaction among events. A given event may thus be the motivation for:
a transformation by which the system recognizes that the event has occurred, if the occurrence of the event doesn’t correspond directly to the arrival of a discrete input,
one or more transformations by which the system responds to the event,
state transitions within a control transformation that permit or prohibit responses to other events, if the event is part of an interdependent group.
(The correspondence between the other elements of the environmental model – context schema flows, stores, and terminators – is part of the structure of the model itself and need not be documented by a trace.)
In addition to being documented, the connections between events and elements of the behavioral model must be justified. The most straightforward justification is that the narrative requirements document describes the event, the nature of the response, the flows and stores used as inputs and outputs by the response, the mechanism by which the system recognizes that the event has occurred (if any), and interactions between this event and others that affect the response. If any of these elements are missing, the tracing document should indicate the rationale for any assumptions made.
The most likely omission in a narrative requirements document is a systematic description of event dependencies. In Table 7.2, for example, the transformation Control Cruise Control Engagement controls the interactions of four events, but only two of the possible sequences are described by the narrative. There is no information on the expected system response to the sequence Brake Pedal is Depressed followed by Driver Requests End of Speed Increase. The “obvious” solution – and the one chosen – is that the second event will not elicit a response. However, what is obvious to the model builder may not be obvious to the narrative specification writer, and it is important that these decisions be documented.
Figure 7.2 traces a behavioral model in which the stored data requirement is quite simple and consists of requirements for storage of a few individual data elements. If the stored data requirement were more complex, tracing between the narrative and the object types and relationships of the stored data model might be more convenient.
7.4 Use of Tracing Tables in the Absence of a Narrative
It is possible that a development project may proceed directly with the creation of a model without an initial narrative document. It is also possible that a narrative document take the form of a general charter for the project and contain no detailed requirements from which traces may be made. In this case tracing tables may still serve a valuable purpose. The “source” columns in the various tables, instead of referring to a narrative document, can contain brief descriptions of the reasons for choosing terminators, responses, and the like. Whether or not a narrative requirements document exists, tracing tables provide a valuable “audit trail” of the thought process involved in the model building activity.
7.5 Documentation of Omissions from the Model
The tracing tables described thus far answer questions of the type “Why was this particular feature incorporated into the model?” However, systems development projects often raise questions about why particular features were not incorporated into a model. Omissions from a model may turn out after the fact to be mistakes. This may be due simply to something being forgotten, or to an omission specifically required by the narrative document but for ill-conceived reasons. There is no foolproof method for assuring that nothing has been left out of the model. However, procedures carried out by the model-builders, like the “brainstorming” approach to identifying events described in Chapter 3, Modeling External Events, may reduce the probability of an error of omission.
The thought process involved in considering a candidate feature for inclusion in a model, and then rejecting it, is important enough to be documented. For example, let’s consider the override mechanism for speed maintenance described in the Cruise Control background document in Appendix A. Since pressing the accelerator pedal causes the chain to slacken, the embedded control system need not “know” about the override. The system’s manipulation of the valve position in a (vain) attempt to restore the speed has no effect on the throttle. However, there are other possible linkages between the embedded system and the throttle that would cause contention for the throttle between the system and the driver in this situation. The inclusion of some mechanism that would allow the system to recognize the override and discontinue the control action makes the embedded system user in a larger variety of potential implementation environments. Choosing not to define such a mechanism might be a perfectly reasonable requirements-definition choice. However, failing to recognize the consequences of the choice is a defect in the development process.
A tracing table very similar to the ones illustrated earlier in the chapter can be used to document features omitted from the model. Instead of listing model features, the table lists candidate features, and describes the source of the decision not to include the features.
7.6 Summary
The essential model building process proceeds by deriving features of the essential model either from background information about the system or from previous features of the model or from both. Documenting this derivation process is an important part of the overall job of systems development. The documentation takes the form of a data base showing connections among the system background and model features, which may be accessed in a variety of ways to answer questions that arise during the development process.