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.
|Calling Object||Called Object||Input Message||Output Message||Action Type||Return Object|
||Execute Init Session||Schedule
|Schedule||Schedule||UserID||Memory Address or Logoff||Execute Init Session||Schedule|
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||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