Copyright The Object Agency, Inc., 1995
This report has been prepared to assist an organization in better evaluating the availability, and appropriateness of, of object-oriented methods for their environment.
Assumptions: This paper assumes the reader has a basic understanding of object-oriented concepts and object-oriented development in general.
The readers of methodology comparisons constitute a number of overlapping sets. For example:
This section will satisfy all three types of reader.
"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:
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.
Numerous object-oriented methodology comparisons currently exist in the literature. These include, for example:
This report compares a number of analysis and design methodologies. Analysis methodologies considered include: DeMarco Structured Analysis, Yourdon Modern Structured Analysis, Martin Information Engineering, Bailin OO Specification, Coad and Yourdon OO Analysis, Shlaer and Mellor OO Analysis. Design methodologies reviewed include: Yourdon and Constantine Structured Design, Martin Information Engineering, Wasserman OO Structured Design, Booch OO Design, and Wirfs-Brock Responsibility-Driven Design. Contact 617-253-2348 for pricing and availability.
This "white paper" compares the notations, terminologies, and models used in methods by: Booch, Coad and Yourdon, Edwards and Odell and Martin, Graham, Rumbaugh, Shlaer and Mellor, Wasserman and Pircher, and Wirfs-Brock. Contact SIGS Publications at 212-274-0640 for pricing and availability.
This study, conducted by Hewlett Packard, evaluates the methods of Booch, Buhr, Rumbaugh, Wirfs-Brock, and HOOD (Hierarchical Object-Oriented Design).
This article compares 23 object-oriented analysis and design methodologies to identify common themes, and strengths and weaknesses in object-oriented analysis and design methods in general.
This report compares the background ideas, steps, concepts, notations, communication mechanism, and the specification techniques of six accepted methods, that are available in textbooks. The comparison is performed by meta-modeling, yielding detailed information on concepts (in EER notation) and steps (in task diagrams). Extensive comparison tables of steps, concepts, techniques are included, as well as mappings of the methodical concepts to the constructs of programming languages (Smalltalk, C++, Eiffel, and others) Six methods are: Booch, Martin/Odell, Coad/Yourdon, Rumbaugh, Wirfs-Brock, Shlaer/Mellor.
Available for North America through OSoft Development Corp. Call 404-875-2216 for pricing and availability. Elsewhere call +31.53.893690 (Netherlands) or mail to email@example.com.
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 firstname.lastname@example.org or email@example.com.
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
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:
are clear indicators of this problem. These studies yield numerical results, which are then often used independent of their context and their cited caveats.
A complete methodology is far more than a notation, process, and tools. For example, most of the available object-oriented methodology books range in page count from 200 - 600 pages in length, and from U.S. $25.00 to U.S. $60.00. Yet there are organizations who attempt to create fully elaborated methodologies, considering cradle to grave software support. For instance, Ernst and Young's Navigator method and Arthur Andersen's Foundation method (available from two information systems consulting firms) consists of thousands of pages bound in a number of three-ring binders, are provided on a number of CD-ROMs, are coordinated with extensive training, and cost in excess of U.S. $25,000. In addition to a "notation, process, and tools," these "complete methodologies" provide:
As of September 1992, none of the reviewed object-oriented methodology texts provide this degree of support, nor should they be expected to. As such, the evaluation and comparison of methodologies must be done with the knowledge that, for all methods reviewed, there still remains a great deal of work to be done before these methods are fully elaborated.
Setting the comments made above aside, this section uses the term "methodology" as consisting of a notation and a process, as well as being published in either a book or refereed journal.
This report 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:
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.
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".
The process component of the this comparison is used to characterize within what development contexts the method is appropriate, how much of the systems development life-cycle is covered by the method, and what tailoring or heuristics are available for the method's process.
A development context specifies whether the effort is useful in creating new software, reengineering or reverse engineering existing software, prototyping, or designing for or with reuse components.
Greenfield development is "new" development or development pursued outside any existing software. No regard is paid to legacy systems or any existing software.
Reengineering (or reverse engineering, depending upon the definition one uses) involves enhancing an existing system to improve or make more useful an existing application. The process involves employing methods and tools to understanding existing and legacy systems and maintaining their value as assets for organizations. Reengineering involves learning how to manage such systems effectively, capturing their essential design, identifying their structure and content, and enabling their renovation to meet the needs of the business they are meant to support.
Some methods strongly recommend prototyping as a key component of their process, while some other methods processes can be characterized as being prototyping, albeit in a more formal manner. The adaptability of a method to use, or not use, prototyping, is an additional process characteristic.
The support for reuse is evaluated for each method. Methods that explicitly address reuse provide steps, deliverables, and heuristics for the identification, construction, testing, demonstration, and application of reusable components. One of the touted benefits of object-oriented approaches, as well as extensions to other disciplines such as Information Engineering (Martin, 1990), is their ability to create, as well as incorporate, reusable components. Through such reuse significant productivity gains are touted. Each method is evaluated to determine its support for the incorporation of reusable components, as well as the methods facility in creating reusable components.
Life-cycle coverage of each method is then evaluated. Life-cycle coverage of the particular method involves ascertaining what elements of software development is dealt with within the method. Each methodology may have elements that are useful to a portion of the development life cycle. For the purposes of this discussion, the life cycles phases are defined as follows:
Next evaluated are the properties or attributes of the method's process. A process's properties serve as a measure of the method's repeatability and flexibility. The properties should defined the sequence of steps, required inputs and outputs, involved roles, as well as interaction with other steps. Optional steps should be clearly identified. Available heuristics and mechanisms for traceability, verification, and validation of the process are also desirable attributes of a well-defined process.
This section considers the pragmatics of the methodology. A methodology's pragmatics consists of:
This section considers the method's support for software engineering goals and principles. In particular, each method is appraised for:
The final section of this section addresses an issue of comparing methodologies that is seldom made explicit, that of the "marketability" of the method. A common flaw in many methodology comparisons (especially those conducted in-house by a corporation) is that prior to conducting the comparison some assumptions are made that in many instances bias the results dramatically. Some of these "marketing" factors can include, for example:
The above "marketability" criteria have little to do with the cleanness or usefulness of a particular method. In many instances these criteria are totally corporation-specific, and will vary from company to company. While any study must address these issues, they should be placed in an appropriate context. This section isolates these concerns to a specific section.
This section attempts to avoid the problems encountered in prior comparisons in the following way.
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.
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:
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(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:
Colbert, consisting of:
Coad and Yourdon, consisting of:
[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:
IBM, consisting of:
[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:
Rumbaugh, consisting of:
Shlaer and Mellor, consisting of:
[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:
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.
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 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:
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.
-- 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
... 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
-- 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."
-- 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:
-- 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.)
-- 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.
-- 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.
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|
|Coad and Yourdon||X||-||X||-|
|Martin and Odell||X||-||-||-|
|Shlaer and Mellor||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|
|Coad and Yourdon||-||X||X||-||-|
|Martin and Odell||X||X||-||-||-|
|Shlaer and Mellor||-||-||-||-||-|
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|
|Coad and Yourdon||-||X||-||-|
|Martin and Odell||-||-||-||X|
|Shlaer and Mellor||-||X||X||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.
|Coad and Yourdon||X||X||-||-|
|Martin and Odell||-||-||-||-|
|Shlaer and Mellor||-||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:
|Roles played by persons or organizations||doctor
performance (of a play, etc.)
an electrical network
|Specifications||insurance policy types|
Coad and Yourdon recommend searching for objects through the following sources:
These two approaches, while useful, are limited. Booch and Berard, on the other hand, discuss object-oriented domain analysis, which while much more involved than the straightforward guidelines presented above, appears much richer from the standpoint of identifying related objects in a coherent and repeatable manner.
Generally speaking, their appears to be a continuum of "object-orientedness" of the reviewed methods. Booch, Berard, Colbert, and Wirfs-Brock seem to be the most object-oriented, with their strict emphasis on objects, and downplaying of associations and relationships. Coad and Yourdon and IBM seem to be next, with accommodations for data (attributes and instance variables). Rumbaugh, Embley and Kurtz, and Shlaer and Mellor cluster next, with a strong emphasis on associations and relationships almost at a level making these items peers of objects. Martin and Odell is the least object-oriented, seemingly presenting slight extensions to information engineering with a very heavy behavioral orientation.
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.
|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|
|7.||System of Interacting Objects||pp. 175-176|
|8.||Program Unit Graphic||page 236|
|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)|
|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)|
|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)|
|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)|
|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)|
|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)|
|1.||Object Model Used to describe classes, objects, attributes, operations, specialization, generalization, and inheritance.||(page 44)|
|2.||Dynamic Model consisting of:||-|
|-||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|
|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)|
|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)|
Each methodology was evaluated as to how it represented the following concepts:
These questions, while not exhaustive, provide an indication as to how the models are used within the method.
|Method||Aggregation||Specialization||Communication||Module Interfaces||Qualifications for Reuse|
|Berard||Semantic Net||Semantic Net||Object Message Diagram||Program Unit Graphic||Semantic Net|
|Booch||Class Diagram||Class Diagram||Class Diagram||Module||Object Diagram|
|Coad and Yourdon||Whole-Part||Gen-Spec||Message||-||-|
|Colbert||Object Hierarchy||Object-Class Diagram||Object-Interaction||Ada Structure||Object-Class|
|Embley and Kurtz||Object Relationship Model||Object Relationship Model||Object Relationship Model||-||-|
|Martin and Odell||Composed-Of||Object Generalization||Object Flow||-||-|
|Rumbaugh||Object Model||Object Model||Scenario||-||-|
|Shlaer and Mellor||-||Inheritance||Object Communication||Class Diagram||-|
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.
The representation of state changes, timing, and object interactions over time are essential elements for modeling the behavior of systems.
|Berard||State Transition/Petri Net||Timing Diagram|
|Booch||State Transition||Timing Diagram|
|Coad and Yourdon||State Diagram||-|
|Embley and Kurtz||State Net||State Net|
|Martin and Odell||State Change||-|
|Rumbaugh||State Diagram||Extended State|
|Shlaer and Mellor||State Model||-|
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.
|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|
|Coad and Yourdon||Y||Y||Y||Y|
|Embley and Kurtz||Y||Y||Y||Y|
|Martin and Odell||Y||Y||Y||-|
|Shlaer and Mellor||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.
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.
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.
|Berard||Kits, Systems of Interacting Objects|
|Coad and Yourdon||Subjects|
|Colbert||Scale of Objects( Systems are Objects)|
|Embley and Kurtz||High-Level Views|
|Martin and Odell||-|
|Shlaer and Mellor||Subsystems|
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.
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.
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.
Coad and Yourdon
Embley and Kurtz
Martin and Odell
Shlaer and Mellor
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.
An attribute of any development process is the number and types of deliverables the process generates. Life-cycle documentation generally includes requirements specifications, design specifications, system and subsystem specifications, as well as test cases. Specifically, in object-oriented development, the requirement that object and classes also be specified surfaces. The deliverables for each method are evaluated using the following criteria:
The evaluation results in the following table:
|Method||Requirement Specification||Design Specification||Test Cases||Object/Class Specification||Subsystem Specification||Totals|
|Coad and Yourdon||2||2||0||5||0||9|
|Embley and Kurtz||5||1||0||1||1||8|
|Martin and Odell||0||0||0||0||0||0|
|Shlaer and Mellor||5||5||0||5||4||19|
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.
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|
|Coad and Yourdon||Y||-||Y||Y||Y||-||4|
|Embley and Kurtz||Y||-||-||-||-||-||1|
|Martin and Odell||Y||-||Y||-||Y||-||3|
|Shlaer and Mellor||Y||-||-||-||-||-||1|
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.
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.
|Coad and Yourdon||-||-||page 25||-|
|Embley and Kurtz||-||-||pp. 135-136, 143-148,159-165||-|
|IBM||-||-||-||pp. 13-14 (indeterminate)|
|Martin and Odell||-||-||-||pp. 444-445 (indeterminate)|
|Shlaer and Mellor||-||-||-||indeterminate|
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.
Life cycle coverage provides an indication of the completeness of the methodology. A methodology that covers all aspects of the system development life-cycle offers an attractive solution to the organization in that the methodology itself ensures completeness and consistency. If an organization, for example, is required or decides to "mix and match" one methodology's analysis approach with another methodology's design approach, the organization must take responsibility for the consistency and completeness of transition from one life cycle phase to another. Such "mix and match" strategies introduce an element of risk into the approach.
Booch (Booch, page 201) notes, for example:
Therefore, more complete life cycle coverage is preferable to more limited life cycle coverage. In the following table, the values presented reflect the following:
|Method||Enterprise Modeling||Domain Analysis||Requirement Analysis||Design||Implement||Test||Total|
|Coad and Yourdon||0||1||5||5||3||3||17|
|Embley and Kurtz||0||0||5||1||0||0||6|
|Martin and Odell||1||0||3||5||0||0||9|
|Shlaer and Mellor||0||0||5||5||1||0||11|
Each methodology should describe a process which, if followed, should yield an appropriate set of products (e.g., analysis products, design products, code, and test cases). The clarity of a process simplifies the execution and introduction of the process into a development organization. A well-defined process has the following attributes:
While the above may appear overly rigorous, they provide a comparison mechanism for ascertaining the completeness of each methodology's process definition.
|Coad and Yourdon||Y||-||Y||Y||Y||4|
|Embley and Kurtz||Y||-||Y||-||-||2|
|Martin and Odell||Y||-||-||Y||-||2|
|Shlaer and Mellor||Y||-||Y||-||-||2|
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.
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.
|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||-||-||-||-||-|
|Embley and Kurtz||-||-||-||-||-|
|Martin and Odell||-||-||-||-||page 443|
|Shlaer and Mellor||-||-||-||-||-|
Only Berard spends any significant text in describing the roles and responsibilities associated with object-oriented development. Martin and Odell cite roles such as "workshop leader," "scribe," "rapid prototyper," and "modeling expert." These roles seem to be carryover from Martin's Rapid Application Development (RAD) approach, and are not additionally elaborated for their need or purpose in object-oriented development. In point of fact, Martin states "The modeling expert is typically part of the data-administration staff." This seems to imply that little organization change is required in adopting OO technology. Booch, on the other hand, notes (Booch, page 207):
Generally speaking, this area of the methodologies needs significant expansion. Only (Berard(a)) deals with this subject at length, devoting 45 pages to role descriptions.
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|
|Coad and Yourdon||3||3||0||0||1||7|
|Embley and Kurtz||3||3||1||1||3||11|
|Martin and Odell||3||3||1||-||3||10|
|Shlaer and Mellor||3||1||1||3||3||11|
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.
|Berard||pp. 196, 213||pp. 206-207|
|Coad and Yourdon||-||page 197|
|Embley and Kurtz||-||-|
|Martin and Odell||-||-|
|Shlaer and Mellor||-||-|
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)
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.
|Coad and Yourdon||Provided|
|Embley and Kurtz||Provided|
|Martin and Odell||-|
|Shlaer and Mellor||Provided|
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.
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.
|Coad and Yourdon||Prototype|
|Embley and Kurtz||-|
|Martin and Odell||Prototype|
|Shlaer and Mellor||-|
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.
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).
|Coad and Yourdon||-||Y||-|
|Embley and Kurtz||-||Y||-|
|Martin and Odell||-||Y||-|
|Shlaer and Mellor||-||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).
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:
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.
This question attempts to ascertain whether the life cycle presented by the methodology differs dramatically from the development life cycle of other approaches. Many conventional development efforts exhibit a 40-20-40 distribution between analysis and design, coding, and testing and integration.
Little information is presented specifically regarding the life cycle efforts involved in each of the methods. Only Booch provides specifics in a graphic on page 207. Extrapolated from the graphic are the following percentages:
Anecdotal information provides some insight. Rumbaugh discusses an object diagram compiler developed using Rumbaugh's OMT.
Berard (Richardson et al., pp. v-vi) presents the following anecdote concerning the developing of a complexity measures tool in 1984, using his OOD approach as defined then:
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.
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.
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.
|Booch||Both||At least 2||Y||1||1|
|Coad and Yourdon||Both||1||Y||2||-|
|Embley and Kurtz||-||-||-||1||-|
|Martin and Odell||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.
"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.
|Coad and Yourdon||Y||Y||-||Y||Y|
|Embley and Kurtz||Y||Y||Y||Y||-|
|Martin and Odell||-||-||-||-||-|
|Shlaer and Mellor||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.
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.
|Coad and Yourdon||Low|
|Embley and Kurtz||High|
|Martin and Odell||High|
|Shlaer and Mellor||High|
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.
|Coad and Yourdon||Y||-||Y||Y||-||3|
|Embley and Kurtz||-||-||-||-||-||0|
|Martin and Odell||-||-||-||-||-||0|
|Shlaer and Mellor||Y||-||-||Y||-||2|
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.
(Rumbaugh, pp. 211-212) identifies a spectrum of software domains, including but not limited to:
While these classifications are useful, the criteria selected compares information systems, real-time embedded systems, and component libraries (e.g., class libraries and application frameworks) as a more discrete criteria of comparison. Examples and anecdotes presented in each methodology were reviewed to identify support for each software domain.
|Coad and Yourdon||Y||?||?|
|Embley and Kurtz||Y||Y||?|
|Martin and Odell||Y||N||?|
|Shlaer and Mellor||Y||Y||?|
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.
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|
|Coad and Yourdon||7|
|Embley and Kurtz||-|
|Martin and Odell||2|
|Shlaer and Mellor||3|
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.
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.
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 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|
|Coad and Yourdon||Y||Y||Y||-|
|Embley and Kurtz||-||-||-||-|
|Martin and Odell||Y||Y||Y||-|
|Shlaer and Mellor||-||-||-||-|
(Shlaer and Mellor(a), pp. 123-124) do discuss reuse, but only in terms of reusing processes, and not objects or classes.
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|
|Booch||page 206||-||-||page 279|
|Coad and Yourdon||-||-||-||-|
|Embley and Kurtz||-||-||-||-|
|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 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 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:
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:
|Method||Introduced Term||Carry Over||New||Alias||Redefined|
|-||system of interacting objects||-||Y||-||-|
|Coad and Yourdon||subject||-||-||Y||-|
|Embley and Kurtz||action||Y||-||-||-|
|Martin and Odell||object type||-||-||Y||-|
|Shlaer and Mellor||-||-||-||-||-|
Berard introduces the concepts of "kits" and "systems of interacting objects." In other methods these are both referred to as "frameworks" (Wirfs-Brock) and "subsystems" (Booch, Rumbaugh, Shlaer/Mellor, Wirfs-Brock) respectively.
Coad and Yourdon introduce the term Services to represent what other methods term "operations".
The term "subject" is introduced as a partitioning mechanism, which some other methods may term "domain". (Coad and Yourdon, page 106) define Subject as "a mechanism for guiding a reader (analyst, problem domain expert, manager, client) through a large, complex model." Other methods use the term "domain", but since there is no rigor associated with the creation of subjects, and normally there is some rigor in the specification of domains, the term domain is not equivalent.
Embley and Kurtz use the term "actions" to represent operations.
Martin and Odell introduces a number of new terms, or variants of terms in common use. These include:
Wirfs-Brock introduces the terms collaboration, responsibility, contract, and frameworks.
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)
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.
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.
The marketability of something is a measure of how easily it can be sold, introduced, and adopted by an organization. Marketing an object-oriented methodology to an organization is a formidable task, largely because different audiences are concerned with different attributes of a methodology. With regards to a methodology, such audiences and their perspectives include:
By evaluating each of these audience's concerns, the initiator of technology adoption can prepare a strategy to evaluate and assess the appropriateness of a new method for their organization. In addition, the initiator must be aware that generally speaking, more evolutionary approaches are adopted more successfully than revolutionary approaches. The reasons for this are obvious. Yet in many cases the benefits from such incremental change is less than for more radical change. In effect, with radical change can come high benefits and high risk. Less radical change brings less risk and less benefit.
The marketability, and eventual selection, of any methodology for an organization is very dependent on the current status and direction of the organization with regards to software. Some organizations may be interested in increased productivity, or increased quality, or reduced maintenance costs, or improved portability, or some combination of these, and possibly other, factors. Therefore, the purpose of the following questions is to illustrate how candidate methods can be selected based on the content of the questions and the results of this comparison.
The conclusions of each of the prior sections of this section resulted in the following clusters.
From the Concepts Analysis: Generally speaking, their appears to be a continuum of "object-orientedness" of the reviewed methods. Booch, Berard, Colbert, and Wirfs-Brock seem to be the most object-oriented, with their strict emphasis on objects, and downplaying of associations and relationships. Coad and Yourdon and IBM seem to be next, with accommodations for data (attributes and instance variables). Rumbaugh, Embley and Kurtz, and Shlaer and Mellor cluster next, with a strong emphasis on associations and relationships almost at a level making these items peers of objects. Martin and Odell are the least object-oriented, seemingly presenting slight extensions to information engineering with a very heavy behavioral orientation.
From the Notations Analysis: Well-defined notations include Kurtz and Embley, Rumbaugh, Shlaer and Mellor, Booch, Coad and Yourdon, Wirfs-Brock. Methods requiring additional elaboration regarding their notations include Colbert, Martin and Odell, Berard, and IBM. This is not to indicate that the notations are not complete, simply that insufficient information was provided to assess the completeness. Berard does provide a fairly complete set of examples so that much of the notation can be deduced from the examples supplied.
From the Process Analysis: Process definition varies dramatically from method to method. Rumbaugh, Shlaer and Mellor, Wirfs-Brock, Berard, and IBM each have relatively well-elaborated processes. Colbert and Embley and Kurtz are less defined, but still relatively clear. Martin and Odell presents little in terms of a process definition. There is little to indicate how and where each model is to be developed during the process. In addition, Martin and Odell seem to be relying on I-CASE (integrated computer aided software engineering) technology to assist in the effort. Such tool support is not demonstrated to be adequate to support the object-oriented development effort.
From the Pragmatics Analysis: In terms of general pragmatics, Booch, Coad and Yourdon, Rumbaugh, and Shlaer/Mellor are each well-supported, with a significant number of tools. The greatest depth of object-oriented training is from Berard. Embley and Kurtz and IBM do not have any commercially available tools supporting their methods.
From the Software Engineering Support Analysis: With regards to support for software engineering principles and goals, only Berard and Booch stand out. In general, the issues of testability, traceability, reusability, and conceptual integrity are only lightly addressed, if addressed at all, by the other methods reviewed.
Based on the above analyses, the following questions are postulated, and answers proposed.
Select top candidates from Concepts, therefore Booch, Berard, Colbert, and Wirfs-Brock.
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..
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.
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.
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.
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!
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.