Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD03 - Supporting Architectural Design  

  LSE03 - Architekturentwurf 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

    SD4.1 - SW Architecture Design

  • SW Architecture.Modularization/Database Design

    • Method
    ODT - Object Design Technique
    STRD - Structured Design

    2 Brief Characteristics

    This service unit defines the requirements for tools applied for the static decomposition of a SW Unit into SW Components and SW Modules. Requirements for tools with regard to the communication of these SW Components and SW Modules are also defined in form of data and control couplings.

    3 Requirements

    3.1 Requirements for Interfaces

    SSD03.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.
    SSD03.I.2 Output interface to SSD10 - Supporting Component and Module Specification It is possible to transmit the Components and Modules specified in an architecture via the object management to SSD10 as reference points for the specification.
    SSD03.I.3 Output interface to SSD11 - Supporting Database Specification It is possible to transmit the Databases specified in an architecture via the object management to SSD11 as reference points for the specification.

    3.2 Requirements for the Methods Support

    SSD03.M.1 ODT - Object Design Technique
    SSD03.M.1.1 Symbols
    SSD03.M.1.1.1 Object Symbols are available for the representation of objects. These symbols also show if the object is active or passive. Active objects contain a separate control flow while passive objects only become active if an operation is initiated by other objects.
    SSD03.M.1.1.2 Hierarchical structuring
    SSD03.M.1.1.2.1 Consists of Symbols are available for the representation of the decomposition of an object into subobjects.
    SSD03.M.1.1.2.2 Utilizes Symbols are available that can be used to represent that an object utilizes operations of another object.
    SSD03.M.1.1.3 Data flow Symbols are available for the representation of the data flow between objects. This also includes the representation of the direction of the data flow.
    Such data flows can be uni-directional (directed in one direction only) or they can be bi-directional (directed in both directions).
    SSD03.M.1.1.4 Exception Symbols are available used to represent that a utilized object can send an exception to the utilizing object. An exception refers to a reset not being premature during the execution of an operation of the utilized object. The exception handler of the utilizing object is then automatically processed. This concept was adopted from the programming language Ada.
    SSD03.M.1.2 Masking It is possible to mask parts of the object diagram out according to certain criteria.
    It is possible only to display the upper hierarchy level or only directly concerned objects of a preset object.
    SSD03.M.1.3 Names It is possible to name objects, operations, and data flows.
    SSD03.M.2 STRD - Structured Design
    SSD03.M.2.1 Symbols
    SSD03.M.2.1.1 Component/Module Symbols are available for the representation of Components and Modules.
    SSD03.M.2.1.2 Static decomposition Symbols are available representing the utilization of the Components and Modules.
    SSD03.M.2.1.3 Communication
    SSD03.M.2.1.3.1 Data coupling Symbols are available for the representation of the data couplings.
    SSD03.M.2.1.3.2 Control coupling Symbols are available for the representation of the control couplings.
    SSD03.M.2.1.4 Connectors Symbols are available to place subtrees of a structure chart to additional pages of the documentation.
    SSD03.M.2.1.5 Time sequence symbolic Symbols are available to represent the time sequence of Component and Module calls.
    SSD03.M.2.2 Means of description
    SSD03.M.2.2.1 Names The graphic objects are named via identifiers.
    SSD03.M.2.2.2 Data coupling It is possible to describe the data couplings by means of data structures.
    SSD03.M.2.2.3 Control coupling It is possible to describe the control couplings by means of control information.

    3.3 Requirements for Functions

    SSD03.F.1 Derivation of the architecture It is possible to generate a solution proposal for the architecture based on the structure of the function model.

    3.4 Other Requirements

    SSD03.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.
    SSD03.O.2 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