Chapter 7 of Volume 2, Essential Model Traceability, justified the need for traceability between the narrative specification document, the environmental model and the behavioral model. A tool for keeping the traces, namely tracing tables, was described. The same need exists to trace the implementation model back to its sources. The implementation model is derived from the essential model, so implementation model traceability is intended to answer two questions: First, is each essential model component implemented by the implementation model? Second, is each implementation model component required to implement some essential model component? Tracing tables can again be used to show the connections between the models.
The production of the implementation model is often supported by a narrative document that describes the implementation constraints on the design. Please note that the implementation model is not derived from this document in the same way that the essential model is built from the narrative specification document. Instead the implementation constraints place limits on the possible solutions that may be evaluated against the constraints as described in Chapter 11 — Sizing, Efficiency, and Optimization. This is a part of the act of building the model, rather than a static correlation between components such as that shown by tracing tables.
The implementation model is a coherent whole which is built in three stages; each stage contains essential model responses or fragments of responses. In some cases, there is a one-to-one correspondence between an implementation unit and an essential model response. In other words, a processor, task, or module implements a single, entire essential response. In these cases, the tracing table entry should be created at the level of the correspondence. Otherwise, the tracing should be done at the lowest implementation model level. To illustrate this let us examine the Cruise Control System (described in Appendix A). This system does not have structure charts built for its tasks since each task is relatively simple; the lower levels of the model for each task represent the fragments of essential model responses. (If a structure chart had been built, each fragment would correspond to a leg of the chart.)
Table 1 shows a partial tracing table for Monitor Engine, Control Learning, and Report Speed. The left-hand column is used to define the implementation unit under examination; the right-hand column contains the names (and numbers) of the essential model responses embodied by the entry to the left. Note that several entries appear in the essential response column when several responses are packaged into a single implementation unit. Similarly, since fragmentation of the responses may occur, a single essential model response may be referenced several times.
Table 1 may be inverted so as to index from the essential model responses as shown in Table 2.
System services exist in order to carry out functions required by the implementation. For example, a data transmission network exists only to transmit data between processors; choosing to have several processors in a design is its justification. Any additional models of system utilities built to support an implementation should have a statement of purpose just as with other essential models. In this case, however, the reason for the system is the needs of the implementation of the application.
System services may carry out essential model functions by providing general support for implementation technology or more directly by virtue of their use by the application code. In the latter case, the implementation model for the application will contain a reference to the use of the service utility. These connections are modeled as described in Chapter 6, Modeling System Services — System Software.