- 23.1 Architecture Context Diagram
- 23.2 Architecture Flow and Interconnect Diagrams
- 23.3 Example of AFD and AID Mapping
- 23.4 Model Consistency and Balancing
- 23.5 The Complete Architecture Model
- 23.6 Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
23.4 Model Consistency and Balancing
The requirements model components, along with other requirements for the system, must be accounted for in the architecture model. Components of the architecture model must be consistent with each other. The consistency rules, therefore, are designed to ensure a balanced architecture model and to ensure traceability between the requirements model and the architecture model. These consistency rules follow.
- RULE 1
- Every architecture module that appears on an AFD must also appear on the corresponding AID.
The AFD and AID represent two views of the system’s architecture: one is from the information flow aspect, and the other from a physical interconnect aspect. These two views may not show any differences between the architecture modules as they both contain the same unique, ones, but the AID shows redundant architecture modules, while the AFD does not. AFDs do not need to show them since redundant modules, and their information flows, are assumed to be identical. They are shown on the AID, however, because their physical interconnections may be different. Any nonidentical modules must appear on both diagrams. The names and numbers of the corresponding architecture modules must be the same on the AID and the AFD.
- RULE 2
- Every component of an information flow into an architecture module must be used within that module, and every component flowing out must be generated within that module.
The information that flows into an architecture module must be used by that module in its entirety and the information flow coming out must be generated inside that module. If there is data being received by a module that it does not use, then the implications of this to the maintenance of the system are well-known as the stamp coupling effect of structured design [12], whereby data of one type or category is all grouped together and transmitted whether or not it is all used. For many systems, this might be accepted for efficiency reasons, but those reasons should be clearly recorded. The information that flows into and out of an architecture module must be defined in the architecture dictionary. The information that flows into and out of the architecture module must be the same as the data and control flows into and out of the allocated data and control processes.
- RULE 3
- Every architecture interconnect channel must have at least one information flow (data or control) allocated to it.
Every architecture interconnect channel must have some flows allocated to it. If not, then that channel is presumably not needed.
- RULE 4
- Every PSPEC and CSPEC from the requirements model must have a place in the architecture model.
Every PSPEC and CSPEC must be traceable to the architecture model through the AMSs. There must be a listing of all processes (or their higher-level groupings) in the AMSs. The CSPECS can appear complete or as individual component sheets, as discussed in Part IV.
- RULE 5
- Every flow (data or control) in the requirements model must be assigned a place in the architecture model.
The architecture dictionary is an enhancement of the requirements dictionary. Every data and control flow in the requirements dictionary must be allocated in the architecture model, verifiable through the dictionary. Every requirements dictionary component has one of two options: Either it must be allocated to a module, or it must flow from one module to another. The architecture dictionary has additional fields that represent the origin module, destination module, and architecture communication channel. For those flows that are allocated to a module, the origin module field must be specified. For flows that go from one architecture module to one or more other architecture modules, all three entries must be filled in. The architecture dictionary makes it possible to verify that complete allocation has taken place, and that there is traceability between the requirements and architecture models.