A Comparison of Object-Oriented Development Methodologies

Copyright The Object Agency, Inc., 1995

This report was originally written in 1992-1993. Therefore, some of its information is out-of-date. The Object Agency, Inc. believes, however, that the report still provides many useful insights.

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
  • Two Different Cultures
  • The Literature
  • Methodology Comparisons -- Problems
  • Definition of Methodology
  • This Report's Approach
    • Concepts
    • Notations
    • Process
    • Pragmatics
    • Support for Software Engineering
    • Marketability
  • Avoiding the Problems Associated with Prior Methodology Comparisons
  • The End Result
• Concepts
  • 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?"
  • How Does The Method Deal With Concepts That Are Larger Than Can Be Reasonably Represented By A Class?
  • Analysis
• Notations
  • What Are The Components Of The Method's Notation?
  • What Static Concepts Is The Notation Capable Of Expressing?
  • What Dynamic Concepts Is The Notation Capable Of Expressing?
  • Are Explicit Rules Presented For Defining The Notations Symbols?
  • Does There Exist Explicit Logic For Transforming Models Into Other Models, Or Partially Creating A Model From Information Present In Another?
  • Does The Notation Provide A Partitioning Mechanism?
  • Analysis
• Process
  • What Are The Process Steps For The Development Process Within The Methodology?
  • What Deliverables Are Generated From The Development Process?
  • What Development Contexts Are Supported By The Methodology?
  • What Development Perspectives Are Supported?
  • What Aspects Of The Lifecycle Are Covered By The Approach?
  • Are The Process Steps Well-Defined?
  • Are Project Development Roles Clearly Defined?
  • Are There Heuristics Available For The Process Steps?
  • Is It Possible To Locate The Origin Of Decisions Made During Development?
  • Does The Process Provide For Verification?
  • Does The Process Provide For Validation?
  • What Development Lifecycle Best Describes The Methodology?
  • Are Quality Assurance Guidelines Presented?
  • Are Estimating Guidelines Presented?
  • What Percentage Of Time Over A Project's Life, Is Spent In Each Life Cycle Phase?
  • Analysis
• Pragmatics
  • What Resources Are Available To Support The Method?
  • What Scope Of Effort Is The Method Suited For?
  • What Is The Required Training For Someone To Fully Exploit The Method, (Independent Of Programming Language Training)?
  • What Languages Has The Methodology Been Used With?
  • Is The Method Targeted At A Specific Type Of Software Domain?
  • What Automated Tools Are Available That Support The Methodology?
  • Analysis
• Support for Software Engineering Principles and Goals
  • Reusability
  • Extensibility, Modifiability, and Maintainability
  • Testability
  • Conceptual Integrity
    • Introduction Of New Terms
    • Viewpoint
  • Analysis
• Marketability
• Final Comments

Introduction

The Purpose of a Methodology Comparison

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

• Those interested in understanding the technology: These individuals are interested in becoming knowledgeable about what "object-oriented" is, what methodologies are available, and how they relate to one another. In some cases this interest is academic (e.g., students or the press), but in many other instances individuals or organizations in companies are being charged with evaluating and selecting a methodology for use on a software development effort. In many instances these groups are given limited time and resources to make this decision, therefore methodology comparisons provide a shortcut means of selection. Unfortunately, the quality of the decision rests solely with the quality of the methodology comparison(s) used.

• Those already using the technology. In some cases individuals are interested in answering the question "Is there anything better?" In these cases methodology comparisons serve to provide evidence that their initial selection was the correct one, or that other, more appropriate methodologies exist.

• Those justifying avoidance of the technology. There exist many in the software engineering community who seek to avoid change. In many cases this reticence is based on sound judgment, i.e., the approach is not yet mature, or has not yet been demonstrated as applicable for a particular problem domain. In some cases this reticence to change is founded in unwillingness to change practice. Regardless of reason, methodology comparisons are extremely useful in "digging up dirt" on methodologies, thus providing material to demonstrate that the technology is not yet ready for use in their environment.

This section will satisfy all three types of reader.

Two Different Cultures

"But first, in order to better understand object-oriented methodologies in general, it helps to understand the people who make up the "object-oriented community" itself. Far from being monolithic, there is a great deal of diversity within this community. Many object-oriented people, for example, seem to focus almost entirely on programming language issues. They tend to cast all discussions in terms of the syntax and semantics of their chosen object-oriented programming language.

"People from this camp seldom have well-defined techniques for analyzing their clients' problems or describing the overall architecture of the software product. Outside of producing "executable prototypes," a great deal of what they do is intuitive. If they happen to have a natural instinct/intuition for good analysis or good design, their efforts on small-to-medium, non-critical projects can result in respectable software solutions.

"Programming language people use the terms "analysis" and "design" in a very loose sense. Analysis can mean listening to their customer, making some notes and sketches, thinking about both the problem and potential solutions, and even constructing a few software prototypes. Design can mean the code-level design of an individual object, the development of an inheritance (specialization) hierarchy, or the informal definition and implementation of a software product (e.g., identify all the objects, create instances of the objects, and have the instances send messages to each other).

"Another sector of the object-oriented community is interested in formality and rigor. To these people, software engineering is largely very systematic, repeatable, and transferable. They view object-oriented software engineering as primarily an engineering process with well-defined deliverables. The quality of the resulting products (and the process itself) can be evaluated in a quantitative, as well as qualitative, manner.

"As you might guess, there are significant cultural differences between these two groups of object-oriented people. For example, some of those who emphasize rigor and formality view the programming language people as chaotic, overly error prone, wasteful, and largely unpredictable. On the other hand, some of the programming language people consider "formality" and "rigor" to be mere window dressing -- at best adding nothing to the quality of the final product, and at worst increasing the cost of development while simultaneously delaying the delivery and lowering the quality of the resulting software product.

"Even if one takes into account the widely different views described above, there are still significant variations within each of these perspectives. Consider inheritance, i.e., the process whereby an object acquires characteristics from another object. (Please note that we are using "object" in its most generic sense. Some people restrict the term "object" to mean only instances of classes.) A few object-oriented programming languages allow an object to directly inherit from only one other object (single inheritance). Other languages allow an object to inherit characteristics from more than one object (multiple inheritance). Someone who defines OOD in programming language terms may choose to include or exclude multiple inheritance from the design process based on whether or not their particular language supports the concept.

"Within the "formality and rigor" group there is also a significant amount of diversity. Some try to portray object-oriented methods as slightly recast structured approaches (old wine in new bottles). Others advocate a more data-driven style, e.g., the extensive use of entity-relationship diagrams and other data modeling techniques. Still others seem to have successfully blended object-oriented thinking and rigorous software engineering. In effect, they have integrated the two without losing the benefits of either."

-- Berard, pp. 5-6.

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

• Comparing methodologies is often like comparing apples and oranges (or even fire trucks). Take, for example, basic terms. Some methodologies use the term "object" and "instance" as synonymous (e.g., Booch). Berard and others use "object" in a more general sense, as including all items (classes, metaclasses, non-class instances) within their particular approach. While this difference in terminology may seem academic at first glance, the appropriateness and applications of these methods is significantly impacted by this distinction.

• Many methodologies are targeted or strongly influenced by specific programming languages. For example, to fully leverage IBM's design approach, IBM assumes the target language to be Smalltalk. Often an evaluation of methods requires the evaluator understand the target platforms for which the methodology is intended.

• Certain methodologies assume a "greenfield" development context (i.e., the project is separate, stand-alone, and has no need to integrate with existing applications). This assumption removes certain constraints the methodology may have to deal with.

• The completeness of various methodologies varies dramatically. For example, some describe a process only, while others present a graphical notation, while still others combine both graphics and a process. The depth and completeness of each of these components varies significantly from method to method.

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:

[Fichman and Kemerer, 1991]. R.G. Fichman and C.F. Kemerer, Object-Oriented and Conventional Analysis and Development Methodologies: Comparison and Critique, Center for Information Systems Research, Sloan School of Management, M.I.T., CISR WP. No. 230, 1991. 38 pages.

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.

[Cribbs et al., 1992] J. Cribbs, C. Roe, and S. Moon, An Evaluation of Object-Oriented Analysis and Design Methodologies, SIGS Books, New York, New York, 1992. 75 pages.

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.

[Arnold et al., 1991] P. Arnold, S. Bodoff, D. Coleman, H. Gilchrist, F. Hayes, An Evaluation of Five Object-Oriented Development Methods, Hewlett Packard Laboratories, Bristol, United Kingdom, Report No. HPL-91-52, June 1991. 35 pages. Contact 415-857-4573 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).

[Monarchi and Puhr, 1992]. D.E. Monarchi and G.I. Puhr, "A Research Typology for Object-Oriented Analysis and Design", Communications of the ACM, Vol. 35, No. 9, September 1992, pp. 35 - 47.

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.

[van den Goor et al., 1992] G. van den Goor, S. Hong and S. Brinkkemper, A Comparison of Six Object-oriented Analysis and Design Methods. Reportmethod Engineering Institute, University of Twente, the Netherlands, and Computer Information Systems Department, Georgia State University, Atlanta, 1992. 163 pages.

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.

[Hong et.al. 1992] S. Hong, G. van den Goor and S. Brinkkemper, A Comparison of Object-oriented Analysis and Design Methods. Working paper, Computer Information Systems Department, Georgia State University, Atlanta, USA, 1992, 12 pages. To appear in the Proceedings of the 26th Hawaiian International Conference on System Sciences, IEEE Computer Science Press.

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

[Rumbaugh et al., 1991]. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, New Jersey, 1991, pp. 266-274.

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:

• Any methodology comparison must evaluate a "snapshot" of methodologies. Any comparison must be restrictive in the information it reviews. Restricting this review to published texts or refereed articles may inadvertently exclude information that is covered in unrefereed articles or training materials. In addition, the information selected may be dated. For instance, some of the texts reviewed are over four years old. All the methods reviewed evolve over time based on user feedback, as well as research by the authors. The reader is advised that this section is simply a starting point for research, and not a comprehensive review of all the information available on the methods reviewed.

• Using an inappropriate framework with which to conduct the evaluation. An evaluator may attempt to evaluate methods using the context (i.e., framework) from their prior development background, often unduly biasing their review. For example, a researcher may have successfully employed entity-relationship (E-R) modeling in prior analysis efforts, and found it extremely useful. In now assessing object-oriented development methods, the researcher may assume that since E-R models were useful in one development approach, they should be equivalently useful in object-oriented development. This may be, but very often is not the case. (Note that the use of flow charts is no longer advocated by structured analysis and design texts, yet flow charts were very useful prior to the advent of more structured techniques.)

• Utilizing reviewers who are simply "looking for words" and "placing check marks in a checklist" without doing the requisite research. Alan Kay remarked in a recent interview that Ivan Sutherland's Sketchpad used concepts such as "instances" and "masters." The term "masters" was used in the same sense we currently use "classes", yet a researcher only looking for the term "class" would miss it in reviewing Sketchpad, and thus assess Sketchpad as not being "object-oriented" (or possibly not as object-oriented as it actually was). A second problem with this "looking for words" approach is that the methodology may mention a term, but in no way incorporate support for the term into the methodology itself. This introduces additional error into the comparison.

• Using an overly constrained, or unconstrained, definition of methodology. Booch, at a 1991 OOPSLA tutorial, defined methodology as "a process, a notation, and tools." (Monarchi and Puhr, 1992) identify the components of object-oriented analysis/design methodologies as being comprised of an OOA process, an OOD process, OOAD representations, and an OOAD complexity abstraction and management mechanism. They further note that object-oriented development methods can be classified into "... three broad categories: 1) processes only, 2) representations only, and 3) processes and representations." The Hewlett Packard Study (Arnold et al., 1991) depicts a methodology as consisting of a set of concepts, a notation(s), processes, and pragmatics (e.g., available training and tools). Based on each definition, a different set of items would be selected as being "methodologies." By Booch's own definition, his method was not truly a methodology until almost two years after his book was published. The definition of "methodology" should be clearly stated within the introduction to any methodology comparison. Each methodology comparison must be careful in its selection of definitions in order not to exclude viable methods, or include non-viable methods.

• Many methodology comparisons seek to identify and document support for particular concepts, but do not rank the degree of support. This can lead to studies showing a number of methods as being relatively equal in support from a numerical standpoint (the number indicating the method "addresses" certain topics, when in reality this is not the case. Caveats such as
  "A marked cell indicates that the issue is addressed; a blank cell indicates that it is not. The table does not grade the research on how well the issues are handled. It simply identified consideration of a topic." (Monarchi and Puhr)

  are clear indicators of this problem. These studies yield numerical results, which are then often used independent of their context and their cited caveats.

• It is, in many instances, difficult to repeat the results of a methodology comparison with any accuracy. Since few (if any) of the comparisons cite page references for where a particular methodology comparison item (e.g., a term, concept, or example) is found in the methodology under review, it is difficult, if not impossible, to verify the accuracy of these methodology comparisons. Some methodology authors' themselves also make this difficult by a) providing inadequate indexes, b) not supplying a glossary of terms, and c) introducing new terminology that expresses an already existing concept (possibly with some extensions or delimits on the originating concept, but without cross-referencing the originating concept).

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:

• Cost Estimating Guidelines,

• Project Management Tasks and Deliverables,

• Measures and Metrics,

• Defined Forms and Deliverable Construction Directions,

• Software Quality Assurance Policies and Procedures,

• Detailed Role Descriptions and Training Programs,

• Completely Worked Examples,

• Training Exercises,

• Techniques for Tailoring the Method, and

• Defined Techniques.

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

• Notations

• Process

• Pragmatics

• Support for Software Engineering

• Marketability

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:

• Analysis is that portion of the life-cycle that describes the outwardly observable characteristics of the system, e.g., functionality, performance, capacity. Normally this description includes models that depict the logical construction of the systems, and its placement within a system environment.

• Design is that portion of the life-cycle prepares definitions as to how the system will accomplish its requirements. The models prepared in analysis are either refined, or transformed, into design models that depict the physical nature of the software product.

• Implementation is that portion of the life-cycle that converts the developed design models into software executable within the system environment. This either involves the hand coding of program units, the automated generation of such code, or the assembly of already built and tested reusable code components from an in-house reusability library.

• Testing focuses on ensuring that each deliverable from each phase conforms to, and addresses the, stated user requirements.

• Domain Analysis addresses researching an application domain and identifying, documenting, constructing, testing, and demonstrating reusable components useful in the domain. Even though this is not a project life-cycle activity, it is an important issue to consider and review method support for.

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:

• Resources: What available resources are there in support of the method? Is a textbook available? Are users groups established? Is training and consulting offered by the vendor and/or third parties? In addition, are automated tools (CASE tools) available in support of the method?

• Required Expertise: What is the required background of those learning the method? A distinguishing characteristic of many methods is the level of mathematical sophistication required to fully exploit the method. Does the method assume knowledge in some discipline?

• Accessibility: Some methods require automation in order to be conducted. In cases where the method precedes available automation, the method is largely inaccessible. In some cases the method, while still requiring automation, can be conducted with partial or ad hoc automation (e.g., use of drawing tools). In these instances the method is partially accessible.

• Language Suitability: Is the method targeted at a particular implementation language? Some methods are specific to COBOL or Ada, while other methods have more general applicability.

• Domain Applicability: Is the method suited to a particular application domain? Some methods are targeted at real-time and embedded systems applications, while other methods are more suited for information systems development. In addition, the appropriateness of each method for the construction of reusable components library is assessed.

Support for Software Engineering

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

• Reusability: How well the method is suited to creating, as well as incorporating, reusable components into its execution.

• Testability: Each method's deliverables are evaluated as to how well they are suited for use in a testing process.

• Modifiability: The degree to which software products generated using the method is evaluated. In particular, the degree of object coupling allowed in the method is determined. If the degree of coupling allowed is unconstrained, then the method provides poor modifiability.

• Conceptual Integrity: Conceptual integrity, in object-oriented development, is a measure of the degree to which the method remain true to the concept of "objects." Those systems with a high-degree of conceptual integrity tend to show a higher degree of quality, more straightforward implementation, and decreased costs of maintenance. Those approaches that make heavy use of data-driven, or functional, decomposition violate this "object-oriented" integrity.

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 methodology requires an automated tool.

• The methodology should only involve a small amount of time before coding can commence.

• The methodology must be cheap.

• The effort is under DoD contract and therefore the methodology must support 2167A documentation.

• The methodology must use models and notations similar to what the corporation/project/I has done in the past (this is often couched as 'leveraging' past software investments.).

• The approach must be evolutionary, or it must be revolutionary.

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.

• Using an inappropriate framework with which to conduct the evaluation

  The reviewers employed in conducting this comparison have over twelve years experience in training and presenting on object-oriented technology to literally thousands of people. Both have developed significant amounts of software using object-oriented technology, as well as having participated in many development efforts in sizes ranging from a few thousand, to hundreds of thousands of lines of object-oriented code.

• Utilizing reviewers who are simply "looking for words" and "placing check marks in a checklist" without doing the requisite research

  Each methodology has been thoroughly reviewed and researched. Not only is the index and glossary of each methodology searched, but the entire document is manually reviewed in search of terms (note that this does not guarantee that a specific term will not be missed, only that every effort has been made to be as thorough as possible). In addition, each methodology's support for a term is quantified using the following guidelines:

  • A "0" indicates that no support identified for the concept was located in the methodology

  • A "1" indicates that the concept was mentioned, but no details are given, or support for the concept within the methodology is not demonstrated.

  • A "2" indicates the concept was mentioned with an example or some anecdotal information provided, or an explicit definition is provided.

  • A "3" indicates the concept is discussed, definition is provided, more than one example presented.

  • A "4" indicates the concept is discussed, detailed definition is provided, numerous examples are presented, and a process is described and depicted.

  • A "5" indicates the concept is discussed, detailed definition is provided, numerous examples are presented, and a process is described and depicted.

  • A "6" indicates the concept is discussed, detailed definition is provided, numerous examples are presented, a process is described and depicted, and quality assurance information is supplied on assessing the quality of the item

• Using an overly constrained, or unconstrained, definition of methodology

  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. The methodologies reviewed include the following:

  Berard, consisting of:
  [Berard, 1993]. E.V. Berard, Essays on Object-Oriented Software Engineering, Volume 1, Prentice Hall, Englewood Cliffs, New Jersey, 1993.

  [Berard(a), 1992]. Berard Software Engineering, Inc., A Project Management Handbook for Object-Oriented Software Development, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1992.

  [Richardson et al., 1992]. J.E. Richardson, R.C. Schultz, and E.V. Berard, A Complete Object-Oriented Design Example, Berard Software Engineering, Inc., Gaithersburg, Maryland, 1992.

  Booch, consisting of:

  [Booch, 1991]. G. Booch, Object-Oriented Design With Applications, Benjamin/Cummings, Redwood City, California, 1991.

  Colbert, consisting of:

  [Colbert, 1989]. E. Colbert, "The Object-Oriented Software Development Method: A Practical Approach to Object-Oriented Development," Proceedings of TRI-Ada '89 -- Ada Technology In Context: Application, Development, and Deployment, October 23-26, 1989, Association for Computing Machinery, New York, New York, pp. 400 - 415.

  Coad and Yourdon, consisting of:

  [Coad and Yourdon, 1990]. P. Coad and E. Yourdon, OOA -- Object-Oriented Analysis, 2nd Edition, Prentice Hall, Englewood Cliffs, New Jersey, 1990.

  [Coad and Yourdon(a), 1991]. P. Coad and E. Yourdon, OOD -- Object-Oriented Design, Prentice Hall, Englewood Cliffs, New Jersey, 1990.

  Embley and Kurtz, consisting of:

  [Embley et al., 1992]. D.W. Embley, B.D. Kurtz, S.N. Woodfield, Object-Oriented Systems Analysis, A Model-Driven Approach, Yourdon Press/Prentice Hall, Englewood Cliffs, New Jersey, 1992.

  IBM, consisting of:

  [IBM, 1990]. IBM International Technical Support Centers, Object-Oriented Design: A Preliminary Approach-Document GG24-3647-00. IBM International Technical Support Center, Raleigh, North Carolina, 1990.

  [IBM(a), 1990]. IBM International Technical Support Centers, A Practical Introduction to Object-Oriented Programming-Document GG24-3641-00. IBM International Technical Support Center, Boca Raton, Florida, 1990.

  [IBM(b), 1990]. IBM International Technical Support Centers, Object-Oriented Analysis of the ITSO Common Scenario-Document GG24-3566-00. IBM International Technical Support Center, Raleigh, North Carolina, 1990.

  [IBM(c), 1991]. IBM International Technical Support Centers, Developing a CUA Workplace Application-Document GG24-3580-00. IBM International Technical Support Center, Raleigh, North Carolina, 1990.

  Martin and Odell, consisting of:

  [Martin and Odell, 1992]. J. Martin and J.J. Odell, Object-Oriented Analysis and Design, Prentice Hall, Englewood Cliffs, New Jersey, 1992.

  Rumbaugh, consisting of:

  [Rumbaugh et al, 1991]. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, New Jersey, 1991.

  Shlaer and Mellor, consisting of:

  [Shlaer and Mellor, 1988]. S. Shlaer and S.J. Mellor, Object-Oriented Systems Analysis: Modeling the World In Data, Yourdon Press: Prentice Hall, Englewood Cliffs, New Jersey, 1988.

  [Shlaer and Mellor(a), 1992]. S. Shlaer and S.J. Mellor, Object-Oriented Systems Analysis: Modeling the World In States, Yourdon Press: Prentice Hall, Englewood Cliffs, New Jersey, 1992.

  Wirfs-Brock, consisting of:

  [Wirfs-Brock et al, 1990]. R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-Oriented Software, Prentice Hall, Englewood Cliffs, New Jersey, 1990.

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.

• It is, in many instances, difficult to repeat the results of a methodology comparison with any accuracy

  This issue, unfortunately, cannot be entirely removed. In order to allow one to repeat this study, this section cites page numbers where particular concepts, notations, etc. are noted. In many instances other references are also cited, but these citations are by no means exhaustive. The conclusions reached for each question should be verifiable by those willing and able to follow the references cited. There are some instances, though, where a subjective assessment must be made. In such instances mention will be made that the assessment was subjective, and the reason the assessment was made. The reader may wish to reassess these subjective items to determine if they agree, or disagree, with this section's conclusions.

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:

• "I wish to learn about object-oriented development in a general sense. The process of object-oriented software development and the availability of tools is not really very important to me at this time. Just tell me about objects."

• "I have a large project commencing that involves over twenty people, outside consultants, and is critical to the success of our company. What methods are appropriate for me?"

• "My project requires the use of Smalltalk. What methods are appropriate considering that the programming language has already been selected for my project?"

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?"

Objects are the real and conceptual things we find in the world around us. An object may be hardware, software, a concept (e.g., velocity), or even "flesh and blood." Objects are complete entities, i.e., they are not "simply information" or "simply information and actions." Software objects strive to capture as completely as possible the characteristics of the "real world" objects which they represent. Finally, objects are "black boxes," i.e., their internal implementations are hidden from the outside world, and all interactions with an object take place via a well-defined interface.

-- Berard, page 335

Something you can do things to. An object has state, behavior, and identity; the structure and behavior of similar objects are defined in their common class. The terms instance and object are interchangeable.

-- Booch, page 516

An abstraction of something in a problem domain, reflecting the capabilities of a system to keep information about it, interact with it, or both; an encapsulation of Attribute values and their exclusive Services. (synonym: an Instance)

-- Coad and Yourdon, page 52

An object is a visible or tangible thing of relatively stable form; a thing that may be apprehended intellectually; a thing to which though or action is directed. It is a unit of structural and behavioral modularity which has properties. Each object can be characterized by the set of operations that can be performed on it and by the set of operations that it can perform on other objects (either of these two sets may be empty), and by the set of states which it goes through during its lifetime. Each object encloses components, i.e., objects of which it has been constructed, and the operations that can be performed on it, which it makes available for other objects to perform. When these characterizations are accurate, we recognize an object: a self-contained thing which exhibits behavior.

-- Colbert, page 400

An object is a person, place, or thing. An object may be physical or conceptual. ... The idea is that an object is a single entity or notion. Each object is a unique individual. An object may be related to or made up of other objects, but each object is unique.

-- Embley et al., page 18

The object is an Instance of a Class. It is the computer representation of a real world object. The object has Properties as defined in the class of which it is an instance.

-- IBM, page 142

Anything to which a concept, or object type, applies - an instance of a concept or object type. In OOPLs, it is any instance of a class."

-- Martin and Odell, page 456

We define an object as a concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand. Objects serve two purposes: They promote understanding of the real world and provide a practical basis for computer implementation. Decomposition of a problem into objects depends on judgment and the nature of the problem. There is no one correct representation.

-- Rumbaugh et al., page 21

An object is an abstraction of a set of real-world things such that

• all the things in the set - the instances - have the same characteristics, and

• all instances are subject to and conform to the same set of rules and policies.

... An object in OOA represents a single typical but unspecified instance of something in the real world - any airplane, I don't care which one, as long as it is typical. The object-oriented analyst distinguishes this concept from that of a specified instance: Airplane number N2713A, Air Force One, or The Spirit of St. Louis, for example.

-- Shlaer and Mellor (a), pp. 11-12

Objects know certain data about themselves (just as, for example, you know the colors of your hair and eyes), and objects know how to do certain functions (just as you know how to buy groceries or do your job).

-- Wirfs-Brock, page 6

In one sense, an object can be viewed as a statement that certain knowledge and certain operations are conceptually related to one another, so that it makes sense to bundle them together.

-- Wirfs-Brock, page 18

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

an object which is used to create instances, i.e., a template, description, pattern, or "blueprint" of a category or collection of very similar items. Among other things, a class describes the interface the these items will present to the outside world, i.e., the available and appropriate methods, constants, and exceptions. A class represents an abstraction of the items. A class may itself be parameterized (i.e., it actually represents a family of very closely related classes), in which case we refer to it as a parameterized class. Class is a recursive concept. Specifically, we may define classes as being composed of other classes (i.e., heterogeneous composite classes and homogeneous composite classes), in terms of itself (a recursively defined class), as inheriting characteristics from one or more other classes (i.e., the superclasses of the class), and as providing characteristics to other classes (i.e., the subclasses of the class). In some places, classes are defined as "the set of all instances of a type," and the term "type" is given the above definition for class.

-- Berard, page 328

A set of objects that share a common structure and a common behavior. The terms class and type are usually (but not always) interchangeable; a class is a slightly different concept than a type, in that it emphasizes the importance of hierarchies of classes.

-- Booch, page 513

A description of one or more Objects with a uniform set of Attributes and Services, including a description of how to create new Objects in the Class.

Class-&-Object. A term meaning "a Class and the Objects in that Class."

-- Coad and Yourdon, page 52

A class defines a number of objects that share the same set of states, the same set of operations that can be performed on them, the same set of operations that they can perform on other objects, and the same class of component objects. By identifying a class, we can avoid redundancy in defining the objects that are members of that class.

-- Colbert, page 400

Identification of sets of objects that belong together for some logical reason is called classification. In OSA, a set of objects that belong together for some logical reason is called an object class. The Object-Relationship Model encourages analysts to organize objects into object classes. Each object class has a name that is generic and denotes any member of the object class. Thus, in an ORM, an object class whose name is X designates a classification of objects each of which is considered to be an X. Since each object in object class X is an X, the objects in the class are alike, at least in some sense.

-- Embley et al., page 24

The definition of the properties (Instance Variables and methods) shared by all instances of this class. The description will serve as a template for the construction of instances of the class. Classes are similar to data types, but they contain functions as well as data.

-- IBM, page 141

An implementation of a concept or object type. In OO programming languages, abstract data types are called classes. In mathematics, the meaning of class is similar to that of set. The meaning of the OOPL definition of class arose from the mathematical definition.

-- Martin and Odell, page 454

An object class describes a group of objects with similar properties (attributes), common behavior (operations), common relationships to other objects, and common semantics. Person, company, animal, process, and window are all object classes.

-- Rumbaugh, page 22

Objects which share the same behavior are said to belong to the same class. A class is a generic specification for an arbitrary number of similar objects. You can think of a class as a template for a specific kind of object, or as a factory, cranking out as many of its products as required.

-- Wirfs-Brock et al., page 22

Shlaer and Mellor provide no explicit definition for "class."

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

an action which is suffered by, or required of, an object. Operations may be selectors, constructors, or iterators. An operation is contained in an object's interface and has its details described in a corresponding method. Operations may be composite, i.e., composed of other operations. However, encapsulation of composite operations within the interface to an object is not encouraged.

-- Berard, page 336

Some action that one object performs upon another in order to elicit a reaction. All of the operations upon a specific object may be found in free subprograms and member functions or methods. The terms message, method, and operation are usually interchangeable.

-- Booch, page 517

A Service is a specific behavior that an Object is responsible for exhibiting.

-- Coad and Yourdon, page 143

The external behavior of an object relates the operations performed on it to the operations it performs on other objects... The internal behavior of an object relates the operations performed on it to the operations it performs on its component objects.

-- Colbert, page 407

In addition to states and transitions among states, we also wish to model the actions an object performs. An action may cause events, create or destroy objects and relationships, observe objects and relationships, and send or receive messages.

-- Embley et al., page 62

We place actions into two categories in OSA: noninterruptible actions and interruptible actions. Noninterruptible actions are actions that the analyst expects to run to completion unless exceptions or system failures occur. Interruptible actions may be suspended before they finish executing and may resume execution at a later time. In OSA, we think of actions associated with transitions as noninterruptible, whereas actions associated with states are interruptible."

-- Embley et al., page 62 (No index entry exists for "operation". We used entries for "action" instead.)

The Behavior of Objects is implemented in their methods. A method can be compared to a traditional programming routine. However, instead of "calling" the method, a Message is sent to the object. The message contains the name of the method to be run and one or more optional parameters. The method will normally send Messages to other objects in order to complete its task. Methods can read and/or update the Instance Variables of the object that received the message. The method will return an object to the sender upon completion.

-- IBM, page 142

A process that can be requested as a unit. A single step that is performed in a series of steps. Operations may or may not change the state of an object. Functions are operations that do not change state. However, in an event schema, the operations that result in events do change states (and could more properly be called state-changing-operations).. Each state-changing operation can be though of as a transaction. A transaction is a process or a series of processes acting as a unit to change the state of an object. Instances of operations are called invoked operations. The specification of how an operation must be carried out is called the method. Some approaches, such as Eiffel, differentiate between an operation that changes object state and an operation that does not. In these approaches, the former is called a procedure and the latter, a function.

-- Martin and Odell, page 456

An operation is a function or transformation that may be applied to or by objects in a class. Hire, fire, and pay-dividend are operations on class Company. Open, close, hide, and redisplay are operations on class Window. All objects in a class share the same operations.

-- Rumbaugh et al., page 25

Event takers. Define a published operation corresponding to each event generate that is shown in the state process table as having been assigned to the object under consideration. Such published operations are known as event takers. There are two cases to consider:

• If the event generated by the event generator does not cause a new instance of the object to be created, define the corresponding event taker as an instance operation. Name it Take Event <event label>.

• If the event generated by the event generator causes a new instance of the object to be created, define the corresponding event taker as a class operation and name it Take and Create <event label>."

-- Shlaer and Mellor(a), page 176

When an object receives a message, it performs the requested operation by executing a method.

-- Wirfs-Brock et al., page 21 (Note that no index entry for the term "operation" is provided.)

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

metaclass [in structurally reflective systems] a class whose instances are themselves classes.

-- Berard, page 334

metaclass The class of a class; a class whose instances are themselves classes.

-- Booch, page 515

Classes can also be considered as objects, but they are meta-objects and not real-world objects. Class descriptor object have features, and they in turn have their own classes, which are called metaclasses. Treating everything as an object provides a more uniform implementation and greater functionality for solving complex problems.

-- Rumbaugh et al., page 71

metaclass a class describing other classes

-- Rumbaugh et al, page 459

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?

Object-oriented domain analysis seeks to identify reusable items localized around objects e.g., classes, instances, systems of interacting objects, and kits.

-- Berard, page 185

kit: a collection of objects (e.g., classes, metaclasses, non-class instances, unencapsulated composite operations, other kits, and systems of interacting objects) all of which support a single, large, coherent, object-oriented concept, e.g., windows, switches, and insurance policies. There may indeed be some physical connection among some members of a given kit. However, kits are "granular," i.e., while all the components of a kit are logically related, there are very few physical connections that bind them together.

-- Berard, page 333

system of interacting objects: a collection of objects (e.g., classes, metaclasses, non-class instances, unencapsulated composite operations, kits, and others systems of interacting objects) all of which support a single, large, coherent, object-oriented concept, and in which there must be a direct or indirect physical connection between any two arbitrary objects within the collection. Further, systems of interacting objects have at least one internal, independently executing thread of control. Lastly systems of interacting objects may exhibit multiple, completely disjoint public interfaces.

-- Berard, page 342

However, the class structure of a large system may contain as many as several hundred or a few thousand classes. Trying to put all these classes in one class diagram becomes unwieldy. To deal with this problem, we need some means of organizing classes into meaningful chunks, which leads us to the idea of a class category.

-- Booch, page 161

class category A collection of classes, some of which are visible to other class categories, and others of which are hidden.

-- Booch, page 513

...domain analysis seeks to identify the classes and objects that are common to all applications within a given domain, such as missile avionics systems, compilers, or accounting software.

-- Booch, page 142

subsystem a collection of modules, some of which are visible to other subsystems and others of which are hidden.

-- Booch, page 518

Subject. A Subject is a mechanism for guiding a reader (analyst, problem domain expert, manager, client) through a large, complex model. Subjects are also helpful for organizing work packages on larger projects, based upon initial OOA investigations.

-- Coad and Yourdon, page 106

For example, a diagram is created that describes the internal structure of the system - note that the system itself is an object. The internal view of the system object describes component objects of the system object and how the system and component objects interact.

-- Colbert, page 401

A high-level object class groups objects classes, relationship sets, constraints, and notes into a single object class. For example, in the ORM for the Green-Grow Seed Company, which is duplicated in Fig. 4.1, we may wish to create a high-level object class by grouping together the object classes Preferred Customer Group, Name (Of Preferred Customer Group), and Discount Rate, including the relationship sets that connect them, and the participation constraints on these connecting relationship sets.

-- Embley, page 99

subsystem a major component of a system organized around some coherent theme. A system may be divided in subsystems using either partitions or layers.

-- Rumbaugh, page 463

system an organized collection of components that interact.

-- Rumbaugh, page 463

partition a subsystem that provides a particular kind of service. A partition may itself be built from lower level subsystems. (Contrast with layer.)

-- Rumbaugh, page 461

layer a subsystem that provides multiple services, all of which are at the same level of abstraction, built on subsystems at a lower level of abstraction. (Contrast with partition.)

-- Rumbaugh, page 459

While a small domain (consisting of fifty or fewer objects) can generally be analyzed as a unit, large domains must be partitioned to make the analysis a manageable task. To make such a partitioning, we take advantage of the fact that objects on an information model tend to fall into clusters: groups of objects that are interconnected with one another by many relationships. By contrast, relatively few relationships connect objects in different clusters.

When partitioning a domain, we divide the information model so that the clusters remain intact... Each section of the information model then becomes a separate subsystem. Note that when the information model is partitioned into subsystems, each object is assigned to exactly one subsystem.

-- Shlaer and Mellor (a), page 145

We have been talking about classes as if they were the only conceptual entities composing an application. But depending upon the complexity of your design, various levels of encapsulation can be nested, one within the other. ...

A subsystem is a set of classes (and possibly other subsystems) collaborating to fulfill a set of responsibilities. Although subsystems do not exist as the software executes, they are useful conceptual entities.

-- Wirfs-Brock et al., page 30

Frameworks are skeletal structures of programs that must be fleshed out to build a complete application.... Frameworks are white boxes to those that make use of them. Application developers must be able to quickly understand the structure of a framework, and how to write code that will fit into the framework. Frameworks are reusable designs as well as reusable code.

-- Wirfs-Brock et al., page 13

Applications are complete programs. A fully developed simulation, a word processing system, a spreadsheet, a calculator, or an employee payroll system are all examples of applications.

-- Wirfs-Brock et al., page 13

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:

• Structures

• Other Systems

• Devices

• Things or events remembered

• Roles played

• Operational procedures

• Sites

• Organization units

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:

• Aggregation: From what component objects is a composite object constructed?

• Specialization: How is an object depicted as being a generalization, or specialization, of another object?

• Communication: How are objects shown as communicating (i.e., sending messages) to one another?

• Module Interfaces: How are the physical implementations of objects depicted (e.g., what does a "structure chart, ala structured design," look like for an object?

• Qualifications for Reuse: How is a specific instance of an object depicted as being instantiated from a class?

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?

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

• Object-Oriented Analysis (page 216)
  1. Identify the sources of requirements information
  2. Characterize the sources of requirements information
  3. Identify candidate objects
  4. Build object-oriented models of both the problem, and the potential solution, as necessary
  5. Re-localize the information around the appropriate candidate objects
  6. Select, create, and verify candidate objects
  7. Assign the candidate objects to the appropriate section of the object-oriented requirements specification (OORS)
  8. Develop and refine the precise and concise system description

• Object-Oriented Design (page 231)
  1. Identify Candidate Objects
     • Develop an object-oriented model of the solution
     • Identify objects of interest from the model
     • Associate attributes with the operations of interest

  2. Identify operations suffered by, and required of, candidate objects
     • Identify operations of interest
     • Associate attributes with the operations of interest
     • Handle composite operations
       • Decompose into primitive operations
       • Decouple objects

  3. Select, create, and verify objects for design
     • Bind objects and operations
     • Examine objects for completeness

  4. Decide on programming language implementation of objects
     • Objects identified during analysis
     • Objects identified during design

  5. Create object-oriented graphical models

  6. Establish the interface for each object-oriented item

  7. Implement each object-oriented item
     • Refine the interface objects
     • Refine the other objects
     • Recursively apply the object-oriented development process

Booch

• Object-Oriented Design (pp. 191-194)
  • Identify Classes and Objects
  • Identify the Semantics of Classes and Objects
  • Identify the Relationships Among Classes and Objects
  • Implement Classes and Objects

Coad and Yourdon

• Object-Oriented Analysis (Coad and Yourdon, pp. 198-204)
  1. Identify Objects
  2. Identify Structures
     • Gen-Spec Structures
     • Whole-Part Structures
     • Multiple Structures

  3. Identify Subjects
  4. Define Attributes
     • Identify the Attributes
     • Position the Attributes
     • Identify Instance Connections
     • Check special cases
     • Specify the Attributes

  5. Define Services
     • Identify Object States
     • Identify the Required Services
     • Identify Message Connections
     • Specify the Services
     • Put the OOA documentation set together

• Object-Oriented Design( (Coad and Yourdon(a) pp. 171-181)
  1. Design the Problem Domain Component
     • Reuse design and programming classes
     • Group problem-domain-specific Classes together
     • Establish a protocol by adding a generalization Class
     • Accommodate the supported level of inheritance
     • Improve performance
     • Support the Data Management Component
     • Add lower level components
     • Review and challenge the additions to OOA results

  2. Design the Human Interaction Component
     • Classify the humans
     • Describe the humans and their task scenarios
     • Design the command hierarchy
     • Design the detailed interaction
     • Continue to prototype
     • Design the Human Interaction Components Classes
     • Design, accounting for GUI (when applicable)

  3. Design the Task Management Component
     • When needed tasks
     • Identify event-driven tasks
     • Identify clock-driven tasks
     • Identify priority tasks and critical tasks
     • Identify a coordinator
     • Challenge each task
     • Define each task

  4. Design the Data Management Component
     • Select Data management approach
     • Assess data management tools
     • Design the Data Management Component

Colbert

• Object-Oriented Requirements Analysis (page 401)
  1. Perform Object-Oriented Requirements Analysis
  2. Create an Object-Interaction Specification
  3. Create Object-Class Specifications
  4. Create Behavior Specifications
  5. Create Attribute Specifications

• Object-Oriented Design (pp. 410-413)
  1. Represent each object in the Object-Interaction Diagram
  2. Represent each class in the Object-Class Diagram
  3. Represent each interaction in the Object-Interaction Diagram
  4. Review the State-Transition for details of behavior that affect the Ada Structure
  5. Add Ada-specific components needed to complete the representation

Embley and Kurtz

• Object-Oriented Systems Analysis (pp. 12, 14)
  1. Construct Object-Relationship Models
  2. Construct Object-Behavior Models
  3. Construct Object Interaction Models
  4. Integrate Models

IBM

• Object-Oriented Design (pp. 39-114)
  • Design the View (page 39)
    1. Define Business Transactions (page 40)
    2. Capture the User's Model (page 42)
       • Model the User's Objects (page 42)
       • Model the User's Behavior (page 44)
       • Enhance the User's Model (page 45)
       • Provide Natural Interaction Techniques (page 48)
       • Extract the Objects (page 51)
       • Document the User's Model (page 51)
       • Validate and Iterate (page 51)

    3. Specify the Objects (page 53)
       • Find and Document the Objects (page 53)
       • Find and Document the Methods (page 57)
       • Find the Detailed Methods for the Model Objects (page 62)

    4. Build the View (page 67)
       • Design Direct Manipulation Actions (page 67)
       • Decompose the Model Objects (page 68)
       • Define Instance Variables (page 73)
       • Design the Windows (page 76)

    5. Code and Test the View (page 77)
       • Code and Open the View Object (page 77)
       • Initialize and Update Pointers and Primitives (page 78)
       • Change Pointer Object (page 79)
       • Get More Details (page 80)
       • Implement Direct Manipulation (page 80)
       • Test the View (page 87)

  • Design the Business Model (page 89)
    1. Find the Technical Model Objects (page 90)
       • Process New Model Interface Objects (page 90)
       • Determine Required Knowledge and Decompose into Elementary Objects (page 94)
       • Re-Evaluate the Objects and Document Their Relationships (page 95)

    2. Implement the Model Objects (page 97)
       • Define Methods to Access Knowledge (page 98)
       • Create Message Interaction Diagrams (page 99)
       • Document the Model Interface Objects (page 102)

    3. Code and Test the Classes (page 105)
       • Compare Objects to Database (page 105)
       • Code the Classes (page 107)
       • Simulate Dynamic Behavior of Objects (page 108)

    4. Build the Objects (page 109)
       • Refine the Class Hierarchy (page 109)
       • Group Objects (page 110)
       • Abstract Classes (page 111)
       • Decompose or Compose (page 113)
       • Iterate (page 114)

Martin and Odell

• Object-Oriented Behavior Analysis (page 376)
  1. Define Analysis Goals
  2. Clarify Event Type
  3. Generalize Event Type
  4. Define Operation Conditions
  5. Identify Operation Causes
  6. Refine Cycle Results

Rumbaugh

• Analysis (pp. 261-262)
  1. Write or obtain an initial description of the problem (Problem Statement)
  2. Build an Object Model
     • Identify object classes.
     • Begin a data dictionary containing descriptions of classes, attributes, and associations
     • Add associations between classes
     • Add attributes for objects and links.
     • Organize and simplify object classes using inheritance.
     • Test access paths using scenarios and iterate the above steps as necessary
     • Group classes into modules, based on close coupling and related function.

  3. Develop a Dynamic Model
     • Prepare scenarios of typical interaction sequences.
     • Identify events between objects and prepare an event trace for each scenario.
     • Prepare an event flow diagram for the system.
     • Develop a state diagram for each class that has important dynamic behavior
     • Check for consistency and completeness of events shared among the state diagrams.

  4. Construct a Functional Model
     • Identify input and output values.
     • Use data flow diagrams as needed to show functional dependencies.
     • Describe what each function does.
     • Identify constraints.
     • Specify optimization criteria.

  5. Verify, iterate, and refine the three models.
     • Add key operations from Functional to Object model
     • Verify consistency and completeness of classes, attributes, associations, and operations
     • Develop more detailed models to further explore and verify the three models
     • Iterate the above steps as needed to complete the analysis

• System Design
  1. Organize the system into subsystems
  2. Identify concurrency inherent in the problem.
  3. Allocate subsystems to processors and tasks.
  4. Choose the basic strategy for implementing data stores in terms data structures, files, and databases.
  5. Identify global resources and determine mechanisms for controlling access to them.
  6. Choose an approach to implementing software control
     • Use the location within the program to hold state, or
     • Directly implement a state machine, or
     • Use concurrent tasks

  7. Consider boundary conditions.
  8. Establish trade-off priorities.

• Object Design
  1. Obtain operations for the object model from the other models:
     • Find an operation for each process in the functional model
     • Define an operation for each event in the dynamic model, depending on the implementation of control

  2. Design algorithms to implement operations:
     • Choose algorithms that minimize the cost of implementing the operation
     • Select data structures appropriate to the algorithms.
     • Define new internal classes and operations.
     • Assign responsibility for operations that are not clearly associated with a single class.

  3. Optimize access paths to data:
     • Add redundant associations to minimize access cost and maximize convenience.
     • Rearrange the computation for greater efficiency.
     • Save derived values to avoid recomputation of complicated expressions.

  4. Implement software control by fleshing out the approach chosen during system design.
  5. Adjust class structure to increase inheritance:
     • Rearrange and adjust classes and operations to increase inheritance.
     • Abstract common behavior out of groups of classes.
     • Use delegation to share behavior where inheritance is semantically invalid.

  6. Design implementation of associations:
     • Analyze the traversal of associations
     • Implement each association as a distinct object or by adding object-valued attributes to one or both classes in the association.

  7. Determine the exact representation of object attributes.
  8. Package classes and associations into modules.

Shlaer and Mellor

• For the Information models row (Shlaer and Mellor(a), pp. 155-157)
  • Research
  • Develop and Refine the Model
  • Integrate with Other Models
  • Review

• For the State models row (Shlaer and Mellor(a), page 157)
  • Construct the State Model
  • Verify the Interactions between state models and the object communications model
  • Build, or update, the subsystem communication model
  • Review for correctness and consistency

• For the Process models row (Shlaer and Mellor(a), page 158)
  • Construct Active Data Flow Diagrams
  • Integrate and Merge with State Process Tables, then produce the object access model for the subsystem and update the subsystem access model
  • Review

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:
   • Model physical objects
   • Model conceptual entities
   • Use a single term for each concept
   • Be wary of the use of adjectives
   • Model categories of objects
   • Model external interfaces
   • Model the values of an object's attributes

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:
   • Recall the purpose for each class, as implied by its name and specified in the statement of purpose
   • Extract responsibilities from the specification by looking for actions and information.
   • Identify responsibilities implied by the relationships between classes.

10. Assign responsibilities to classes using the following guidelines:
    • Evenly distribute system intelligence
    • State responsibilities as generally as possible
    • Keep behavior with related information
    • Keep information about one thing in one place.
    • Share responsibilities among related classes.

11. Find additional responsibilities by looking for relationships between classes.
    • Use "is-kind-of" relationships to find inheritance relationships.
    • Use "is-analogous-to" relationships to find missing superclasses.
    • Use "is-part-of" relationships to find other missing 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

• Postulate a state for the system.
• Propose an action by the user.
• Note each class responsible for performing an action, and the classes with which it interacts.

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:

• 0 indicates no mention is made.

• 1 indicates that mention is made, but no details are provided.

• 2 indicates that mention is made and a definition is supplied.

• 3 indicates that mention is made, a definition is supplied, and at least one example is presented.

• 4 indicates that mention is made, a definition is supplied, and at least one example is presented, and a process is defined.

• 5 indicates that mention is made, a definition is supplied, at least one example is presented, a process is defined, and heuristics are supplied.

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:

Structured analysis is an attractive front-end to object-oriented design primarily because it is well-known, many people are trained in its techniques, and many tools support its notation. However, structured analysis is not the optimal front end to object-oriented design. It is hard to know when a particular data flow diagram ceases to represent an essential model of the problem and instead articulates a design decision. Furthermore, structured analysis can sometimes perpetuate an algorithm-oriented view of the problem, which makes the job of object-oriented design much more difficult.

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

• 0 indicates no mention is made.

• 1 indicates that mention is made, but no details are provided.

• 2 indicates that mention is made and a definition is supplied.

• 3 indicates that mention is made, a definition is supplied, and at least one example is presented.

• 4 indicates that mention is made, a definition is supplied, and at least one example is presented, and a process is defined.

• 5 indicates that mention is made, a definition is supplied, at least one example is presented, a process is defined, and heuristics are supplied.

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:

• Each step is well-defined, with clear instructions, and tips and techniques where appropriate.

• The inputs to each step are defined, with possible examples.

• The outputs, or products, of each step are defined, with possible examples.

• The role(s) responsible in the execution of each step are delineated.

• Software quality assurance guidelines and instructions are provided.

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):

"a shift in roles among the members of the software development team. With object-oriented design, four kinds of developers are needed:
• System architects

• Class designers

• Class implementors

• Application programmers"

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:

General references in software quality assurance include: [Chow, 1985], [Dunn, 1990], [Dunn and Ullman, 1982], [Mizuno, 1983], and [Schulmeyer and McManus, 1987]. While there is a growing body of knowledge regarding the quality assurance of object-oriented software, I could find no specific references on the topic.

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:

• 25% in Analysis

• 38% in Design

• 13% in Coding

• 19% in Testing

• 7% in Integration

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

The final code was 13,000 lines long. It took one person three months to develop the diagram compiler. Six weeks were consumed by analysis and design and six weeks by coding and debugging. About twenty bugs were found, each of which only took a few minutes to find and correct. (Rumbaugh, page 412)

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:

• "The final product encompassed 25,000 lines of code, about 260 source files, and approximately 700 pages of documentation.

• Three software engineers worked in the problem, half time, for six calendar months, i.e., a total of 9 person months of effort were invested.

• We had no computer aided software engineering (CASE) tools to speak of. Indeed, all we has was a word processor and a drawing program.

• We produced all of the design, wrote all of the source code, and then looked for a compiler. We had no in-house compiler for the language we were using. When the 25,000 lines of code were compiled for the first time, there were 7 compilation errors.

  We continued using and refined the OOD process for our in-house software development efforts, eventually using it to produce almost 1,000,000 lines of source code."

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:

• Batch transformation

• Continuous transformation

• Interactive interface

• Dynamic simulation

• Real-time system

• Transaction manager

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:

• "object type" (page 452) which is equivalent to a class.

• "conception" (page 453) which is a privately-help concept.

• "functions" (page 454) which are defined as being "operations that do not change object state."

• "persistent object" (page 456) as an object that survives the invoked operation that creates it. (Most objects survive the operation that creates them, otherwise the object would not be available for any work. Usually persistence is a measure of whether an object survives the termination of the "program" or "system" that creates it, not the "invoked operation" that creates it.)

• "realm specification" (page 457) which identifies a set of object types specific to a realm of interest. This term seems to correspond closely to Coad and Yourdon's term "subject."

• "state" is defined as being "The collection of object types that applies to an object. An alternate, but equivalent, definition is that the state of an object is the collection of associations that an object has with other objects." (page 458) Since "object type" is defined as being the same as "class", this definition reads "the collection of classes that applies to an object." This definition is confusing, and appears erroneous.

• "type partition" is defined as a "division or partitioning of an object type into disjoint subtypes." (page 459) Other methods seem to accomplish this via "specialization" or "inheritance."

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

• Collaborations represent requests from a client to a server in fulfillment of a client responsibility. A collaboration is the embodiment of the contract between a client and a server. An object can fulfill a particular responsibility by itself, or it may require the assistance of other objects. We say that an object collaborates with another if, to fulfill a responsibility, it needs to send the other object any messages. A single collaboration flows in one direction - representing a request from the client to the server. From the client's point of view, each of its collaborations are associated with a particular responsibility implemented by the server. (Wirfs-Brock, page 90)

• Responsibilities include two key items:
  • The knowledge an object maintains, and

  • the actions an object can perform.

  Responsibilities are meant to convey a sense of the purpose of an object and its place in the system. The responsibilities of an object are all the services it provides for all the contracts it supports. When we assign responsibilities to a class, we are stating that each and every instance of that class will have those responsibilities, whether there is just one instance or many... Responsibilities are intended to represent only publicly available services. (Wirfs-Brock, pp. 61-62)

• A contract between two classes represents a list of services an instance of one class can request from an instance of the other class. (Wirfs-Brock, page 62)

• Frameworks are skeletal structures of programs that must be fleshed out to build a complete application. For example, a windowing system or a simulation system can both be viewed as frameworks fleshed out by a windowed application or a simulation, respectively... Frameworks typically use unmodified components as well as framework-specific extensions of components. They also typically use code unique to the framework. (Wirfs-Brock, page 13)

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:

• The end user - How quickly can this approach deliver my application or system and how much will it cost? In this case the process elements of the method is important (e.g., when, how much, who is involved?).

• The trainer - How difficult will it be to train staff in using this approach, and what kind of support is available? For this audience, the pragmatics are important (e.g., available training, outside consultants, and tools).

• The manager - What is the impact on my project plans, and how do I recruit or train people to use this approach? The audience is also interested in the process element, as well as the software engineering attributes (e.g., when, how much, and who is involved, as well as testability, reusability, etc.).

• The senior manager - How much risk is there in adopting this approach? Can I leverage investments in existing skills and tools, or must I start from scratch? What is the payback if I adopt this approach? The senior manager will be concerned with the process and pragmatics elements. Process elements provide visibility into the development effort, while pragmatics elements provide outside support.

• The developer - How will my existing skills be affected? Will I need to learn a few, or many new skills and tools? Will my position become obsolete? What will be the impact on my status in the organization? This audience will be interested in the notation, the concepts, and the process elements primarily.

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.

• Organization desires to explore object-oriented and is only interested in an answer to "what is an object?"

  Select top candidates from Concepts, therefore Booch, Berard, Colbert, and Wirfs-Brock.

• Organization is heavily vested in tools, technology, and training based on data modeling or information engineering, and desires minimal changes to this base.

  Select candidates that from Concepts that are not high in "object-orientedness." Rumbaugh, Shlaer and Mellor, and Kurtz and Embley are all evolutionary changes since they are not very "object-oriented." Since each approach still makes significant use of data modeling constructs, the impact on tools, technology, and training would be minimally impacted..

• Organization is engineering large application, with real-time constraints.

  Select from Process where the process deals with large application issues, and from Pragmatics based on project size and real-time support. Booch, Berard, Shlaer and Mellor, and possibly, Rumbaugh have demonstrated delivery of a significant number of efforts.

• Effort requires high testability and reliability.

  Select from Support for Software Engineering Principles and Goals where testability is addressed. Berard provides the most support, with Booch, Shlaer/Mellor, and Rumbaugh clustered thereafter.

• Effort is developing reusable components for commercial sale.

  Select Process and Pragmatics where developing for reuse is addressed. Support for Software Engineering Principles and Goals should also be reviewed. Berard and Booch provide the most support.

• Interested in a method where the only concern is that the development process is well-defined.

  Select those methods clustered high in Process. Rumbaugh, Shlaer and Mellor, Wirfs-Brock, Berard, and IBM are all relatively well-defined processes.

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.