5.2.7 Object Modeling Technique (OMT)
OMT (Rumbaugh et al., 1991) was developed as an approach to software development.
A fundamental assumption of OMT is that object-oriented thinking represents
a more natural and intuitive way for people to reason about reality (ibid.:21),
although this claim has been severely questioned, e.g. by Høydalsvik
and Sindre, 1993; and Hanseth and Monteiro, 1994.
OMT is included here because Rumbaugh (1993:18) discusses enterprise
modeling explicitly using OMT. OMT is also a widely popular and comprehensive
approach that exemplifies the vast number of object-oriented approaches
to modeling.
The purposes of modeling according to Rumbaugh et al. (1991:15) are
-
testing physical entities before building them (simulation),
-
communication with customers,
-
visualization (alternative presentation of information), and
-
reduction of complexity.
Hence, understanding and simulation is at the core. As a
general modeling approach, OMT may be used to model all types of work.
OMT proposes three main types of models:
-
Object model
The object model represents the static and most stable phenomena in
the modeled domain (Rumbaugh et al.,1991:21). Main concepts are classes
and associations, with attributes and operations.
Aggregation and generalization (with multiple inheritance)
are predefined relationships.
-
Dynamic model
The dynamic model represents a state/transition view on the model.
Main concepts are states, transitions between states, and
events to trigger transitions. Actions can be modeled as
occurring within states. Generalization and aggregation (concur-rency)
are predefined relationships.
-
Functional model
The functional model handles the process perspective of the model,
corresponding roughly to data flow diagrams. Main concepts are process,
data store, data flow, and actors.
The entire OMT software development process has four phases: Analysis,
system design, object design, and implementation of the software. Most
of the modeling is performed in the analysis phase. The recommended method
incorporates the following activities (Rumbaugh et al., 1991:261ff):
-
Develop a Problem Statement.
-
Build an Object Model:
-
Identify object classes.
-
Develop a data dictionary for classes, attributes, and associations.
-
Add associations between classes.
-
Add attributes for objects and links.
-
Organize and simplify object classes using inheritance.
-
Test access paths using scenarios and iterate the above steps as necessary.
-
Group classes into modules, based on close coupling and related function.
-
Build a Dynamic Model:
-
Prepare scenarios of typical interaction sequences.
-
Identify events between objects and prepare an event trace for each scenario.
-
Prepare an event flow diagram for the system.
-
Develop a state diagram for each class that has important dynamic behavior.
-
Check for consistency and completeness of events shared among the state
diagrams.
-
Build a Functional Model:
-
Identify input and output values.
-
Use data flow diagrams as needed to show functional dependencies.
-
Describe what each function does.
-
Identify constraints.
-
Specify optimization criteria.
-
Verify, iterate, and refine the three models:
-
Add most important operations to the object model.
-
Verify that classes, associations, attributes and operations are consistent
and complete, check with problem statement.
-
Iterate steps to complete the analysis.
A remark concerning the method is that it exclusively refers to activities
using concepts from the modeling language, i.e., classes, attributes, etc.
Hence, the focus is on the representation of enterprise models.
Worldview is not discussed explicitly, but OMT seems to have an objectivistic
foundation. This was also concluded by Krogstie (1995:126). One indication
can be found when looking at the method above: There is no support for
the sense-making part of modeling, the focus is on representation. Another
indication is the lack of discussion of modeling as a social and creative
activity: The references to social actors typically concern the modeler
obtaining a problem statement from the requestor or a domain expert (Rumbaugh
et al., 1991:150) or checking his model with the requestor or the domain
expert (ibid.:186). There are no indications of seeing reality as socially
constructed.