SD 5.1-SW: Description of SW Component/Module/Database



		SD 5.1-SW: Description of SW Component/Module/Database

SD5.1-SW - SW-Komponente/-Modul/Datenbank beschreiben

Contents
Product Flow
Handling
Roles
Methods

Tools Requirements
External Norms
Links to the V-Model Mailinglist

Contents		Product Flow Handling Roles Methods		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 Detail. Design
SD3	accepted	All	Technical Requirements	-	-
SD4-SW	accepted	All	Software Architecture	-	-
SD4-SW	accepted	All	Interface Overview	-	-
SD4-SW	accepted	All	Interface Description	-	-
CM4.1	being proc.	Existing	Data-Dictionary	CM4.1 SD5.2-SW SD6-SW	being proc., submitted	ACC ⁽¹⁾ DVER ⁽⁴⁾ FS ⁽⁵⁾	SSD09 SSD11 SSD21
-	-	2	SW Design (Module). SW Component/SW Module Description	SD5.2-SW	being proc.	ACC ⁽¹⁾ COM ⁽²⁾ CRC ⁽²⁾ DVER ⁽⁴⁾ FS ⁽⁵⁾ IAM ⁽²⁾ MODIAG ⁽²⁾ PCODE STMO ⁽³⁾	SSD10 SSD20 SS211 SSD22 SSD24 SSD27 SSD28 SSD29 SSD30 SSD31
-	-	2	SW Design (Database). Database Description	SD5.2-SW	being proc.	DNAV ⁽⁶⁾ LOGM NORM	SSD09 SSD11 SS211 SSD22 SSD29 SSD30 SSD31
SD4-SW	being proc.	Existing	Operational Information: User Manual Diagnosis Manual Operator Manual Other Application Information	SD8	being proc.

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

The software-related realization of the SW Components, SW Modules and Databases are the subject of this activity. It is necessary to describe the construction of each SW Module and of each SW Component down to the programming specification level. Each Database has to be specified down to the level of the elementary parts (data and attributes).

The Operational Information has to be updated with design-related details. The SW Architecture and the SW Design (Module,Database) give information about the further processing of the Operational Information (User Manual, Diagnosis Manual, Operator Manual, Other Application Information).

* a) Description of SW Component/SW Module:

The SW Components and the SW Modules must be specified and described down to the programming specification level, with regard to their environment, the realization of its functionality, the data keeping, exception and error handling, etc.

* b) Description of Database:

With regard to the DB design in the SW Architecture and depending on the number of accesses, the Databases must be specified with regard to their schema and right down to the level of data elements. While doing so, each data storage has to be described in detail with respect to its type-specific instantiation. Thus, file systems are described by record structures and the data elements they contain. For hierarchical databases the DB segments, the data elements contained in those segments, and the DB segment hierarchies will be defined. For relational databases tables or views and the data elements they contain will be set up (e. g. the external keys). The integrity conditions have to be defined too.

* Generation of the Data Dictionary:

Data used in the SW Unit must be entered into the Data-Dictionary. The input information for the Data Dictionary is provided by the DB-related information in the Software Architecture and in the SW Design (Module/Database). The Data Dictionary must also include information dependent on the implementation, like identifier, data type, data format, life time, access type, access and generation times and frequencies, allocation to databases, memory type, memory space requirement, etc.

Since the Data Dictionary is a product for the entire project, by QA only the quality of the updates will be assessed. The Data Dictionary must only reach the state "accepted" if the central data administration has signaled that they agree (CM4.1 - Data Administration).

* Update Operational Information:

The description of the SW Modules, SW Components and Databases provides the design-related information for the completion of the Operational Information. Based on these descriptions the exact information about application and operation as well as about the handling of errors when working with the user functions (Information for the User Manual), the diagnostic possibilities and measures (Information for the Diagnosis Manual ) and the initialization, completion and control of the operation (Information for the Operator Manual) as well as installation and data transition (Other Application Information) have to be generated.

Roles

Role	Participation
SW Developer	responsible
Technical Author	cooperating

Methods

Product	Methods Allocation	Use
Chapter 2 SW Design (Module). SW Component/SW Module Description	ACC - Analysis of Covert Channels ⁽¹⁾	Generate
	COM - Class/Object Modeling ⁽²⁾	Generate
	CRC - Class Responsibility Collaboration ⁽²⁾	Generate
	DVER - Design Verification ⁽⁴⁾	Generate
	FS - Formal Specification ⁽⁵⁾	Generate
	IAM - Interaction Modeling ⁽²⁾	Generate
	MODIAG - Module Diagrams ⁽²⁾	Generate
Chapter 2.4 SW Design (Module). Realization of the SW Component/ SW Module	PCODE - Pseudocode	Generate
	STMO - State Modeling in the OO Field ⁽³⁾	Generate
Chapter 2.6 SW Design (Module). Exceptional Behavior	PCODE - Pseudocode	Generate
Chapter 2 SW Design (Database). Database Description	COM - Class/Object Modeling ⁽²⁾	Generate
Chapter 2 SW Design (Database). Database Description	CRC - Class Responsibility Collaboration ⁽²⁾	Generate
Chapter 2.2 SW Design (Database). Schema Definition	DNAV - Data Navigation Modeling ⁽⁶⁾	Generate
	LOGM - Logical DB Modeling	Generate
	NORM - Normalization	Generate
Chapter 2 Data Dictionary. Data Description	ACC - Analysis of Covert Channels ⁽¹⁾	Generate
	DVER - Design Verification ⁽⁴⁾	Generate
	FS - Formal Specification ⁽⁵⁾	Generate
Chapter 3 Data Dictionary. Data Realization	ACC - Analysis of Covert Channels ⁽¹⁾	Generate
	DVER - Design Verification ⁽⁴⁾	Generate
	FS - Formal Specification ⁽⁵⁾	Generate

Tools Requirements

Product	Functional Tools Requirements
Data-Dictionary	SSD09 - Supporting Information Structuring SSD11 - Supporting Database Specification SSD21 - Transforming Databases, Data Structures Backwards
Chapter 2 SW Design (Database). Database Description	SSD09 - Supporting Information Structuring SSD11 - Supporting Database Specification SSD21 - Transforming Databases, Data Structures Backwards SSD22 - Supporting Class/Object Modeling SSD29 - Formal Specification SSD30 - Formal Verification SSD31 - Analysis of Covert Channels
Chapter 2 SW Design (Module). SW Component/SW Module Description	SSD10 - Supporting Component and Module Specification SSD20 - Transforming Code Backwards SSD21 - Transforming Databases, Data Structures Backwards SSD22 - Supporting Class/Object Modeling SSD24 - Supporting Module Diagrams SSD27 - Supporting State Modeling in the Object-Oriented Field (Chapter 2.4) SSD28 - Supporting Interaction Modeling SSD29 - Formal Specification SSD30 - Formal Verification SSD31 - Analysis of Covert Channels

External Norms

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

Links to the V-Model Mailinglist

Mail 0578 - Re: Kenngr��en (578)
Mail 0304 - Re: Anwenderforderung zur Datenhaltung auf Ebene der SE 1.2
Mail 0261 - SE 5.1 in zwei Teile trennen (261)

Notes:

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

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

(3) Method STMO is to be applied for the dynamic system modeling in object-oriented procedures.

(4) 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.

(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) Method DNAV is to be applied for hierarchical or network-like database types.

GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster