5 Part 5: V-Modell Reference Work Products

5.3 Products

5.3.10 System Design

5.3.10.5 Software Architecture

Responsible: Software Architect (when using process module Software Development)

Activity: Preparing Software Architecture

Participating: Software Developer, System Architect, System Integrator

Purpose

For every software unit identified in the system architecture, a »Software Architecture will be developed. Based on the functional and non-functional requirements posed on a »Software Unit, the »Software Architect is tasked with designing a suitable »Software Architecture. The Product Software Architecture will be used as design guide and for documenting the design decisions.

As in the system architecture development, significant architectural principles will be specified, and possible design alternatives will be examined. In accordance with the selected design alternative, the software unit will be decomposed into »Software Component, »Software Modules and products of the type External Software Module. Relations and interfaces between the elements and to the environment will be identified and summarized. A »Data Catalog of the data structures exchanged at the interfaces will be prepared.

The suitability of the selected architecture for the system to be developed will be assessed. Open questions may be answered, e.g., within the scope of a prototype development.

The software architecture design may lead to changes in the system architecture. Depending on the specifications in the Project Manual, the »System Architect will examine the change and integrate it immediately, if required. In individual cases, an explicit change request may be necessary.

The main responsibility for the design of the software architecture will be vested in the Software Architect who will be supported by the »Software Developer and various specialists for individual subjects, e.g., logistics, safety and security, and ergonomics.

The software architecture is the central document for the preparation of additional products. It specifies all software components and software modules of the software unit. The individual elements and their specifications will be developed in accordance with these architectural requirements.

Is generated by

System Implementation, Integration and Evaluation Concept, System Architecture (see product dependency 4.15)

System Implementation, Integration and Evaluation Concept, Enabling System Architecture (see product dependency 4.16)

Generates

Evaluation Report Usability, Evaluation Specification Usability, Software Component, Software Specification, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.17)

Evaluation Report Usability, Evaluation Specification Usability, Market Survey for Off-the-Shelf Products, External Software Module, External Software Module Specification, Make-or-Buy Decision, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.18)

Evaluation Report Usability, Evaluation Specification Usability, Software Module, Software Specification, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.19)

Example Work Products

»FWD:Software Architecture ECU-SW

5.3.10.5.1 Architectural Principles and Design Alternatives

The description of the Subject Architectural Principles and Design Alternatives is similar to the Subject Architectural Principles and Design Alternatives of the system architecture.

The architectural principles at software level include, e.g., the decision for a programming paradigm (object-oriented, procedureal), the decision fo a technology (CORBA, EJB) or specifications for a special system type (distributed internet application, desktop application). Design alternatives for software development are supported, e.g., by design patterns, sample designs and design heuristics.

5.3.10.5.2 Software Unit Decomposition

The decomposition specifies the static structure of the »Software Unit. The static structure describes the dissection of the software unit into »Software Components and »Software Modules. The design result will be documented as graph depicting the software elements to be realized and their interrelations. It may also be presented by component and/or class diagrams.

The decomposition is based on the requirements posed in the »Software Specification for the software unit or a higher system element. The framework conditions will be specified by the architectural principles defined in the »Software Architecture and the design decisions.

5.3.10.5.3 Interface Overview

The summary of interfaces of the »Software Architecture provides a survey of the interfaces of the »Software Unit and the interfaces of the corresponding elements. For the summary of interfaces, only the communication at one level will be described :

At the level of the software unit, the interfaces to other units and to the environment will be described.
At the level ot the»Software Components, the interfaces between the component within the unit will be described.
At the level of the»Software Modules, the interfaces between the process modules within the component will be described.

Interfaces to the environment may exist between a software element and the user, logistic systems or various »Enabling Systems. The interfaces are described in detail in the specification of the respective software element.

5.3.10.5.4 Data Catalog

The »Data Catalog of the »Software Architecture decribes the data structures exchanged at the interfaces of the »Software Unit, including attributes, data types and range of values. Every programming language and platform has its own solutions which must be taken into account during the definition phase.

5.3.10.5.5 Design Evaluation

If an architectural design for the »Software Unit has been selected and developed down to unit level, it must be ensured that the selected design implements the requirements in a suitable manner. Various methods are available for securing the design of the »Software Architecture. Two frequently used methods are the architecture evaluation by scenario-based methods and the prototype development of system parts. Execution and results of the design securing process will be documented. They may lead to a re-evaluation of the design decisions and a review of the architecture.

5.3.10.5.6 Software Elements to be Specified

The preparation of a specification for a software element is expensive and not always required. In order to adapt the specification effort to the requirements of individual projects, the »Software Architect can - based on the specifications in the Project Manual and the requirements - determine which software elements need a »Software Specification.

Critiera for the necessity of a specification may include the following: criticality of the software element, complexity of the requirements posed on the software element, test requirements specified in the software implementation, integration and evaluation concept. In any case, a software specification shall be prepared for software elements to be tested, since this specification will be the basis for the »Evaluation Specification System Element. If software elements are classified as not to be specified, a rationale shall be included.