ACCU Home page ACCU Conference Page ACCU 2017 Conference Registration Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

pinRumbaugh's OMT - The method behind C++ Designer

Overload Journal #1 - Apr 1993 + Design of applications and programs   Author: Stuart Frost


This article gives an overview of the Object Modelling Technique (OMT), which is fully described in the book by Rumbaugh et al. (Object-Oriented Modelling and Design, Prentice-Hall 1991).

OMT has been used as the basis for Select's new C++ Designer product.

Why we chose OMT

Prior to starting the C++ Designer development, we reviewed most of the OO methods which were availa­ble at the time, including Booch, Coad-Yourdon and Shlaer-Mellor. In making our choice, we considered the following factors:

  • The method should support all of the main OO se­mantics - i.e. inheritance (is a kind of), aggregation (is a part of) and association (is related to)
  • It must cover both analysis and design to a reasona­ble extent and give a smooth transition between the various stages of the life-cycle - especially between the design phase and C++ code.
  • It should provide support, or at least form a good basis for providing support, for real-time as well as MIS systems.
  • It should not be over complex.
  • It should, where possible, use familiar techniques in order to reduce the learning curve for users experi­enced in structured methods.
  • It should be an open standard - i.e. it should be pub­lished, public and well known.
  • The book in which the method is described should be readable and reasonably complete and consistent.
  • Training courses and consultancy should be availa­ble on both sides of the Atlantic from a variety of sources.
  • Other CASE vendors should be supporting, or con­sidering support for, the method.
After a great deal of internal and external debate, we finally settled on OMT:
  • The combination of the object, dynamic and function­al models gives OMT the ability to support many dif­ferent kinds of applications, including real-time systems (although the authors don't make any claims for this area). In addition, the transition between analy­sis and design is smooth and fairly well defined.
  • OMT is based on Yourdon, but with a strong object-oriented bias. This means that the learning curve is relatively small for the large number of developers who are already trained in Yourdon and other similar methods.
  • The book by Rumbaugh et al is reasonably clear and complete. Some aspects, especially those relating to integration between the three models are not present­ed very consistently, but such criticisms can be lev­elled at most software engineering books.
  • OMT is supported by several training and consultan­cy organisations in both Europe and the US. This is ex­tremely important for vendors of low-cost CASE tools, since it removes the risk of customers feeling that they are entirely dependent upon the developer of the tool.
  • OMT was developed in the General Electric Re­search and Development Center, New York and has been used for some time in that environment. In the UK, companies such as Object Designers Ltd have been using OMT as the basis for their OO develop­ments over the last two years. In addition, we have found several major clients who are starting OMT pilot projects (e.g. British Aerospace and Serco).

OMT Overview

OMT uses three integrated models to describe a sys­tem; the object, dynamic and functional models. Only the first of these is supported by C++ Designer, how­ever Select will be adding a full OMT toolkit to their range later this year.

The Object Model

The object model is central to the method and uses a diagram which is similar to the ERDs used in Yourdon. Classes and their attributes and operations are shown, together with relationships between classes. The rela­tionships which can be drawn include inheritance, aggregation and association. The modelling syntax is rich enough to represent the majority of 00 constructs in com­mon use.

The diagram shows the symbol for a class in OMT notation. The attributes and operations correspond to C++ data and function members.

Symbols for a class in OMT notation

Here we are illustrating single inheritance. The land and water vehicle classes are sub­classes of vehicle.

Single inheritence in OMT

Now we've added multiple inheritance by introducing an amphibious vehicle.

Mulitple inheritence in OMT

The diamond symbol is used to show aggregation or 'part-of rela­tionships

Arrgregation in OMT.

Petrol station control system design in OMT

The above diagram shows how the notation would be used for the design of a petrol station control system. Note that we have also used the association notation (e.g. between the CONSOLE and the PUMP), which is similar to a rela­tionship in entity-relationship notations.

The Dynamic Model

The dynamic model consists of a state transition diagram (STD) for each of the classes in the object model.

The STD notation is that defined by Harel (1987), which allows for decomposable states. This is richer and more pow­erful than that commonly used in Yourdon.

The dynamic model in OMT

The Functional Model

The functional model uses a hierarchy of data flow diagrams (DFDs) in a similar fashion to the Yourdon method. However, the DFDs are not very well integrated with the object and dynamic models and it is difficult to imagine many projects making extensive use of the functional model.

Some aspects of the functional model are, however, quite useful. For example, the context diagram is vital for defin­ing the scope of the system. Also, it may be possible to strengthen the real-time aspects of the method by introducing the concept of a processor and task model using DFDs.

The functional model in OMT


OMT is a very useful, expressive object-oriented analysis and design method. The object model allows a smooth transition from analysis, through design, to code - especially when systems are implemented in an OO language such as C++. The dynamic model is very useful for illustrating the way in which the system responds to events. However, the functional model must be used with great care in order to avoid distorting the structure of the final application.

Overload Journal #1 - Apr 1993 + Design of applications and programs