Strategies for Real-Time System Specification: Creating the System Architecture Model
Read Strategies for Real-Time System Specification and more than 24,000 other books and videos on Safari Books Online. Start a free trial today.
This chapter is from the book
This chapter is from the book
This chapter is from the book
In the preceding chapter, we saw how the technology-nonspecific model is created. Now we will use the architecture model to map the enhanced requirements model allocations to architecture modules, using the components described in Part IV.
We will use the architecture context diagram to establish the system’s architectural boundary, architecture flow diagrams to identify the modules and the information that flows between them, and architecture interconnect diagrams to define the channels on which the information flows.
23.1 Architecture Context Diagram
The architecture context diagram establishes the architectural boundary between the system and the environment. Figure 23.1 shows the ACD for the Automobile Management System.
)
Figure 23.1. ACD for the Automobile Management System.
Should the architecture context diagram be any different from the data and control context diagrams in the system requirements model? In most cases, the answer is No, the boundary should remain the same. Sometimes, however, technology decisions and enhancements to the requirements model might add some additional functions, which might in turn result in different, additional, or reduced flow across the system boundary.
In determining the architectural boundary between the system and its environment, the areas most likely to be affected are the user interface and the maintenance and self-test blocks. Technology decisions on the user interface can cause some system functions to be enhanced to make it more user-friendly.
This is such an important aspect of system design, and one that in the past has often been overlooked, that it may well be worth including, in the original requirements analysis, functions performed by users of the system as well as the functions to be automated. This results in a wider context for the model, which has several benefits.
One such benefit is better specification of the interfaces between the user functions and those to be automated. Another is that this wider scope helps in selecting the most appropriate system-to-user boundary, which is then reflected in the architecture context diagram.