Object-Oriented Design

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	Create	Human Interface
Human Interface	Video Inventory	Video Information	VideoId, #BarCode Videos Created	Create	Human Interface
Schedule	Schedule	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 TempTrans
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 interprocessor 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