CS302: Software Engineering

Rules for Defining Messages 

The next step after the Booch diagram is to actually define message contents to provide inter-object 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

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

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 inter-object 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.