OOAD Methodologies

OOAD Methodologies

OOAD methodologies fall into two basic types. The ternary (or three-pronged) type is the natural evolution of existing structured methods and has three separate notations for data, dynamics, and process. The unary type asserts that because objects combine processes (methods) and data, only one notation is needed. The unary type is considered to be more object-like and easier to learn from scratch, but has the disadvantage of producing output from analysis that may be impossible to review with users.
Dynamic modeling is concerned with events and states, and generally uses state transition diagrams. Process modeling or functional modeling is concerned with processes that transform data values, and traditionally uses techniques such as data flow diagrams.

Booch

Grady Booch's approach to OOAD ( Object-Oriented Design with Applications, Benjamin/Cummings, 1994) is one of the most popular, and is supported by a variety of reasonably priced tools ranging from Visio to Rational Rose. Booch is the chief scientist at Rational Software, which produces Rational Rose. (Now that James Rumbaugh and Ivar Jacobson have joined the company, Rational Software is one of the major forces in the OOAD world.)
Booch's design method and notation consist of four major activities and six notations, as shown schematically in Table.
While the Booch methodology covers requirements analysis and domain analysis, its major strength has been in design. However, with Rumbaugh and Jacobson entering the fold, the (relative) weaknesses in analysis are disappearing rapidly. Booch represents one of the better developed OOAD methodologies, and now that Rational Rose is moving away from its previous tight link with C++ to a more open approach that supports 4GLs such as PowerBuilder, the methodology's popularity should increase rapidly.
For systems with complex rules, state diagrams are fine for those with a small number of states, but are not usable for systems with a large number of states. Once a single-state transition diagram has more than eight to 10 states, it becomes difficult to manage. For more than 20 states, state transition diagrams become excessively unwieldy.

Coad and Yourdon

Coad and Yourdon published the first practical and reasonably complete books on OOAD (Object-Oriented Analysis and Object-Oriented Design, Prentice-Hall, 1990 and 1991, respectively). Their methodology focuses on analysis of business problems, and uses a friendlier notation than that of Booch, Shlaer and Mellor, or the others that focus more on design.
In Coad and Yourdon, analysis proceeds in five stages, called SOSAS:
* Subjects: These are similar to the levels or layers in data-flow diagrams and should contain five to nine objects.
* Objects: Object classes must be specified in this stage, but Coad and Yourdon provide few guidelines for how to do this.
* Structures: There are two types: classification structures and composition structures. Classification structures correspond to the inheritance relationship between classes. Composition structures define the other types of relationships between classes. Coad and Yourdon do not deal as well as Rumbaugh, Jacobson, and several other methodologies do with these structures.
* Attributes: These are handled in a fashion very similar to that in relational analysis.
* Services: The identification of what other methodologies call methods or operations.
In design, these five activities are supplanted by and refined into four components:
* problem domain component: classes that deal with the problem domain; for example, Customer classes and Order classes
* human interaction component: user-interface classes such as window classes
* task management component: system-management classes such as error classes and security classes
* data management component: database access method classes and the like
Although Coad and Yourdon's methodology is perhaps one of the easiest OO methodologies to learn and get started with, the most common complaint is that it is too simple and not suitable for large projects. However, if you adhere to a premise that you should use those pieces of a methodology that work, and add other parts from other methodologies as required, Coad and Yourdon's methodology is not as limiting as its critics claim.

Fusion

In 1990, Derek Coleman of Hewlett-Packard led a team in the U.K. to develop a set of requirements for OOAD, and conducted a major survey of methods in use at HP and elsewhere. The chief requirement was a simple methodology with an effective notation.
The result was Fusion, which Coleman and others developed by borrowing and adapting ideas from other methodologies. They incorporated some major ideas from Booch, Jacobson, Rumbaugh, and others, and explicitly rejected many other ideas from these methodologies. Articles that Fusion practitioners have written have been some of the most pragmatic and useful about OOAD, but, unless you conduct a significant research effort, you generally hear much more about other methodologies than about Fusion.
Coleman did not use some of the major components of Rumbaugh and Shlaer and Mellor in Fusion, because the components were not found to be useful in practice. Some writers have called this encouraging and remarkable, and consider it indirect proof that excessive emphasis on state models comes from Rumbaugh and Shlaer and Mellor's telecommunications and realtime system backgrounds.
Fusion's pragmatic approach seems to hold considerable potential for client/server applications, but this methodology is not being marketed as aggressively as most of the other methodologies.

Jacobson: Objectory and OOSE

Although Jacobson's full OOAD methodology, Objectory, is proprietary (to use it you must buy consulting services and a CASE tool, OrySE, from Rational Software), it is probably the most serious attempt by an OOAD tool vendor to support the entire software development life cycle. Jacobson is considered to be one of the most experienced OO experts for applying OO to business problems such as client/server applications.
Jacobson's Object-Oriented Software Engineering (OOSE) is a simplified version of Objectory, which Jacobson himself has declared inadequate for production applications. According to Jacobson: "You will need the complete ... description which, excluding large examples, amounts to more than 1200 pages" (Object-Oriented Systems Engineering, Addison-Wesley, 1992).
Object modeling and many other OO concepts in Objectory and OOSE are similar to OO concepts in other methodologies. The major distinguishing feature in Jacobson is the use case. A use-case definition consists of a diagram and a description of a single interaction between an actor and a system; the actor may be an end user or some other object in the system. For example, the use-case description of an order-entry application would contain a detailed description of how the actor (the user) interacts with the system during each step of the order entry, and would include descriptions of all the exception handling that might occur.
According to Jacobson, a use case is any description of a single way to use a system or application, or any class of top-level usage scenario, that captures how actors use their black-box applications. An actor is an interface to the system, that is, something with which the system communicates, and may be a person or another program. Jacobson adds that a use case is any behaviorally related sequence of transactions that a single actor performs in a dialog with a system, in order to provide some measurable value to the actor.
Generally, you employ use cases to document user requirements in terms of user dialogs with a system. Use cases appear first in the requirements model, and are then used to generate a domain object model with objects drawn from the entities of the business as mentioned in the use cases. This is then converted into an analysis model by classifying the domain objects into three types: interface objects, entity objects, and control objects.
The big danger with OOSE is the assumption that you can express all sequences and business in use cases. One of my best object analysts ran into major difficulties while trying to force a large, complex client/server application into the Jacobson methodology. Several major authors have subsequently declared that for many complex systems and almost all expert systems, it cannot be done.
However, the use-case descriptions and their corresponding interaction diagrams can provide a very useful view of many parts of a system, and Objectory and OOSE have a good, simple notation. For client/server applications with rules of typical, rather than extreme, complexity, Jacobson provides a sound approach. The use-case analyses are easier to review with end users than is much of the output from other OO analysis methodologies; and use cases use narrative descriptions in plain English and are much easier to review with individuals who are not OO experts than are object models with object interaction diagrams.

LBMS SEOO

Systems Engineering OO (SEOO) is a proprietary methodology and toolkit from the U.K.-based company LBMS, which has its U.S. headquarters in Houston. SEOO is tightly integrated with Windows 4GLs such as PowerBuilder, and is perceived to be a very pragmatic and useful tool, but this perception may be due in part to a stronger marketing effort than is often made for nonproprietary methodologies. LBMS focuses on selling CASE tools that support its methodology, and SEOO is the only methodology described in this article that is not documented in a published book.
Because SEOO is proprietary, there is not as much detailed information available about it as there is about other methodologies, and it is somewhere between difficult and impossible to try it out just to compare it with the others.
The four major components of the SEOO methodology are:
* work-breakdown structures and techniques
* an object modeling methodology
* GUI design techniques
* relational database linkages to provide ER modeling and 4GL-specific features
Of all the major OOAD approaches, only SEOO gives the feeling of having started with non-OO approaches and then adapting to OO. A very positive aspect of this is the heavy focus on data management and data modeling. SEOO is intended to be object oriented while retaining the advantages of traditional data modeling. This makes the methodology well-suited for client/server database applications.
SEOO is unique in treating data, triggers, and referential-integrity rules as a set of shared objects in a database. It treats a data model as a view of the shared objects, which also include constraints, rules, and dynamics (state transitions and so on). SEOO draws a clear line between shared objects and other objects, and regards the shared objects as important interfaces between subsystems. This technique allows a distinction, for example, between customer behavior shared by all applications and customer object behavior unique to a single application. It is a technique with which a purist would quibble, but which is eminently practical.

Rumbaugh OMT

James Rumbaugh's methodology, as described in his book Object-Oriented Modeling and Design (Prentice-Hall, 1991), has always been one of my favorites. It offers one of the most complete descriptions yet written of an OO analysis methodology. Although it is somewhat lacking in OO design and construction, it contains a large number of ideas and approaches that are of significant use to analysts and designers.
Rumbaugh starts by assuming that a requirements specification exists. Analysis consists of building three separate models:
* the Object Model (OM): definition of classes, together with attributes and methods; the notation is similar to that of ER modeling with methods (operations) added
* the Dynamic Model (DM): state transition diagrams (STDs) for each class, as well as global event-flow diagrams
* the Functional Model (FM): diagrams very similar to data flow diagrams
Because Rumbaugh's notation (as well as that of Booch and Shlaer and Mellor) is supported by low-end drawing tools such as Visio, I have used it not only for OO analysis, but for a number of diagrams in recent proposals. For example, I recently drew a diagram of project deliverables (in a proposal for a large OO development project) using Visio and Rumbaugh notation to show the object hierarchy of deliverables which, at the first level of inheritance, included hardware, software, and printed deliverables.
Of the major methodologies, Rumbaugh's is one of those with which I feel most comfortable. It supports many traditional diagrams from structured methodologies, and contains a much richer object modeling notation than Coad and Yourdon's. Its weakness at this time is that is it less useful for client/server application design and construction, but experienced analysts can overcome this with enough experience with class libraries for their development tool, if they have successfully completed other OO projects.

Shlaer and Mellor OO Analysis

When Shlaer and Mellor OO analysis first came out in 1988, it represented one of the earliest examples of OO methodology and it has evolved very positively since then. (See Shlaer and Mellor's books, Object-Oriented Systems Analysis -- Modeling the World in Data and Object Lifecycles: Modeling the World in States, Prentice-Hall, 1988 and 1992, respectively.)
Originally an object-based extension of data modeling, the Shlaer and Mellor methodology starts with an information model describing objects, attributes, and relationships. (Note that this is more like a data model than an object model.) Next, a state model documents the states of objects and the transitions between them. Finally, a data-flow diagram shows the process model.
This methodology seems to be influenced strongly by relational design, but I have not seen it used for client/server development. This does not mean that it is not usable for such work, but the applications occasionally cited as examples of its use seem to be in the areas of real-time or process control. This may have to do with the fact that an earlier version, the Ward/Mellor approach, is widely used in the realtime world.

The Steps in Booch's Methodology

Steps Notations
Logical structure Class Diagrams, Object Diagrams
Physical structure Module Diagrams,Process Diagrams
Dynamics of Classes State Transition Diagrams
Dynamics of Instances Timing Diagrams