Q. Explain Rumbaugh et al.s Object Modeling Technique (OMT) in detail?

The object-modeling technique (OMT) is an object modeling language for software

modeling and designing. It was developed circa 1991 by Rumbaugh, Blaha, Premerlani,
Eddy and Lorensen as a method to develop object-oriented systems, and to support
object-oriented programming.

OMT was developed as an approach to software development. The purposes of

modeling according to Rumbaugh (1991) are:

* testing physical entities before building them (simulation),

* communication with customers,
* visualization (alternative presentation of information), and
* reduction of complexity.

OMT has proposed three main types of models:

* Object model : The object model represents the static and most stable phenomena
in the modeled domain. 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 Booch Methodology

The Booch software engineering methodology [#!booch!#] provides an objectoriented development in the analysis and design phases. The analysis phase is split
into steps. The first step is to establish the requirements from the customer
perspective. This analysis step generates a high-level description of the system's
function and structure. The second step is a domain analysis. The domain analysis is
accomplished by defining object classes; their attributes, inheritance, and methods.
State diagrams for the objects are then established. The analysis phase is completed
with a validation step. The analysis phase iterates between the customer's
requirements step, the domain analysis step, and the validation step until consistency
is reached.
Once the analysis phase is completed, the Booch software engineering methodology
develops the architecture in the design phase. The design phase is iterative. A logic
design is mapped to a physical design where details of execution threads, processes,
performance, location, data types, data structures, visibility, and distribution are
established. A prototype is created and tested. The process iterates between the logical
design, physical design, prototypes, and testing.
The Booch software engineering methodology is sequential in the sense that the
analysis phase is completed and then the design phase is completed. The methodology
is cyclical in the sense that each phase is composed of smaller cyclical steps. There is
no explicit priority setting nor a non-monotonic control mechanism. The Booch
methodology concentrates on the analysis and design phase and does not consider the
implementation or the testing phase in much detail.

CS1402-Object
Oriented Analysis
and Design
Einstein
College of
Engineering

Modeling Based
on the Unified

Modeling Langu
age

The UA uses the

unified modeling
language (UML)
to describe and

model theanalysis
and design phases
of system
development.
The UA Proposed
Repository

The requirement,
analysis, design,
and
implementation
documents should
bestored in the
repository, so
reports can be

run on them
for traceability.

This allows us
to produce
designs that are
traceable across

requirements,
analysis,design,
implementation,
and testing.
The Layered
Approach to
Software
Development

Most systems
developed with
today's CASE
tools or clientserver
applicationdevelo
pment
environments tend

to lean toward
what is known as
two-layered archit
ecture
: interface and
data.
Two-Layer Archit
ecture

In a two-layer
system, user
interface screens
are tied directly to
the data through
routines thatsit
directly behind the
screens

Problem with the

Two-Layer
Architecture
This approach
results in objects
that are very
specialized and
cannot be reused

easily inother
projects.
Three-Layer Arc
hitecture
Your objects are
completely
independent of
how
:


they are
represented to the
user (through an
interface) or

how they are

physically stored.
DataWorkstation

OwnerNameTitleAddress

CS1402-Object
Oriented Analysis
and Design
Einstein
College of
Engineering

User Interface
layer

This layer is
typically
responsible for
two major aspects
of the applications:

Responding
to user interaction

Displaying
business objects.
Business Layer

The
responsibilities of
the business layer
are very straightforward:

model the objects

of the business
and how they
interact to
accomplish the
businessprocesses.
Business Layer:
Real Objects

These objects
should not be
responsible for:1.
Displaying
details2.
Data access details
DataWorkstation

OwnerNameTitleAddress

CS1402-Object
Oriented Analysis
and Design

 Einstein
College of
Engineering

Access Layer
The access layer
contains objects
that know how to
communicate with

the placewhere
the data actually
resides, whether it
is a relational
database,
mainframe,Interne
t, or file. The
access layer has
two major

responsibilities:
Translate
requestTranslate
result
Three-Layered
Architecture

2.7 Unified
Modeling Langua
ge
A
model
is an
abstract representa
tion of a system,
constructed to

understand the
system priorto
building or
modifying it. Most
of the modeling
techniques involve
graphical
languages.

Static or
Dynamic
ModelsStatic Mo
del Dynamic Mod
el

A static model can

be viewed
as"snapshot" of a
system's
parameters atrest
or at a specific
point in time.

The classes
structure and
their
relationships to
each other
frozenin time are

examples of static
models.

Is a collection of
procedures
orbehaviors that,
taken together,

reflectthe behavior
of a system over
time.

For example, an
order interacts
withinventory to

determine
productavailabilit
y.

BusinessLa
yerViewLay
erAccessLa
yer