The OOA Landscape

21.1.2 The OOA Landscape

The popularity of object technologies spawned dozens of OOA methods during the late 1980s and into the 1990s. 2 Each of these introduced a process for the analysis

1 In this context, entity refers to either a data object (in the structured analysis sense) or an object (in the OOA sense).

2 A detailed discussion of these methods and their differences is beyond the scope of this book. In addition, the industry is moving toward a unified method of analysis modeling, making a detailed discussion of older methods useful for historical purposes only. The interested reader should refer to Berard [BER99] and Graham [GRA94] for detailed comparisons.

of a product or system, a set of diagrams that evolved out of the process, and a nota- tion that enabled the software engineer to create the analysis model in a consistent manner. Among the most widely used were 3

The Booch method. The Booch method [BOO94] encompasses both a “micro development process” and a “macro development process.” The micro level defines a set of analysis tasks that are reapplied for each step in the macro process. Hence, an evolutionary approach is maintained. Booch’s OOA micro development process identifies classes and objects and the semantics of classes and objects and defines relationships among classes and objects and conducts a series of refinements to elaborate the analysis model.

The Rumbaugh method. Rumbaugh [RUM91] and his colleagues devel- “The central activity

of working with oped the object modeling technique (OMT) for analysis, system design, and objects is not so

object-level design. The analysis activity creates three models: the object much a matter of

model (a representation of objects, classes, hierarchies, and relationships), programming as it is

the dynamic model (a representation of object and system behavior), and the representation.” functional model (a high-level DFD-like representation of information flow

David Taylor

through the system). The Jacobson method. Also called OOSE (object-oriented software engi-

neering), the Jacobson method [JAC92] is a simplified version of the propri- etary objectory method, also developed by Jacobson. This method is differentiated from others by heavy emphasis on the use-case—a description or scenario that depicts how the user interacts with the product or system.

The Coad and Yourdon method. The Coad and Yourdon method [COA91] is often viewed as one of the easiest OOA methods to learn. Modeling nota- tion is relatively simple and guidelines for developing the analysis model are straightforward. A brief outline of Coad and Yourdon’s OOA process follows:

• Identify objects using “what to look for” criteria. • Define a generalization/specification structure. • Define a whole/part structure. • Identify subjects (representations of subsystem components). • Define attributes. • Define services.

The Wirfs-Brock method. Wirfs-Brock, Wilkerson, and Weiner [WIR90] do not make a clear distinction between analysis and design tasks. Rather a continuous process that begins with the assessment of a customer specifica- tion and ends with design is proposed. A brief outline of Wirfs-Brock et al.'s analysis-related tasks follows:

3 In general, OOA methods are identified using the name(s) of the developer of the method, even if the method has been given a unique name or acronym.

• Evaluate the customer specification. • Extract candidate classes from the specification via grammatical parsing. • Group classes in an attempt to identify superclasses. • Define responsibilities for each class. • Assign responsibilities to each class. • Identify relationships between classes. • Define collaboration between classes based on responsibilities. • Build hierarchical representations of classes. • Construct a collaboration graph for the system.

Although the terminology and process steps for each of these OOA methods dif- fer, the overall OOA processes are really quite similar. To perform object-oriented analysis, a software engineer should perform the following generic steps:

1. Elicit customer requirements for the system. are applied during

A set of generic steps

2. Identify scenarios or use-cases. OOA, regardless of the analysis method that is

3. Select classes and objects using basic requirements as a guide. chosen.

4. Identify attributes and operations for each system object.

5. Define structures and hierarchies that organize classes.

6. Build an object-relationship model.

7. Build an object-behavior model.

8. Review the OO analysis model against use-cases or scenarios. These generic steps are considered in greater detail in Sections 21.3 and 21.4.