Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD27 - Supporting State Modeling in the Object-Oriented Field  

  LSE27 - Zustandsmodellierung im objektorientierten Bereich 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.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.2 - Design of Internal and External SW Interfaces

  • Interface Description.Description of the Interfaces

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

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

    • Method

    STMO - State Modeling in the OO Field

    2 Brief Characteristics

    This service unit defines the requirements for tools used to support the method STMO - State Modeling in the OO Field.

    3 Requirements

    3.1 Requirements for Interfaces

    SSD27.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.
    SSD27.I.2 Input Interface to SSD22 - Supporting Class/Object Modeling It is possible to have access, via the object management, to information with the class/object structure defined using SSD22.
    SSD27.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.
    SSD27.I.4 Input Interface to SSD28 - Supporting Interaction Modeling It is possible to access interaction models defined with SSD28 via the object management.
    SSD27.I.5 Input Interface to SSD29 - Formal Specification It is possible to access information about specifications defined with SSD29 via the object management.
    SSD27.I.6 Input Interface to SSD30 - Formal Verification It is possible to access information about verifications realized with SSD30 via the object management.
    SSD27.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

    SSD27.M.1 STMO - State Modeling in the OO Field
    SSD27.M.1.1 Symbols
    SSD27.M.1.1.1 States A symbol is available for the representation of states.
    SSD27.M.1.1.2 Initial States A symbol is available for the representation of initial states.
    SSD27.M.1.1.3 Final States A symbol is available for the representation of final states.
    SSD27.M.1.1.4 State Transitions A symbol is available for the representation of state transitions.
    SSD27.M.1.2 Events It is possible to allocate events, that are able to cause the transitions, to state transitions.
    SSD27.M.1.3 Names It is possible to allocate identifying names to states and events.
    SSD27.M.1.4 Attributes It is possible to allocate events to attributes representing the transfer of data to a function realizing the event.
    SSD27.M.1.5 Conditions It is possible to allocate conditions to state transitions allowing the transitions into new states only when the conditions have been met and the corresponding events have occurred.
    SSD27.M.1.6 Actions
    SSD27.M.1.6.1 Actions in state transitions It is possible to allocate actions to state transitions that have to be executed immediately after the occurrence of state transitions.
    The time requirement for these actions is negligible.
    SSD27.M.1.6.2 Entry and Exit Actions It is possible to allocate actions to states that have to be executed when entering or leaving states.
    The time requirement for these actions is negligible.
    SSD27.M.1.7 Activities It is possible to allocate activities to states that have to be executed when reaching the state.
    Activities require an execution time to be taken into consideration.
    SSD27.M.1.8 Hierarchy
    SSD27.M.1.8.1 Hierarchical Decomposition It is possible to hierarchically improve the states used in state diagrams.
    SSD27.M.1.8.2 Automatic Display Incoming and outgoing state transitions are automatically displayed in diagrams on the next lower hierarchy level.
    SSD27.M.1.9 Opening State Diagrams
    SSD27.M.1.9.1 Next Lower Level It is possible to open a state diagram from a state diagram of the next lower level in the tree structure.
    SSD27.M.1.9.2 Next Higher Level It is possible to open a state diagram from a state diagram of the next higher level in the tree structure.
    SSD27.M.1.10 Interconnections between state diagrams of various classes It is possible to specify the sending of events to objects of another class.
    SSD27.M.1.11 Generation and deletion of objects It is possible to specify events causing the generation or deletion of objects.
    SSD27.M.1.12 Concurrency
    SSD27.M.1.12.1 Concurrency in States It is possible to identify concurrent occurrences of states and events in complex states.
    SSD27.M.1.12.2 Splitting State Transitions It is possible to identify that a state transition causes the entry into several concurrent state occurrences.
    SSD27.M.1.12.3 Synchronization of State Transitions It is possible to identify that only the occurrence of state transitions from several concurrent state occurrences cause the transition into a new state.
    SSD27.M.1.13 Additional Descriptions It is possible to specify states, state transitions, events, conditions, actions and activities more detailed by additional text descriptions.

    3.3 Requirements for Functions

    none

    3.4 Other Requirements

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