|4.22 Elementary Method "Class/Object Modeling" (COM)|
The method is used for the object-oriented system development. This requires the modeling of classes, of corresponding attributes and operations as well as the relationships between the classes. The task of class modeling is to define the static class structure into class models. With regard to the execution of a system a class is static and defines the structure and the behavior of similar objects.
Objects have to be modeled as instances of classes. Objects are volatile with regard to the execution of a system. They are generated while executing a program, they communicate with each other and are then deleted. In the object-oriented development it is advisable to model objects and their relationships for actual situations. It is the task of object modeling to define such "snapshots" from object structures into object models. It can be used in development activities to describe certain system behavior, to convert a functional specification or other mechanisms, to specify assessment cases and for the discussion of examples.
In object-oriented development, the class/object modeling can be applied both during the analysis and during the design. During the analysis the class structure or the object structures have to be modeled from a users point of view in order to express what a system does. In the design, these structures have to be improved; it also has to be specified what the system does. When modeling classes, it is necessary to use attributes to model identifying, describing or even referencing information in a class. With the operations, the functions or transformations that can be used for objects of a class have to be specified. The specification can be further improved by listing their tasks or responsibilities, their in/output behavior, the change of objects and by information about the system state before and after their execution. Inheritance relationships (simple and multiple), aggregations and associations must be specified by a name and by specifiying the cardinalities. By additional modeling possibilities like the predefinition of visibilities, the allocation of role names, the allocation of contraints, the description of derived attributes and the use of highlevel relationships the development results can be improved.
The concepts of class modeling can also be used to define the static aspects of interfaces of classes and subsystems (compare elementary method SSM - Subsystem Modeling) and their application. The class portions (attributes operations) or subsystems (classes, relationships) that are to be defined as interfaces can be identified again, in their own interface models. In notation and means of representation, these interface models are also class models and can identify the interfaces. In object modeling, the consistency and the corresponding class structure defined in the class modeling must be guaranteed. It must be possible to allocate each specified object to a class, and all relationships between objects must be represented in corresponding class relationships. A number of objects structures can be defined for one class structure.
Means of Representation
In /Booch, 1997/, diagrams and text descriptions in specifications and data-dictionaries are used as means of representation of the class/object modeling.
By the cooperation of Booch and Rumbaugh , the notations and means of representation known from the complex methods OOAD /Booch, 1994/ and OMT /Rumbaugh, 1991/; /Rumbaugh, 1995b/ were combined and further developed into class/object modeling. Very compact means of representation are available in which the above mentioned information can be visualized both in analysis and design. For class modeling, class diagrams are used; within the scope of object modeling object diagrams are used. Mixed forms that are generally referred to as class diagrams are possible.
Apart from the above mentioned information, it is also possible to model improved concepts like compositions, parameterized classes, utility classes with global variables and functions and packages. Operations can be specified with more detail by using the above mentioned information in operation specifications. A better description of the applied notation and means of representation can be found in /Booch, 1997/.
Class modeling is one of the generally accepted main tasks of the object-oriented development. Therefore it is also used in other well-known complex and object-oriented development methods /Coleman, 1994/; /Jacobson, 1992/; /Shlaer, Mellor, 1992/, but with different notations, means of representation and with different details of the specifyable information. Contrary to /Booch, 1997/ they use, e. g. different means of representation in analysis and design, the information are distributed to several diagram types or the modeling of classes and operations is separated in the analysis. If object modeling is applied in other methods, it is also done with different notations and partially different objectives.
The class and object modeling is applied iteratively, whereby more detailed, improved or new or changed classes and objects are generated at every run. The individual iterations are embedded in the methods of the corresponding complex, object-oriented development methods used. Basically, it can be differentiated between the following steps:
In more complex systems with a greater number of classes and objects a decomposition into subsystems is recommended (method SSM - Subsystem Modeling), as well as applying the class modeling for these subsystems.
|4.1||SD1.1 - Recording of Actual Status and Analysis||
With the help of this method, the actual state of the static structure of the old system can be collected in class models and in object models relevant for the understanding of old systems. The specification must be delimited since only the essential structure has to be represented that is relevant from a professional, user-oriented point of view.
The method covers subproduct User Requirements.Actual Status and Current Analysis from the point of view of the static system structure.
|4.2||SD1.2 - Description of Application System||
With the help of the method the overall horizon of the system can be modeled in basic class and object structures. From aspects of the static system structure it must be defined what the new system has to do.
The method covers subproduct User Requirements.Preliminary System Description from the point of view of the static system structure.
|4.3||SD1.4 - Definition of Marginal Conditions||
With the help of this method, the requirements to the static class and object structure can be specified by technical, organizational and other marginal conditions. General requirements to interfaces can be modeled in basic static interface models.
The method covers subproduct User Requirements.Marginal Conditions from the point of view of the static system structure.
|4.4||SD1.5 - User-Level System Structure||
With the help of this method, the static system structure can be modeled professionally by means of class and object structures, down to segment level. External system interfaces can be designed as static interface models.
The method covers subproduct User Requirements.Description of the Functionality from the point of view of the static system structure.
|4.5||SD2.1 - Technical System Design||
With the help of the method, the system can be structured into segments and/or SW/HW units, in combined use with method SSM - Subsystem Modeling. The static class and object structures can be improved for a selected solution suggestion. In this connection, the technical requirements have to be taken into consideration. For the interfaces between the defined architecture elements and for the system-external interfaces it is possible to specify or improve static interface models.
In product System Architecture and related to the system, the two methods cover the subproducts System Architecture.Solution Proposals and System Architecture.Technical System Structure. Also, subproducts Technical Requirements.Overall Function of Element and Technical Requirements.Technical Requirements for the Interfaces with regard to the system, i. e. from a point of view of the static structure; subproduct Interface Overview.System-External Interfaces and related to the defined architecture elements the subproduct Interface Overview.System-Internal Interfaces from the point of view of the static structure.
|4.6||SD2.5 - Interface Description||
By using this method the interfaces of the system and the defined architecture elements can be modeled or improved as static interface models, in combination with method SSM - Subsystem Modeling.
The two methods cover subproduct Interface Description.Description of the interfaces from the point of view of the static system structure.
|4.7||SD3.2 - Specification of Requirements for External Interfaces of SW/HW Unit||
By using this method the requirements with regard to external interfaces of SW units can be specified as static interface models. They may be modeled or improved.
This method covers subproduct Technical Requirements.Technical Requirements for the Interfaces from the point of view of the static system structure.
|4.8||SD3.3 - Definition of Requirements for the Functionality||
In order to specify requirements for the technical functionality the class and object structures can be improved and adjusted with regard to the SW unit with the help of this method.
With regard to the SW unit, the method covers subproduct Technical Requirements.Overall Function of Element from the point of view of the static system structure.
|4.9||SD4.1 - SW Architecture Design||
With the help of this method and in combination with method SSM - Subsystem Modeling, the logical structure of the SW unit into static architecture elements can be realized and adjusted with a physical structure via method MODIAG - Module Diagrams. Statical interface models can be specified for the interfaces between defined architecture elements.
The two methods cover subproducts SW Architecture.Solution Proposals, SW Architecture.Modularization/Database Design and SW Architecture.Interfaces, and subproduct Interface Overview.System-Internal Interfaces with regard to the defined architecture elements.
|4.10||SD4.2 - Design of Internal and External SW Interfaces||With the help of this method the SW interfaces can be modeled as static interface models and be improved in that activity. The method covers subproduct Interface Description.Description of the Interfaces from the point of view of the static system structure.|
|4.11||SD5.1 - Description of SW Component/Module/Database||
With the help of this method, the static structure of SW Components/SW Modules or object-oriented databases can be modeled in detailed class and object structures. The structures set up the the preceding activities have to be improved or updated.
The method covers subproduct SW Design (Module).SW Component/SW Module Description or in object-oriented databases subproduct SW Design (Database).Database Description from the point of view of the static system structure.
|No.||Interface||Observation||Information in Annex 1|
|5.1||COM-CRC||Method CRC can be used in method COM to find and improve the class structure.|
|5.2||COM-SSM||In the combined use of methods COM and SSM the system is to be structured into segments, SW/HW units, SW Components and SW Modules, according to the V-Model. The external interfaces of the architecture elements have to be specified.|
|5.3||COM-MODIAG||The classes and objects identified by method COM are allocated to physical program parts by method MODIAG. For active objects having a separate control flow, individual main programs may be specified.|
|5.4||COM-PRODIAG||The active objects defined in method COM having a separate control flow can be realized as independent processes in method PRODIAG.|
|5.5||COM-UCM||The functional requirements defined with method UCM must be converted in method COM when defining class and object structures. With their functional requirements, the defined use cases are the basis for the detection of classes and objects, for the allocation of functionality to classes and for the interface design.|
In addition to the static structure of classes defined in method COM, the significant dynamic behavior of classes of active objects are modeled in method STMO. Modeling states must be harmonized with the modeling of class attributes, the modeling of events and actions must be harmonized with the modeling of class operations.
While the static structure of interfaces can be specified with method COM, method STMO - State Modeling in the OO Field can be used to represent permitted call sequences of interface functions.
IAM - Interaction Modeling must be harmonized with the modeling of class operations in method COM. If more complex operations are defined in method COM, their dynamic sequences can be modeled in method IAM. Modeling objects in method COM has to be harmonized with modeling objects in method IAM.
While the static structure of interfaces can be specified with method COM, method IAM - Interaction Modeling can be used to represent sequence-oriented requirements to communication protocols.
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|