Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD09 - Supporting Information Structuring  

  LSE09 - Informationsstrukturierung 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

    SD1.1 - Recording of Actual Status and Analysis

  • User Requirements.Actual Status and Current Analysis
  • SD1.5 - User-Level System Structure

  • User Requirements.Description of the Functionality
  • SD2.4 - Allocation of User Requirements

  • System Architecture.Requirements Allocation
  • SD5.1 - Description of SW Component/Module/Database

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

    ER - E/R Modeling
    ELH - Entity Life History
    NORM - Normalization

    2 Brief Characteristics

    This service unit defines the requirements for tools used to support the methods

    3 Requirements

    3.1 Requirements for Interfaces

    SSD09.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.
    SSD09.I.2 Input interface to SSD05 - Supporting Function Structure It is possible to select functions directly collected with SSD05 from the object management as reference points for the generation of information structures.
    SSD09.I.3 Input interface to SSD07 - Supporting Modeling of Information Flows It is possible to directly select processes, data flows, and data stores-from data flow diagrams collected with SSD07-from the object management as reference points for the generation of information structures.
    SSD09.I.4 Input interface to SSD21 - Transforming Databases, Data Structures Backwards It is possible to integrate information structures-generated with SSD21 from logical schema specifications for databases and data structures-from the object management without further transformation.
    SSD09.I.5 Output interface to SSD11 - Supporting Database Specification It is possible to transmit information structures without further transformation via the object management to SSD11 in order to be converted into logical schema specifications for databases and data structures.
    SSD09.I.6 Output interface to SSD21 - Transforming Databases, Data Structures Backwards It is possible to transmit information structures via the object management without further transformation to SSD21 in order to be considered in the analysis of descriptions for databases and data structures.

    3.2 Requirements for the Methods Support

    SSD09.M.1 ER - E/R Modeling
    SSD09.M.1.1 Symbols
    SSD09.M.1.1.1 Fundamental entity types Symbols are available for the representation of fundamental entity types.
    SSD09.M.1.1.2 Attributive entity types Symbols are available for the representation of entity types used to take out iteration groups.
    SSD09.M.1.1.3 Associative entity types Symbols are available for the representation of entity types used to resolve N:M relationships.
    SSD09.M.1.1.4 Relationship types and cardinalities Symbols are available for the representation of relationship types.
    SSD09.M.1.1.5 Aggregations Symbols are available for the representation of aggregations.
    Aggregations may be represented by a relationship of type "is part of". Entity types that are combined by such a relationship type in a higher-level entity type must be understood as entity subtypes for the corresponding entity supertype.
    SSD09.M.1.1.6 Specializations Symbols are available for the representation of specializations.
    Specializations may be represented by a relationship of type "is a". Entity types subordinated to an entity type as special case by this kind of relationship type must be understood as entity subtypes for the corresponding entity supertype.
    SSD09.M.1.2 Handling relationship types
    SSD09.M.1.2.1 Rearranging relationship types It is possible to rearrange relationship types.
    SSD09.M.1.2.2 Changing the relationship direction It is possible to change the relationship direction of relationship types.
    SSD09.M.1.2.3 Relationship types always between entity types It is guaranteed that only such relationship types are generated that are linking entity types with each other.
    SSD09.M.1.2.4 Cardinalities It is guaranteed that only such relationship types are generated that were allocated discernible cardinalities in the E/R diagrams.
    SSD09.M.1.3 Description of entity types with attributes
    SSD09.M.1.3.1 Attributes It is possible to describe entity types by attributes.
    SSD09.M.1.3.2 Relationship types as attribute It is possible to utilize relationship types as attributes.
    SSD09.M.1.3.3 Inheritance It is possible to transmit attributes to entity types.
    The inheritance of attributes is relevant when generating subtypes.
    SSD09.M.1.3.4 Attribute groups It is possible to combine attributes in a group.
    SSD09.M.1.3.5 Renaming attributes It is possible to rename attributes with the exception of key attributes or parts of concatenated keys.
    SSD09.M.1.3.6 Deleting attributes It is possible to delete attributes.
    SSD09.M.1.3.7 Rejection of already allocated attribute names When adding attributes, already allocated attribute names will be rejected.
    SSD09.M.1.3.8 Primary key It is possible to distinguish attributes or attribute groups as primary keys.
    SSD09.M.1.3.9 Alternative primary key It is possible to distinguish attributes or attribute groups as alternative primary keys.
    SSD09.M.1.3.10 Data type It is possible to allocate a data type to attributes.
    SSD09.M.1.3.11 Value range It is possible to allocate value ranges to attributes.
    SSD09.M.1.3.12 Deleting an entity type It is guaranteed that prior to the deletion of an entity type the utilization of this entity type in aggregations and specializations will be displayed.
    SSD09.M.1.3.13 Automatic deletion of attributes When deleting an entity type, it is guaranteed that all corresponding attributes are deleted automatically.
    SSD09.M.1.3.14 Overall model It is possible to generate an overall model from entity and relationship types stored in various E/R models.
    SSD09.M.1.3.15 Partial data model It is possible to generate partial data models from an existing overall data model.
    SSD09.M.1.3.16 Consolidations It is possible to integrate a partial data model into an overall model whereby the integration takes place only after eliminating all inconsistencies.
    SSD09.M.2 ELH - Entity Life History
    SSD09.M.2.1 Symbols
    SSD09.M.2.1.1 State symbol A symbol is available for the representation of the state of an entity type which can be labeled with the name of the state.
    SSD09.M.2.1.2 Transition symbol A symbol is available for the representation of the transition from one state to another; it can be labeled with the name of the event changing the state.
    SSD09.M.2.2 State diagram It is possible to generate a state diagram for each entity type automatically.
    SSD09.M.2.3 State changes In a state diagram it is possible to represent all states and the events changing the states within the lifecycle of the allocated entity.
    SSD09.M.2.4 Integrity conditions It is possible to allocate to an entity all integrity conditions that are relevant for the status changing events in the lifecycle.
    SSD09.M.3 NORM - Normalization
    SSD09.M.3.1 Key attributes It is possible to mark key attributes in a relation.
    SSD09.M.3.2 Functionally depending attributes It is possible to mark functionally dependent attributes in a relation of key and parts of concatenated keys.
    SSD09.M.3.3 Transitively dependent attributes It is possible to mark transitively dependent attributes that do not belong to the key.
    SSD09.M.3.4 First normal form It is possible to transform an unnormalized relation automatically into relations in the first normal form, i. e. if the key in the unnormalized relationship as well as all attributes not functionally depending on the key have been marked.
    SSD09.M.3.5 Second normal form It is possible to transform a relation in the first normal form automatically into relations in the second normal form, i. e. if in the relation of the first normal form-apart from the key-every attribute not belonging to the key and depending on a part of the concatenated key has been marked.
    SSD09.M.3.6 Third normal form It is possible to transform a relation in the second normal form automatically into relations in the third normal form, i. e. if in the relation of the second normal form-apart from the key-all attributes not belonging on the key and transitively depending on each other are marked.
    SSD09.M.3.7 De-normalization It is possible to automatically reset all normalizations of a relation.

    3.3 Requirements for Functions

    none

    3.4 Other Requirements

    SSD09.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.
    SSD09.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.
    SSD09.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