We introduced the concept of a design pyramid for conventional software. Four design layers—data, architectural, interface, and component l...
We introduced the concept of a design pyramid for conventional software. Four design layers—data, architectural, interface, and component level—were defined and discussed. For object-oriented systems, we can also define a design pyramid, but the layers are a bit different. Referring to figure, the four layers of the OO design pyramid are
The subsystem layer contains a representation of each of the subsystems that enable the software to achieve its customer-defined requirements and to implement the technical infrastructure that supports customer requirements.
The class and object layer contains the class hierarchies that enable the system to be created using generalizations and increasingly more targeted specializations. This layer also contains representations of each object.
The message layer contains the design details that enable each object to communicate with its collaborators. This layer establishes the external and internal interfaces for the system.
The responsibilities layer contains the data structure and algorithmic design for all attributes and operations for each object.
The design pyramid focuses exclusively on the design of a specific product or system.It should be noted, however, that another “layer” of design exists, and this layer forms the foundation on which the pyramid rests. The foundation layer focuses on the design of domain objects. Domain objects play a key role in building the infrastructure for the OO system by providing support for human/computer interface activities, task management, and data management. Domain objects can also be used to flesh out the design of the application itself.
Conventional vs. OO Approaches
Conventional approaches to software design apply a distinct notation and set of heuristics to map the analysis model into a design model. Recalling figure, each element of the conventional analysis model maps into one or more layers of the design model. Like conventional software design, OOD applies data design when attributes are represented, interface design when a messaging model is developed, and component-level (procedural) design for the design of operations. It is important to note that the architecture of an OO design has more to do with the collaborations among objects than with the flow of control between components of the system.
Although similarity between the conventional and OO design models does exist, we have chosen to rename the layers of the design pyramid to reflect more accurately the nature of an OO design. Figure illustrates the relationship between the OO analysis model and design model that will be derived from it.
The subsystem design is derived by considering overall customer requirements (represented with use-cases) and the events and states that are externally observable (the object-behavior model). Class and object design is mapped from the description of attributes, operations, and collaborations contained in the CRC model. Message design is driven by the object-relationship model, and responsibilities design is derived using the attributes, operations, and collaborations described in the CRC model.
Fichman and Kemerer suggest ten design modeling components that may be used to compare various conventional and object-oriented design methods:
1. Representation of hierarchy of modules.
2. Specification of data definitions.
3. Specification of procedural logic.
4. Indication of end-to-end processing sequences.
5. Representation of object states and transitions.
6. Definition of classes and hierarchies.
7. Assignment of operations to classes.
8. Detailed definition of operations.
9. Specification of message connections.
10. Identification of exclusive services.
Because many conventional and object-oriented design approaches are available, it is difficult to develop a generalized comparison between the two methods. It can be stated, however, that modeling dimensions 5 through 10 are not supported using structured design or its derivatives.
Design Issues
Bertrand Meyer suggests five criteria for judging a design method's ability to achieve modularity and relates these to object-oriented design:
• Decomposability—the facility with which a design method helps the designer to decompose a large problem into subproblems that are easier to solve.
• Composability—the degree to which a design method ensures that program components (modules), once designed and built, can be reused to create other systems.
• Understandability—the ease with which a program component can be understood without reference to other information or other modules.
• Continuity—the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or a very few modules.
• Protection—an architectural characteristic that will reduce the propagation of side effects if an error does occur in a given module.
From these criteria, Meyer [MEY90] suggests five basic design principles that can be derived for modular architectures: (1) linguistic modular units, (2) few interfaces, (3) small interfaces (weak coupling), (4) explicit interfaces, and (5) information hiding.
Modules are defined as linguistic modular units when they "correspond to syntactic units in the language used". That is, the programming language to be used should be capable of supporting the modularity defined directly. For example, if the designer creates a subroutine, any of the older programming languages (e.g., FORTRAN, C, Pascal) could implement it as a syntactic unit. But if a package that contains data structures and procedures and identifies them as a single unit were defined,
a language such as Ada (or another object-oriented language) would be necessary to directly represent this type of component in the language syntax.
To achieve low coupling , the number of interfaces between modules should be minimized ("few interfaces") and the amount of information that moves across an interface should be minimized ("small interfaces"). Whenever components do communicate, they should do so in an obvious and direct way ("explicit interfaces"). For example, if component X and component Y communicate through a global data area , they violate the principle of explicit interfaces because the communication between the components is not obvious to an outside observer. Finally, we achieve the principle of information hiding when all information about a component is hidden from outside access, unless that information is specifically defined as public information.
The design criteria and principles presented in this section can be applied to any design method (e.g., we can apply them to structured design).The object-oriented design method achieves each of the criteria more efficiently than other approaches and results in modular architectures that allow us to meet each of the modularity criteria most effectively.
The OOD Landscape
A wide variety of object-oriented analysis and design methods were proposed and used during the 1980s and 1990s. These methods established the foundation for modern OOD notation, design heuristics, and models. A brief overview of the most important early OOD methods follows:
The Booch method. The Booch method encompasses both a “micro development process” and a “macro development process.” In the design context, macro development encompasses an architectural planning activity that clusters similar objects in separate architectural partitions, layers objects by level of abstraction, identifies relevant scenarios, creates a design prototype, and validates the design prototype by applying it to usage scenarios. Micro development defines a set of “rules” that govern the use of operations and attributes and the domain-specific policies for memory management, error handling, and other infrastructure functions; develops scenarios that describe the semantics of the rules and policies; creates a prototype for each policy; instruments and refines the prototype; and reviews each policy so that it “broadcasts its architectural vision”.
The Rumbaugh method. The object modeling technique encompasses a design activity that encourages design to be conducted at two different 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. Operations are selected from the analysis model and algorithms are defined for each operation. Data structures that are appropriate for attributes and algorithms are represented. Classes and class attributes are designed in a manner that optimizes access to data and improves computational efficiency. A messaging model is created to implement the object relationships (associations).
The Jacobson method. The design activity for OOSE (object-oriented software engineering) is a simplified version of the proprietary objectory method, also developed by Jacobson. The design model emphasizes traceability to the OOSE analysis model. First, the idealized analysis model is adapted to fit the real world environment. Then primary design objects, called blocks, 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 was developed by studying how “effective object-oriented designers” do their design work. The design approach addresses not only the application but also the infrastructure for the application and focuses on the representation of four major system components: the problem domain component, the human interaction component, the task management component, and the data management component.
The Wirfs-Brock method. Wirfs-Brock, Wilkerson, and Weiner define a continuum of technical tasks in which analysis leads seamlessly into design. Protocols for each class are constructed by refining contracts between objects. Each operation (responsibility) and protocol (interface design) is designed at a level of detail that will guide implementation. Specifications for each class (defining private responsibilities and detail for operations) and each subsystem (identifying all encapsulated classes and the interaction between subsystems) are developed.
Although the terminology and process steps for each of these OOD methods differ, 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 support, and task management.
3. Design an appropriate control mechanism for the system.
4. Perform object design by creating a procedural representation for each operation 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.
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.
A Unified Approach to OOD
We already noted that Grady Booch, James Rumbaugh, and Ivar Jacobson combined the best features of their individual object-oriented analysis and design methods into a unified method. The result, called the Unified Modeling Language has become widely used throughout the industry.
During analysis modeling , the user model and structural model views are represented. These provide insight into the usage scenarios for the system (providing guidance for behavioral modeling) and establish a foundation for the implementation and environment model views by identifying and describing the static structural elements of the system.
UML is organized into two major design activities: system design and object design. The primary objective of UML system design is to represent the software architecture. Bennett, McRobb, and Farmerdiscuss this issue in the following way:
In terms of object-oriented development, the conceptual architecture is concerned with the structure of the static class model and the connections between components of the model. The module architecture describes the way the system is divided into subsystems or modules and how they communicate by exporting and importing data. The code architecture defines how the program code is organized into files and directories and grouped into libraries. The execution architecture focuses on the dynamic aspects of the system and the communication between components as tasks and operations execute.
The definition of the “subsystems” noted by Bennett et al. is a primary concern during UML system design.
UML object design focuses on a description of objects and their interactions with one another. A detailed specification of attribute data structures and a procedural design of all operations are created during object design. The visibility for all class attributes is defined and interfaces between objects are elaborated to define the details of a complete messaging model.
System and object design in UML are extended to consider the design of user interfaces, data management with the system to be built, and task management for the subsystems that have been specified. User interface design in UML draws on the same concepts and principles . The user model view drives the user interface design process, providing a scenario that is elaborated iteratively to become a set of interface classes
Data management design establishes a set of classes and collaborations that allow the system (product) to manage persistent data (e.g., files and databases). Task management design establishes the infrastructure that organizes subsystems into tasks and then manages task concurrency. The process flow for design is illustrated in figure.
Throughout the UML design process, the user model view and structure model view are elaborated into the design representation outlined above.
