Практика выполнения: Архитектурное проектирование

This practice focuses on the incremental (by use case) allocation of the functional requirements (system operations) and non-functional requirements to an architectural structure including ports and interfaces at the lowest level of decomposition.

The main value proposition is to enable the understanding of the components in the system architecture, including new and legacy components that are impacted by the stakeholder requirements.

Based on the design concept, optionally elaborated in a previous trade study, it starts with the decomposition of the chosen system block into parts. Generally, there are two ways to proceed with regard to the allocation of the system block operations to the parts. If an allocation concept exists, they may be copied directly into the relevant parts. Otherwise, the allocation can be elaborated graphically for each use case by means of the associated Use Case White-Box Activity Diagram. Essentially, this activity diagram is a copy of the use case black-box activity diagram, partitioned into swim lanes, each representing a block of the decomposition hierarchy. Based on the chosen design concept, the operations ( = actions) then are "moved" into respective block swim lanes. An essential requirement for this allocation is that the initial links (functional flow) between the actions are maintained. Use case white-box activity diagrams may be nested, thus reflecting the iterative architectural decompositions of the system under design.

If an operation cannot be allocated to a single block, it must be decomposed. In this case, the associated decomposed SuD operations need to be linked to the parent operation through a respective dependency. A system-level operation may also be allocated to more than one block, e.g. architectural redundancy in order to meet fault tolerance requirements. In this case, the relevant action is copied into the respective block swim lane and integrated into the functional flow.

White-box activity diagrams allow a first estimate of the resulting load on respective communication channels, as links that cross a swim lane correspond to interfaces.

Once all system block operations, that capture system functional requirements are allocated to system parts, non-functional requirements (e.g. design constraints) are allocated to the relevant parts and respective trace links are established.

Next, the focus shifts on the definition of ports and interfaces, as well as on the definition of the state-based behavior of the system blocks at the lowest level of the architectural decomposition. Leaf block ports and interfaces are identified from White-Box Sequence Diagrams. White-box sequence diagrams are derived from the use case white-box activity diagrams that were created in the previous architectural design phase. The focus of black-box sequence diagrams was on the identification of the required sequences of system functions (operations). White-box activity diagrams focus on the collaboration between the different subsystems taking into consideration the allocation of the operations. The received service requests define the (provided) interfaces of a block.

The derivation of white-box sequence diagrams is performed iteratively for each use case white-box activity diagram. Once ports and interfaces are defined, the resulting state-based behavior of each leaf block needs to be captured in a statechart diagram.

The correctness and completeness of the system architecture model is verified through model execution. Once the model functionality is verified, the architectural design may be analyzed with regard to performance and safety requirements. The analysis may include Failure Modes Effects Analysis (FMEA), and Mission Criticality Analysis.