Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD16 - Linking  

  LSE16 - Binden

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

    SD6.1 - Coding of SW Modules

  • SW Modules

    • SD7.1 - Integration into SW Component

  • SW Components

    • SD7.3 - Integration into SW Unit

  • SW Units

    • SD8.1 - Integration into System

  • System

    • Method

    none

    2 Brief Characteristics

    This service unit defines the requirements for tools used to link several program units into an executable load module. This also includes

    3 Requirements

    3.1 Requirements for Interfaces

    SSD16.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.
    SSD16.I.2 Input interface to SSD15 - Compiling It is possible to integrate code compiled with SSD15 from the object management without further transformation in order to be linked.
    SSD16.I.3 Output interface to SSD17 - Debugging It is possible to transmit linked code via the object management without further transformation to SSD17 in order to realize debugging.
    SSD16.I.4 Output interface to SSD18 - Estimating Performances It is possible to transmit linked code via the object management without further transformation to SSD18 in order to estimate the expected performance behavior.

    3.2 Requirements for the Methods Support

    none

    3.3 Requirements for Functions

    SSD16.F.1 Linking It is possible to link several units into an executable load module. In this connection, the external references of the units are dissolved and its validity is checked.
    In general, the following units are linked to the target code: memory management, input/output routines, mathematical operations, exception handling (if supported by the language), scheduling of quasi-parallel processes (if supported by the language). These linked units are part of the runtime system.
    SSD16.F.2 Locations
    SSD16.F.2.1 Target code It is possible to enter the file name of the target code to be linked.
    SSD16.F.2.2 Load module It is possible to enter the file name for the load module to be generated.
    SSD16.F.3 Linkage protocol
    SSD16.F.3.1 Option It is possible to get a linkage protocol generated by means of an option.
    SSD16.F.3.2 Link map This protocol contains a link map.
    The link map contains at least a list of all linked units and their corresponding memory addresses, sizes, and overlay structures (if relevant).
    SSD16.F.3.3 Details The linkage protocol contains the relevant parameters, the valid options and the data and time of linking
    SSD16.F.4 Debug information It is possible to instrument the load module with debug information.
    A load module thus instrumented can-in case it has already been compiled with the debug option-be tested with a debugger (see SSD17 "Debugging").
    SSD16.F.5 Heap size It is possible to specify the heap size by means of an option.
    Heap refers to the memory area for dynamically generated objects that is administrated during the runtime of the load module.
    SSD16.F.6 Optimizations
    SSD16.F.6.1 Size It is possible to get unused code deleted from the load module by means of an option.
    SSD16.F.6.2 Runtime Routines Runtime routines that are not required are not linked.
    For example, if no sinus functions are used there is no necessity to link them. In this way memory area is saved.
    SSD16.F.6.3 Time behavior By means of an option it is possible to initiate that the units to be linked to the load module are rearranged in a way that optimizes the time behavior of the load module.
    For example, routines belonging together are packed into hardware segments so time-consuming segment switching is avoided.
    SSD16.F.6.4 Frequency of utilization By means of an option it is possible to specify that a unit is rarely utilized at runtime. Such a unit needs not be memory-resident.

    3.4 Other Requirements

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