The OOD Landscape
22.1.3 The OOD Landscape
As we noted in Chapter 21, a wide variety of object-oriented analysis and design methods were proposed and used during the 1980s and 1990s. These methods estab- lished the foundation for modern OOD notation, design heuristics, and models. A brief overview of the most important early OOD methods follows:
The Booch method. As we noted in Chapter 21, the Booch method [BOO94] encompasses both a “micro development process” and a “macro development process.” In the design context, macro development encom- passes an architectural planning activity that clusters similar objects in sepa-
“There is no reason why the transition
rate architectural partitions, layers objects by level of abstraction, identifies from requirements to
relevant scenarios, creates a design prototype, and validates the design pro- design should be
totype by applying it to usage scenarios. Micro development defines a set of any easier in
“rules” that govern the use of operations and attributes and the domain-spe- software engineering
than it is in any cific policies for memory management, error handling, and other infrastruc- other engineering
ture functions; develops scenarios that describe the semantics of the rules discipline. Design is
and policies; creates a prototype for each policy; instruments and refines the hard.”
prototype; and reviews each policy so that it “broadcasts its architectural
Alan Davis
vision” [BOO94]. The Rumbaugh method. The object modeling technique [RUM91] encom-
passes a design activity that encourages design to be conducted at two differ- ent levels of abstraction. System design focuses on the layout for the components that are needed to construct a complete product or system. The analysis model is partitioned into subsystems, which are then allocated to processors and tasks. A strategy for implementing data management is defined and global resources and the control mechanisms required to access them are identified.
Object design emphasizes the detailed layout of an individual object. Oper- ations are selected from the analysis model and algorithms are defined for each operation. Data structures that are appropriate for attributes and algo- rithms are represented. Classes and class attributes are designed in a manner that optimizes access to data and improves computational efficiency. A mes- saging model is created to implement the object relationships (associations).
CHAPTER 22
OBJECT-ORIENTED DESIGN
The Jacobson method. The design activity for OOSE (object-oriented soft- ware engineering) [JAC92] is a simplified version of the proprietary objectory method, also developed by Jacobson. The design model emphasizes trace- ability to the OOSE analysis model. First, the idealized analysis model is adapted to fit the real world environment. Then primary design objects,
called blocks, 2 are created and categorized as interface blocks, entity blocks, and control blocks. Communication between blocks during execution is defined and the blocks are organized into subsystems.
The Coad and Yourdon method. The Coad and Yourdon method for OOD [COA91] was developed by studying how “effective object-oriented design- ers” do their design work. The design approach addresses not only the appli- cation but also the infrastructure for the application and focuses on the representation of four major system components: the problem domain com- ponent, the human interaction component, the task management compo- nent, and the data management component.
The Wirfs-Brock method. Wirfs-Brock, Wilkerson, and Weiner [WIR90] Although it is not
define a continuum of technical tasks in which analysis leads seamlessly into nearly as robust as
design. Protocols 3 for each class are constructed by refining contracts UML, the Wirfs-Brock
between objects. Each operation (responsibility) and protocol (interface method has a simple
elegance that makes it design) is designed at a level of detail that will guide implementation. Specifi- an interesting
cations for each class (defining private responsibilities and detail for opera- alternative approach to
tions) and each subsystem (identifying all encapsulated classes and the OOD.
interaction between subsystems) are developed. Although the terminology and process steps for each of these OOD methods dif-
fer, the overall OOD processes are reasonably consistent. To perform object-oriented design, a software engineer should perform the following generic steps:
1. Describe each subsystem and allocate it to processors and tasks.
2. Choose a design strategy for implementing data management, interface sup- are applied during
A set of generic steps
OOD, regardless of the port, and task management. design method that is
3. Design an appropriate control mechanism for the system.
chosen.
4. Perform object design by creating a procedural representation for each oper- ation and data structures for class attributes.
5. Perform message design using collaborations between objects and object relationships.
6. Create the messaging model.
7. Review the design model and iterate as required.
2 A block is the design abstraction that allows for the representation of an aggregate object. 3 A protocol is a formal description of the messages to which a class will respond.
It is important to note that the design steps discussed in this section are iterative. That is, they may be executed incrementally, along with additional OOA activities, until a completed design is produced.
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