Object-Oriented Design

The text uses the Booch methodology (1991) to illustrate object-oriented design. The result of object-oriented analysis is translated into time-event diagrams, Booch diagrams, message communications, service objects, and process diagrams. Collectively, they constitute a set of holistic specifications to effectively allocate functionality over program modules at the lowest level as well as multiprocessor configurations at the highest level.

The Booch notation has been unified with other object-oriented notations (Rumbaugh and Jacobsen) into Unified Modeling Language (UML). In Unit 10, we will look at another example of object-oriented analysis and design using the UML notation. Therefore, you may skim this chapter quickly to gain familiarity with OOD, which you will apply in Unit 10.

4. Object-Oriented Design Activities

4.5. Define Message Communications

Rules for Defining Messages 

The next step after the Booch diagram is to actually define message contents to provide interobject interfaces for the application. A table is created to document the specific requirements of each message (see Table 12-7). The objects that act as clients are listed in the Calling Object column, service objects are in the Called Object column. This information should come from the Booch diagram coupled with the Process table generated during analysis that identifies objects with the processes that act on them. The Input Message column describes the data that is sent as part of the calling object message to be processed. The output message is the result data that is sent on (or returned) by the called object after processing. The columns Action Type and Return Object are optional. The action type describes the process to be performed in terms of CRUD or other processing. The return object provides continuity of processing logic when the called object does not return directly to the calling object.

TABLE 12-6 Consolidated Process Subdomain Assignments for Oracle

Process Name Data  Hardware  Process  Human 
EnterCustPhone  X
ReadCust  X
CreateTempTrans  X
Retrieve VOR  X
DisplayTempTrans  X
EnterBarCode  X
Retrievelnventory  X
ComputeTempTransTotal  X
EnterPayAmt  X
ComputeChange  X
DisplayChange  X
Updatelnventory  X
WriteVOR  X
PrintTempTrans  X
EnterBarCode  X
Retrieve VOR X
AddRetDateTempTrans VOR  X
AddltoVlnv  X
Updatelnventory  X
ComputeLateFees  X
WriteVOR  X
EnterCustomer  X
CreateCustomer  X
EnterVideolnventory  X
Create Videolnventory  X

FIGURE 12-19 ABC Rental Booch Diagram Objects

FIGURE 12-20 ABC Booch Diagram Message Passing Scheme

For each process-object pair defined in the Process Definition List, we will have one input message to initiate processing and, if needed, an output message which reports the results of processing. The message list contains one column for each of the types of information shown in Table 12-7. The steps to creating the message list are:

1. Make a table with headings as listed in Table 12-7. 

2. Refer to the list of all object-process combinations. The objects from that list are listed in the' Called object' column. The processes from the process list are placed in the 'Input message' column. 

3. Next, decide both the 'Calling object' and other 'Input message' entries.

These two definitions seem to go together because as we define the input message, we know the information required to perform the process. Once we know the information to perform the process, we decide which object has that information to pass it on. This step determines much of the logical process flow from one encapsulated object-process to another. The logical process flow defines the sequence of processing in the application.

TABLE 12-7 Message List Contents
Header  Contents 
Calling object  Identifies the client. 
Called object  Identifies the server. 
Input message  Identifies the process to be performed and any input parameter data needed to perform the process, for instance, the data type for polymorphic processes.
Output message  Defines the output to be passed, if any. 
Action type  Defines the process as Read, Read/Write, Write, Display, or Print. 
Return to  Identifies either the object to which the result is returned or a nested object for further processing, if any. 

4. Define the 'Output messages' by determining what type of information is required next from each process as it completes. For data entry type processes, frequently the output message is only an acknowledgement of processing (ACK = successful, NACK = unsuccessful). For some processes, no response is required. 

5. Complete the 'Action type' column. The action type summarizes the type of processing for designers to determine possible implementation consolidation of activities, or to decide on further allocation of processing to hardware, software, or firmware. 

6. Define the return object column.

This column usually refers to the calling object which is ordinarily the object to which control returns, but some nested subprocess might take place. When subprocessing occurs, the return object column identifies the next object entered to help other software engineers understand the logic flow. 

Completeness and correctness review of the message list is done to ensure that each process-object pair has an associated message in the table and that the calling/return objects are correct.

ABC Video Example of Message List 

First, we make a table with the above headings. Then, referring to the process list that we used to draw the Booch diagram, we list all object process combinations. The objects from that list are listed in the 'Called object' column. Make sure that all process-object pairs have one entry in the table. 

Next, we decide both the 'Calling object' from the Booch diagram and the 'Input message' for each entry (Table 12-8 shows the completed list). Then the 'Output message' is completed for each entry. As the output message is complete, we complete each line with the 'Action' and 'Return Object' definitions. 

Table 12-8 shows the message list for ABC's application. It reflects the consolidated data objects, the messages decided during the development of the Booch diagram, and the details of information that must be provided for each object-process. Notice that many processes are called from within an object itself. This localizing of processing is desirable to simplify interobject communication and ensure information hiding, but it also can encourage development of nonobject-oriented designs. Make sure that each message contains all, and only, the information required to perform the process. Make sure that each message returns only the information required by the client object.