Lecture 4

CHAPTER 22
OBJECT-ORIENTED DESIGN
Topics:
22.1 Design for Object-Oriented Systems
22.2 The System Design Process
22.3 The Object Design Process
22.4 Design Patterns
22.5 Object-Oriented Programming

22. OBJECT-ORIENTED DESIGN
? Object-oriented design transforms the analysis model created using object-oriented analysis into a design model that serves as a blueprint for software construction.
? Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inheritance hierarchies, and establish key relationships among them.
? Your design should be specific to the problem at hand but also general enough to address future problems and requirements.
? You also want to avoid redesign, or at least minimize it.
? Experienced object-oriented designers will tell you that a reusable and flexible design is difficult if not impossible to get "right" the first time. Before a design is finished, they usually try to reuse it several times, modifying it each time.
? Unlike conventional software design methods, OOD results in a design that achieves a number of different levels of modularity.
? Major system components are organized into subsystems, a system-level “module.” Data and the operations that manipulate the data are encapsulated into objects.
? a modular form that is the building block of an OO system.
? OOD must describe the specific data organization of attributes and the procedural detail of each individual operation.
? These represent data and algorithmic pieces of an OO system and are contributors to overall modularity.
? The unique nature of object-oriented design lies in its ability to build upon four important software design concepts: abstraction, information hiding, functional independence, and modularity.
? All design methods strive for software that exhibits these fundamental characteristics, but only OOD provides a mechanism that enables the designer to achieve all four without complexity or compromise.
? Object-oriented design, object-oriented programming, and object-oriented testing are construction activities for OO systems.
? What is it? The design of object oriented software requires the definition of a multilayered software architecture, the specification of subsystems that perform required functions and provide infrastructure support, a description of objects (classes) that form the building blocks of the system, and a description of the communication mechanisms that allow data to flow between layers, subsystems, and objects. Object-oriented design accomplishes all of these things.
? Who does it? OOD is performed by a software engineer.
? Why is it important? An object-oriented system draws upon class definitions that are derived from the analysis model. Some of these definitions will have to be built from scratch, but many others may be reused if appropriate design patterns are recognized. OOD establishes a design blueprint that enables a software engineer to define the OO architecture in a manner that maximizes reuse,thereby improving development speed and end product quality.
? What are the steps? OOD is divided into two major activities: system design and object design.
• System design creates the product architecture, defining a series of “layers” that accomplish specific system functions and identifying the classes that are encapsulated by subsystems that reside at each layer. In addition, system design considers the specification of three components: the user interface, data management functions, and task management facilities.
• Object design focuses on the internal detail of individual classes, defining attributes, operations, and message detail.
? What is the work product? An OO design model encompasses software architecture, user interface description, data management components, task management facilities, and detailed descriptions of each class to be used in the system.
? How do I ensure that I’ve done it right? At each stage, the elements of the object-oriented design model are reviewed for clarity, correctness, completeness, and consistency with customer requirements and with one another.

22.1 Design for Object-Oriented Systems
? Previously, the concept of a design pyramid for conventional software was introduced.
? 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 22.1, 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.

Figure 22.1: the OO design pyramid

? The design pyramid focuses exclusively on the design of a specific product or system.
? The foundation layer focuses on the design of domain objects (called design patterns).
? 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.

22.1.1 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. 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.
? 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 22.2 illustrates the relationship between the OO analysis model and design model that will be derived from it.

Figure 22.2: Translating an OOA model into an OOD model
? 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.
? 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.

22.1.2 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 sub problems those 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 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 (what we called common coupling, 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). As we will see, however, 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.

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 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 foreach 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). “There is no reason why the transition from requirements to design should be any easier in software engineering than it is in any other engineering discipline. Design is hard.” Alan Davis.
? The Jacobson method. The design activity for OOSE (object-oriented software engineering) is a simplified version of the proprietary objector 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.

22.1.4 A Unified Approach to OOD
? In Chapter 21, we 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 Farmer [BEN99] discuss 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.

FIGURE 22.3: Process flow for OOD

? 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 22.3.7
? Throughout the UML design process, the user model view and structure model view are elaborated into the design representation outlined above.

22.2 The System Design Process
? System design develops the architectural detail required to build a system or product.
? The system design process encompasses the following activities:
1. Partition the analysis model into subsystems.
2. Identify concurrency that is dictated by the problem.
3. Allocate subsystems to processors and tasks.
4. Develop a design for the user interface.
5. Choose a basic strategy for implementing data management.
6. Identify global resources and the control mechanisms required to access them.
7. Design an appropriate control mechanism for the system, including task management.
8. Consider how boundary conditions should be handled.
9. Review and consider trade-offs.

22.2.1 Partitioning the Analysis Model
? One of the fundamental analysis principles is partitioning.
? In OO system design, we partition the analysis model to define cohesive collections of classes, relationships, and behavior.
? These design elements are packaged as a subsystem.
? In general, all of the elements of a subsystem share some property in common.
? They all may be involved in accomplishing the same function; they may reside within the same product hardware, or they may manage the same class of resources.
? Subsystems are characterized by their responsibilities; that is, a subsystem can be identified by the services that it provides. When used in the OO system design context.
? a service is a collection of operations that perform a specific function (e.g., managing word-processor files, producing a three-dimensional rendering, translating an analog video signal into a compressed digital image).
? As subsystems are defined (and designed), they should conform to the following design criteria:
• The subsystem should have a well-defined interface through which all communication with the rest of the system occurs.
• With the exception of a small number of “communication classes,” the classes within a subsystem should collaborate only with other classes within the subsystem.
• The number of subsystems should be kept low.
• A subsystem can be partitioned internally to help reduce complexity.
? When two subsystems communicate with one another, they can establish a client/server link or a peer-to-peer link.
? In a client/server link, each of the subsystems takes on one of the roles implied by client and server. Service flows from server to client in only one direction.
? In a peer-to-peer link, services may flow in either direction.
? When a system is partitioned into subsystems, another design activity, called layering, also occurs.
? Each layer of an OO system contains one or more subsystems and represents a different level of abstraction of the functionality required to accomplish system functions.
? In most cases, the levels of abstraction are determined by the degree to which the processing associated with a subsystem is visible to an end-user.
? For example, a four-layer architecture might include:
(1) a presentation layer (the subsystems associated with the user interface),
(2) an application layer (the subsystems that perform the processing associated with the application),
(3) a data formatting layer (the subsystems that prepare the data for processing),
(4) a database layer (the subsystems associated with data management).
? Each layer moves deeper into the system, representing increasingly more environment-specific processing.
? Buschmann and his colleagues suggest the following design approach for layering:
1. Establish layering criteria. That is, decide how subsystems will be grouped in a layered architecture.
2. Determine the number of layers. Too many introduce unnecessary complexity; too few may harm functional independence.
3. Name the layers and allocate subsystems (with their encapsulated classes) to a layer. Be certain that communication between subsystems (classes) on one layer and other subsystems (classes) at another layer follow the design philosophy for the architecture.
4. Design interfaces for each layer.
5. Refine the subsystems to establish the class structure for each layer.
6. Define the messaging model for communication between layers.
7. Review the layer design to ensure that coupling between layers is minimized (a client/server protocol can help accomplish this).
8. Iterate to refine the layered design.

22.2.2 Concurrency and Subsystem Allocation
? The dynamic aspect of the object-behavior model provides an indication of concurrency among classes (or subsystems). If classes (or subsystems) are not active at the same time, there is no need for concurrent processing. This means that the classes (or subsystems) can be implemented on the same processor hardware.
? On the other hand, if classes (or subsystems) must act on events asynchronously and at the same time, they are viewed as concurrent. When subsystems are concurrent, two allocation options exist:
(1) Allocate each subsystem to an independent processor or
(2) Allocate the subsystems to the same processor and provide concurrency support through operating system features.
? Concurrent tasks are defined by examining the state diagram for each object. If the flow of events and transitions indicates that only a single object is active at any one time, a thread of control has been established.
? The thread of control continues even when one object sends a message to another object, as long as the first object waits for a response. If, however, the first object continues processing after sending a message, the thread of control splits. Tasks in an OO system are designed by isolating threads of control.
? For example, while the SafeHome security system is monitoring its sensors, it can also be dialing the central monitoring station for verification of connection.
? Since the objects involved in both of these behaviors are active at the same time, each represents a separate thread of control and each can be defined as a separate task.
? If the monitoring and dialing activities occur sequentially, a single task could be implemented.
? To determine which of the processor allocation options is appropriate, the designer must consider performance requirements, costs, and the overhead imposed by inter-processor communication.

22.2.3 The Task Management Component
? Coad and Yourdon suggest the following strategy for the design of the objects that manage concurrent tasks:
• The characteristics of the task are determined.
• A coordinator task and associated objects are defined.
• The coordinator and other tasks are integrated.
? The characteristics of a task are determined by understanding how the task is initiated.
? Event-driven and clock-driven tasks are the most commonly encountered. Both are activated by an interrupt, but the former receives an interrupt from some outside source (e.g., another processor, a sensor) while that latter is governed by a system clock.
? In addition to the manner in which a task is initiated, the priority and criticality of the task must also be determined. High-priority tasks must have immediate access to system resources.
? High-criticality tasks must continue to operate even if resource availability is reduced or the system is operating in a degraded state.
? Once the characteristics of the task have been determined, object attributes and operations required to achieve coordination and communication with other tasks are defined.
? The basic task template (for a task object) takes the form:
(1) Task name - the name of the object.
(2) Description - a narrative describing the purpose of the object.
(3) Priority - task priority (e.g., low, medium, high).
(4) Services - a list of operations that are responsibilities of the object.
(5) Coordinates by - the manner in which object behavior is invoked.
(6) Communicates via - input and output data values relevant to the task.
? This template description can then be translated into the standard design model (incorporating representation of attributes and operations) for the task object(s).

22.2.4 The User Interface Component
? Although the user interface component is implemented within the context of the problem domain, the interface itself represents a critically important subsystem for most modern applications.
? The OO analysis model contains usage scenarios (called use-cases) and a description of the roles that users play (called actors) as they interact with the system. These serve as input to the user interface design process.
? Once the actor and its usage scenario are defined, a command hierarchy is identified.
? The command hierarchy defines major system menu categories (the menu bar or tool palette) and all sub-functions that are available within the context of a major system menu category (the menu windows).
? The command hierarchy is refined iteratively until every use-case can be implemented by navigating the hierarchy of functions.
? Because a wide variety of user interface development environments already exist, the design of GUI elements is not necessary. Reusable classes (with appropriate attributes and operations) already exist for windows, icons, mouse operations, and a wide variety of other interaction functions.
? The implementer need only instantiate objects that have appropriate characteristics for the problem domain.

22.2.5 The Data Management Component
? Data management encompasses two distinct areas of concern:
(1) The management of data that is critical to the application itself.
(2) The creation of an infrastructure for storage and retrieval of objects.
? In general, data management is designed in a layered fashion. The idea is to isolate the low-level requirements for manipulating data structures from the higher-level requirements for handling system attributes.
? Within the system context, a database management system is often used as a common data store for all subsystems.
? The objects required to manipulate the database are members of reusable classes that are identified using domain analysis or are supplied directly by the database vendor.
? The design of the data management component includes the design of the attributes and operations required to manage objects.
? The relevant attributes are appended to every object in the problem domain and provide information that answers the question, “How do I store myself?”
? Coad and Yourdon suggest the creation of an object-server class “with services to:
(a) Tell each object to save itself.
(b) Retrieve stored objects for use by other design components.
? As an example of data management for the sensor object discussed as part of the SafeHome security system, the design could specify a flat file called “sensor.” Each record would correspond to a named instance of sensor and would contain the values of each sensor attribute for that named instance. Operations within the object server class would enable a specific object to be stored and retrieved when it is needed by the system. For more complex objects, it might be necessary to specify a relational database or an object-oriented database to accomplish the same function.

Figure 22.4: A model of collaboration between subsystems

22.2.6 The Resource Management Component
? A variety of different resources are available to an OO system or product; and in many instances, subsystems compete for these resources at the same time.
? Global system resources can be external entities (e.g., a disk drive, processor, or communication line) or abstractions (e.g., a database, an object). Regardless of the nature of the resource, the software engineer should design a control mechanism for it.
? Rumbaugh and his colleagues suggest that each resource should be owned by a “guardian object.” The guardian object is the gatekeeper for the resource, controlling access to it and moderating conflicting requests for it.

22.2.7 Inter-subsystem Communication
? Once each subsystem has been specified, it is necessary to define the collaborations that exist between the subsystems.
? The model that we use for object-to-object collaboration can be extended to subsystems as a whole.
? Figure 22.4 illustrates a collaboration model.
? Communication can occur by establishing a client/server link or a peer-to-peer link. Referring to the figure, we must specify the contract that exists between subsystems.
? Recall that a contract provides an indication of the ways in which one subsystem can interact with another.
? The following design steps can be applied to specify a contract for a subsystem:
1. List each request that can be made by collaborators of the subsystem. Organize the requests by subsystem and define them within one or more appropriate contracts. Be sure to note contracts that are inherited from superclasses.
2. For each contract, note the operations (both inherited and private) that are required to implement the responsibilities implied by the contract. Be sure to associate the operations with specific classes that reside within a subsystem.
3. Considering one contract at a time, create a table of the form shown in Figure 22.5. For each contract, the following entries are made in the table:
• Type: the type of contract (i.e., client/server or peer-to-peer).
• Collaborators: the names of the subsystems that are parties to the contract.
• Class: the names of the classes (contained within a subsystem) that support services implied by the contract.
• Operation: the names of the operations (within the class) that implement the services.
• Message format: the message format required to implement the interaction between collaborators. Draft an appropriate message description for each interaction between the subsystems.
4. If the modes of interaction between subsystems are complex, a subsystem- collaboration diagram, illustrated in Figure 22.6 is created.
? The collaboration graph is similar in form to the event flow diagram. Each subsystem is represented along with its interactions with other subsystems.
? The contracts that are invoked during an interaction are noted as shown. The details of the interaction are determined by looking up the contract in the subsystem collaboration table (Figure 22.5)

Figure 22.5: Subsystem collaboration table

FIGURE 22.6: Abbreviated subsystem collaboration graph for Safe-Home

22.3 The Object Design Process
? The OO system design might be viewed as the floor plan of a house.
? The floor plan specifies the purpose of each room and the architectural features that connect the rooms to one another and to the outside environment. It is now time to provide the details that are required to build each room.
? In the context of OOD, object design focuses on the “rooms.”
? Bennett and his colleagues discuss object design in the following way:
• Object design is concerned with the detailed design of the objects and their interactions. It is completed within the overall architecture defined during system design and according to agreed design guidelines and protocols.
? Object design is particularly concerned with the specification of attribute types, how operations function, and how objects are linked to other objects.
? It is at this stage that the basic concepts and principles associated with component level design come into play. Local data structures are defined (for attributes) and algorithms (for operations) are designed.

22.3.1 Object Descriptions
? A design description of an object (an instance of a class or subclass) can take one of two forms:
(1) a protocol description that establishes the interface of an object by defining each message that the object can receive and the related operation that the object performs when it receives the message or,
(2) An implementation description that shows implementation details for each operation implied by a message that is passed to an object. Implementation details include information about the object s private part; that is, internal details about the data structures that describe the object’s attributes and procedural details that describe operations.
? The protocol description is nothing more than a set of messages and a corresponding comment for each message. For example, a portion of the protocol description for the object motion sensor (described earlier) might be:
? MESSAGE (motion.sensor) --> read: RETURNS sensor.ID, sensor.status; This describes the message required to read the sensor.
? MESSAGE (motion.sensor) --> set: SENDS sensor.ID, sensor.status; sets or resets the status of the sensor.
? For a large system with many messages, it is often possible to create message categories.
? For example, message categories for the SafeHome system object might include system configuration messages, monitoring messages, event messages, and so forth.
? An implementation description of an object provides the internal ("hidden") details that are required for implementation but are not necessary for invocation. That is, the designer of the object must provide an implementation description and must therefore create the internal details of the object.
? However, another designer or implementer who uses the object or other instances of the object requires only the protocol description but not the implementation description.
? An implementation description is composed of the following information:
(1) a specification of the object s name and reference to class;
(2) a specification of private data structure with indication of data items and types;
(3) a procedural description of each operation or, alternatively, pointers to such procedural descriptions.
? The implementation description must contain sufficient information to provide for proper handling of all messages described in the protocol description.
? Cox [COX85] characterizes the difference between the information contained in the protocol description and that contained in the implementation description in terms of "users" and "suppliers" of services.
• A user of the service provided by an object must be familiar with the protocol for invoking the service; that is, for specifying what is desired. The supplier of the service (the object itself) must be concerned with how the service is to be supplied to the user; that is, with implementation details.

22.3.2 Designing Algorithms and Data Structures
? A variety of representations contained in the analysis model and the system design provide a specification for all operations and attributes.
? Algorithms and data structures are designed using an approach that differs little from the data design and component-level design approaches discussed for conventional software engineering.
? An algorithm is created to implement the specification for each operation. In many cases, the algorithm is a simple computational or procedural sequence that can be implemented as a self-contained software module.
? However, if the specification of the operation is complex, it may be necessary to modularize the operation. Conventional component-level design techniques can be used to accomplish this.
? Data structures are designed concurrently with algorithms. Since operations invariably manipulate the attributes of a class, the design of the data structures that best reflect the attributes will have a strong bearing on the algorithmic design of the corresponding operations.
? Although many different types of operations exist, they can generally be divided into three broad categories:
(1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting),
(2) operations that perform a computation,
(3) operations that monitor an object for the occurrence of a controlling event.
? For example, the SafeHome processing narrative contains the sentence fragments: "sensor is assigned a number and type" and "a master password is programmed for arming and disarming the system."
? These two phrases indicate a number of things:
• That an assign operation is relevant for the sensor object.
• That a program operation will be applied to the system object.
• That arm and disarm are operations that apply to system (also that system status may ultimately be defined (using data dictionary notation) as system status = [armed | disarmed]
? The operation program is allocated during OOA, but during object design it will be refined into a number of more specific operations that are required to configure the system.
? For example, after discussions with product engineering, the analyst, and possibly the marketing department, the designer might elaborate the original processing narrative and write the following for program (potential operations—verbs—are underlined):
? Program enables the SafeHome user to configure the system once it has been installed. The user can:
(1) Install phone numbers;
(2) define delay times for alarms;
(3) Build a sensor table that contains each sensor ID, its type, and location; and
(4) Load a master password.
? Therefore, the designer has refined the single operation program and replaced it with the operations: install, define, build, and load. Each of these new operations becomes part of the system object, has knowledge of the internal data structures that implement the object s attributes, and is invoked by sending the object messages of the form:
? MESSAGE (system) --> install: SENDS telephone.number;
? This implies that, to provide the system with an emergency phone number, an install message will be sent to system.
? Verbs connote actions or occurrences. In the context of object design formalization, we consider not only verbs but also descriptive verb phrases and predicates (e.g., "is equal to") as potential operations. The grammatical parse is applied recursively until each operation has been refined to its most-detailed level.
? Once the basic object model is created, optimization should occur. Rumbaugh and his colleagues suggest three major thrusts for OOD design optimization:
? Review the object-relationship model to ensure that the implemented design leads to efficient utilization of resources and ease of implementation.
? Add redundancy where necessary.
? Revise attribute data structures and corresponding operation algorithms to enhance efficient processing.
? Create new attributes to save derived information, thereby avoiding re-computation.

22.3.3 Program Components and Interfaces
? An important aspect of software design quality is modularity; that is, the specification of program components (modules) that are combined to form a complete program.
? The object-oriented approach defines the object as a program component that is itself linked to other components (e.g., private data, operations). But defining objects and operations is not enough. During design, we must also identify the interfaces between objects and the overall structure (considered in an architectural sense) of the objects.
? Although a program component is a design abstraction, it should be represented in the context of the programming language used for implementation. To accommodate OOD, the programming language to be used for implementation should be capable of creating the following program component (modeled after Ada):
PACKAGE program-component-name IS
TYPE specification of data objects
•
•
•
PROC specification of related operations . . .
PRIVATE
data structure details for objects
PACKAGE BODY program-component-name IS
PROC operation.1 (interface description) IS
•
•
•
END
PROC operation.n (interface description) IS
•
•
•
END
END program-component-name
? Referring to the Ada-like PDL (program design language) just shown, a program component is specified by indicating both data objects and operations.
? The specification part of the component indicates all data objects (declared with the TYPE statement) and the operations (PROC for procedure) that act on them.
? The private part (PRIVATE) of the component provides otherwise hidden details of data structure and processing. In the context of our earlier discussion, the PACKAGE is conceptually similar to objects discussed throughout this chapter.
? The first program component to be identified should be the highest-level module from which all processing originates and all data structures evolve. Referring once again to the SafeHome example, we can define the highest-level program component as PROCEDURE SafeHome software.
? The SafeHome software component can be coupled with a preliminary design for the following packages (objects):
PACKAGE system IS
TYPE system data
PROC install, define, build, load
PROC display, reset, query, modify, call
PRIVATE
PACKAGE BODY system IS
PRIVATE
system.id IS STRING LENGTH (8);
verification phone.number, telephone.number, ...
IS STRING LENGTH (8);
sensor.table DEFINED
sensor.type IS STRING LENGTH (2),
sensor.number, alarm.threshold IS NUMERIC;
PROC install RECEIVES (telephone.number)
{design detail for operation install}
•••
END system
PACKAGE sensor IS
TYPE sensor data
PROC read, set, test
PRIVATE
PACKAGE BODY sensor IS
PRIVATE
sensor.id IS STRING LENGTH (8);
sensor.status IS STRING LENGTH (8);
alarm.characteristics DEFINED
threshold, signal type, signal level IS NUMERIC,
hardware.interface DEFINED
type, a/d.characteristics, timing.data IS NUMERIC,
END sensor
•••
END SafeHome software
? Data objects and corresponding operations are specified for each of the program components for SafeHome software. The final step in the object design process completes all information required to fully implement data structure and types contained in the PRIVATE portion of the package and all procedural detail contained in the PACKAGE BODY.
? To illustrate the detail design of a program component, we reconsider the sensor package described earlier. The data structures for sensor attributes have already been defined. Therefore, the first step is to define the interfaces for each of the operations attached to sensor:
• PROC read (sensor.id, sensor.status: OUT);
• PROC set (alarm.characteristics, hardware.interface: IN)
• PROC test (sensor.id, sensor.status, alarm.characteristics: OUT);
? The next step requires stepwise refinement of each operation associated with the sensor package. To illustrate the refinement, we develop a processing narrative (an informal strategy) for read:
? When the sensor object receives a read message, the read process is invoked. The process determines the interface and signal type, polls the sensor interface, converts A/D characteristics into an internal signal level, and compares the internal signal level to a threshold value. If the threshold is exceeded, the sensor status is set to "event." Otherwise, the sensor status is set to "no event." If an error is sensed while polling the sensor, the sensor status is set to "error."
? Given the processing narrative, a PDL description of the read process can be developed:
PROC read (sensor.id, sensor.status: OUT);
raw.signal IS BIT STRING
IF (hardware.interface.type = "s" & alarm.characteristics.signal.type = "B"
THEN
GET (sensor, exception: sensor.status := error) raw.signal;
CONVERT raw.signal TO internal.signal.level;
IF internal.signal.level > threshold
THEN sensor.status := "event";
ELSE sensor.status := "no event";
ENDIF
ELSE {processing for other types of s interfaces would be specified}
ENDIF
RETURN sensor.id, sensor.status;
END read
? The PDL representation of the read operation can be translated into the appropriate implementation language. The functions GET and CONVERT are assumed to be available as part of a run-time library.

22.4 Design Patterns
? The best designers in any field have an uncanny ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution.
? Gamma and his colleagues discuss this when they state: You’ll find recurring patterns of classes and communicating objects in many object oriented systems.
? These patterns solve specific design problems and make object-oriented design more flexible, elegant, and ultimately reusable.
? They help designers reuse successful designs by basing new designs on prior experience.
? A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.
? Throughout the OOD process, a software engineer should look for every opportunity to reuse existing design patterns (when they meet the needs of the design) rather than creating new ones


22.4.1 Describing a Design Pattern
? Mature engineering disciplines make use of thousands of design patterns.
? For example, a mechanical engineer uses a two-step, keyed shaft as a design pattern. Inherent in the pattern are attributes (the diameters of the shaft, the dimensions of the keyway, etc.) and operations (e.g., shaft rotation, shaft connection).
? An electrical engineer uses an integrated circuit (an extremely complex design pattern) to solve a specific element of a new problem.
? All design patterns can be described by specifying the following information:
• The name of the pattern.
• The intent of the pattern.
• The “design forces” that motivate the pattern.
• The solution that mitigates these forces.
• The classes that are required to implement the solution.
• The responsibilities and collaboration among solution classes.
• Guidance that leads to effective implementation.
• Example source code or source code templates.
• Cross-references to related design patterns.
? The design pattern name is itself an abstraction that conveys significant meaning once the applicability and intent are understood. Design forces describe the data, functional, or behavioral requirements associated with part of the software for which the pattern is to be applied.
? In addition forces define the constraints that may restrict the manner in which the design is to be derived. In essence, design forces describe the environment and conditions that must exist to make the design pattern applicable.
? The pattern characteristics (classes, responsibilities, and collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems.
? These attributes represent characteristics of the design that can be searched (e.g., via a database) so that an appropriate pattern can be found.
? Finally, guidance associated with the use of a design pattern provides an indication of the ramifications of design decisions.
? The names of objects and subsystems (potential design patterns) should be chosen with care. one of the key technical problems in software reuse is simply the inability to find existing reusable patterns when hundreds or thousands of candidate patterns exist. The search for the “right” pattern is aided immeasurably by a meaningful pattern name along with a set of characteristics that help in classifying the object.

22.4.2 Using Patterns in Design
? In an object-oriented system, design patterns can be used by applying two different mechanisms: inheritance and composition.
? Inheritance is a fundamental OO concept. Using inheritance, an existing design pattern becomes a template for a new subclass. The attributes and operations that exist in the pattern become part of the subclass.
? Composition is a concept that leads to aggregate objects. That is, a problem may require objects that have complex functionality (in the extreme, a subsystem accomplishes this). The complex object can be assembled by selecting a set of design patterns and composing the appropriate object (or subsystem).
? Each design pattern is treated as a black box, and communication among the patterns occurs only via well defined interfaces.
? Gamma and his colleagues suggest that object composition should be favored over inheritance when both options exist. Rather than creating large and sometimes unmanageable class hierarchies (the consequence of the overuse of inheritance),
? composition favors small class hierarchies and objects that remain focused on one objective. Composition uses existing design patterns (reusable components) in an unaltered form.

22.5 Object-Oriented Programming
? Although all areas of object technologies have received significant attention within the software community, no subject has produced more books, more discussion, and more debate than object-oriented programming (OOP).
? Hundreds of books have been written on C++ and Java programming, and hundreds more are dedicated to less widely used OO languages.
? The software engineering viewpoint stresses OOA and OOD and considers OOP (coding) an important, but secondary, activity that is an outgrowth of analysis and design.
? The reason for this is simple. As the complexity of systems increases, the design architecture of the end product has a significantly stronger influence on its success than the programming language that has been used. And yet, “language wars” continue to rage.

References:
1.” Software engineering practitioners approach “8th by Pressman.