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 ...
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 componentlevel design come into play. Local data structures are defined (for attributes) and algorithms (for operations) are designed.
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. Similarly,
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 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.
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, and (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 toenhance efficient processing.
• Create new attributes to save derived information, thereby avoiding recomputation.
• 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 toenhance efficient processing.
• Create new attributes to save derived information, thereby avoiding recomputation.
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.
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
•••
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.
