Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD20 - Transforming Code Backwards  

  LSE20 - Code rückwärts transformieren

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
  • SD5.1 - Description of SW Component/Module/Database

  • SW Design (Module).SW Component/SW Module Description
  • Method

    none

    2 Brief Characteristics

    This service unit defines the requirements for tools used to realize post documentation and code analysis for an implementation. This comprises:

    3 Requirements

    3.1 Requirements for Interfaces

    SSD20.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.
    SSD20.I.2 Input interface to SSD12 - Generating Components and Modules It is possible to integrate source code generated with SSD12 for Components and Modules without further transformation from the object management.
    SSD20.I.3 Input interface to SSD14 - Generating User Interface Formats It is possible to integrate physical schema specifications for interfaces generated with SSD14 without further transformation from the object management.
    SSD20.I.4 Output interface to SSD02 - Supporting Specification of User Interfaces It is possible to transmit interface specifications generated from the physical schema specifications to SSD02 without further transformation via the object management.
    SSD20.I.5 Output interface to SSD10 - Supporting Component and Module Specification It is possible to transmit specifications generated from the source code for Components and Modules to SSD10 without further transformation via the object management.

    3.2 Requirements for the Methods Support

    none

    3.3 Requirements for Functions

    SSD20.F.1 Code processing It is possible to transform code backwards without having to perform preparatory working on the code.
    SSD20.F.2 Back transformation sequence It is possible to transfer the information content of the code to be transformed completely into the new structure.
    SSD20.F.3 Default setting It is possible to adopt default values for controlling the back transformation without manual intervention.
    SSD20.F.4 Back transformation options
    SSD20.F.4.1 Selection A selection is at least possible between the options "Analysis" and "Unconditioned Back Transformation".
    SSD20.F.4.2 Display It is possible to display back transformation options.
    SSD20.F.5 Result It is possible to utilize the back transformation result without manual additions.
    SSD20.F.6 Objects It is possible that each object of a back transformation is created as object.
    SSD20.F.7 Stubs It is possible that calls for programs that are not transformed backwards are generated as dummy object (stub).
    SSD20.F.8 Data declaration It is possible to transform data declarations of a program backwards.
    SSD20.F.9 Analysis/statistics
    SSD20.F.9.1 Call analysis It is possible to analyze the code with regard to calls and to document the result.
    SSD20.F.9.2 Transfer-of-control analysis It is possible to analyze the code with regard to transfer-of-control statements and to document the result.
    SSD20.F.9.3 Verb analysis It is possible to analyze the code with regard to used verbs and to document the result.
    SSD20.F.9.4 Statement coverage It is possible to analyze and to document code that is not processed.
    SSD20.F.10 Graphic Output
    SSD20.F.10.1 Call hierarchy diagram It is possible to represent the code transformed backwards means of a call hierarchy diagram.
    SSD20.F.10.2 Module link diagram It is possible to represent the code transformed backwards by means of a module link diagram.
    SSD20.F.11 Reference list It is possible to represent the code transformed backwards by means of a reference list to illustrate the utilization of objects and verbs.

    3.4 Other Requirements

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