SD 4.1-SW: SW Architecture Design



		SD 4.1-SW: SW Architecture Design

SE4.1-SW - SW-Architektur entwerfen

Contents
Product Flow
Handling
Explanation
Roles

Tools Requirements
External Norms
Links to the V-Model Mailinglist

Contents		Product Flow Handling Explanation Roles		Tools Requirements External Norms Links to the V-Model Mailinglist

Product Flow

From		Product		to		Methods	Tool Req.	Ext. Norms
Activity	State	Chapter	Title	Activity	State	Methods	Tool Req.	Ext. Norms
SD1	accepted	All	User Requirements	-	-			/ISO IEC 12207/ Devlp. Proc.: SW Arch. Design
SD2	accepted	All	System Architecture	-	-
SD3	accepted	All	Technical Requirements	-	-
SD2	being proc.	Existing	Interface Overview	SD4.2-SW SD5-SW CM4.3	submitted	COM ⁽²⁾ MODIAG ⁽²⁾ SSM ⁽²⁾	SSD22 SSD23 SSD24 SSD29 SSD30 SSD31
SD3	being proc.	Existing	Operational Information: User Manual Diagnosis Manual Operator Manual Other Application Information	SD4.3-SW	being proc.
-	-	All	Software Architecture	SD4.2-SW SD4.3-SW SD5-SW	submitted	ACC ⁽⁷⁾ COM ⁽²⁾ DVER ⁽⁶⁾ FS ⁽⁵⁾ IAM ⁽²⁾ MODIAG ⁽²⁾ ODT ⁽⁸⁾ PIM ⁽³⁾ PRODIAG ⁽²⁾ SSM ⁽²⁾ STM ⁽⁴⁾ STRD ⁽⁸⁾	SSD01 SSD03 SSD04 SSD20 SSD22 SSD23 SSD24 SSD25 SSD28 SSD29 SSD30 SSD31

+ "Chapter" are extra columns from the original printed version of GD 250

* SW Architecture Design

The Software Architecture describes the decomposition of a Software Unit into SW Components, Processes, SW Modules and Databases. Proposals for possible SW Architectures are generated and evaluated; a solution proposal must be selected for the further processing.

In general, SW Units consist of several processes or tasks that are running parallel or quasi-parallel. The aim is to structure a SW Unit under the aspects of necessary or feasible parallel processing. In this connection, the actual conditions of the operating and runtime system and also the requirements and limitations of the hardware and the programming language have to be taken into consideration. The Software Architecture contains a description of the process ensemble, including its structure, communication, synchronization and the representation of the dynamic sequence model.

A brief performance specification and the relevance with regard to security (criticality level, security-specific function, security-relevant function) must be made for each item (Process, SW Component, SW Module, Database) of the selected proposal.

The interfaces defined on the basis of the architectural decisions have to be identified in the Software Architecture and to be documented in the Interface Overview.

The complete coverage of the requirements by Processes, SW Components, SW Modules and Databases defined in the Software Architecture has to be proven.

Details for the Operational Information (User Manual, Diagnosis Manual, Operator Manual, Other Application Information) have to be generated on the basis of the Software Architecture.

* Observing the IT Security Aspects

Apart from the dependences of the IT security functions it is necessary to investigate the interactions of the IT security mechanisms that were selected for the realization of the IT security functions. The probable effects which the realization of the IT security functions might have on other SW Units, must also be investigated. The dependences of functions with regard to the criticality must also be investigated.

It is necessary to find out if, and if yes, which IT security-specific or IT security-relevant portions ⁽¹⁾ are created in other SW Components/SW Modules/Databases during the realization.

The interfaces between the IT security-relevant to the uncritical IT Security Portion must be minimized in every SW Unit. These interfaces in each SW Unit and between the individual SW Units have to be exactly defined.

Explanation

Normally, additional SW Components/SW Modules are required besides the SW Components/SW Modules that are necessary for the realization of operational user functions; these additional ones only make available technical help functions and can therefore not be derived from the operational requirements, but from the conditions of the technical approach (e. g. gateway elements). They must be taken into consideration while the SW Architecture is being defined.

These modularization decisions are influenced by:

the process structure of the SW Unit,
additionally required (system-internal) functions,
target computers (runtime system, protocols, etc.),
concepts of error handling, communication, etc.,
criteria like: information hiding, data abstraction, encapsulation, minimality of interfaces, comprehensibility, assessability, easiness of integration, reusability, etc.,
requirements for time response and reliability.

Roles

Role	Participation
SW Developer	responsible
Technical Author	cooperating

Product	Methods Allocation	Use
Chapter 2 SW Architecture. Solution Proposals	COM - Class/Object Modeling ⁽²⁾	Generate
	MODIAG - Module Diagrams ⁽²⁾	Generate
	PRODIAG - Process Diagrams ⁽²⁾	Generate
	SSM - Subsystem Modeling ⁽²⁾	Generate
Chapter 3 SW Architecture. Modularization/Database Design	COM - Class/Object Modeling ⁽²⁾	Generate
	MODIAG - Module Diagrams ⁽²⁾	Generate
	PRODIAG - Process Diagrams ⁽²⁾	Generate
	SSM - Subsystem Modeling ⁽²⁾	Generate
Chapter 3.1 SW Architecture. Overview of SW Components, SW Modules, Processes and Databases	ODT - Object Design Technique ⁽⁸⁾	Generate
	STRD - Structured Design ⁽⁸⁾	Generate
Chapter 3.2 SW Architecture. Individual Descriptions	ACC - Analysis of Covert Channels ⁽⁷⁾	Assessment
	DVER - Design Verification ⁽⁶⁾	Generate
	FS - Formal Specification ⁽⁵⁾	Generate
	PIM - Process Interaction Modeling ⁽³⁾	Generate
	STM - State Transition Modeling ⁽⁴⁾	Generate
Chapter 3.3 SW Architecture. Dynamic Sequence Model	ACC - Analysis of Covert Channels ⁽⁷⁾	Assessment
	DVER - Design Verification ⁽⁶⁾	Generate
	FS - Formal Specification ⁽⁵⁾	Generate
	IAM - Interaction Modeling ⁽²⁾	Generate
	PIM - Process Interaction Modeling ⁽³⁾	Generate
Chapter 4 SW Architecture. Interfaces	COM - Class/Object Modeling ⁽²⁾	Generate
Chapter 4 SW Architecture. Interfaces	SSM - Subsystem Modeling ⁽²⁾	Generate
Chapter 3 Interface Overview. System-Internal Interfaces	COM - Class/Object Modeling ⁽²⁾	Generate
	MODIAG - Module Diagrams ⁽²⁾	Generate
	SSM - Subsystem Modeling ⁽²⁾	Generate

Tools Requirements

Product	Functional Tools Requirements
Chapter 2 SW Architecture. Solution Proposals	SSD22 - Supporting Class/Object Modeling SSD23 - Supporting Subsystem Modeling SSD24 - Supporting Module Diagrams SSD25 - Supporting Process Diagrams SSD29 - Formal Specification SSD30 - Formal Verification SSD31 - Analysis of Covert Channels
Chapter 3 SW Architecture. Modularization/Database Design	SSD03 - Supporting Architectural Design SSD04 - Supporting Process Modeling SSD20 - Transforming Code Backwards SSD22 - Supporting Class/Object Modeling SSD23 - Supporting Subsystem Modeling SSD24 - Supporting Module Diagrams SSD25 - Supporting Process Diagrams SSD29 - Formal Specification SSD30 - Formal Verification SSD31 - Analysis of Covert Channels
Chapter 3.3 SW Architecture. Dynamic Sequence Model	SSD28 - Supporting Interaction Modeling
Chapter 4 SW Architecture. Interfaces	SSD22 - Supporting Class/Object Modeling SSD23 - Supporting Subsystem Modeling SSD29 - Formal Specification SSD30 - Formal Verification SSD31 - Analysis of Covert Channels
Chapter 5 Software Architecture. Requirements Allocation	SSD01 - Recording Requirements
Chapter 3 Interface Overview. System-Internal Interfaces	SSD22 - Supporting Class/Object Modeling SSD23 - Supporting Subsystem Modeling SSD24 - Supporting Module Diagrams SSD29 - Formal Specification SSD30 - Formal Verification SSD31 - Analysis of Covert Channels

External Norms

Norm	Process	Chapter	Obs.
/ISO IEC 12207/	Development Process	Software Architectural Design	(s. Part 3 - ISO 3.2.1)

Links to the V-Model Mailinglist

Mail 0724 - Re: Abdeckungsmatrix (724)
Mail 0524 - Mehrere Fragen zum V-Modell (524)
Mail 0251 - Midestanforderungen (251)

(1 ) "IT security specific or IT security relevant portions" also refers to the functions of high criticality that are realized by corresponding measures.

(2 ) The methods have to be applied in object-oriented developments.

(3 ) Method PIM is to be applied when the design contains several processes to be parallelly executed.

(4 ) Method STM is to be applied if complex situations have to be considered during the run of the function or the process.

(5 ) Method FS is to be applied in case of special requirements to correctness, e. g. based on very high criticality. According to [ITSEC], FS is required for the description of the formal security model with the evaluation level E4, for the preliminary design FS is required with the evaluation level E6.

(6 ) A formal specification on two different abstraction levels is required for the application of DVER. Because of the great effort, the most critical portions of a specification have to be selected for which the DVER has to be applied. According to [ITSEC], method DVER is required for the proof of the formal security model with the evaluation level E4, for the proof of consistency between security model and preliminary design DVER is required with the evaluation level E6.

(7 ) Method ACC must be applied according to [ITSEC].

(8 ) Method ODT is to be applied for a realtime-oriented development with parallel processes; otherwise method STRD has to be applied.

This page online • GDPA Online • Last Updated 07.Mar.2004 by C. Freericks