A Comparison of Object-Oriented Development Methodologies

Copyright The Object Agency, Inc., 1995

This report has been prepared to assist an organization in better evaluating the availability, and appropriateness of, of object-oriented methods for their environment.

Assumptions: This paper assumes the reader has a basic understanding of object-oriented concepts and object-oriented development in general.

Introduction

The Purpose of a Methodology Comparison

The readers of methodology comparisons constitute a number of overlapping sets. For example:

This section will satisfy all three types of reader.

Two Different Cultures

Objectively evaluating methodologies is a difficult and complex activity. This difficulty and complexity results from a number of factors, including, but not limited to:

Without understanding the culture underlying a particular development approach, effective comparison cannot be achieved. Explicitly acknowledging the diverse culture of the object-oriented community is a first step in better understanding the methodologies presented by this community.

The Literature

Numerous object-oriented methodology comparisons currently exist in the literature. These include, for example:

This report compares a number of analysis and design methodologies. Analysis methodologies considered include: DeMarco Structured Analysis, Yourdon Modern Structured Analysis, Martin Information Engineering, Bailin OO Specification, Coad and Yourdon OO Analysis, Shlaer and Mellor OO Analysis. Design methodologies reviewed include: Yourdon and Constantine Structured Design, Martin Information Engineering, Wasserman OO Structured Design, Booch OO Design, and Wirfs-Brock Responsibility-Driven Design. Contact 617-253-2348 for pricing and availability.

This "white paper" compares the notations, terminologies, and models used in methods by: Booch, Coad and Yourdon, Edwards and Odell and Martin, Graham, Rumbaugh, Shlaer and Mellor, Wasserman and Pircher, and Wirfs-Brock. Contact SIGS Publications at 212-274-0640 for pricing and availability.

This study, conducted by Hewlett Packard, evaluates the methods of Booch, Buhr, Rumbaugh, Wirfs-Brock, and HOOD (Hierarchical Object-Oriented Design).

This article compares 23 object-oriented analysis and design methodologies to identify common themes, and strengths and weaknesses in object-oriented analysis and design methods in general.

This report compares the background ideas, steps, concepts, notations, communication mechanism, and the specification techniques of six accepted methods, that are available in textbooks. The comparison is performed by meta-modeling, yielding detailed information on concepts (in EER notation) and steps (in task diagrams). Extensive comparison tables of steps, concepts, techniques are included, as well as mappings of the methodical concepts to the constructs of programming languages (Smalltalk, C++, Eiffel, and others) Six methods are: Booch, Martin/Odell, Coad/Yourdon, Rumbaugh, Wirfs-Brock, Shlaer/Mellor.

Available for North America through OSoft Development Corp. Call 404-875-2216 for pricing and availability. Elsewhere call +31.53.893690 (Netherlands) or mail to sjbr@cs.utwente.nl.

This paper is a summary of the report [van den Goor et.al., 1992]. Discusses the comparison approach and gives excerpts of the comparison results. Available from the authors at cisssh@gsu2.gsu.edu or sjbr@cs.utwente.nl.

In addition, the following text, while not a methodology comparison, does include a comparison of Structured Analysis/Structured Design (SA/SD), Jackson Structured Development, Information Modeling Notations, and some other object-oriented methodologies

Methodology Comparisons -- Problems

Significant research exists in the area of methodology frameworks. For example, the oldest working group of the International Federation of Information Processing (IFIP Working Group 8.1) is involved in evaluating and designing information systems and their supporting methodologies. Yet methodology comparisons suffer from a number of common flaws. These include:

Definition of Methodology

A complete methodology is far more than a notation, process, and tools. For example, most of the available object-oriented methodology books range in page count from 200 - 600 pages in length, and from U.S. $25.00 to U.S. $60.00. Yet there are organizations who attempt to create fully elaborated methodologies, considering cradle to grave software support. For instance, Ernst and Young's Navigator method and Arthur Andersen's Foundation method (available from two information systems consulting firms) consists of thousands of pages bound in a number of three-ring binders, are provided on a number of CD-ROMs, are coordinated with extensive training, and cost in excess of U.S. $25,000. In addition to a "notation, process, and tools," these "complete methodologies" provide:

As of September 1992, none of the reviewed object-oriented methodology texts provide this degree of support, nor should they be expected to. As such, the evaluation and comparison of methodologies must be done with the knowledge that, for all methods reviewed, there still remains a great deal of work to be done before these methods are fully elaborated.

Setting the comments made above aside, this section uses the term "methodology" as consisting of a notation and a process, as well as being published in either a book or refereed journal.

This Report's Approach

This report presents a methodology evaluation framework within which the methodology comparison is conducted. This framework consists of a series of questions used to identify and quantify a methodology's support for a specific development process. The framework employed considers six major areas of each methodology:

Concepts

This section cites from the particular method and then contrasts support for terms within each method under scrutiny. Terms such as object, class, metaclass, and operation are evaluated. This analysis in many cases classifies a method's perspective, i.e., whether or not it is "data-driven," "extended-structured," or "programming-language oriented." This classification is useful in later appraising the method's "object-orientedness" in that it provides insight into each author's view of what an object, and what "object-oriented", means.

Notations

Many methods require the creating of abstract descriptions, or graphical models, of the system under analysis and/or design. These models are constructed using some form of notation. In assessing a method it is necessary to consider the models the method requires and the notations required of each model. Some models, such as data flow diagrams, are simple and straightforward notations. Models used in formal development methods such as Z, VDM, or OBJ are involved and mathematical in nature. One of the major requirements of any method is that the set of models the method develops form a complete and consistent description of the system. In addition, each model's linkage with other models is also appraised. Ideally, each model represents some aspect of the system not represented completely by another model, yet each model provides "clues" or direction in the partial or complete creation of other models.

The expressiveness of each method's notation is evaluated for its support for such concepts as aggregation, generalization/specialization, and object interaction. If the notation is not sufficiently expressive the user is required to encode the representation in an ad hoc manner, often as unformatted text attached to the model, or maintained separately from the model. This leads to inconsistent, more complex, and less easily understood models.

The syntax and semantics should, in addition to being expressive, also be well-defined. The syntax of a notation defines the rules which describe the primitive components of a notation and the legal combination of those symbols. BNF notations are common for defining textual semantics, such as those governing a programming language. Techniques for defining diagram syntax and semantics are less formalized, but at the very least the methodology should provide a clear definition of icons and their legal combinations. A significant collection of examples is also useful. The semantics of a notation gives meaning to the syntactic primitives and their combinations. The notation semantics provide meaning to the models. In addition, the method should provide rules for reasoning and transforming models (e.g., transforming models from analysis to design).

Scaleability addresses whether or not the notation is appropriate for use on large systems. Notations, in order to be effective in large systems development, require a mechanism for partitioning components into more manageable "chunks".

Process

The process component of the this comparison is used to characterize within what development contexts the method is appropriate, how much of the systems development life-cycle is covered by the method, and what tailoring or heuristics are available for the method's process.

A development context specifies whether the effort is useful in creating new software, reengineering or reverse engineering existing software, prototyping, or designing for or with reuse components.

Greenfield development is "new" development or development pursued outside any existing software. No regard is paid to legacy systems or any existing software.

Reengineering (or reverse engineering, depending upon the definition one uses) involves enhancing an existing system to improve or make more useful an existing application. The process involves employing methods and tools to understanding existing and legacy systems and maintaining their value as assets for organizations. Reengineering involves learning how to manage such systems effectively, capturing their essential design, identifying their structure and content, and enabling their renovation to meet the needs of the business they are meant to support.

Some methods strongly recommend prototyping as a key component of their process, while some other methods processes can be characterized as being prototyping, albeit in a more formal manner. The adaptability of a method to use, or not use, prototyping, is an additional process characteristic.

The support for reuse is evaluated for each method. Methods that explicitly address reuse provide steps, deliverables, and heuristics for the identification, construction, testing, demonstration, and application of reusable components. One of the touted benefits of object-oriented approaches, as well as extensions to other disciplines such as Information Engineering (Martin, 1990), is their ability to create, as well as incorporate, reusable components. Through such reuse significant productivity gains are touted. Each method is evaluated to determine its support for the incorporation of reusable components, as well as the methods facility in creating reusable components.

Life-cycle coverage of each method is then evaluated. Life-cycle coverage of the particular method involves ascertaining what elements of software development is dealt with within the method. Each methodology may have elements that are useful to a portion of the development life cycle. For the purposes of this discussion, the life cycles phases are defined as follows:

Next evaluated are the properties or attributes of the method's process. A process's properties serve as a measure of the method's repeatability and flexibility. The properties should defined the sequence of steps, required inputs and outputs, involved roles, as well as interaction with other steps. Optional steps should be clearly identified. Available heuristics and mechanisms for traceability, verification, and validation of the process are also desirable attributes of a well-defined process.

Pragmatics

This section considers the pragmatics of the methodology. A methodology's pragmatics consists of:

Support for Software Engineering

This section considers the method's support for software engineering goals and principles. In particular, each method is appraised for:

Marketability

The final section of this section addresses an issue of comparing methodologies that is seldom made explicit, that of the "marketability" of the method. A common flaw in many methodology comparisons (especially those conducted in-house by a corporation) is that prior to conducting the comparison some assumptions are made that in many instances bias the results dramatically. Some of these "marketing" factors can include, for example:

The above "marketability" criteria have little to do with the cleanness or usefulness of a particular method. In many instances these criteria are totally corporation-specific, and will vary from company to company. While any study must address these issues, they should be placed in an appropriate context. This section isolates these concerns to a specific section.

Avoiding the Problems Associated with Prior Methodology Comparisons

This section attempts to avoid the problems encountered in prior comparisons in the following way.

The above list of methodologies is by no means exhaustive, but serves as a reasonable representation of some of the methodologies available. Please note that Colbert is the only method reviewed from an article (of only 16 pages), and not a book.

The End Result

The expectation of any methodology comparison is that it will provide a vehicle to weed out methodologies that do not appear of value to the reader, thus allowing the reader to "home in" on those methods showing the most potential for the effort at hand. This section handles this expectation in the Marketability section. By posing a set of sample questions and using the documented results to answer the question this study identifies means the reader can use the results of this study to address their particular needs. These questions are by no means exhaustive, but do serve as a jumping-off point for conducting further research. A sample of the questions includes:

Concepts

The following section reviews each method's definition of some object-oriented terms. From this review, similarities and differences are identified and the methods are contrasted.

What Is Each Method's Definition Of "Object?"

What Is The Method's Definition Of "Class?"

What Is The Method's Definition Of "Operation?"

What Is The Method's Definition Of "Metaclass?"

No explicit mention of metaclass is made in any of the other methods reviewed.

How Does The Method Deal With Concepts That Are Larger Than Can Be Reasonably Represented By A Class?

No explicit mention of larger object-oriented concepts is made by the other methods reviewed.

Analysis

This section cites specific quotes from each methodology to ascertain each author's view of a number of object-oriented concepts. The list of terms used is by no means exhaustive. Terms such as inheritance, state, and attribute could be readily added, as well as many others. What is interesting to note is the perspective of each author. For instance, in terms of the term "object", the following can be noticed:

Method Mention of Abstraction Uniqueness or Identity Behavior or Actions State
Berard - X X -
Booch - X X X
Coad and Yourdon X - X -
Colbert - X X X
Embley - X - -
IBM - X - -
Martin and Odell X - - -
Rumbaugh X - - -
Shlaer and Mellor X - - -
Wirfs-Brock - X X X

The above indicates that certain methods consider the mention of abstraction integral to their definitions of object, and others consider uniqueness and identity as critical (only Rumbaugh mentions both). In addition, the mention of behavior and state seems limited to those methods focusing on uniqueness. Drawing conclusions from single paragraphs is risky, but the basic definitions of objects used in the methods compared seem to differ in a specific manner.

Method Mention of Abstraction Mention of Structure Mention of Behavior State Relations
Berard X X X - -
Booch - X X - -
Coad and Yourdon - X X - -
Colbert - X X X -
Embley X - - - X
IBM - X X - -
Martin and Odell X X - - -
Rumbaugh X X X - X
Shlaer and Mellor - - - - -
Wirfs-Brock - - X - -

The above review of each method's definition of class provides some additional insight. Please note that while Shlaer and Mellor's method uses Class Diagrams and makes significant mention of the term "class" in their approach, they supply no explicit definition of class. As another note, Rumbaugh mentions that a class must identify its relations with other classes, while Embley mentions that the Object-Relation Model is useful in identifying classes. These two methods differ from the other methods in their reliance on relations as fundamental to their use of the term "class."

Method Operation = Method? External Internal State
Berard - X X -
Booch X - X -
Coad and Yourdon - X - -
Colbert - X X X
Embley - X - -
IBM - X X X
Martin and Odell - - - X
Rumbaugh - X X -
Shlaer and Mellor - X X X
Wirfs-Brock - X - -

In reviewing each definition of "operation", only Booch states that method and operation are equivalent. The IBM method, being strongly based in the Smalltalk language, does not even define the term "operation." Some methods provide for looking at an object's methods from an external perspective, while others focus on an object's methods from an internal perspective. Only the Martin and Odell method ignores the issue of external or internal methods.

Method Subjects/Categories Domains Domain Analysis Subsystems
Berard - X X X
Booch X X X X
Coad and Yourdon X X - -
Colbert - - - X
Embley X - - -
IBM - - - -
Martin and Odell - - - -
Rumbaugh - X - X
Shlaer and Mellor - X - -
Wirfs-Brock - - - X

The partitioning present in each method varies significantly. Only Booch and Berard spend a significant amount of text in describing object-oriented domain analysis. (Shlaer and Mellor, pp. 16 -17) suggest that objects can be located using the following sources:

Source Examples
Tangible things airplane

pipe support

nuclear reactor

Roles played by persons or organizations doctor

patient

broker

Incidents flight

accident

performance (of a play, etc.)

Interactions purchase

marriage

an electrical network

Specifications insurance policy types

Coad and Yourdon recommend searching for objects through the following sources:

These two approaches, while useful, are limited. Booch and Berard, on the other hand, discuss object-oriented domain analysis, which while much more involved than the straightforward guidelines presented above, appears much richer from the standpoint of identifying related objects in a coherent and repeatable manner.

Generally speaking, their appears to be a continuum of "object-orientedness" of the reviewed methods. Booch, Berard, Colbert, and Wirfs-Brock seem to be the most object-oriented, with their strict emphasis on objects, and downplaying of associations and relationships. Coad and Yourdon and IBM seem to be next, with accommodations for data (attributes and instance variables). Rumbaugh, Embley and Kurtz, and Shlaer and Mellor cluster next, with a strong emphasis on associations and relationships almost at a level making these items peers of objects. Martin and Odell is the least object-oriented, seemingly presenting slight extensions to information engineering with a very heavy behavioral orientation.

Notations

What Are The Components Of The Method's Notation?

Each methodology is characterized by a specific set of models (components of the notation). The following lists each method's models, and provides references into the appropriate text for each model. The titles of each model give an indication of the concepts addressed by each notation.

Berard
1. Object-Message Diagram page 204
2. Semantic Network Diagram pp. 136, 204, 292
3. State Transition Diagram pp. 137, 204, 292
4. Petri-net Graph pp. 204, 293-294
5. Timing Diagram page 204
6. Kit page 169
7. System of Interacting Objects pp. 175-176
8. Program Unit Graphic page 236

Booch
1. Class Diagram (inside front cover)
2. Object Diagram (inside back cover)
3. State Transition Diagram (inside back cover)
4. Timing Diagram (inside back cover)
5. Module Diagram (inside back cover)
6. Process Diagram (inside back cover)

Coad and Yourdon
1. The OOA Class Symbol, depicting a Class, its Attributes, and its Services. (page 58)
2. The OOA Class-&-Object Symbol (page 56)
3. Generalization-Specialization Structure notation (page 81)
4. Whole-Part Structure notation (page 91)
5. Subject notation (page 112)
6. Attribute notation (page 121)
7. Instance Connection notation (page 127)
8. Service notation (page 145)
9. Object State Diagram notation (page 146)
10. Message Connection notation (page 150)
11. Service Chart notation (page 157)

Colbert
1. Object Interaction Diagram (page 403)
2. Object-Hierarchy Diagram (page 406)
3. Object-Class Diagram (page 406)
4. State Transition Diagram (page 408)
5. Ada Structure Diagram (page 412)

Embley et al.
1. Object-Relationship Model (ORM) (pp. 267-269)
2. High-Level ORM (page 270)
3. State Net (pp. 271-274)
4. High-Level State Net (page 275)
5. Interaction Diagram (pp. 276-278)
6. High-Level Interaction Diagram (page 279)

-
IBM
1. User's Interface Model (page 44)
2. User's Model for Objects (page 45)
3. User's Model for Transactions (pp. 48, 49, 50)
4. Use Case (a variant of a timing diagram) (page 59)
5. Object-Method Matrix (page 62)
6. Direct Manipulation Matrix (page 68)
7. Doughnut Diagrams

Martin and Odell
1. Data Structure Diagram (page 177)
2. Object-generalization hierarchy diagram (undefined, but examples shown on pp. 136-140) (pp. 178, 136-140)
3. Object-relationship diagrams (page 83)
4. Object composed-of diagrams (pp. 81, 139-140, 177)
5. Action diagrams (page 177).
6. Structure charts. No examples shown. (page 177)
7. Declarative tables. No examples identified in the index. (page 177)
8. State-change diagrams. Alternately referred to as fence diagrams and as State Transition diagrams. (pp. 90, 91, 104, 143, 177)
9. Event diagrams. Alternately referred to as Event schema. (pp. 94-101, 178)
10. Object flow diagrams. (page 101)
11. Tools for designing the graphical user interface. No elaboration provided. (page 177)

Rumbaugh et al.
1. Object Model Used to describe classes, objects, attributes, operations, specialization, generalization, and inheritance. (page 44)
2. Dynamic Model consisting of: -
-Scenario (page 86)
-Event trace (page 87)
-State Diagram (pp. 90-98)
-Event hierarchy (page 98)
-Concurrent state diagrams (page 100)
-Extended state diagram for synchronization of concurrent activity (page 104)
3. Functional Models consisting of: -
-Data flow diagram (pp. 125-129)
-Control flow diagram (page 130)
4. System Architecture page 217

Shlaer and Mellor
1. Information Structure Diagram (pp. 77-81)
2. Overview Information Structure Diagram (pp. 81-82)
3. Domain Chart (page 141)
4. Project Matrix (page 155)
5. Subsystem Relationship Model (pp. 149, 153)
6. Subsystem Communication Model (page 153)
7. Subsystem Access Model (page 153)
8. Information Model (pp. 41, 57, 76, 80, 91, 113)
9. Object and Attribute Descriptions (page 14)
10. Relationship Descriptions (pp. 21-29)
11. Object Communication Model (page 86)
12. Event List (page 65)
13. Object Access Model (pp. 131-132)
14. State Process Table (pp. 129-130)
15. State Model (pp. 37-40, 49, 58-60, 77-83)
16. Action Data Flow Diagram (pp. 112-122)
17. Process Descriptions (pp. 128-129)
18. Inheritance Diagram (pp. 220-221)
19. Dependency Diagram (pp. 216-219)
20. Class Diagram (pp. 206-211)
21. Class Structure Chart (pp. 211-216)

Wirfs-Brock
1. Class Card (pp. 46, 49)
-Class Card with Responsibilities (page 72)
-Class Card with Collaborations (page 94)
-A Class Card with a Subsystem Delegation (page 138)
2. Hierarchies (pp. 26, 28,48, 58-59, 87, 108, 109,122,123,126)
3. User Interface Model (pp. 51, 203, 204, 211, 217, 219)
4. Collaborations Graph (page 133)
5. Subsystem Card with Delegations (page 137)

What Static Concepts Is The Notation Capable Of Expressing?

Each methodology was evaluated as to how it represented the following concepts:

These questions, while not exhaustive, provide an indication as to how the models are used within the method.

Method Aggregation Specialization Communication Module Interfaces Qualifications for Reuse
Berard Semantic Net Semantic Net Object Message Diagram Program Unit Graphic Semantic Net
Booch Class Diagram Class Diagram Class Diagram Module Object Diagram
Coad and Yourdon Whole-Part Gen-Spec Message - -
Colbert Object Hierarchy Object-Class Diagram Object-Interaction Ada Structure Object-Class
Embley and Kurtz Object Relationship Model Object Relationship Model Object Relationship Model - -
IBM - - - - -
Martin and Odell Composed-Of Object Generalization Object Flow - -
Rumbaugh Object Model Object Model Scenario - -
Shlaer and Mellor - Inheritance Object Communication Class Diagram -
Wirfs-Brock Class Card Hierarchy Collaborations - -

The reason the IBM approach shows a blank line above is because the approach is largely text-based, with no specific graphical notation. Over half of the methods do not provide implementation graphics for object construction. This is interesting in that structured design used "structure charts" for implementation support, yet no such support appears present in some of these object-oriented methods. Implementation graphics would appear extremely useful in providing a visual aid in helping the object-oriented implementer in constructing the source code for the object.

What Dynamic Concepts Is The Notation Capable Of Expressing?

The representation of state changes, timing, and object interactions over time are essential elements for modeling the behavior of systems.

Method State Changes Timing
Berard State Transition/Petri Net Timing Diagram
Booch State Transition Timing Diagram
Coad and Yourdon State Diagram -
Colbert State Transition -
Embley and Kurtz State Net State Net
IBM - -
Martin and Odell State Change -
Rumbaugh State Diagram Extended State
Shlaer and Mellor State Model -
Wirfs-Brock - -

No attempt was made to assess the complexity of the graphical notations above. Berard uses state transition diagrams to model a single object's change in state, while he uses Petri net graphs to depict the interaction of multiple objects in varying states interacting over time. Both IBM and Wirfs-Brock have no graphical support for modeling timing or state changes, but IBM does have a textual "Use Case" to depict timing.

Are Explicit Rules Presented For Defining The Notations Symbols?

Each method was reviewed to determine if the method's symbology was defined explicitly, and if so, where. If examples are available, this is so noted. Note that an explicit definition of the symbology is required if automated tool support is to be provided.

Berard notation is not formally defined. Numerous examples are provided
Booch notation is documented on the inside front and back covers. Numerous examples are provided
Coad and Yourdon provides specific rules for symbol notation in Appendix A of Object-Oriented Analysis and numerous examples are provided.
Colbert notation is partially defined, and numerous examples are presented of the notation
Embley and Kurtz notation is formally defined in Appendix A, and numerous examples are provided
IBM notation is not formally defined.
Martin and Odell notation is defined in Chapter 9., Recommended Diagramming Standards, pp. 121-153.
Rumbaugh notation is defined on the inside front and back covers.
Shlaer/Mellor notation is formally defined throughout their books.
Wirfs-Brock notation is not formally defined, but numerous examples are presented.

In addition, definition of the notations semantics were also sought, as well as examples and heuristics for the construction of models.

Method Syntax Defined Semantics Defined Examples Provided Heuristics Presented
Berard - - Y Y
Booch Y Y Y Y
Coad and Yourdon Y Y Y Y
Colbert Y Y Y
Embley and Kurtz Y Y Y Y
IBM - - - -
Martin and Odell Y Y Y -
Rumbaugh Y Y Y Y
Shlaer and Mellor Y Y Y Y
Wirfs-Brock Y Y Y Y

Generally speaking, each notation (except Berard, Colbert, and IBM) provide explicit definition of the semantics of their notation, with examples and heuristics. In many cases fairly complete examples are given of the models required for a specific problem, or a variety of problems. Booch, Rumbaugh, and Embley and Kurtz, and Wirfs-Brock in particular stand out.

Does There Exist Explicit Logic For Transforming Models Into Other Models, Or Partially Creating A Model From Information Present In Another?

Each model within a notation should contribute to the overall understanding of the problem or design. Yet each model should not be entirely orthogonal to every other model in the notation. Each model should provide "clues" in assisting the software engineer in partially, or fully, completing, the other models. This interaction of models also assists in the verification and software quality assurance of the models. This "forward engineering" of models should also serve to increase productivity, since the software engineer can leverage information gathered from one model to construct others, without having to wait until all the models are completed and then "iterating" through the entire model set to determine if the set is complete and consistent.

While many of the methods provided checklists of guidelines for checking the consistency and completeness of the models, none of the methods reviewed provided detail on the forward transformation process except for Berard (as presented in (Richardson et al.)). In some methods this process was alluded to, but in no other method is it made explicit.

Does The Notation Provide A Partitioning Mechanism?

As the size of a system increases, some mechanism becomes required to limit the visibility of information to only those objects of interest at a particular time. Each methodology was reviewed to determine what mechanisms it provided.

Method Partitioning Mechanism
Berard Kits, Systems of Interacting Objects
Booch Subsystems, Processors
Coad and Yourdon Subjects
Colbert Scale of Objects( Systems are Objects)
Embley and Kurtz High-Level Views
IBM -
Martin and Odell -
Rumbaugh Subsystems
Shlaer and Mellor Subsystems
Wirfs-Brock Subsystems, Frameworks

Colbert mentions system partitioning on page 409 in his Language-Specific Software Architecture Specification, but no details are provided. Martin and Odell mention "realms" and "realm specifications" in their glossary, but no index references are provided to assist in determining how this relates to system partitioning.

Analysis

All the methodologies reviewed, except for IBM, have what appear to be fairly complete representation for most, if not all, object-oriented concepts. Specialization is absent from Colbert, probably due to his implementation focus on the Ada programming language, which currently does not support inheritance. As far as definition and completeness of notation is concerned, clustering would appear as follows:

Well-defined notations include Kurtz and Embley, Rumbaugh, Shlaer and Mellor, Booch, Coad and Yourdon, Wirfs-Brock. Methods requiring additional elaboration regarding their notations include Colbert, Martin and Odell, Berard, and IBM. This is not to indicate that the notations are not complete, simply that insufficient information was provided to assess the completeness. Berard does provide a fairly complete set of examples so that much of the notation can be deduced from the examples supplied.

Note that this ordering bears no reflection on how supportive the notation is of object-oriented development. The two sets of methods above simply reflect the completeness and expressiveness of the notation.

Process

The following section shows the process steps presented by each method, and then evaluates the process in terms of its completeness, consistency, and support for project control and management.

What Are The Process Steps For The Development Process Within The Methodology?

Berard

Booch

Coad and Yourdon

Colbert

Embley and Kurtz

IBM

Martin and Odell

Rumbaugh

Shlaer and Mellor

Wirfs-Brock

  1. Read and Understand the Specification
  2. As you follow the steps below, walk through various scenarios to explore possibilities. Record the results on design cards.
  3. Extract noun phrases from the specification and build a list.
  4. Look for nouns that may be hidden (for example, by the use of the passive voice), and add them to the list.
  5. Identify candidate classes from the noun phrases by applying the following guidelines:

  6. Identify candidates for abstract superclasses by grouping classes that share common attributes.
  7. Use categories to look for classes that may be missing.
  8. Write a short statement for the purpose of the class.
  9. Find responsibilities using the following guidelines:

  10. Assign responsibilities to classes using the following guidelines:

  11. Find additional responsibilities by looking for relationships between classes.

  12. Find and list collaborations by examining the responsibilities associated with classes.
  13. Identify additional collaborations.
  14. Discard classes if no classes collaborate with them, and they collaborate with no other classes.
  15. Build hierarchy graphs that illustrate the inheritance relationships between classes.
  16. Identify which classes are abstract and which are concrete.
  17. Draw Venn diagrams representing the responsibilities shared between classes.
  18. Construct class hierarchies.
  19. Construct the contracts defined by each class.
  20. Draw a complete collaborations graph of your system.
  21. Identify possible subsystems within your design.
  22. Simplify the collaborations between and within subsystems
  23. Construct the protocols for each class. Refine responsibilities into sets of signatures that maximize the usefulness of classes.
  24. Write a design specification for each class.
  25. Write a design specification for each subsystem.
  26. Write a design specification for each contract.

Walk-through

Note that the process definition varies dramatically from method to method. Most of the methods support each item above with additional text that describes the process, often providing checklists, tips and techniques, and guidelines in helping complete the task. Martin and Odell are the weakest in this category providing little information regarding their process, and no examples of how to execute the process.

What Deliverables Are Generated From The Development Process?

An attribute of any development process is the number and types of deliverables the process generates. Life-cycle documentation generally includes requirements specifications, design specifications, system and subsystem specifications, as well as test cases. Specifically, in object-oriented development, the requirement that object and classes also be specified surfaces. The deliverables for each method are evaluated using the following criteria:

The evaluation results in the following table:

Method Requirement Specification Design Specification Test Cases Object/Class Specification Subsystem Specification Totals
Berard 2 5 5 5 2 19
Booch 1 2 0 1 1 5
Coad and Yourdon 2 2 0 5 0 9
Colbert 2 2 0 2 2 8
Embley and Kurtz 5 1 0 1 1 8
IBM 5 3 0 5 0 13
Martin and Odell 0 0 0 0 0 0
Rumbaugh 2 2 0 5 0 9
Shlaer and Mellor 5 5 0 5 4 19
Wirfs-Brock 1 5 0 5 5 16

The lack of clear, well-constructed specifications is a significant weakness in many of the reviewed methods. Without such specifications, there can be no reuse except for the developed code (e.g., no analysis or design effort can be reused, since it is undocumented). In addition, testing is impacted severely since black-box testing can not be done without such specifications. Some methods consider such specifications as only necessary when "programming-in-the-large." (Rumbaugh, pp. 288-289), for instance, comments that documenting classes and methods is important when writing large, complex programs involving teams of programmers, seemingly implying it is less important for smaller, albeit just as critical, programs.

What Development Contexts Are Supported By The Methodology?

A development context establishes a set of constraints within the development must occur. Greenfield (i.e., new development) is the least constrained, while reengineering is the most constraining. "With Prototyping" is an indicator of whether the methodology explicitly discusses conducting prototyping within the method. "As Prototyping" indicates whether the methodology can deliver prototypes into production (i.e., successive iterations of the prototypes deliver the system). The wisdom is delivering prototypes into production is not dealt with in this section. "With Reuse" is used to indicate if the methodology explicitly addresses the incorporation of reuse products into its process, while a "Y" in the For Reuse column flags whether the methodology provides steps for delivering reusable products for other efforts.

Method Greenfield Reengineering With Prototype As Prototype With Reuse For Reuse Totals
Berard Y - Y - Y Y 4
Booch Y - Y - Y Y 4
Coad and Yourdon Y - Y Y Y - 4
Colbert Y - - - - - 1
Embley and Kurtz Y - - - - - 1
IBM Y - Y Y Y - 4
Martin and Odell Y - Y - Y - 3
Rumbaugh Y - - - Y - 2
Shlaer and Mellor Y - - - - - 1
Wirfs-Brock Y - Y Y Y Y 5

Shlaer and Mellor mention reuse, but only in the context of reusing processes. Embley and Kurtz do not even have an index entry for the term reuse. Martin and Odell make numerous points about reuse, but other than allowing for inheritance they provide no demonstration that their approach delivers, or utilizes, reusable components.

What Development Perspectives Are Supported?

Top down development and decomposition is strongly advocated by structured analysis and design, as well as Information Engineering, but reuse can only occur with a bottom-up, compositional approach. Object-oriented approaches should support both, allowing the top-down decomposing of a problem or solution in an object-oriented manner (focusing on objects, and not on functions or data), while allowing for the composition of objects into larger units, thus supporting reuse.

Method Top-Down Bottom-Up Both Indeterminate
Berard - - page 54 -
Booch - - page 195 -
Coad and Yourdon - - page 25 -
Colbert - - - indeterminate
Embley and Kurtz - - pp. 135-136, 143-148,159-165 -
IBM - - - pp. 13-14 (indeterminate)
Martin and Odell - - - pp. 444-445 (indeterminate)
Rumbaugh - - - indeterminate
Shlaer and Mellor - - - indeterminate
Wirfs-Brock - - pp. 235-236 -

For a number of the methods evaluated it was not possible to determine whether the methodology supported a bottom-up perspective. All supported a top-down development approach.

What Aspects Of The Life-Cycle Are Covered By The Approach?

Life cycle coverage provides an indication of the completeness of the methodology. A methodology that covers all aspects of the system development life-cycle offers an attractive solution to the organization in that the methodology itself ensures completeness and consistency. If an organization, for example, is required or decides to "mix and match" one methodology's analysis approach with another methodology's design approach, the organization must take responsibility for the consistency and completeness of transition from one life cycle phase to another. Such "mix and match" strategies introduce an element of risk into the approach.

Booch (Booch, page 201) notes, for example:

Therefore, more complete life cycle coverage is preferable to more limited life cycle coverage. In the following table, the values presented reflect the following:

Method Enterprise Modeling Domain Analysis Requirement Analysis Design Implement Test Total
Berard 0 4 4 5 5 5 23
Booch 0 4 2 5 4 0 15
Coad and Yourdon 0 1 5 5 3 3 17
Colbert 0 0 4 4 3 0 11
Embley and Kurtz 0 0 5 1 0 0 6
IBM 0 0 5 5 5 2 17
Martin and Odell 1 0 3 5 0 0 9
Rumbaugh 0 0 5 5 3 2 15
Shlaer and Mellor 0 0 5 5 1 0 11
Wirfs-Brock 0 0 3 5 4 3 15

Are The Process Steps Well-Defined?

Each methodology should describe a process which, if followed, should yield an appropriate set of products (e.g., analysis products, design products, code, and test cases). The clarity of a process simplifies the execution and introduction of the process into a development organization. A well-defined process has the following attributes:

While the above may appear overly rigorous, they provide a comparison mechanism for ascertaining the completeness of each methodology's process definition.

Method Step Defined Inputs Outputs Roles SQA Totals
Berard Y Y Y Y Y 5
Booch Y - Y Y Y 4
Coad and Yourdon Y - Y Y Y 4
Colbert Y - Y Y Y 4
Embley and Kurtz Y - Y - - 2
IBM Y Y Y Y - 4
Martin and Odell Y - - Y - 2
Rumbaugh Y - Y Y Y 4
Shlaer and Mellor Y - Y - - 2
Wirfs-Brock Y - Y - Y 3

The above table does not reflect the depth each topic is discussed. For instance, the process steps defined in (Berard(a)) exceed 120 pages. Most of the methods devote significantly less to the process.

Are Project Development Roles Clearly Defined?

The responsibilities involved in an object-oriented development effort require some delineation. In Information Engineering, for example, data modelers are responsible for identifying and defining data and relationships prior to physical database design. Object-oriented methodologies require similar definition in order to understand the impact of adopting a particular method. Ideally, each required role should be elaborated with a summary job description, a list and explanation of duties and responsibilities, and the requisite skills and education specified.

Method Analyst Designer Architect Tester Manager
Berard(a) 3-48 to 3-53 3-54 to 3-58 3-76 to 3-78 3-79 to 3-83 3-59 to 3-71
Booch - page 207 page 207 - -
Coad and Yourdon - - - - -
Colbert - - - - -
Embley and Kurtz - - - - -
IBM - - - - -
Martin and Odell - - - - page 443
Rumbaugh - - - - -
Shlaer and Mellor - - - - -
Wirfs-Brock - - - - -

Only Berard spends any significant text in describing the roles and responsibilities associated with object-oriented development. Martin and Odell cite roles such as "workshop leader," "scribe," "rapid prototyper," and "modeling expert." These roles seem to be carryover from Martin's Rapid Application Development (RAD) approach, and are not additionally elaborated for their need or purpose in object-oriented development. In point of fact, Martin states "The modeling expert is typically part of the data-administration staff." This seems to imply that little organization change is required in adopting OO technology. Booch, on the other hand, notes (Booch, page 207):

Generally speaking, this area of the methodologies needs significant expansion. Only (Berard(a)) deals with this subject at length, devoting 45 pages to role descriptions.

Are There Heuristics Available For The Process Steps?

Heuristics provide tips to assist the analyst and designer in executing the process steps. In some cases these heuristics are simple and obvious, while others are less obvious. The availability of a large set of heuristics simplifies process execution. The following table represents a subject assessment of the number of heuristics presented by the steps of identifying classes, operations, subsystems, and states, as well as placing operations onto classes and locating states. These steps are not exhaustive, but serve as an indicator to the degree of support the method provides for heuristics. A "1" indicates few if any heuristics, while a "3" indicates five or more heuristics.

Method Identifying Classes Identifying Operations Placing Operations Identifying Subsystems Identifying States Totals
Berard 1 1 1 3 1 7
Booch 3 3 3 3 3 15
Coad and Yourdon 3 3 0 0 1 7
Colbert 1 1 1 1 1 5
Embley and Kurtz 3 3 1 1 3 11
IBM 1 1 - - - 2
Martin and Odell 3 3 1 - 3 10
Rumbaugh 3 3 1 2 3 12
Shlaer and Mellor 3 1 1 3 3 11
Wirfs-Brock 3 1 1 3 - 8

Is It Possible To Locate The Origin Of Decisions Made During Development?

Being able to trace analysis, design, and implementation decisions is mandatory for conducting software quality assurance on any significant development effort. Each methodology was assessed to determine whether it provides some mechanism, or discussion, on tracing decisions through the development life cycle.

Method Discussion Mechanism
Berard pp. 196, 213 pp. 206-207
Booch - -
Coad and Yourdon - page 197
Colbert - -
Embley and Kurtz - -
IBM - -
Martin and Odell - -
Rumbaugh page 251-252 -
Shlaer and Mellor - -
Wirfs-Brock - -

Berard is the only method assessed that provides specific traceability mechanisms. Specifically (Berard, pp. 206-207) mentions "short maps" and "object and class specification precursors." "A short map resembles an index, i.e., it is simply a list of the candidate objects which were found in the requirements information ..." (Berard, page 206). Coad and Yourdon place "traceabilityCodes" (Coad and Yourdon, page 197) on their Class-&-Object specification template, but no discussion is provided to the purpose or use of the codes.

As an aside, (Rumbaugh, page 252) notes that "Traceability from an element in the original analysis to the corresponding element in the design document should be straightforward since the design document is an evolution of the analysis model and retains the same names." (Coad and Yourdon(a), page 38) states the same line of reasoning when stating "Put OOA results directly into the PDC." (PDC stands for the Problem Domain Component of their OOD approach, one of four components.) Berard does not adhere to this direct mapping of "analysis" objects into design. "OORA will have identified some objects which are necessary for setting the context for the application, but will not be considered during the design process. We generally refer to these objects as "analysis objects." (Berard, page 228)

Does The Process Provide For Verification?

A defined process should contain rules to allow the verifying of correctness for developed products. For example, the different models constructed may present information that allows for the verification of other models. Or an object and class specification may be verifiable against the models used in its construction. Without such rules, verification of the specifications and other products is not possible.

Method Verification Rules
Berard Provided
Booch -
Coad and Yourdon Provided
Colbert Provided
Embley and Kurtz Provided
IBM -
Martin and Odell -
Rumbaugh Provided
Shlaer and Mellor Provided
Wirfs-Brock -

Please note that while Wirfs-Brock does not provide specifics on verifying life-cycle products, the method is the only one to specifically discuss walkthroughs of specifications.

Does The Process Provide For Validation?

Each methodology should provide some form that allows independent validation of the development products with the customer, independent of the methodology's notation itself. Executable models, prototypes, and scenario flows are each sample approaches.

Method Validation Approach
Berard Prototype
Booch Prototype
Coad and Yourdon Prototype
Colbert See below
Embley and Kurtz -
IBM Prototype
Martin and Odell Prototype
Rumbaugh Event Flows
Shlaer and Mellor -
Wirfs-Brock Prototype

Colbert on page 407 discusses "demonstrating" the behavior of a system in order to provide validation. It is unclear here how exactly this demonstration is accomplished, but validation is mentioned. None of the methodologies reviewed clearly outlines how validation is to occur. This area is in significant need of elaboration by all the reviewed methodologies.

What Development Life-Cycle Best Describes The Methodology?

Understanding the development life-cycle presented by the methodology is a necessary requirement for project planning. For example, a project whose selected methodology is oriented toward an iterative, prototyping life cycle that is conducted using a waterfall, step-by-step, rigorously-sequential is at high risk of yielding unexpected results (i.e., failing).

Method Sequential Iterative Recursive
Berard - Y Y
Booch - Y -
Coad and Yourdon - Y -
Colbert - Y -
Embley and Kurtz - Y -
IBM - Y -
Martin and Odell - Y -
Rumbaugh - Y -
Shlaer and Mellor - Y -
Wirfs-Brock - Y -

None of the reviewed methodologies follows a sequential (i.e., waterfall) development cycle. Sequential life cycles are not prohibited, but in most methods are not recommended. (Booch, pp. 188-189) uses the term "Round-Trip Gestalt Design" to discuss the iterative nature of his development approach. All the methods reviewed speak of iterative development. (Berard, pp. 49-60) spends an entire chapter on "The Recursive/Parallel Life-Cycle", an iterative approach that is also recursive (i.e., the products from one iteration serve as inputs to the succeeding iteration).

Are Quality Assurance Guidelines Presented?

Quality assurance guidelines provide those responsible for software quality assurance some initial set of information in constructing project-specific or organization-specific quality policies and procedures. Without such guidelines quality will be assessed in an ad-hoc manner, with no visibility to management as to the "true" status of the developed product. While many of the methods provide guidelines to assist in quality assuring software products, these guidelines are insufficient for formal quality assurance.

Generally speaking, the area of software quality assurance is in need of significant elaboration by each of the methodologies. While heuristics are available in most of the methods reviewed, specific criteria to assess the quality of object-oriented products is minimal.

As Berard (Berard, page 258) notes:

Are Estimating Guidelines Presented?

The availability of cost estimating guidelines is essential for project management to effectively apply an object-oriented method. Without such guidelines project estimating can only be approached in an ad-hoc manner, without specific targets or goals of the effort. The availability of such guidelines simplifies the project planning effort and provides some targets and goals.

None of the methodologies reviewed provide any support for estimating the costs, schedule, number of objects required, etc. of the developed software. This area is in need of significant elaboration by all the methodologies.

What Percentage Of Time Over A Project's Life, Is Spent In Each Life Cycle Phase?

This question attempts to ascertain whether the life cycle presented by the methodology differs dramatically from the development life cycle of other approaches. Many conventional development efforts exhibit a 40-20-40 distribution between analysis and design, coding, and testing and integration.

Little information is presented specifically regarding the life cycle efforts involved in each of the methods. Only Booch provides specifics in a graphic on page 207. Extrapolated from the graphic are the following percentages:

Anecdotal information provides some insight. Rumbaugh discusses an object diagram compiler developed using Rumbaugh's OMT.

Berard (Richardson et al., pp. v-vi) presents the following anecdote concerning the developing of a complexity measures tool in 1984, using his OOD approach as defined then:

Booch notes "It is not unusual for a team of roughly 30-40 developers to produce more than a million lines of production-quality code in a single year." (Booch, page 208)

While comparing such isolated fragments of information is dangerous, it is interesting to note that the Rumbaugh method yielded a productivity of 4333 lines of code per programmer month, Berard 2777 lines of code per programmer month, and Booch 2083 lines of code per programmer month. The Berard and Booch anecdotes discuss production-quality software; it is undetermined whether the Rumbaugh anecdote reflects a similar development effort.

Analysis

Process definition varies dramatically from method to method. Rumbaugh, Shlaer and Mellor, Wirfs-Brock, Berard, and IBM each have relatively well-elaborated processes. Colbert and Embley and Kurtz are less defined, but still relatively clear. Martin and Odell presents little in terms of a process definition. There is little to indicate how and where each model is to be developed during the process. In addition, Martin and Odell seem to be relying on I-CASE (integrated computer aided software engineering) technology to assist in the effort. Such tool support is not demonstrated to be adequate to support the object-oriented development effort.

Pragmatics

What Resources Are Available To Support The Method?

The following table identifies resources available to support the methodology. These resources include on-site or public training, whether training is available from a single or multiple sources, the availability of training video tapes, the number of texts available that deal with the methodology, and whether consulting services are available. In addition, reusable component libraries available that are constructed using the methodology are identified.

Method Training Sources Video Texts Components
Berard Both 2 - 3 1
Booch Both At least 2 Y 1 1
Coad and Yourdon Both 1 Y 2 -
Colbert On-Site 1 - - -
Embley and Kurtz - - - 1 -
IBM - - - 5 -
Martin and Odell Both 1 Y 1 -
Rumbaugh Both 1 Y 1 -
Shlaer and Mellor Both 1 - 2 -
Wirfs-Brock Both At least 2 - 1 -

The depth of training was not assessed. Some of the methodologies provide training that covers analysis and design in three days. Berard presents the most comprehensive curriculum, with five day courses in general object-oriented software engineering, domain analysis, requirements analysis, design, and testing of object-oriented software, as well as a three day course in object-oriented project management. No other methodology vendor has near this depth of object-oriented training.

What Scope Of Effort Is The Method Suited For?

"Programming-in-the-large" is recognized as a significantly more complex activity than programming smaller applications. A methodology's support for "scaling" to large and "colossal" systems development requires mechanisms for clustering, layering, and leveling products (e.g., analysis, design, and code products). An effort was made to assess the scale of development supported by each methodology, and whether the method could be conducted only formally, or informally, or both. In addition, the formality of the method was assessed as to whether the method could be conducted informally (as in an exploratory fashion), or whether a more formal conducting was required. This evaluation results in the following table.

Method Small Medium Large Formal Informal
Berard Y Y Y Y -
Booch Y Y Y Y -
Coad and Yourdon Y Y - Y Y
Colbert Y Y Y Y -
Embley and Kurtz Y Y Y Y -
IBM Y Y - Y Y
Martin and Odell - - - - -
Rumbaugh Y Y Y Y -
Shlaer and Mellor Y Y Y Y -
Wirfs-Brock Y Y Y Y Y

Generally speaking, all the methods reviewed can handle small efforts (<50 classes) and medium size efforts (<100-150 classes). Larger efforts require the methodology have some mechanism for scoping visibility and defining interfaces at a level higher than that of class. IBM, Martin and Odell, and Coad and Yourdon do not provide such support. Most of the methods reviewed require formality in their execution. Coad and Yourdon, IBM, and Wirfs-Brock appear to support informal development, if desired.

What Is The Required Training For Someone To Fully Exploit The Method, (Independent Of Programming Language Training)?

The following is a subjective appraisal of each method's complexity. This appraisal is based on the number of models present in each notation, the amount of expertise required to use the method, the number of steps present in each process, and the clarity of the approach. Based on these factors, an estimate of the required training needed to effectively use the method is made. Highly complex methods require the most training (i.e., > 6 weeks), medium complexity methods will require 3-6 weeks worth of training, and low complexity methods will require < 3 weeks of training. In all cases a period of time will be required (3-6 months) before staff becomes comfortable with the method.

Method Complexity
Berard Medium
Booch Medium
Coad and Yourdon Low
Colbert Medium
Embley and Kurtz High
IBM Low
Martin and Odell High
Rumbaugh Medium
Shlaer and Mellor High
Wirfs-Brock Medium

What Languages Has The Methodology Been Used With?

Language independence is a desirable attribute of any methodology in that it provides for portability of analysis and design products across languages. The more "language-independent" a particular methodology is, the greater flexibility implementers have in their selection of implementation languages.

Method Ada Eiffel Smalltalk C++ CLOS Total
Berard Y Y Y Y Y 5
Booch Y Y Y Y Y 5
Coad and Yourdon Y - Y Y - 3
Colbert Y - - - - 1
Embley and Kurtz - - - - - 0
IBM - - Y - - 1
Martin and Odell - - - - - 0
Rumbaugh Y Y Y Y - 4
Shlaer and Mellor Y - - Y - 2
Wirfs-Brock - - Y - - 1

In Richardson, et. al, the Berard method is used to completely solve a sample design problem into C++ and Smalltalk. Booch provides significant code fragments for the design of five problems in five different languages (Smalltalk, Object Pascal, C++, CLOS, Ada). While each problem is not completely solved, the examples are diverse and the mapping to the languages is well-defined.

Is The Method Targeted At A Specific Type Of Software Domain?

(Rumbaugh, pp. 211-212) identifies a spectrum of software domains, including but not limited to:

While these classifications are useful, the criteria selected compares information systems, real-time embedded systems, and component libraries (e.g., class libraries and application frameworks) as a more discrete criteria of comparison. Examples and anecdotes presented in each methodology were reviewed to identify support for each software domain.

Method MIS Real-Time Components
Berard Y Y Y
Booch Y Y Y
Coad and Yourdon Y ? ?
Colbert ? Y ?
Embley and Kurtz Y Y ?
IBM Y N ?
Martin and Odell Y N ?
Rumbaugh Y Y ?
Shlaer and Mellor Y Y ?
Wirfs-Brock Y N ?

Both Berard and Booch have delivered reusable component libraries (EVB's GRACE product and Rational's Booch Components for C++ and Ada, respectively) based on their methodologies. It is undetermined as to whether or not the other methodologies surveyed are capable of supporting such construction. IBM, Martin and Odell, and Wirfs-Brock have no support for timing, therefore real-time development using these approach is unlikely. Coad and Yourdon discusses timing and shows examples of a real-time air traffic control system, but real-time issues such as thread of control and concurrency are not addressed. This omissions make the use of Coad and Yourdon for real-time development unlikely.

What Automated Tools Are Available That Support The Methodology?

The following table presents available object-oriented CASE tools.

Company Tool Name Platforms Supported Description and Methodologies Supported
Associative Design Technology, 508-366-9166 Ptech Unix (DECStation, RS6000, Silicon Graphics) Martin and Odell
Andersen Consulting, Chicago, IL Foundation MVS, PC-DOS, OS/2, VAX/VMS, GCOS Object-oriented full life-cycle tools
Bachman Information Systems, Burlington, MA, 800-222-4626 Bachman Data Analyst PC-DOS, OS/2 Modeling and analysis with OO support
Cadre Technologies, Providence, RI, 401-351-CASE Teamwork VAX/VMS, Unix, OS/2, PC-DOS CASE toolset with object-oriented capabilities Shlaer/Mellor, HOOD
Chen & Associates, Inc., Baton Rouge, LA, 504-928-5765 OBJECT-DESIGNER PC-DOS Graphical object-oriented design tool
Excel Software, Marshalltown, IA, 515-752-5359 MacAnalyst and MacDesigner Macintosh Object-oriented analysis
GE Advanced Concepts Center, King of Prussia, PA, 215-992-6200 or 800-438-7246 OMTool Unix Object-oriented analysis and design Rumbaugh
Hamilton Technologies, Cambridge, MA 001 VAX/VMS, Unix Object-oriented, full life cycle CASE
Hewlett Packard, Cupertino, CA, 800-752-0900 ext. 2707 or 303-229-2255 HP C++/Softbench HP, Apollo CASE tool integration, C/C++ development
Iconix Software Engineering, Santa Monica, CA, 310-458-0092 Iconix Power Tools Macintosh Multiuser, OO development toolset Rumbaugh, Coad/Yourdon, and Booch
Intellicorp, 415-965-5700 OMW WIndows and Unix Martin and Odell
Interactive Development Environments, San Francisco, CA, 800-888-4331 Software Through Pictures VAX/VMS, Unix Object-oriented structured design with multi-user OO data dictionary Wasserman's OOSD
Mark V Software, Encino, CA, 818-995-7671 ObjectMaker MS-Windows, Unix, Macintosh Object-oriented analysis and design Berard, Booch, Coad/Yourdon, Colbert, Rumbaugh, and others
Object International, Inc., Austin, TX, 512-795-0202 or 800-926-9306 OOATool Unix, Macintosh, MS-Windows Object-oriented analysis Coad/Yourdon
Palladio Software, Inc., Brookfield, WI, 1-800-437-0019 or 414-789-5253 Object System/Designer MS-Windows Object-oriented design Booch
Popkin Software, NY, 212-571-3434 System Architect MS-Windows, OS/2 Object-oriented design Booch, Coad/Yourdon, Shlaer/Mellor
Protosoft, Houston, TX, 713-480-3233 Paradigm Plus Windows, Unix, OS/2 CASE toolset supporting Berard (EVB), Booch, Coad/Yourdon, and others
Rational, Santa Clara, CA, 408-496-3700 Rose Unix, AIX Object-oriented analysis and design Booch
Semaphore, North Andover, MA, 508-794-3366 or 800-937-8080 ATRIOM MS-Windows Object-oriented analysis and design Booch, Coad/Yourdon, Rumbaugh Shlaer/Mellor
StructSoft, Bellevue, WA, 206-644-9834 TurboCase Macintosh Object-oriented analysis, structured design Wirfs-Brock
TGS Systems, Halifax, Nova Scotia, 902-455-4446 Prograph Macintosh OO visual programming environment
Roman Zielinski Method & SystemUtveckling, Norsborg, Sweden OOTher Windows OO Documentation Tool Coad/Yourdon

A summary of the number of tools available, by method, is presented below.

Method Number of Tools Available
Berard 2
Booch 7
Coad and Yourdon 7
Colbert 1
Embley and Kurtz -
IBM -
Martin and Odell 2
Rumbaugh 4
Shlaer and Mellor 3
Wirfs-Brock 1

The tools depicted mentioned above have not been assessed for their completeness in implementing a particular method. For instance, both Rational's Rose and Palladio's Object System/Designer are known not to yet support Booch's subsystem and processor notation, and the tools supporting Berard support his methodology as of 1989.

Analysis

Of all the methods reviewed, each (except IBM) has available training that covers the use and application of the method. In terms of general pragmatics, Booch, Coad and Yourdon, Rumbaugh, and Shlaer/Mellor are each well-supported, with a significant number of tools. Berard is unique in providing some training that is independent of his method, e.g., object-oriented project management and object-oriented software engineering. Embley and Kurtz and IBM do not have any commercially available tools supporting their methods.

Support for Software Engineering Principles and Goals

Up until this point each methodology has largely been reviewed from the "inside-out", i.e., the method has been appraised in its own terms for support of its own concepts or those common to other object-oriented methods. In this section we look at criteria applied to software engineering that are independent of object-oriented technology. While many attributes may be considered, we have selected reusability, extensibility (including modifiability and maintainability), testability, and conceptual integrity for consideration. The ease with which object-oriented development supports reuse and extension is a much-touted benefit of the object-oriented paradigm, and hence their selection. Much less evaluated are the testability of object-oriented applications, or the conceptual integrity of object-oriented software products. These factors were selected to see how each method provided support, and to what degree.

Reusability

Reusability is defined by the IEEE Standard Glossary of Terms as "The extent to which a module can be used in multiple applications." Reviewing each of the methodologies provides specific insights into the author's view of reuse. Some of the methodologies only cite reuse at the code-level. The IBM method is a case in point. Other methodologies cite reuse for only those components discovered in the problem domain (i.e., there are no "generally reusable" classes).

For example, (Coad and Yourdon, page 12)'s discussion of reuse focuses exclusively on the problem domain component, as stated in "More effective analysis requires the use of problem domain constructs, both for present reuse and future reuse." Only one component of their method, that of the Problem Domain, is singled out for potential reuse.

Rumbaugh follows a similar vein. "Reuse a module from a previous design if possible, but avoid forcing a fit. Reuse is easiest when part of the problem domain matches a previous problem. If the new problem is similar to a previous problem but different, the original design may have to be extended to encompass both problems. Use your judgment about whether this is better than building a new design." (Rumbaugh, page 169)

In addition, Rumbaugh discounts the utility of defining classes in isolation for general reuse. "Planning for future reuse takes more foresight and represents an investment. It is unlikely that a class in isolation will be used for multiple projects. Programmers are more likely to reuse carefully thought out subsystems, such as abstract data types, graphics packages, and numerical analysis libraries." (Rumbaugh, page 282).

From a process perspective, Booch (pp. 143-143) and Berard (pp. 182-192) provide specific guidelines for the construction of reusable components. Both methods also discuss a project-independent role, that of the object-oriented domain analyst, whose organization is responsible for the identification, development, marketing, and demonstration of reusable components in conjunction with the projects.

Method Reuse Discussed Problem Domain Specific? With Reuse For Reuse
Berard Y - Y Y
Booch Y - Y Y
Coad and Yourdon Y Y Y -
Colbert - - - -
Embley and Kurtz - - - -
IBM Y - Y -
Martin and Odell Y Y Y -
Rumbaugh Y Y Y -
Shlaer and Mellor - - - -
Wirfs-Brock Y - Y -

(Shlaer and Mellor(a), pp. 123-124) do discuss reuse, but only in terms of reusing processes, and not objects or classes.

Extensibility, Modifiability, and Maintainability

Extensibility is an attribute of something that allows it to last or continue, or to be expanded in range or scope. Modifiability may be defined as the extent to which the something itself facilitates the incorporation of changes, once the nature of the desired change has been determined. Maintainability may be defined as a measure of the ease with which changes necessitated by new requirements, error corrections, new environments, and enhancements, may be introduced into a product. Generally speaking, many of the method's reviewed cite inheritance and the construction of well-defined interfaces as key ingredients in supporting these concepts. For example, (Rumbaugh, page 243) cites "The creation of abstract superclasses improves the extensibility of a software product."

Method Concepts Discussed Process Described Heuristics Provided Examples Provided
Berard - - - -
Booch page 206 - - page 279
Coad and Yourdon - - - -
Colbert - - - -
Embley and Kurtz - - - -
IBM - - - -
Martin and Odell page 3 - - -
Rumbaugh page 243 pp. 285-286 page 286 -
Shlaer and Mellor - - - -
Wirfs-Brock page 2, 8 - - -

Rumbaugh provides the most specifics concerning extensibility and modifiability, while Booch shows specific examples. Booch is the only method clearly demonstrates that the developed software is modifiable and easy to enhance. While, for example, (Rumbaugh, page 144) professes a commonly expressed claim that "... an object-oriented approach produces a clean, well-understood design that is easier to test, maintain, and extend than non-object-oriented designs because the object classes provide a natural unit of modularity.", no specifics are provided to substantiate this claim.

Testability

Testability measures the degree of ease with which a software product can be examined with the intention of finding errors. This requires the method provide some means of traceability from one step in the life cycle to another, or from one specification to another, as well as specific specifications that may be used for black-box testing. Only Berard deals with testing to any degree and provides specific mechanisms for traceability. Therefore, the testability of the other methods can not be assessed objectively. Most of the methods reviewed imply that testing procedures are not significantly impacted by object-oriented designs and implementations. Yet (Berard, pp. 257-284) expounds at length on how encapsulation and information hiding, as well as other attributes of object-oriented software, significantly impacts the conducting of testing.

Conceptual Integrity

Conceptual integrity might be defined as "being true to a concept," or more simply as "being consistent". The more consistent the approach used in the development of software, typically the more reliable, more maintainable, and more usable the software becomes. Conceptual integrity problems noted with the reviewed methodologies include:

Introduction Of New Terms

The introduction of terms not commonly shared with other methodologies can create a number of problems. For instance, a "method-speak", or jargon-riddled method can be difficult to learn, difficult to teach, and create significant problems when dealing with those not versed with the method. Term introduction manifests itself for a number of reasons, three of which are detailed below:

  1. Terms are sometimes introduced into a method to reuse knowledge from prior methods. This is sometimes valid, but often times is not. This is especially true when the prior knowledge being reused has nothing to do with object-oriented technology. For instance, a discussion of "normalizing objects" would indicate an inappropriate blending of relational database design experience and object-oriented concepts.

  2. In other instances terms are introduced because a particular concept is not adequately addressed by any existing terms in the technology. Booch's "subsystems", Berard's "kits" and "systems of interacting objects", and Wirfs-Brock "frameworks" are all elaborations of the theme that there are things greater in size than "classes," and object-oriented methods must address these larger, object-oriented "things."

  3. The author may introduce a term that simply "aliases" an equivalent, or almost equivalent, term in the object-oriented literature. Often this is an indication of a lack of understanding and knowledge about available object-oriented research and literature. In some cases the term simply adds some jargon to the method. But over time the term may take on a life of its own, diverging from its original synonym. This may create longer term problems in people attempting to use method, or integrating the method with other approaches.

  4. The author may redefine a term already in common use. This practice is extremely dangerous, and almost always indicates a lack of knowledge about available object-oriented research.

Method Introduced Term Carry Over New Alias Redefined
Berard kit - Y - -
- system of interacting objects - Y - -
Booch subsystem - Y - -
Coad and Yourdon subject - - Y -
- service - - Y -
Colbert - - - - -
Embley and Kurtz action Y - - -
IBM - - - - -
Martin and Odell object type - - Y -
- conception - Y - -
- function Y - - -
- persistent object - - - Y
- realm specification - - Y -
- state - - - Y
- type partition - - Y -
Rumbaugh - - - - -
Shlaer and Mellor - - - - -
Wirfs-Brock collaboration - - Y -
- contract - - Y -
- framework - Y - -
- responsibility - - Y -

Berard introduces the concepts of "kits" and "systems of interacting objects." In other methods these are both referred to as "frameworks" (Wirfs-Brock) and "subsystems" (Booch, Rumbaugh, Shlaer/Mellor, Wirfs-Brock) respectively.

Coad and Yourdon introduce the term Services to represent what other methods term "operations".

The term "subject" is introduced as a partitioning mechanism, which some other methods may term "domain". (Coad and Yourdon, page 106) define Subject as "a mechanism for guiding a reader (analyst, problem domain expert, manager, client) through a large, complex model." Other methods use the term "domain", but since there is no rigor associated with the creation of subjects, and normally there is some rigor in the specification of domains, the term domain is not equivalent.

Embley and Kurtz use the term "actions" to represent operations.

Martin and Odell introduces a number of new terms, or variants of terms in common use. These include:

Wirfs-Brock introduces the terms collaboration, responsibility, contract, and frameworks.

Viewpoint

Determining the viewpoint is a little like conducting a psychological profile on a methodology to determine the attitude of the methodologist. If conceptual integrity is indeed important, than the methodology should be rigorously consistent with regard to its approach to conducting object-oriented development.

With regard to definitions, Berard is the most rigorously consistent, followed by Booch, Colbert, and Wirfs-Brock. Coad and Yourdon, and IBM cluster closely together, followed by Rumbaugh, Shlaer and Mellor, Martin and Odell, and Embley and Kurtz.

The first four methods focus on objects almost exclusively, looking at external views, then internal views. The issues of interface, general reuse, and minimized coupling are of high concern. Relationships and associations, if even mentioned, are secondary and subjugated to control by larger, object-oriented items such as subsystems, frameworks, systems of interacting objects, or kits. System decomposition occurs in an object-oriented manner using domain analysis, or an approach that decomposes objects into other objects. Booch and Berard also provide for control structures that are not assigned to a particular class. Booch's "free subprograms" and Berard's "unencapsulated composite operations" both provide for increased reusability by decoupling objects from the applications the objects are utilized in.

The next two also focus on objects, but relations and associations are promoted in importance, coupling is increased, and cohesion is decreased. System control is assigned to classes, resulting in a significant increase in the coupling of objects to the application they are used within. System decomposition occurs in a non-object-oriented manner. Coad and Yourdon, for example, discuss decomposition about the problem domain, the user interface, data management, and tasks. This viewpoint is further detailed in the IBM approach. Such decomposition is more functional in nature, and follows a more classical than object-oriented approach.

The last four methods present extensions to entity-relationship, state-modeling, and information engineering as solutions to object-oriented development. In each of these methods relationships, associations, and states are promoted to same degree of importance as objects. In addition, decomposition follows along more functional than object-oriented lines. For example, (Rumbaugh, page 199) states "A subsystem is usually identified by the services it provides. A service is a group of related functions that share some common purpose, such as I/O processing, drawing pictures, or performing arithmetic." This functional orientation leads to significant object coupling and reduced reusability. As an illustration, the following class specification is presented on page 290 of the Rumbaugh text:

Class Description
Class Name: Circle
Version: 1.0
Description: Ellipse whose major and minor axes are equal
Super Classes: Ellipse
Features:
	Public Attributes:
		center: Point - location of its center
		radius: Real - its radius
	Public Methods:
		draw (Window) - draws a circle in the window
		intersectLine (Line): Set of Points - finds the
			intersection of a line and a circle, returns set 0-2
							
			points
		area(): Real - calculates area of circle
		perimeter(): Real - calculates circumference of circle
	Private Methods: none

The above specification indicates that instances of the Class Circle are aware of Windows and Lines. This "awareness" indicates that circles are coupled to lines and windows, probably within the context of a drawing application. This coupling decreases the reusability of Class Circle by embedding some application-specific knowledge into the class itself.

Analysis

With regards to support for software engineering principles and goals, only Berard and Booch stand out. In general, the issues of testability, traceability, reusability, and conceptual integrity are only lightly addressed, if addressed at all, by the other methods reviewed.

Marketability

The marketability of something is a measure of how easily it can be sold, introduced, and adopted by an organization. Marketing an object-oriented methodology to an organization is a formidable task, largely because different audiences are concerned with different attributes of a methodology. With regards to a methodology, such audiences and their perspectives include:

By evaluating each of these audience's concerns, the initiator of technology adoption can prepare a strategy to evaluate and assess the appropriateness of a new method for their organization. In addition, the initiator must be aware that generally speaking, more evolutionary approaches are adopted more successfully than revolutionary approaches. The reasons for this are obvious. Yet in many cases the benefits from such incremental change is less than for more radical change. In effect, with radical change can come high benefits and high risk. Less radical change brings less risk and less benefit.

The marketability, and eventual selection, of any methodology for an organization is very dependent on the current status and direction of the organization with regards to software. Some organizations may be interested in increased productivity, or increased quality, or reduced maintenance costs, or improved portability, or some combination of these, and possibly other, factors. Therefore, the purpose of the following questions is to illustrate how candidate methods can be selected based on the content of the questions and the results of this comparison.

The conclusions of each of the prior sections of this section resulted in the following clusters.

From the Concepts Analysis: Generally speaking, their appears to be a continuum of "object-orientedness" of the reviewed methods. Booch, Berard, Colbert, and Wirfs-Brock seem to be the most object-oriented, with their strict emphasis on objects, and downplaying of associations and relationships. Coad and Yourdon and IBM seem to be next, with accommodations for data (attributes and instance variables). Rumbaugh, Embley and Kurtz, and Shlaer and Mellor cluster next, with a strong emphasis on associations and relationships almost at a level making these items peers of objects. Martin and Odell are the least object-oriented, seemingly presenting slight extensions to information engineering with a very heavy behavioral orientation.

From the Notations Analysis: Well-defined notations include Kurtz and Embley, Rumbaugh, Shlaer and Mellor, Booch, Coad and Yourdon, Wirfs-Brock. Methods requiring additional elaboration regarding their notations include Colbert, Martin and Odell, Berard, and IBM. This is not to indicate that the notations are not complete, simply that insufficient information was provided to assess the completeness. Berard does provide a fairly complete set of examples so that much of the notation can be deduced from the examples supplied.

From the Process Analysis: Process definition varies dramatically from method to method. Rumbaugh, Shlaer and Mellor, Wirfs-Brock, Berard, and IBM each have relatively well-elaborated processes. Colbert and Embley and Kurtz are less defined, but still relatively clear. Martin and Odell presents little in terms of a process definition. There is little to indicate how and where each model is to be developed during the process. In addition, Martin and Odell seem to be relying on I-CASE (integrated computer aided software engineering) technology to assist in the effort. Such tool support is not demonstrated to be adequate to support the object-oriented development effort.

From the Pragmatics Analysis: In terms of general pragmatics, Booch, Coad and Yourdon, Rumbaugh, and Shlaer/Mellor are each well-supported, with a significant number of tools. The greatest depth of object-oriented training is from Berard. Embley and Kurtz and IBM do not have any commercially available tools supporting their methods.

From the Software Engineering Support Analysis: With regards to support for software engineering principles and goals, only Berard and Booch stand out. In general, the issues of testability, traceability, reusability, and conceptual integrity are only lightly addressed, if addressed at all, by the other methods reviewed.

Based on the above analyses, the following questions are postulated, and answers proposed.

The above sample questions should serve to illustrate how to apply the results of this section in identifying methods of interest to a particular organization, development effort. Again, it must be reiterated, that these results simply start the research effort, and are not a final analysis. Each method is constantly evolving, and the clusters identified in this section are subject to change over time. In addition, new methods are being published almost monthly. These too may need to be considered before a final selection is made.

A word of caution: Selling management on object-oriented technology is identical to selling management on any new technology. Generally speaking, management must understand that the transition to any "new" technology is difficult. The degree of difficulty the organization will have in adopting new technology is typically directly proportional to the organization's experience level. Specifically, the more experience the organization has in "traditional" software engineering approaches, the more difficult it will be (usually) for the organization to make the transition to object-oriented software engineering.

As a final note, Martyn Ould identified his "Fourteen Dilemmas of Software Engineering" (Ould, 1990). This tongue-in-cheek appraisal of the resistance to change of organizations is a useful checklist in preparing arguments for why, or why not, a methodology should be selected. At the very least it provides a ready-made list of excuses to avoid object-oriented technology!

  1. "We can't use a new and unfamiliar method on a fixed price contract because we can't increase the risk of exceeding our budget and/or timescales. We can't use a new method on a time and materials contract because the client won't stand for the bill for training and learning time, or for the increased timescales necessary to cover our training and familiarization, or for the risk it represents.

  2. "We can't use a new method on a real job because there is a risk the we will fail on it as a result. There's no point in trying out a new method on an artificial job created for the purpose because there aren't the pressures of a real job.

  3. "The first project on which we use a new method must be one on which the method will succeed or the method will lose credibility right from the start. If we use a new method on a difficult project where it could fail then the outcome will not prove anything about the method. If we use a new method on an easy project and it succeeds the we shall have proved nothing.

  4. "It's not possible to decide on methods at the start of a project because we don't know much about the system and hence what methods would be appropriate. It's not worth deciding on methods after a project has started because it's too late to do anything about training, tooling, planning, and so on.

  5. "It's no good sending our people willy-nilly on training courses on new methods because unless there is the immediacy on using it on a real project they won't be motivated to understand it. We can't send people on courses once a project has started because we probably haven't got the budget or the time for such luxuries, even if the client would buy the idea, i.e., it's too late.

  6. "We can't introduce a new method on a small project because it will probably be too short and there will not be the time or budget for training. We can't introduce a new method on a large project because the increased risk and cost of failure would be too great.

  7. "We can't use a new method on a project until we have seen it work on other projects (alias the basic chicken and egg dilemma).

  8. "Training must take place on the project on which a new method is to be used. The cost of training cannot be borne on a single project because it is quite likely to be too large a proportion of up-front money.

  9. "We cannot safely use a new method on a project unless we have a person on the team familiar with the use of that method. We don't have such a person because we haven't used the method before.

  10. "What we are looking for on projects is reducing risks and increasing predictability. Traditional methods, being informal, increase risk and reduce predictability (because it is difficult to tell whether something is complete, consistent or correct if it is informally expressed or informally developed). However, we continue to use them and take the risks. Formal methods reduce risk and increase predictability because we can make positive statements about what we produce. However, we do not use formal methods because we suspect they are more risky and we cannot predict how successful our use of them will be.

  11. "We can't use a new method unless we have the tools to support it. But we don't mind using a traditional method even though there is no tool support.

  12. "We could justify the use of a new method on a project if we could quantify the costs of using it. But we use traditional methods on projects even though we can't quantify the costs of using them (e.g., we are still unable to make reliable estimates).

  13. "Tools that are generally applicable are generally weak. Strong tools are very specific and hence generally inapplicable.

  14. "An important feature of new methods is that they tend to be powerful in particular areas. This makes them generally inapplicable. The traditional methods are weak in all areas. This makes them generally inapplicable."

Final Comments

This section has attempted to identify "discriminators" that assists the reader in reviewing and classifying object-oriented methodologies. Certain key discriminators were identified that proved useful in classifying the methods reviewed based on specific needs of an organization. No methodology was found to be "complete." There exists significant room for improvements in each. In particular, software quality assurance, testing, and the maintenance of object-oriented applications are largely ignored. The project management issues of reuse, cost estimating, project planning, and personnel selection are also largely avoided. In addition, the need for additional guidelines and heuristics for effectively improving the creation of reusable components, and the selection and incorporation of such components into applications is clear.

Each of the methods reviewed are evolving. While performing a comparison is useful, the reader is advised that each method reviewed has additional components (e.g., tools, training, course materials). Also, this review limited itself to reviewing published works of varying lengths (e.g., the Colbert method was reviewed from as 16 page article). Hopefully this comparison will serve as a starting point in conducting further research into object-oriented methods.

[TOA Home Page] [HTML
Documents] [Contact TOA] [Mailing
List]