CS302: Software Engineering

Guidelines for Developing Booch Diagram 

Booch diagrams, also called module structure diagrams, provide a graphical summary of the class and object information in the entire application. The icons for drawing the diagram are shown in Figure 12-16 with service objects in vertical rectangles with no other detail beyond their name, and problem domain objects in vertical rectangles with smaller ovals to identify the object and horizontal rectangles to identify the individual processes. One diagram connecting the domains as required is drawn; then one Booch diagram for each subdomain (or for the whole project if it is small) is developed. 

The steps to drawing a Booch diagram are:

1. Draw the Booch icons (see Figure 12-16) relating to service and problem domain objects. 

2. Evaluate and choose a scheme for connecting the objects via messages. 

3. Draw lines between objects to signify the legal message connections. 

4. Define message processing scheme.

FIGURE 12-16 Booch Diagram Icons

Service objects selected for controlling application operations are arranged by personal preference, but can be grouped by function performed: scheduling, synchronizing, and multitasking within subdomain. The service objects described in the previous section are shown with sub domain grouping in Figure 12-17. 

Problem-domain objects are obtained from the process-object assignment list developed during analysis. This table is now reversed with the information arranged by object for this diagram. During the reversal process, a reevaluation of process-object assignment should be made to ensure that the processes are associated correctly with their necessary objects. Subdomain groups may be maintained on the diagram which means that we may have new superset objects to define the split between objects for subdomain processing.

FIGURE 12-17 Service Objects by Subdomain

Processes that are candidates for generic, reusable object development should be marked consistently in some way, for instance by bold or italic print to identify them visually. A quick glance at the diagram gives the viewer a sense of the extent to which reusable objects and processes are being leveraged in the application. 

After the icons are drawn, they are played with to evaluate different message passing schemes.

There is no one right way to do message passing, but there are definitely some methods that are better than others. We will walk through a reasoning process for message passing definition in the ABC Video example. In general, the goal of messages are 

1. To accomplish the application's tasks. 

2. Pass minimal information and pass only to objects requiring information. 

3. Minimize the potential for bottlenecks. 

4. Maximize the potential for application throughput.

FIGURE 12-18 Sample Configurations of Object Message Passing

The evaluation of alternatives is to determine the best throughput scheme of message passing without creating bottlenecks, while accomplishing the first two goals. Booch suggests a 3x5 approach to this evaluation in which, rather than drawing the diagram icons on paper, the information for each object is written on a 3" x 5" card. The cards are arranged spatially in different configurations on a large piece of paper with lines drawn to signify the required inter-object message communications. When a configuration is identified that might be useful, it is annotated for further analysis. Figure 12-18 shows two different configurations for a simple application. You can see how, if you have 20 or 30 objects, the 3" x 5" method simplifies evaluation of message passing schemes. 

All further alternative configurations are evaluated to determine message traffic. Message traffic is the number and direction of messages in the system. Overall, the goal is to minimize the number of messages passed for any single transaction, while not overloading any single object with message traffic related work. 7 The minimum number of messages is n-l, where n is the number of packages needing to communicate in the application. That is, once initiated, each package must communicate with at least one other package. The centralized message control scheme shown in Figure 12-18 shows an example of n-l messages. The arrangement with the best message traffic configuration is selected for prototype development, and the design process continues.

ABC Booch Diagram 

Before we can develop a Booch diagram, we need to digress and redefine some application needs to fit the SQL environment. 8 The drawing of packages normally assumes no consolidation of functions or data via user views, but we have collapsed our processing to take advantage of SQL features. Therefore, Table 12-6 shows the effects of user views on data domain processes: the 11 data processes are now eight consolidated processes. The remaining subdomains are not affected by the data changes.

First, we will draw the packages based on what we now know to be the design of the application (see Table 12-6). There are four data packages: Customer, Videolnventory, UserViewl which includes VideoOnRental, VideoInventory, BarCode Video and Customer, and U serView2 which includes VideoInventory and BarCodeVideo (see Figure 12-19). The related processes for those data objects are placed in horizontal rectangles in their respective packages. 

There is one scheduling service object (which we may not need because of the environment) that includes initiation and termination of the application, user sessions, and transactions. There is an interface service object to provide all display and input from personal computers (see Figure 12-19). The hardware service object contains only one process for printing TempTrans. Finally, the TempTrans object contains the data and problem domain processes that are the core of rental processing. 

Next, we try different configurations of the objects to develop a message passing scheme that will provide necessary processing and information to called objects, while minimizing the communications overhead in the application. Figure 12-20 shows one reasonable message passing scheme that follows the logic of processing. The scheduling object passes control to the interface object which has some choices. The interface object could pass, for instance, a CustomerPhone to either TempTrans or Customer to initiate rental processing. If the pass is to Customer, it could return and pass the customer information to Temp Trans , or Customer could continue and initiate TempTrans directly. You see how the options can build and get complex. We will opt for a fairly traditional scheme in which the Interface will pass any rental transaction data to TempTrans which will determine what to do with it. This decision is reflected by the line connecting Humanlnterface with TempTrans.

TempTrans then initiates one of three data retrievals: Customer, UserViewl, or UserView2. The data is returned and TempTrans continues processing. This method of passing provides the most information hiding between objects, but could result in a bottleneck within TempTrans which is controlling all of the inter-object communication for the problem (e.g., software), hardware, and data subdomains. This is a potential problem that would be checked during prototype development. 

The Humanlnterface object also communicates directly with Customer and Videolnventory for create processing which does not require TempTrans. All completed transactions, regardless of type, return to the Scheduling object to terminate the transaction.