The Booch And Rambaugh Omt Methods Information Technology Essay
Rambaugh, are reviewed and compared with each other with a focus on their development processes. The purpose of this article is to 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 instead giving an abstract description in a way that facilitates the readers for the purposes of understanding each methodology, and also to make it easier to select and evaluate each methodology’s process.
Introduction
Research Area
Object Oriented Methodologies:
We will compare and evaluate the Booch Object Oriented methodology and Rumbaugh Object Oriented Methodology (OMT).
Research Question
Which one is better, Booch object oriented methodology or the Rambaugh for the higher productivity in software development organizations?
Motivation
The comparison of these two methodologies will 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, and to make it easier to tailor, select, and evaluate the methodologies. The other purpose is to provide knowledge to the individuals that are interested to get the knowledge about “object-oriented” concepts, what object oriented methodologies are available, 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.
Background
Methodology is the way something gets don; (i.e. strategy, steps, directions or actions.) Software methodology is a process for organized production of software using a collection of predefines techniques and notation convention.
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.
There are two main methodology of software development.
Traditional
Object Oriented
Object Oriented Methodology
Object Oriented Methodology (OOM) is a system development approach that facilitates the re-use of software components. A system can be developed with O-O methodology on a component basis that will allow the effective re-use of existing components and will encourage and facilitate the sharing of its components by some other systems. Higher productivity, better quality and lower maintenance cost can be achieved by adopting the O-O methodology.
The ultimate objective of OOM is application assembly – the construction of new business solutions from existing components. The components are combined in different ways to meet the new requirements specified by the user community. Only completely new functionality will have to be built to complete the solution.
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:
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;
Research Methodology
First we will review the existing object-oriented software development methodologies (seminal methodology), focusing on their development processes. The aims of this review are to understand the philosophy of the core processes and internal activities involved in each of these methodologies. This understanding is captured by using a process-centered template
, where we summarized the two methodologies, the activities and techniques discuss in the two methodologies are highlighted. We described the modeling languages and notation (mainly diagrams and tables) used as secondary to the activities. In the second step we will evaluate and compare Booch and Rumbaugh Object Oriented Methodologies only due to time limitation 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.
In the last after evaluating and comparing the two methodologies we will conclude our research by discussing our finding in a way that will 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.
Limitations
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 [Booch 1991]. 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 [Booch 1994].
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 [Booch 1994]:
The classes and objects are identified at a given abstraction level.
Figure 2-The Micro Process Booch [1994]
2. The meanings of the classes and objects that are identified in the previous step are
established by identifying the Semantics of classes and objects, 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.
OMT (1991)
Rumbaugh introduced Object Modeling Technique (OMT) in 1991 [Rumbaugh et al. 1991].OMT
consists of following three major models and then it defines a method for integrating them.
1. The Object Model
2. The Dynamic Model
3. The Functional Model
1. 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 (i.e. relationship)
aggregation
Inheritance
2. The dynamic model, this model describes the dynamics of the objects and their
changes in states. This models show the essential aspects of the system that change over time by exploring the behavior of the objects over time, and the flow control and events 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
3. The functional model, this model shows the 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 7 shows these processes.
Figure 7.-The OMT process- Derr [1995].
1. Analysis – this phase goal is to build a comprehensible and correct model of 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:
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 terms 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 design system is translated into programming language or hardware instantiation.
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
In this paper we are considering the following three major areas of each methodology for comparison:
Process
Concepts
Notations
Pragmatics
Support For software Engineering
Marketability
3.1 Process
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 results of this evaluation are shown in the following table 1:
Table 1:
Method
Rumbaugh
Booch
Requirement Specification
2
1
Design
Specification
2
2
Test Cases
Object/Class
Specification
5
1
Subsystem
Specification
1
Totals
9
5
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 2:
Method
Rumbaugh
Booch
With Prototype
–
Y
As Prototype
–
–
With Reuse
Y
Y
For Reuse
Partial
Y
Aspects of 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 3 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 3:
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 4:
Method
Completeness
Consistency
Extensibility
Rumbaugh
Y
Y
Y
Booch
N
N
N
Table 5:
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 6:
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 shows that which methodology follows what strategy.
Table 7:
Method
Recursive
Iterative
Sequential
Rumbaugh
–
Y
–
Booch
–
Y