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 object-oriented 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 Language• 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 client-server applicationdevelopment environments tend

to lean toward what is known astwo-layered architecture: interface and data.Two-Layer Architecture

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 ArchitectureThis approach results in objects that are very specialized and cannot be reused

easily inother projects.Three-Layer ArchitectureYour objects are completely independent of how:

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

 how they are physically stored.DataWorkstationOwnerNameTitleAddress

 

CS1402-Object Oriented Analysis and Design© Einstein College of EngineeringUser 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 straight- forward:• 

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 detailsDataWorkstation

OwnerNameTitleAddress

 

CS1402-Object Oriented

Analysis and Design© Einstein College of Engineering Access LayerThe access layer contains objects that know how to

communicate with the placewhere the data actually resides, whether it is a relational database, mainframe,Internet, or file. The access layer has

two major responsibilities: Translate requestTranslate resultThree-Layered   Architecture 

2.7 Unified Modeling Language Amodelis an abstract representation 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 Model Dynamic Model • 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 productavailability.

BusinessLayerViewLayerAccessLayer