|SSD22 - Supporting Class/Object Modeling|
LSE22 - Klassen-/Objektmodellierung unterstützen
MethodCOM - Class/Object Modeling.
|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.|
|SSD22.M.1||COM - Class/Object Modeling|
|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.18.104.22.168||Inheritance||A symbol is available for the representation of inheritance relationships.|
|SSD22.M.22.214.171.124||Association||A symbol is available for the representation of association relationships.|
|SSD22.M.126.96.36.199||Aggregation||A symbol is available for the representation of aggregation relationships.|
|SSD22.M.188.8.131.52||Object Relations||A symbol is available for the representation of relationships between objects ("left").|
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.
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|
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++.
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.
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.
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.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.|
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.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
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.|
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.|
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.|
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.|
|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.
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.|
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.|
|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.|
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|