Previous Next V-Model Official Homepage by IABG  
Header  
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
  • Product Flow

    From Product to Methods Tool Req. Ext. Norms
    Activity State Chapter Title Activity State
    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 (1)
    DVER (4)
    FS (5)
    SSD09
    SSD11
    SSD21
    - - 2 SW Design (Module).
    SW Component/SW Module Description
    SD5.2-SW being proc. ACC (1)
    COM (2)
    CRC (2)
    DVER (4)
    FS (5)
    IAM (2)
    MODIAG (2)
    PCODE
    STMO (3)
    SSD10
    SSD20
    SS211
    SSD22
    SSD24
    SSD27
    SSD28
    SSD29
    SSD30
    SSD31
    - - 2 SW Design (Database).
    Database Description
    SD5.2-SW being proc. DNAV (6)
    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

    Handling

    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 (1) Generate
    COM - Class/Object Modeling (2) Generate
    CRC - Class Responsibility Collaboration (2) Generate
    DVER - Design Verification (4) Generate
    FS - Formal Specification (5) Generate
    IAM - Interaction Modeling (2) Generate
    MODIAG - Module Diagrams (2) Generate
    Chapter 2.4
    SW Design (Module).
    Realization of the SW Component/ SW Module
    PCODE - Pseudocode Generate
    STMO - State Modeling in the OO Field (3) Generate
    Chapter 2.6
    SW Design (Module).
    Exceptional Behavior
    PCODE - Pseudocode Generate
    Chapter 2
    SW Design (Database).
    Database Description
    COM - Class/Object Modeling (2) Generate
    CRC - Class Responsibility Collaboration (2) Generate
    Chapter 2.2
    SW Design (Database).
    Schema Definition
    DNAV - Data Navigation Modeling (6) Generate
    LOGM - Logical DB Modeling Generate
    NORM - Normalization Generate
    Chapter 2
    Data Dictionary.
    Data Description
    ACC - Analysis of Covert Channels (1) Generate
    DVER - Design Verification (4) Generate
    FS - Formal Specification (5) Generate
    Chapter 3
    Data Dictionary.
    Data Realization
    ACC - Analysis of Covert Channels (1) Generate
    DVER - Design Verification (4) Generate
    FS - Formal Specification (5) 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.

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