Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD22 - Supporting Class/Object Modeling  

  LSE22 - Klassen-/Objektmodellierung 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.Representation of the Technical System Architecture
  • System Architecture.Solution Proposals
  • Technical Requirements.Overall Function of Element
  • Technical Requirements.Technical Requirements for the Interfaces
  • Interface Overview.System-External Interfaces
  • Interface Overview.System-Internal Interfaces

    • 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.Solution Proposals
  • SW Architecture.Modularization/Database Design
  • SW Architecture.Interfaces
  • Interface Overview.System-Internal Interfaces

    • 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
  • SW Design (Module).SW Component/SW Module Description (in object-oriented Databases)

    • Method

    COM - Class/Object Modeling

    2 Brief Characteristics

    This service unit defines the requirements for tools used to support the object-oriented method COM - Class/Object Modeling.

    3 Requirements

    3.1 Requirements for Interfaces

    SSD22.I.1 Interface to SOM01 - Creating, Storing, Administration of Data Structures and Data of the SDE The information generated with the method is stored in a central repository.
    SSD22.I.2 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.
    SSD22.I.3 Interface to SSD23 - Supporting Subsystem Modeling It is possible to access information for the logical structure of the system defined with SSD23 via the object management.
    SSD22.I.4 Interface to SSD24 - Supporting Module Diagrams It is possible to access the module structure information defined with SSD24 via the object management.
    SSD22.I.5 Interface to SSD25 - Supporting Process Diagrams It is possible to access information about the process structure defined with SSD25 via the object management.
    SSD22.I.6 Interface to SSD26 - Supporting Use Case Modeling It is possible to access information about the use cases defined with SSD26 via the object management.
    SSD22.I.7 Interface to SSD27 - Supporting State Modeling in the Object-Oriented Field It is possible to access information about states, events and actions defined with SSD27 via the object management.
    SSD22.I.8 Interface to SSD28 - Supporting Interaction Modeling It is possible to access information about objects and interactions defined with SSD28 via the object management.

    3.2 Requirements for the Methods Support

    SSD22.M.1 COM - Class/Object Modeling
    SSD22.M.1.1 Symbols
    SSD22.M.1.1.1 Classes A symbol is available for the representation of classes. The symbol permits the separate representation of corresponding attributes and operations.
    SSD22.M.1.1.2 Objects A symbol is available for the representation of objects.
    SSD22.M.1.1.3 Utilities A symbol is available for the combination of global operations, global variables and library functions.
    SSD22.M.1.1.4 Relationships
    SSD22.M.1.1.4.1 Inheritance A symbol is available for the representation of inheritance relationships.
    SSD22.M.1.1.4.2 Association A symbol is available for the representation of association relationships.
    SSD22.M.1.1.4.3 Aggregation A symbol is available for the representation of aggregation relationships.
    SSD22.M.1.1.4.4 Object Relations A symbol is available for the representation of relationships between objects ("left").
    SSD22.M.1.1.4.5 Instantiation A symbol is available for the representation of instantiation relationships between parameterized classes and between classes and objects.
    Instantiated classes are normal classes generated from parameterized classes by entering the current parameter.
    SSD22.M.1.2 Names It is possible to allocate identifying names for classes, objects and relationships.
    In order to allocate unique names it is necessary, depending on the validity range, to complete the corresponding class name/names with the corresponding subsystem name.
    SSD22.M.1.3 Special Class Types
    SSD22.M.1.3.1 Parameterized Classes It is possible to identify classes as parameterized classes and to specify the formal parameters.
    Parameterized classes can be used for the modeling of the template concept, e. g. the template concept known from C++.
    SSD22.M.1.3.2 Meta Classes It is possible to identify classes as meta classes.
    With this concept, known from Smalltalk, classes can be defined for the description of classes. Instances of meta classes are classes themselves.
    SSD22.M.1.3.3 Abstract Classes It is possible to identify classes as abstract.
    Abstract classes can be used for the specification of abstractions from which concrete classes can be deviated by means of inheritance. Abstract classes cannot have instances.
    SSD22.M.1.3.4 Association Classes It is possible to improve relationships by the additional allocation of association classes.
    The relationship can be specified more precisely by this allocation.
    SSD22.M.1.4 Attributes
    SSD22.M.1.4.1 Description It is possible to specify attributes by entering a name, a type and an initial value. It must be possible, at least, to represent the names within class symbols.
    SSD22.M.1.4.2 Class Attributes It is possible to identify attributes as class attributes.
    Class attributes are valid across all classes and have the same value for all objects of a class.
    SSD22.M.1.4.3 Object Attributes It is possible to define concrete attribute values for objects. It must be possible to represent the object attributes within object symbols.
    SSD22.M.1.5 Operations
    SSD22.M.1.5.1 Description It is possible to specify operations by entering a name, parameters and a return value. It must be possible, at least, to represent the names within class symbols.
    SSD22.M.1.5.2 Specification of Operations It is possible to specify operations more precisely by entering
  • their task or responsibility,
  • their input and output behavior,
  • the change of objects, and
  • information about the system state before and after the execution.
    • SSD22.M.1.6 Visibility It is possible to identify the visibility of attributes and operations.
    For example, the following visibility levels can be used according to C++: "public", "protected", "private".
    SSD22.M.1.7 Improvement of relationships
    SSD22.M.1.7.1 Cardinality It is possible to specify relationships in more detail by allocating cardinalities.
    SSD22.M.1.7.2 Roles It is possible to specify relationships in more detail by allocating roles.
    By allocating roles the participation of an object in a relationship can be better expressed.
    SSD22.M.1.7.3 Qualifications It is possible to characterize the direct dependence between objects in relationships by allocating a qualification.
    SSD22.M.1.8 Derivations It is possible to identify attributes and relations as "derived".
    Derived attributes identify information that can be calculated from other attributes. Derived relationships are also represented by a combination of other relationships.
    SSD22.M.1.9 Conditions and Limitations It is possible to specify classes and relationships in more detail by conditions and limitations.
    SSD22.M.1.10 Combinations When modeling classes, it is possible to define even such attributes that represent objects and relationships between these classes.
    SSD22.M.1.11 Interfaces It is possible to specify interfaces for classes and the utilization of these interfaces.
    The use of attributes and operations of a class or a group of classes can be identified by an interface for a certain problem area. An interface can further limit the visibility of classes.
    SSD22.M.1.12 Additional Descriptions It is possible to better specify elements like classes, objects, relationships, attributes and operations by additional text descriptions.

    3.3 Requirements for Functions

    SSD22.F.1 Representation of language-oriented information It is possible to complete elements of the static class structure for the implementation by target language-oriented information.
    The implementation in the target language can be specified in more detail by pointed information. If this information is available in a form understandable for a generator, the automatic code generation can be supported.
    SSD22.F.2 Code generation It is possible to generate source code for the required target language from the static class structure defined with method COM.
    Complete specifications and frames for bodies can be generated from the static class structure.
    SSD22.F.3 Code extension It is possible for developers to extend the generated source code and that these extensions are kept in a new generation sequence. Extensions are required for programming bodies. The source code sections to be changed by the developer can be identified with comments.
    SSD22.F.4 Reverse engineering It is possible to generate the static class structure from existing source code in a form corresponding to method COM.
    SSD22.F.5 Masking out It is possible to mask out parts of class or object diagrams according to certain criteria.
    It may be practical, e. g., to mask out the attribute or operation blocks in class diagrams in order to make complex diagrams more distinct.
    SSD22.F.6 Distribution to several diagrams It is possible to distribute information defined with method COM to several diagrams of the same type.

    3.4 Other Requirements

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