Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD11 - Supporting Database Specification  

  LSE11 - Spezifikation der Datenbanken unterstützen

Contents  
  • 1 Allocation to V-Model and Methods Allocation
  • 2 Brief Characteristics
  • 3 Requirements
  •       3.1 Requirements for Interfaces
  •       3.2 Requirements for the Methods Support
  •       3.3 Requirements for Functions
  •       3.4 Other Requirements
  • 1 Allocation to V-Model and Methods Allocation

    V-Model

    SD5.1 - Description of SW Component/Module/Database

  • Data-Dictionary
  • SW Design (Database).Database Description
  • Method

    DNAV - Data Navigation Modeling
    LOGM - Logical DB Modeling

    2 Brief Characteristics

    This service unit defines the requirements for tools used

    3 Requirements

    3.1 Requirements for Interfaces

    SSD11.I.1 Granularity The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface.
    SSD11.I.2 Input interface to SSD03 - Supporting Architectural Design It is possible to select directly databases specified in an architecture with SSD03 from the object management as reference points for the specification.
    SSD11.I.3 Input interface to SSD09 - Supporting Information Structuring It is possible to integrate information structures generated with SSD09 without further transformation from the object management in order to be converted into logical schema specifications for databases.
    SSD11.I.4 Input interface to SSD21 - Transforming Databases, Data Structures Backwards It is possible to integrate logical schema specifications for databases and data structures-generated from physical schema specifications with SSD21-from the object management without further transformation.
    SSD11.I.5 Output interface to SSD10 - Supporting Component and Module Specification It is possible to transmit logical schema specifications for databases and data structures without further transformation via the object management to SSD10 in order to be integrated into the specification of Components and Modules.
    SSD11.I.6 Output interface to SSD13 - Generating Databases It is possible to transmit logical schema specifications for databases and data structures via the object management without further transformation to SSD13 in order to generate physical schema specifications.
    SSD11.I.7 Output interface to SSD19 - Simulating Timing Behavior It is possible to transmit logical schema specifications for databases and data structures via the object management without further transformation to SSD19 in order to simulate the expected time behavior.
    SSD11.I.8 Output interface to SSD21 - Transforming Databases, Data Structures Backwards It is possible to transmit logical schema specifications for databases and data structures via the object management without further transformation to SSD21 in order to be converted into information structures.
    SSD11.I.9 Output interface to SQA14 - Generation of Test Cases It is possible to transmit logical schema specifications for databases and data structures via the object management without further transformation to SQA14 in order to generate test cases.

    3.2 Requirements for the Methods Support

    SSD11.M.1 DNAV - Data Navigation Modeling/LOGM - Logical DB Modeling Support
    SSD11.M.1.1 Logical schema specifications With the help of the sequence, frequency, priority, and the mode of the data accesses to conceptual data models it is possible to generate automatically logical schema specifications for a (relational, hierarchical or network-oriented) partial database system.
    SSD11.M.1.2 Secondary indices With the help of the sequence, frequency, priority, and the mode of the data accesses to conceptual data models it is possible to generate automatically proposals for the specification of secondary indices for a (relational, hierarchical or network-oriented) partial database system.
    SSD11.M.1.3 Completeness of the logical schema specifications It is guaranteed that all entity types, relationship types, and attributes of the conceptual schema specification are transformed into the logical schema specifications.
    SSD11.M.1.4 Accepting integrity conditions When generating logical schema specifications, it is guaranteed that the integrity conditions contained in the conceptual schema specifications are integrated into the logical schema specifications.
    SSD11.M.1.5 Several logical schema specifications It is possible to generate logical schema specifications for views (conceptual partial data models) of a conceptual data model.

    3.3 Requirements for Functions

    SSD11.F.1 Resource and time requirements It is possible to collect all parameters for sequence, frequency, and mode of data accesses with regard to various processing units. In the same way, it is possible to collect all further information for the quantity structure and for the physical data distribution as well as all information about the (requested) time behavior.

    3.4 Other Requirements

    SSD11.O.1 Upward compatibility It must be possible to process objects generated with an older release of the tool with the later release of that tool, without loss of information and functionality.
    SSD11.O.2 Procedural command language The tool has a procedural command language that can be applied by the user to generate and run macros or procedures.
    SSD11.O.3 Complexity There is no limitation of the complexity caused by the tool itself.

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