Computermethoden der Automatisierungstechnik II SS 1998

W. Schaufelberger, D. Keller und F. Kraus

Object-Oriented Software Development Using

Object Modeling Technique (OMT)
Xiaobing Qiu
Institut für Automatik
ETH Zürich

1 Introduction
One of the most popular object-oriented development techniques today is the Object
Modeling Technique (OMT) developed by Rumbaugh et al. [1]. It is primarily used by
system and software developers supporting full life-cycle development, targeting
object-oriented implementations. Because of its simple core notation, OMT has proven
easy to understand, to draw, and to use. It continues to be successful in many
application domains: telecommunication, transportation, compilers, etc.

The popular Object Modeling Technique (OMT) has been used in many real-world
problems. The object-oriented paradigm using the OMT, spans the entire development
process, so there is no need to transform from one type of model to another. This is a
key benefit of the OMT [2].

1.1 OMT Model

OMT graphically defines a system through three kinds of model: object model, dynamic
model and functional model. The OMT Notation is given in Appendix.

Object model (OM)

The object model is the most important model. It identifies the object classes in the
system and their relationships, as well as their attributes and operations (methods). It
represents the static structure of the system. The object model is represented graphically
by a class diagram.

Dynamic model (DM)

The dynamic model indicates the dynamics of the objects and their changes in state. By
exploring the behavior of the objects over time and the flow of control and events
among the objects, the dynamic model captures the essential behavior of the system.
Scenarios are captured in event trace diagrams. These diagrams, along with state
diagrams (state charts), compose the OMT dynamic model.

Functional model (FM)

The functional model is a data flow diagram (DFD) of the system and describes what
the system does, but not how it is done. A DFD is a network representation of the
system showing the functional relationships of the values that computed by a system.

1
Relationship among models
Each model describes one aspect of the system but contains references to the other
models. The object model describes the data structure that the dynamic and functional
models operate on. The operations in the object model correspond to events in the
dynamic model and functions in the functional model. The dynamic model describes the
control structure of objects. It shows decisions which depend on object values and
which cause actions that change object values and invoke functions. The functional
model describes functions invoked by operations in the object model and actions in the
dynamic model. Functions operate on data values specified by the object model. The
functional model also shows constraints on object values.

Additional OMT Constructs

OMT has several additional constructs and diagrams that are often useful, e.g., problem
statements and use cases. They are used to establish system boundaries, requirements,
and to specify detailed behavior [3].

1.2 Phases of Object-Oriented Development Process

The object-oriented development process using OMT is shown in Fig. 1 [2].

System Object
Analysis Coding Testing
Design Design

Fig. 1 OMT Process.

Analysis
understand and model the application and its domain.

System Design
determine the overall system architecture in terms of subsystem, concurrent tasks and
data storage.

Object Design
refine then optimize the analysis model, from applications to computer concepts.

Coding
implement the object classes in target programming language.

Testing
incremental - at any stage system comprises tested and untested object classes. Testing
is based on the scenarios developed as part of the dynamic modeling process.

Each phase of the process transforms some inputs to outputs, starting at a high level of
abstraction and progressing to a more detailed level of abstraction that ultimately
represents the problem solution (Fig. 2).

2
 Class libraries

Knowledge about
application domain Init. OM Basic
Init. DM System architecture Object
Analysis Coding Testing
Design Design Object
Init. FM Detailed
Problem statement OM, DM, FM OM, DM, FM source code

Analysis System Object Source Test

document design design code scenarios
document document
User interactions

Reuse Database of OMT Specifications

Fig. 2 Inputs and outputs of the object-oriented development process using OMT.

2 Analysis

2.1 Object Model

The OMT identifies the following steps in constructing an object model:

1. Develop a problem statement.
2. Identify the object classes.
3. Discard unnecessary and incorrect classes.
4. Prepare a data dictionary.
5. Identify associations between object classes.
6. Discard unnecessary and incorrect associations.
7. Identify attributes of the object classes.
8. Discard unnecessary and incorrect attributes.
9. Use inheritance to share common structure.
10. Traverse access paths to identify deficiency.

2.2 Dynamic Model

The dynamic model is concerned with changes to objects and their relationships over
time. It is used for systems with important dynamic behavior, e.g. interactive and real-
time systems. The dynamic model shows possible control flows through the system,
while the object model shows possible information flows.

Steps to build a dynamic model:

1. Identify use cases and prepare scenarios of typical interaction sequences.
2. Identify events between objects and prepare an event trace diagram for each
scenario.
3. Prepare an event flow diagram for the system.
4. Develop state diagrams for classes with important dynamic behavior.
5. Check for consistency and completeness of events shared among the state
diagrams.

3
2.3 Functional Model

The functional model consists entirely of data flow diagrams (DFDs) and constraints.
Data flow diagrams consist of processes, data flows, actors, and data stores. A process
transforms input data values into output data values. A process is presented as an
ellipse, with the name of the process inside the ellipse. A data flow shows the flow of
data through a network of processes. An actor, drawn as a rectangle, lines on the
boundary of the DFD and terminates the flow of data as a source or sink of data. Actors
are objects. A data store is a repository for the temporary storing of data. A data store is
represented as a pair of parallel lines containing the name of a data store. Data stores
may also be objects.

Steps to build a functional model:

1. Identify input and output values.
2. Use data flow diagrams as needed to show functional dependencies.
3. Describe what each function does.
4. Identify constraints.
5. Specify optimization criteria.

3 System Design
During system design, the high level structure of the system is chosen. The decisions
that will be addressed during system design are [1]:
1. Organize the system into subsystems.
2. Identify concurrency.
3. Allocate subsystems to processors and tasks.
4. Choose the strategy for implementing data stores in terms of data structures,
files, and databases.
5. Identify global resources and determine mechanisms for controlling access to
them.
6. Choose an approach to implementing software control:
• Use the location within the program to hold state, or
• Directly implement a state machine, or
• Use concurrent tasks.
7. Consider boundary conditions.
8. Establish trade-off priorities.

4 Object Design
Object design is concerned with fully specifying the existing and remaining classes,
associations, attributes, and operations necessary for implementing a solution to the
problem. Operations and data structures are fully defined along with any internal objects
needed for implementation. In essence, all of the details for fully specifying how the
problem will be solved are specified during object design [2]. The remaining classes
have a direct relationship with the development system as well as the class library.
1. Obtain operations for the object model from the other models:
• Find an operation for each process in the functional model.
• Define an operation for each event in the dynamic model, depending on the
implementation of the control.
2.

4
 Design algorithms to implement operations:
• Choose algorithms that minimize the cost of implementing operations.
• Select data structures appropriate to the algorithms.
• Define new internal classes and operations as necessary.
• Assign responsibility for operations that are not clearly associated with a single
class.
3. Optimize access paths to data:
• Add redundant associations to minimize access cost and maximize convenience.
• Rearrange the computation for greater efficiency.
• Save derived values to avoid recomputation of complicated expressions.
4. Implement software control by fleshing out the approach chosen during system
design.
5. Adjust class structure to increase inheritance:
• Rearrange and adjust classes and operations to increase inheritance.
• Abstract common behavior out of groups of classes.
• Use delegation to share behavior where inheritance is semantically invalid.
6. Design implementation of associations:
• Analyze the traversal of associations.
• Implement each association as a distinct object or by adding object-valued
attributes to ore or both classes in the association.
7. Determine the exact representation of object attributes.
8. Package classes and associations into modules.

5 Implementation
Implementation of the design is a straightforward matter of translating the design into
code, since most difficult decisions are made during design. The code should be a
simple translation of the design decisions into the peculiarities of a particular language.
Decisions do have to be made while writing code, but each one should affect only a
small part of the program so they can be changed easily.

Object-oriented languages and non-object-oriented languages, as well as database

systems can be used for implementation [1]. Implementation of an object-oriented
design is easiest using an object-oriented language, but even object-oriented languages
vary in their degree of support for object-oriented concepts. Even when a non-object-
oriented language must be used, an object-oriented design is beneficial. Object-oriented
concepts can be mapped into non-object-oriented language constructs. Use of a non-
object-oriented language requires greater care and discipline to preserve the object-
oriented structure of the program. When the main concern is access to persistent data,
rather than the operations on the data, a database is often the appropriate form of
implementation.

5
6 Testing
Testing is an activity to verify that a correct system is being built. The implementation
and testing are partly involved during the analysis and design. This means that analysis,
design, implementation and testing are very interleaved activities performed in an
incremental fashion.

Testing may be done in various way: in a top-down fashion, a bottom-up fashion or in

a per use case fashion. The relationship among the units is in form of so called “Client-
Server”. A client requests a service from a server unit and the server unit provides the
service and responds with a result. A bottom-up approach may be preferable at the
lower levels, so that when the first unit (module) is certified, its direct clients can be
certified. Then the next level of clients can be certified and so on.

Testing may be performed at different levels: unit testing, integration testing and system
testing. A unit test is the lowest level of testing. In a traditional system a unit test is
often a test of procedures and subroutines. In object-oriented software it concerns
classes, which implies that unit tests in object-oriented systems are carried out at a
higher level. Doing a unit test of object-oriented code is therefore more complex than
testing ordinary procedural code, as a unit is not just a set of routines, but also has an
encapsulated state which may affect the behavior and correctness of the unit. Also,
concepts like inheritance and polymorphism lead to additional complexity in testing,
since we may need to retest both the inherited and override methods at different levels in
the inheritance hierarchy [4]. Integration testing is to test whether different units that
have been developed are working together properly. It includes the testing of modules,
use cases, subsystems and the entire system. Integration tests are performed several
times on different levels. The use case constitute an excellent tool for the integration
test, and integration testing is performed by testing each use case one at a time. When
all use cases have been tested separately, the entire system is tested as a whole. In
system testing several use cases should be tested in parallel, both synchronized and
unsynchronized.

References:
[1] Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy and W. Lorensen (1991).
Object-Oriented Modeling and Design. Prentice-Hall International Editions, New
Jersey.
[2] Derr, K.W. (1995). Apply OMT: A Practical Step-by-step Guide to Using the
Object Modeling Technique. SIGS Books, New York.
[3] Martin, L. (1996). Succeeding with the Booch and OMT Methods: A Practical
Approach. Addison-Wesley, Menlo Park, California.
[4] Jacobson, I., M. Christerson, P. Jonsson and G. Overgaard (1994). Object-
Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley,
Reading, MA.

6
Appendix: OMT Notation

Object Model Notation

Basic Concepts
Class: Association:
Class Name Association Name
Class-1 Class-2
role-1 role-2
Class Name
Qualified Association:
attribute
attribute: data_type Association Name
attribute: data_type = init_value Class-1 qualifier Class-2
... role-1 role-2
operation
operation (arg_list): return_type Multiplicity of Association:
...
Class Exactly one
Generalization (Inheritance):
Class Many (zero or more)
Superclass
Class Optional (zero or one)
1+ one or more
Class
Subclass-1 Subclass-2 1-2, 4
Class numerically specified

Aggregation: Ordering:
{ordered}
Assembly Class Class

Link Attribute:

Part-2-Class Association Name

Part-1-Class Class-1 Class-2
role-1 role-2

Aggregation (alternate form): link attribute

...
Assembly Class
Ternary Association:
Association Name
Class-1 Class-2
Part-1-Class Part-2-Class role-1 role-2
role-3
Class-3
Object Instances:
(Class Name)
Instantiation Relationship:
(Class Name) attribute_name = value
... (Class Name) Class Name

7
 Object Model Notation
Advanced Concepts
Abstract Operation:
Association as Class:
Superclass

Operation is Class-1 Class-2

operation {abstract}
abstract in the
superclass. Association Name
link attribute
...
Subclass-1 Subclass-2 link operation
Subclasses must provide
concrete implementations ...
operation operation of operation.

Generalization Properties:
Subclasses have
Superclass Superclass
overlapping (nondisjoint)
membership.

More subclasses
Subclass-1 Subclass-2 ... Subclass-1 Subclass-2
exist.

Multiple Inheritance:
Superclass-1 Superclass-2 Superclass Discriminator is an attribute
whose value differentiates
discriminator between subclasses.

... Subclass ... Subclass-1 Subclass-2

Class Attributes and Class Operations: Derived Attribute:

Class Name Class Name

$attribute attribute

$operation
Derived Class:
Propagation of Operations: Class Name

Class-1 Class-2
Derived Association:
operation operation operation
Class-1 Class-2

Constraints on Objects: Constraint between Associations:

A1
Class-1
attrib-1 Class-1 Class-2
{subset}
attrib-2
{attrib-1>=0} A2

8
 Dynamic Model Notation

Event causes Transition between States: Event with Attribute:

event event (attribute)
State-1 State-2 State-1 State-2

Initial and Final States: Action on a Transition:

Initial Intermediate event / action

State-1 State-2
State State
result

Guarded Transition: Output Event on a Transition:

event [guard] event1 / event2
State-1 State-2 State-1 State-2

Actions and Activity while in a State: Sending an event to another object:

State Name event1

State-1 State-2
entry / entry-action
event2
do: activity-A
event-1 / action-1
...
exit / exit-action Class-3

State Generalization (Nesting): Concurrent Subdiagrams:

Superstate

event1 Superstate event1

Substate-1 Substate-3

Substate-1 Substate-2
Substate-2 Substate-4

event3 event2 event2

Splitting of control: Synchronization of control:

event1
State-1 State-3 event3
event0
event2
State-2 State-4 event4

9
 Functional Model Notation

Process: Data Flow between Processes:

process data name

process-1 process-2
name

Data store or File Object: Data Flow that Results in a Data Store:

Name of Name of
data store data store

Actor Objects (as Source or Sink of Data): Control Flow:

d1 d2 boolean result
Actor-1 process Actor-2 process-1 process-2

Access of Data Store Value: Update of Data Store Value:

Data store Data store

d1 d1

process process

Access and Update of Data Store Value: Composition of Data Value:

d1
Data store
composite
d1

d2

process

Duplication of Data Value: Decomposition of Data Value:

d1
d1 composite

d2

10