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.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more