Two Object Oriented Methodologies Booch And Rambaugh Information Technology Essay

In this paper Object-oriented System development methodologies i-e Booch, Rambaugh, are reviewed and compared with each other with a focus on their development processes. We have developed a framework based on a set of criteria to compare the two methods. The aim of this comparison is to better understand the core philosophies and processes of each method, and internal activities that each method provides. The aim of this descriptions and comparisons are not to criticize the philosophies of theses methodologies, but to give a description of the two methodologies that will facilitate the readers to better understand each methodology, and to what extent the two methodologies are object oriented. And also this comparison provides an ease in selecting and evaluating each methodology’s process.

(doc1)The software engineering field has been evolving over the past thirty years, but it has never completely solved the software crisis. Software development methodologies, as an essential element of the discipline of software engineering, have also evolved from the shallow and informal methodologies of the late 1960s to the object-oriented methodologies of the 1990s and the new millennium (doc1). There is a rapid development in the object oriented paradigm during the past years and the important reasons for such rapidness are that the real world applications are modeled in a better way as well as the object oriented paradigm enables the reusability of different artifacts during the development of a software system.

Object oriented system development approach facilitates the re-use of software components. A system developed with Object Oriented Methodology (OOM) on component basis can re-use the existing components effectively, and as well as its components can be shared by some other systems too. One can achieve higher productivity, better quality and low maintenance cost by adopting the OOM.

Since, the object-oriented methodologies (OOM) are still growing and continue to evolve, and there are a number of popular OOMs circulating around, but none of them is widely accepted. The software community is yet not agreed upon several fundamental issues. (1)

“A methodology is a systematic collection of techniques & guidelines for how to build, buy, maintain and/or enhance software products. A methodology provides a basis for communication, a toolkit of techniques and a basis for repeatable, reliable software engineering. The term, method, refers to an approach to activities generally adhering to common principles” [14].

Object-oriented software development methodologies, starts from the appearance of hybrid methodologies, then move to seminal methodologies, and the development of integrated (third-generation/heavyweight) methodologies and their agile (lightweight) counterparts. The following are the categories of Object oriented methodologies [15]:

Seminal: Shlaer-Mellor, Coad-Yourdon, RDD, Booch, OMT, OSA, OOSE,

BON,Hodge-Mock, Syntropy, Fusion;

Integrated: OPM, Catalysis, OPEN, RUP/USDP, EUP, FOOM;

Agile: DSDM, Scrum, XP, ASD, dX, Crystal, FDD;

Although the promises, that the object-oriented software development provides, are based on solid grounds but still there is a confusion among the organization on when and how to invest in this new technology and also whether to invest or not. One of the reason for such confusion is that a great number of methodologies have been evolved during the last years. The other reason for confusion is closely related to the attractiveness of object-oriented software: Many vendors sticks the label “object-oriented” to their products without delivering important features – as King (1989, p. 24) states: “If I were trying to sell (my cat) … I would argue that he is object-oriented.”

Research Problem

The research question we are going to answer is:

To what extent the two Object Oriented Methodologies: Booch and Rambaugh methodologies are Object Oriented and to what extent the methodologies help the software development organizations?. The selection cretaria for the the above two OOM is mentioned in the section 1.4.2.

Since the object oriented paradigm evolved in different areas of the software development simultaneously, therefore fundamental concepts were different in different methodologies and were not completely standardized. Each OOM developed in a particular software domain such as real time systems and Information systems, although some cross-over exists in some concepts among the methodologies. Therefore, some methodologies are best in the development of applications that belong to the domain for which the methodology is evolved, while other can be used more generally. Even though OOM that evolved in the same domain may differ enough in different concepts such as process and notation and as a result can effect the software engineering goals.

Motivation

In the recent years, an overwhelming popularity of object oriented analysis and design has been witnessed. This phenomenon is evidenced by the number of papers and articles that are published in various conference proceedings, journals, books, and other forms.

But There are still a large part of the business world that uses traditional software development approach for applications development. And on the technology side, there is an extensive development in the area of Object-Oriented technologies that promises better quality and productivity through reusability, and also encourages team work.

The following observation is made in a survey [] about the organizations that uses OOM, performed by Sumit:

“A recent survey of IS managers revealed that 39% of organizations have adopted OO technology in some form. Nonetheless, OO development methodologies are used in only 5% of IS projects are developed in OO methodologies (Glass, 1999)”. For a specific application the first task is to decide which methodology is most appropriate for its development. Sometimes we may have to adapt different methodologies.”

Therefore an organization, that wants to switch to object oriented technology, faces one important question: which OOM is appropriate and should be chosen? A systematic comparison of available OOMs can answer such a question in a better way before selecting one of them. There are number of papers and articles that compare different aspects of the OOMs such as the reusability, documentation and others. So there is a need for the comparison which considers their system development core philosophy including all the concepts that methodologies provide in their development process. Unfortunately, the comparison of these methodologies is complicated because each OOM has its own set of definitions of the techniques, concepts, notations and are composed of informal descriptions, therefore the comparison of the methodologies depends largely on the interpretations and perceptions of the person who performs the comparison[10].

Such a comparison facilitate the organization that are developing software with traditional approach and now these organizations want to switch from the traditional software development approach to object oriented approach.. We also want to improve the understanding of these methodologies through this comparison, and to provide an ease in selecting, and evaluating the methodologies. The other purpose is to provide knowledge to the individuals that are interested to get the knowledge about “object-oriented” concepts, to what extent the two methods are “object oriented”, and how they relate to one another. Such interest in some cases is academic (e.g., students). Similarly individuals in companies or organizations want to evaluate and select a methodology to be used in software development process. We believe that sometime these groups are given short time and resources to make this decision, therefore comparisons like this will provide a shortcut means of selection.

Research Methodology and comparison issues

First we will review the existing software development methodologies (seminal methodology) that are object-oriented. We will study their system development processes to get a knowledge base about the object oriented technology. The purpose of this study is to understand their system development processes and internal activities involved in these development processes. Then we will review the two methods using a process-centered template, where we will summarize the two methodologies, and the activities and techniques discuss in the two methodologies will be highlighted.

In the second step we will evaluate and compare Booch and Rumbaugh Object Oriented. We will use books, journals, proceedings, and internet sources as the data sources about the object oriented methodologies and ongoing research to gain the knowledge base.

This report compares the two object oriented methodologies: Booch method and Rambaugh method, by considering their system development core philosophy.

A research has been done in Hewlett Packard Laboratories by Arnold and his colleagues [1], in which several comparing criteria are defined in the form of questions for comparing Object oriented Methodologies. These comparing criteria are based on the concepts, notations, process, and pragmatics of the OOM methodology. Influenced by the above research, this report presents a framework to compare the two selected methodologies using the same set of criteria form the above research. The framework uses these set of comparing criteria for comparing the concepts, notations, process, and pragmatics of the two selected methodology which are defined in the section 1.5.1 under the heading of comparison variables. Using such framework helps us to avoid misunderstanding and misinterpretation of the two methods during the comparison process. Based on this framework, the two methods are extensively compared. The results are presented in a set of tables. Since the results are in tabular form so the similarities and differences as well as the strengths and weaknesses of the two methods can easily be seen.

Comparison Variables

As mentioned above, this report uses four main categories of the two methodologies in the comparison which are defined as follows:

Concepts:

Concepts are related to the conceptual underpinnings of the methodology that makes it object-oriented, and explians how the concepts such as object, class, state, inheritance, aggregation, and information hiding are defined and dealt by the methodology?

Process:

The methodology describes what steps to be taken and in what order to accomplish certain task in develoment process. How well the methodology specifies the process varies largly from methodology to methodology.

Notation:

The methodology describes tecniques (textual, and /or graphical) to capture and represent information within the development process. Some methodologies describe graphical techniques only, while others specify the form and content of whole documents.

Pragmatics:

The pragmatic criteria concentrate on nontechnical features.

Pragmatics covers issues like needed resources, language suitability, learning of the CASE tools, required expertise, and domain applicability.(8)

Comparison variables are listed in Table 1 under each category. The selection criterion for these variables is objectiveness. The aim of this report is to do the objective comparison of methodologies. That is, “hard” facts are produced by these variables about a methodology showing that a methodology either supports or does not support these variables. This selection criterion has one limitation. That is, no fine grained information regarding a variable is provided in this report for the comparison. Typically, the degree to which a methodology supports a variable is not answered in this comparison. In order to alleviate this shortfall for some variables, the report distinguishes explicit methodology support from implicit methodology support in the comparison and provide fine grained information if appropriate.

The definitions of these variables in Table I are delayed until Section 3 when the selected OOADMs are compared.

Table 1: Comparison variables

Category

Variables

Concepts

Class/Object, Abstract Classes, Meta-Classes, Encapsulation, Inheritance, Association, Aggregation, Methods/Messages, Type of Communications between objects and classes, Concurrency

Process

Development Process Deliverables,

Development Context,

Aspects of the Development Life-Cycle,

Partitioning Mechanism,

The Life-Cycle of the Methodologies

Notations

Static Concepts,

Dynamic Concepts,

Explicit Rules for Notations Symbols

Pragmatics

System Size,

Programming Languages Support

Selection of OOMs

As mentioned above that this report compare the following two OOM for comparison.

Object-Oriented Modeling and Techniques by J. Rumbaugh, et al. [Rumbaugh 91]

Object-Oriented Analysis and Design by G. Booch [Booch 94]

The selection of OOMs is based on three criteria. First the Object Oriented Methodologies (OOM) must be published in text book form so that adequate information is available for our comparison; which narrowed down our selection to those OOMs that are available in the text book form. Second the OOMs should be well-known and must be accepted by the software development community as real object-oriented methodologies. Third the methodologies must be supportred by CASE tools.

The two OOM, selected in this report for camparison, fulfill and satisfy the three criteria [1, 10]. Both Booch, and Rumbaugh, which are the most widely used OOM, have evolved either from the real time domain or information processing domain and also are used in general. The two methodologies has gained significant attention so far in the software development community and are well documented at the same time.

These criteria might exclude some well-known OOMs or recent developments in the OOM, but sufficiency, maturity and general acceptance of methodologies are the primary requirements for software development practice.

Literature review

Limitation

This paper evaluates the aforementioned methods by scoring them against a set of criteria. It is not the goal of the paper to answer the question “which one is the best? But rather to show the differences between methods and to allow conclusions be drawn as to their applicability.

Remaining of report is divided into four sections. Section 2 provides a brief introduction of the two methodologies. Section 3 contains the comparison of the two methodologies. Section 4 presents the conclusion for the comparison of the two OOMs. Finally, section 5 contains the references to the literature used for this research.

Brief introduction Of the Booch And Rambaugh (OMT) Methods

Booch (1991, 1994)

Booch introduced object oriented methodology in his book published in 1991. He was the first one to give the idea of the object-oriented approach in software development process, which he called system design [2][3]. He was popular at that for his landmark paper [Booch 1986] and for the work on Ada program design. He then introduced the analysis methodology to his design and extended his design model as a repeating process which he called “The Micro Process”) within a development process which is referred as “The Macro Process”. The macro process is shown in the figure 1 below as prescribed by Booch which is a self-iterative process

Figure 1- The Macro Process -Booch [1994]

These two processes are discussed in the next sections.

The Macro Process

The macro process consists of the following steps [2] [3] [4].

1. Establish core requirements for software (conceptualization).

2. Develop a model of the system’s desired behavior (analysis).

3. Create architecture for the implementation (design).

4. Evolve the implementation through successive refinements (evolution).

5. Post-delivery evolution management (maintenance).

The Micro Process

The micro process consists of the following activities as shown in figure 2 below [2] [3] [4]:

The classes and objects are identified at a given abstraction level.

Figure 2-The Micro Process Booch [1994]

2. Previously identified classes and objects meanings are established by defining the Semantics for every class and object, as well as the behavior of the system and its components are determined.

3. The interface of classes and objects as well as their implementation are specified. Decisions

about the representation of the classes and objects are made in design model.

Rambaugh OMT (1991)

Rumbaugh introduced Object Modeling Technique (OMT) in 1991.OMT consists of following three major models and then it defines a method for integrating them [11] [12].

1. The Object Model

2. The Dynamic Model

3. The Functional Model

The object model

In this model, Objects’ static structure and relationships among these objects are determined within a system. The following are the main concepts used in this model:

object

class

operation

attribute

association

aggregation

Inheritance

Dynamic model

This model gives a description about the dynamics of the objects and their changes in states. This model shows the essential characteristics that change over time in a system by observing the objects’ behavior over time, and by exploring control and events flow among the objects. The control aspects of a system are specified and implemented in this model. The following are the main concepts in this model:

state

sub/super state

event

activity

action

Functional model

This model shows information about the data flow within a system and the outside world. The following are then main concepts of this model:

process

data flow

data store

actor (source/sink)

control flow

OMT consists of five phases.

1. Analysis

2. System Design

3. Object Design

4. Implementation (coding)

5. Testing

OMT processes considers the primary features in the first three phases of development (i-e Analysis, System Design and Object Design) and are explained in following sections. The following figure 3 shows these processes.

Figure 3.-The OMT process- Derr [1995].

1. Analysis – this phase goal is to build a comprehensible and correct model according to the real world situation. The initial problem statement is developed from the requirements of the users and information that are provided by developers and managers. The analysis phase produces the following deliverables [11] [12]:

Problem Statement

Object Model, which consists of Object Model Diagram and data dictionary

Dynamic Model, which consists of State Diagrams and Global Event

Flow Diagram

Functional Model, which consists of Data Flow Diagram and constraints

2. System design – on the bases of architectural design of the system and problem domain, the system is partitioned into subsystems. The following are the system design phase deliverables:

System Design Document: consists of architectural design of the system and high-level strategic decisions for implementing data stores in the form of data structures, files, and databases.

3. Object design – based on the analysis model, the goal of this phase to provide

Implementation details that include the domain infrastructure classes along with the internal objects needed for implementation. The following are the object design phase deliverables:

Detailed Object Model

Detailed Dynamic Model

Detailed Functional Model

4. Implementation – in this phase the system that is designed so far is translated into programming language code and hardware.

5. Test – The entire System that is developed is verified in this phase. Testing includes system level and scenario based tests.

Comparison Of Booch and Rambaugh methods

The framework used in this paper is considering the following major areas of each methodology for comparison:

Concepts

Process

Notations

Pragmatics

3.1 Concepts

A method to be consider as object oriented, it should support concepts that are related to the object oriented methologies. This comparison provides help in evaluating the method to the extent it is is object oriented. Therefore , in this paper we are comparing object oriented concepts of the two methodologies, Booch and Rambaugh, in the following categories.

Concepts, such as Class, Object, etc.

The relationships such as Inheritance and Aggregation

Types of communications between objects and classes.

Concurrency mechanisms

Object is the fundamental concept of every object-oriented method, that must be supported by the method. An object encapsulates its internal state (or attributes) and provides a set of operations (methods/messeges) as an interface for manipulating the state. Whereas a class is a template which describes the attributes and interface of a set of objects. Object instances are produced by defining class variables.[5]

Table 1 lists comparison of the object oreinted concepts that both methodology provides. A “Y” in the box for each concept represents that an artifact is provided by the coresponding methodology.

Table 1. Object Oriented concepts

Method

Rumbaugh

Booch

classes/objects

Y

Y

abstract classes

Y

Y

meta-classes

Y

Y

Encapsulation

Y

Y

single inheritance

Y

Y

multiple inheritance

Y

Y

Aggregation

Y

Y

Association

Y

Y

methods/messages

Y

Y

Total

9

9

Real world is concurrent, so object oriented methods often uses concurrent objects in the analysis

phase to model it.

Objects remain in passive mode, until an operation is invoked by another object to bring them in active mode. If there are more than one thread of control associated with active object, then it is called internally concurrent object. Therefore object oriented methods should support ways to access the shared data in concurrent systems.[5]

Table 2. Concurrency

Method

Passive

Active

internally concurrent

Rumbaugh

Y

Y

Y

Booch

Y

Y

–

Communiication provides information flow and synchronization between objects that are involved in the communication.

In Synchronous communication the sender object send a messege to the reciever object and suspend execution until it receives an aknowlegment message from the reciever, whereas in asynchronous communication the sender does not wait for the aknowlegment and continues it’s execution.

Sequential systems uses procedural call whereas concurrent object systems uses remote procedure Call for communication.

Table 3. Communication

Method

Synchronous

Asynchronous

Procedural

Remote procedure

Rumbaugh

–

Y

Y

Y

Booch

Y

Y

Y

–

Process

3.2.1. Deliverables that are produced during the Development Process:

A number of different types of deliverables are generated during the development process of a system. These include a number of specifications likely requirements, analysis, design, subsystem, and test cases. Particularly, in object-oriented development process, object and classes specifications are very important. Following criteria is used to find out the deliverables that each methodology generates during the development process:

0 shows no deliverable is generated.

1 shows deliverable is generated, but details are not provided.

2 shows deliverable is generated and also well defined.

3 shows deliverable is generated, a definition is provided, and an example is given.

4 shows deliverable is generated, a definition is provided, and an example is given, and a definition for the process is provided.

5 shows deliverable is generated, a definition is supplied, an example is given, a definition for the process is provided, and heuristics are provided.

The following table 4 represents the results of this evaluation:

Table 4: Development process deliverables

Method

Rumbaugh

Booch

Requirement Specification

2

1

Design

Specification

2

2

Test Cases

Object/Class

Specification

5

1

Subsystem

Specification

1

Totals

9

5

3.2.2. Development Contexts

A set of constraints occur during the development process which are established by development context. The following criteria are used to evaluate that whether each methodology explicitly discusses the constraints that are established by the development context, or not within the method.

A “Y” in the “With Prototyping” column shows that prototyping is discussed explicitly in the methodology.

A “Y” in the “As Prototyping” indicates that prototypes iteratively deliver the system and methodology produces prototypes into production.

A “Y” in the “With Reuse” shows that the methodology explicitly incorporate the reuse products into the method

The “For Reuse” indicates whether the methodology delivers reusable products for other processes or not.

Table 5: Development Context

Method

Rumbaugh

Booch

With Prototype

–

Y

As Prototype

–

–

With Reuse

Y

Y

For Reuse

Partial

Y

Aspects of the Development Life-Cycle

The whole development life cycle of a methodology gives us a suggestion about the completeness and consistency of the methodology. If a methodology covers all aspects of the development lifecycle during the development process then it ensures the completeness and the consistency of the methodology and it is useful to the organization as a complete and consistent methodology.

Therefore, complete life cycle coverage is very important to a life cycle with a limited coverage.

Following table 6 values shows these aspects:

0 shows this feature is not covered.

1 shows this feature is covered, but with no details.

2 show this feature is covered with definition.

3 shows this feature is covered, a definition is given with an example (at least one).

4 shows this feature is covered, a definition is given with an example (at least one) and with defined process.

5 shows this feature is covered, a definition is given with an example (at least one) and with defined process, and heuristics are provided.

Table 6: Development process life cycle coverage

Method

Rumbaugh

Booch

Domain Analysis

4

Requirement Analysis

5

2

Enterprise Modeling

Design

5

5

Implement

3

4

Test

2

Total

15

15

In software engineering Extensibility of the system design is a systematic measure of the ability to last or continue. A level of efforts is required to extend a system in range or scope.

Table 7: Extensibility

Method

Completeness

Consistency

Extensibility

Rumbaugh

Y

Y

Y

Booch

N

N

N

Table 8: Process properties

Method

Well-defined

steps(process)

Pure or hybrid

Traceable

across lifecycle

Rumbaugh

Y

H

Y

Booch

Partial

P

–

Partitioning Mechanism

When system size increases, then at a particular time, the visibility of certain information about the objects of interest is very crucial and to limit this visibility a partitioning mechanism is required. Each methodology was studied carefully to seek such mechanisms it provides. So the information in the table below was the outcome.

Table 9: Partition mechanism

Method

Partitioning Mechanism

Rumbaugh

Subsystems

Booch

Subsystems

The Life-Cycle of the Methodologies

The development life-cycle of each methodology was carefully reviewed so as to determine that whether the methodology follows a sequential (i-e Waterfall), iterative or recursive strategy because it is the crucial requirement for project planning. Otherwise it will yield unexpected results with high risk and would lead to total failure. The following table 10 shows that which methodology follows what strategy.

Table 10: life cycle property

Method

Recursive

Iterative

Sequential

Rumbaugh

–

Y

–

Booch

–

Y

–

3.3 Notations

3.3.1. Static Concepts

Each methodology was reviewed to determine that how each methodology represents the following concepts:

Aggregation: what are the components an object is a composed of.

Communication: How the classes or objects communicate with each other(i-e by sending message to one another)

Specialization: An object is represented as a generalization, or specialization, of another class or object?

Module Interfaces: The physical implementations of objects

Qualifications for Reuse: How much each methodology encourages the reuse of different components of development process.

These concepts within each methodology indicates that how the models are used. The table 11 below shows the notations for these concepts.

Table 11: Static Concepts

Method

Rumbaugh

Booch

Aggregation

Object Model

Class Diagram

Specialization

Object Model

Class Diagram

Communication

Scenario

Class Diagram

Module Interfaces

–

Module

Qualifications for Reuse

–

Object Diagram

3.3.2. Dynamic Concepts

A change in the state of the system and Object interactions over time are important elements for system’s behavior modeling. So the following table 12 shows the notations that represents these elements during the whole process.

Table 12. Dynamic Concepts’ Notation

Method

State Changes

Timing

Rumbaugh

State Diagram

Extended State

Booch

State Transition

Timing Diagram

3.3.3. Explicit Rules for Defining the Notations Symbols

Each methodology’s symbology was reviewed to determine that the notation symbols are defined explicitly or not and if so, where. If there are any examples given, they are also noted. It is important to note that defining the explicit rules for method’s symbology is very essential if automated tool support is to be used. The table 13 below indicates the notations defined by each methodology.

Table 13: Notation

Method

Notation

Rumbaugh

notation is defined

Booch

notation is defined

Notations semantics definitions, examples and heuristics were also reviewed for models construction.

Table 14: Notation definition

Method

Syntax

Defined

Semantics

Defined

Examples Provided

Heuristics

Presented

Rumbaugh

YES

YES

YES

YES

Booch

YES

YES

YES

YES

3.4 Pragmatics

3.4.1. System Size effect on methodology

If the system size is larger then the development process is significantly more complicated than the system with smaller size. A methodology must provide some kind mechanisms for development of large sized systems such as scoping visibility and interfaces at higher level than that of classes. Each methodology is reviewed to determine whether the methodology support small size or large size system development or both. The following table 15 represents this review.

Table 15: System Size effect

Method

Rumbaugh

Booch

Small

YES

YES

Medium

YES

YES

Large

YES

YES

3.4.2. Programming Languages that each Methodology supports

Any methodology that is independent of programming languages is highly desirable because it provides portable analysis and design products across any language. The implementers have flexibility in their selection if the methodologies are independent of implementation languages.

Secondly each methodology is also reviewed for real time development. The following table 16 shows the languages that each methodology supports for implementation and also whether the methodologies are fit for the real time development

Table 16: Programming Languages support

Method

Rumbaugh

Booch

C++

YES

YES

Ada

YES

YES

Smalltalk

YES

YES

Real-Time

YES

YES

Total

4

4

3.5 Conclusion

In general OOM can produce better quality systems than traditional methods. But for application domain and software engineering, different OOM provides different support and also these methods have different support for the object oriented paradigm. Therefore to select appropriate method among the different available methods is a tedious job and this selection needs to look for the support and features that each method provides for the system development. Further, an OOM will be more appropriate and valuable for a system development project if it provides such supports and features that a project needs.

We have developed a framework in this paper that considers a set of criteria. We have used four major aspects of the two methodologies in this framework: concepts, notations, process, and pragmatics. This framework enables us to compare and to evaluate the two methods in an accurate way. Using such framework will enable us to better understand and interpretation the two methods. Also this framework can be used to identify the similarities and differences between the two methods, and to find out the strengths and weaknesses of the two.

This kind of comparison provides knowledge to the individuals that are interested to get the knowledge about “object-oriented” concepts, to what extent the two methods are “object oriented”, and how they relate to one another. Such interest in some cases is academic (e.g., students). Similarly individuals in companies or organizations want to evaluate and select a methodology to be used in software development process. We believe that sometime these groups are given short time and resources to make this decision, therefore comparisons like this will provide a shortcut means of selection. Furthermore, this comparison provides valuable information for organizations that want to or planning to switch to object oriented technology.

Finally, we have compared the two methodologies to guide the reader and organization to design a better system by selecting an appropriate method and to take maximum benefits from the object oriented methodology that best suit their projects.