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.6. Develop Process Diagram

Guidelines for Developing the Process Diagram 

A process diagram depicts the hardware configuration and the allocation of processes to processor platforms in a distributed environment. There are two types of icons used in the diagram: processor and device. A processor is any intelligent device that performs data, presentation (i.e., monitor display), or application work. A device is any dumb device that is part of the hardware configuration supporting application work. Processors are shown on the diagram as a shadowed cube; devices are shown as transparent cubes (see Figure 12-21). This diagram is a crude equivalent of a system flowchart used before process methods were developed. It is crude because devices and processors are all treated as the same, the only immediate visual knowledge the user gets is the configuration size and the extent to which intelligent processors are used.

TABLE 12-8 Message List for ABC Video Rental Processing

Calling Object Called Object Input Message Output Message Action Type Return Object
Human Interface Customer

Customer Information CustomerPhone


Human Interface
Human Interface

Video Inventory

Video Information

Videos Created

Human Interface



Application Id 

Queue Address 

Execute Init Session Schedule

Schedule Schedule UserID Memory Address or Logoff Execute Init Session Schedule
Schedule Schedule Session Id,
Menu Selection for Rental
None or Quit Session Execute Init Session Human Interface
Human Interface Human Interface No data (Initiate Request) Trans Request Data Memory Address Enter Request TempTrans
Human Interface TempTrans Trans Request data Data access key Create TempTrans UserView1 or Customer
TempTrans  Customer Data access key Customer Info Read  TempTrans
TempTrans  UserView1 Data access key Customer, VideoOnRental, VideoInventory, BarCodeVideo Read  TempTrans
Customer or UserView1 TempTrans TempTrans Info TempTrans Format TempTrans
TempTrans TempTrans Memory Location, VideoOnRental, Rent/Return Date Ack Compute Late Fees TempTrans
TempTrans TempTrans Memory Location (Amount Due) and End of rentals/returns when present
Ack Compute Total Amount Due TempTrans
TempTrans Human Interface TempTrans Info and End of rentals/returns when present Display Human Interface
Human Interface Human Interface No data (Execute Request) Prompt BarCode or End of Rentals/Returns Prompt Temptrans
Human Interface Temptrans BarCode (Rental) or End of rental None Format UserView2 or TempTrans
Human Interface TempTrans BarCode (Return) or End of return None Format TempTrans
TempTrans User View2 BarCode (new rental) Video Inventory, BarCodeVideo Read TempTrans
User View2 TempTrans TempTrans Info TempTrans Format Human Interface
Human Interface Human Interface End of Rentals/Returns Payment Amount Data Entry TempTrans
Human Interface TempTrans Payment Amount Change or Payment Due Compute Change Human Interface
Temp Trans Human Interface Change or Payment Due End of Trans Display TempTrans
Human Interface TempTrans End of Trans None  Change BarCode Status UserView 1
Temp Trans User View 1 Video on Rental Information Ack Rewrite  TempTrans
Temp Trans User View 1 Video on Rental Information Ack Write  TempTrans
Temp Trans Hardware services TempTrans None Print  Schedule 
Hardware services Schedule  Trans Id  Terminate Trans Schedule 
Schedule  Schedule  Session Id Terminate session Schedule 
Schedule  Schedule  Appl Id Terminate Appl. System

The methodology assumes that hardware configuration decisions are not part of the SE task and that the hardware decisions are known. Similarly, there are no guidelines for allocating processes to processors. This is an artifact of the development of 00 in a defense environment in which the application developers are working from specifications developed by government employees in another city. In the absence of guidelines from the methodology, we can borrow the distribution decision techniques from information engineering and apply them to this decision. In any case, the processes are listed in small print next to the processor in which they will operate.

One shadow cube is drawn for each processor. Individual processes are allocated to each processor. Lines are drawn to show communications capabilities between the processes, not between the processors (i.e., the processors are assumed to be networked whether or not the application processes communicate). Only one line per set of processors is drawn, since the details of messages are documented elsewhere. The lines only have directional pointers to show one-way communication. 

FIGURE 12-21 Process Diagram Icons

FIGURE 12-22 First-Cut ABC Process Diagram

Next, for each processor, draw the terminals, printers, disk drives, and other peripheral devices that are attached to it. If there are more than one disk drive in the configuration, a list of the classes, class/ objects, and objects is made near each drive that will contain data used by the application. 

Finally, the diagram is compared to the message list to ensure that all messages are accommodated in the diagram and accurately depict communications between processes. The Booch diagram or the message list can also be used to validate the accuracy and completeness of processes allocated to processors, and of the data allocated to storage devices.

ABC Video Process Diagram

The most simple form of ABC's process diagram shows the file server as the processor and the PCs and printers as terminal devices (see Figure 12-22). This allocation of work is a problem because it does not take advantage of PC intelligence and, therefore, is suboptimal in terms of benefits to be gained from using PCs. Having said this, the allocation is constrained by the software environment. If SQL supports multilocation processing, then the comment stands. If SQL does not support multilocation processing, then the figure is complete. As it is currently, SQL does not support multilocation processing although it does support distribution of databases.

An alternative process distribution is shown in Figure 12-23. Even with SQL, we could distribute editing, the hardware management functions, payment and change processing, and printing of the rental copy to the local pes. This is a more complex application because the multiple sites now require synchronization and intraprocessor scheduling in order to coordinate their work, but, if bottlenecks show up in a prototype of the first-cut process distribution, this is a likely candidate for the second iteration of design and prototyping. As it is, we select the simple design because it is significantly easier to implement and maintain, having no synchronization overhead. If it works and is robust to additional users, the first prototype will be completed and placed into production.

FIGURE 12-23 Alternative ABC Process Diagram