126.96.36.199 SW Architecture (SwArc)
The SW Architecture (preliminary design) contains proposals for possible SW architectures and for the selected decomposition of the SW Unit: dynamically into individual processes, statically into SW Components, SW Modules, and Databases. The interrelations among processes, SW Components, SW Modules, and Databases are illustrated. Furthermore, the external and internal interfaces of the SW Unit are identified and, finally, the allocation to the requirements is made.
Such a product exists for each SW Unit.
1. General Information
2. Solution Proposals
3. Modularization/Database Design
3.1. Overview of SW Components, SW Modules, Processes and Databases
3.2. Individual Descriptions
3.2.m. SW Component/SW Module/Process/Database (m)
3.3. Dynamic Sequence Model
3.4. Criticality of the SW Components/SW Modules/Processes/Databases
3.5. Other Design Decisions
4.1. External Interfaces of the SW Unit
4.2. Internal Interfaces of the SW Unit
5. Requirements Allocation
See schema 1. General Information.
This chapter includes a description and the following evaluation of possible SW Unit architectures.
The solution proposals for the SW Unit architecture are outlined. They roughly describe the decomposition of the SW Unit into processes as well as into SW Components, SW Modules, and Databases.
For each solution proposal, individual advantages and disadvantages (e. g. with regard to the interface complexity, usability of off-the-shelf products) as well as the feasibility will be illustrated. The selection of one of the solution proposals is documented and justified.
The modularization describes the static decomposition of a SW Unit into SW Components and SW Modules as well as the real-time-specific connections. Furthermore, this chapter includes a preliminary design of the Databases (if available) of the SW Unit.
All SW Modules, processes, SW Components, and Databases are listed, together with their identifications and a long name. A graphical representation should be selected as well (tree) to illustrate the "exists of" hierarchy.
The SW Component/the SW Module/the process/the Database is defined by a performance specification (purpose and function) and by the utilized resources (CPU, memory, peripherals, processors).
If relevant this also contains the allocation of the SW Component/the SW Module to the process to be realized.
Note: "m" is used for consecutive numbers of individual descriptions from 3.2.1 to 3.2.n and as place holder for the identifier of the SW Component, the SW Module, the process, or the Database, according to the conventions for identification defined in the CM Plan.
This chapter describes the dynamic interrelations of processes. Graphical methods are best suited for the representation.
This chapter also describes the mechanisms and concepts made available by the runtime environment and during the realization of the processes.
A criticality level is allocated to each SW Component/SW Module/process/Database in the form of a table. The criticality level is derived from that of the function realizing the SW Component/the SW Module/the process/the Database.
This chapter explains other design decisions that have not yet been mentioned before.
The external interfaces of the SW Unit resulting from the Technical Requirements and the System Architecture and the internal interfaces resulting from the structure of the SW Unit are identified and allocated to the SW Components, SW Modules and Databases.
This chapter is integrated into the product Interface Overview.
External interfaces are interfaces of the SW Unit to its environment, i. e. to other SW Units or HW Units and to the user.
Internal interfaces of the SW Unit are interfaces between SW Components, SW Modules and Databases.
The relationships to the Technical Requirements will be set up. It must be documented if all requirements for the corresponding SW Unit are covered and how the requirements have been allocated to processes/SW Components/SW Modules/Databases.
In connection with the requirements allocation, the following items have to be observed:
- Each requirement is allocated to the lowest element in the refinement level making the coverage of the requirement complete.
- Each requirement must be allocated to at least one element, ideally to exactly one architecture element.
- Provided that a requirement is of importance beyond the element, it is necessary to consider within the scope of the allocation which individual architecture elements at last have to meet these requirements.
- The allocation must be realized in such a way that by the assessment of the corresponding element it can be proven that the requirement has been met.
Mail 0685 - SW-Architektur (Grobentwurf) (685)
Mail 0653 - QS-Plan: Fragen zu Festlegung der Kritikalität, Vererbung, Infizierung und zughörigen Dokumenten (653)
Mail 0524 - Mehrere Fragen zum V-Modell (524)
Mail 0251 - Midestanforderungen (251)