OMT Object Model

3. System Development Context

The object model already is a very basic part of a particular system development methodology: OMT, developed bij James Rumbaugh.
This methodology consists of three phases: analysis, system design and object design. The object model is primarily used in the analysis phase. It is a very important model for the understanding of, and the discussion about the problem domain. Especially the discussion involving the selection of object classes helps to deliminate the problem.
The object model is also used in the other two phases, but the use of the model in these phases results in only a refinement of the model.
The input of the model is a problem statement, most likely in natural language. Additional outputs consists of dialogues with for example the customer. Do not underestimate the latter part for this is a really useful discussion that will result in a better understanding, and therefore a better model of the problem. The output consists of a formal model that describes the structure of the relevant objects in a system. The identity, attributes and operations are described, as well as the relationships between objects. The object model serves as a framework into which the other model of OMT (dynamic and functional) can be placed.

The object model can and is being used in several other system development methodologies as well. One of them is the Booch method, developed by Grady Booch. This methodology is very similar to OMT. In fact, Rumbaugh and Booch are working together at the moment to combine their methodologies.
The original Booch methodology used both class and object diagrams, where the class diagram resembles the object model the most. This diagram represented the static structure of objects and relationships. The object diagram illustrates the physical object structure, and interactions between objects. These are more design and dynamic issues.

In the fusion methodology one also uses an object model that is quite similar tho that of OMT. The emphasis on the object model also lies in the analysis phase. There is one difference however, and that is that there is a separation of the problem domain model, and the system model. The problem domain model is presented by the object model, and the system model is an object model that shows the boundary of the system. The system model is a refinement of the object model developed in the first step of analysis.

The methodology developed by Wirfs-Brock et al. is really a design methodology. The design process roughly consists of two phases:
exploratory phase: definition of classes, responsibilities and collaborations; analysis phase: definition of hierarchies, subsystems and protocols. To structure the phases, the methods makes use of class and subsystem cards, collaborations and hierarchy graphs. These for items can also be represented by using the object model. The responsibility of classes will be shown as operations of those classes, the collaborations as relationships between classe. The aspects of classes, hierarchies and subsystems are already captured in the object model.
The definition of protocols can not be represented by the object model. This is because the object model really is a model to be used in the analysis phase, and the definition of protocols is a design issue.

The HOOD (Hierarchical Object Oriented Design) methodology also is a design methodology. It is especially developed to design ADA programs. The basic desing steps are:

  1. define and analyse the problem;
  2. roduce informal strategy;
  3. indentify objects and operations;
  4. draw parent diagram with child objects and operations;
  5. add implemented_by links, use relationships dataflow and exceptions on the diagram;
  6. formalise the solution in the ODS (Object Definition Skeleton) of the parent;
  7. formalisation of solution in ODS of terminal object.
The steps 1 to 4 can be replaced by the object model, but the fifth step can not be represented in the model, because this concerns design and dynamical issues. For this reason it would not be very useful to use the object model. You can of course, just like in OMT, separate these issues into different model. But in HOOD, the final solution is transformed into an ODS, which maps onto the ADA language. When you separate the models, this transformation and mapping would not be possible (at least not in an easy way).

The conclusion is that the object model really is an analysis model. It helps you to understand the problem. In all of the above mentioned methodologies you start with a model that somehow resembles the object model. The input for this phase is the requirements specification, or problem statement. The output is a formal model that describes the objects and their relations.

Last modified: December 22nd, 1995
Kristel Nieuwenhuys, knieuwen@cs.utwente.nl