Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD28 - Supporting Interaction Modeling  

  LSE28 - Interaktionsmodellierung 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.2 - Description of Application System

  • User Requirements.Preliminary System Description

    • SD1.4 - Definition of Marginal Conditions

  • User Requirements.Marginal Conditions

    • SD1.5 - User-Level System Structure

  • User Requirements.Description of the Functionality

    • SD2.1 - Technical System Design

  • System Architecture.Explanation of the Cooperation of Technical Elements

    SD2.5 - Interface Description

  • Interface Description.Description of the Interfaces

    • SD3.2 - Specification of Requirements for External Interfaces of SW/HW Unit

  • Technical Requirements.Technical Requirements for the Interfaces

    • SD3.3 - Definition of Requirements for the Functionality

  • Technical Requirements.Overall Function of Element

    • SD4.1 - SW Architecture Design

  • SW Architecture.Dynamic Sequence Model

    • SD4.2 - Design of Internal and External SW Interfaces

  • Interface Description.Description of the Interfaces

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

  • SW Design (Database).Database Description

    • Method

    IAM - Interaction Modeling

    2 Brief Characteristics

    This service unit defines the requirements for tools used to support the object-oriented method IAM - Interaction Modeling.

    3 Requirements

    3.1 Requirements for Interfaces

    SSD28.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.
    SSD28.I.2 Input Interface to SSD22 - Supporting Class/Object Modeling It is possible to access information about operations and objects defined with SSD22 via the object management.
    SSD28.I.3 Input Interface to SSD26 - Supporting Use Case Modeling It is possible to access information about use cases defined with SSD26 via the object management.
    SSD28.I.4 Input Interface to SSD27 - Supporting State Modeling in the Object-Oriented Field It is possible to access information about dynamic behavior defined with SSD27 via the object management.
    SSD28.I.5 Input Interface to SSD29 - Formal Specification It is possible to access information about specifications defined with SSD29 via the object management.
    SSD28.I.6 Input Interface to SSD30 - Formal Verification It is possible to access information about verifications realized with SSD30 via the object management.
    SSD28.I.7 Input Interface to SSD31 - Analysis of Covert Channels It is possible to access information about the analysis of covert channels realized with SSD31 via the object management.

    3.2 Requirements for the Methods Support

    SSD28.M.1 IAM - Interaction Modeling
    SSD28.M.1.1 Sequence Diagrams
    SSD28.M.1.1.1 Symbols
    SSD28.M.1.1.1.1 Object Lines It is possible to represent objects with their lifecycle as vertical lines. The upper end of the object line marks the time the object was generated, the lower end identifies the time when it is deleted.
    SSD28.M.1.1.1.2 Horizontal Interaction Arrows It is possible to represent interactions as horizontal arrows. Interaction arrows symbolize events or messages and run from one object line to another.
    SSD28.M.1.1.1.3 Downward Directed Interaction Arrows It is possible to represent interactions as downward directed arrows. These interaction arrows symbolize a time requirement for an event and run from one object line to another.
    SSD28.M.1.1.1.4 Time Marker Time marker can be allocated to object lines in form of character strings.
    SSD28.M.1.1.1.5 Time Limitations Time limitations can be symbolized and specified by Boolean expressions.
    SSD28.M.1.1.2 Names
    SSD28.M.1.1.2.1 Object Names It is possible to allocate identifying names for objects and to display these on top of object lines in diagrams.
    SSD28.M.1.1.2.2 Interaction Names It is possible to allocate identifying names for interactions. These names have to refer to the events or messages representing the interactions. Messages can be identified with the names of the operations (with parameters) they are to be realized with.
    SSD28.M.1.1.3 Order of Interactions It is possible to express the order of interactions by the order of its symbols. The order must be expressed in the diagram in a top-to-bottom manner.
    SSD28.M.1.1.4 Conditions It is possible to identify interactions with time, sequence and synchronization conditions.
    SSD28.M.1.1.5 Branches, Interactions and Recursions It is possible to model alternative, iterative and recursive applications for interactions.
    SSD28.M.1.1.6 Generation and Deletion of Objects It is possible to model the generation and deletion of objects.
    SSD28.M.1.1.7 Synchronous and Asynchronous Message Flow It is possible to model synchronous and asynchronous message flows.
    SSD28.M.1.2 Collaboration Diagrams
    SSD28.M.1.2.1 Symbols
    SSD28.M.1.2.1.1 Objects A symbol is available for the representation of objects.
    SSD28.M.1.2.1.2 Object Relations A symbol is available for the representation of relations between objects (links).
    SSD28.M.1.2.1.3 Implementation Symbol A symbol is available for the representation of different realization forms for an object relation.
    A realization form characterizes the realization of the relation with regard to an object. Therefore, for each participating object different realization forms can be entered for a relation. Examples for realization forms are: association relation, one object is part of the other, global variable, local variable, and procedure parameter.
    SSD28.M.1.2.1.4 Direction Arrows
    SSD28.M.1.2.1.4.1 Synchronous Message Flow A symbol is available for the representation of a synchronous message flow.
    An object sends a message to another object and waits for the reaction (procedural control flow).
    SSD28.M.1.2.1.4.2 Asynchronous Message Flow A symbol is available for the representation of an asynchronous message flow.
    An object sends a message to another object and does not wait for the reaction.
    SSD28.M.1.2.2 Names It is possible to allocate identifying names for objects and messages. In order to uniquely allocate names it may be required, depending of the validity range, to complete object names by the corresponding class name and the corresponding subsystem name.
    SSD28.M.1.2.3 Roles It is possible to specify relations in more detail by allocating roles. By allocating roles, the participation of an object in a relation can be better expressed.
    SSD28.M.1.2.4 Generation and Deletion It is possible to identify objects and relations in such a manner that they can be generated or deleted by sending messages.
    SSD28.M.1.2.5 Messages
    SSD28.M.1.2.5.1 Sequence Number It is possible to allocate sequence numbers to messages in order to define their order.
    SSD28.M.1.2.5.2 Argument List and Return Value It is possible to specify a list of arguments and a return value for messages.
    SSD28.M.1.2.5.3 Allocation It is possible to allocate one or several messages to an object relation.
    SSD28.M.1.2.5.4 Message Flow It is possible to specify the message flow more detailed by means of direction arrows.
    SSD28.M.1.2.5.5 Concurrency
    SSD28.M.1.2.5.5.1 Identification It is possible to express the concurring processing of messages.
    SSD28.M.1.2.5.5.2 Conditions to Processing Order When identifying concurring messages it is possible to define that prior to their processing other messages have to be processed.
    SSD28.M.1.2.5.5.3 Control flows for active parallel objects It is possible to represent the control flows of several active objects in an interaction plan and to express the message flows between them.
    SSD28.M.1.2.5.6 Iterations It is possible to identify an iteration information that several messages of the same form are sent sequentially or concurrently.
    SSD28.M.1.2.5.7 Branches It is possible to model the alternative execution of interactions by entering conditions.
    SSD28.M.1.2.5.8 Recursion It is possible to model the recursive execution of interactions.

    3.3 Requirements for Functions

    none

    3.4 Other Requirements

    SSD28.O.1 Upward Compatibility It must be possible to process objects that were generated with an older release of the tool with the later release of that tool, without loss of information and functionality.
    SSD28.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.
    SSD28.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