Object-Oriented Design

The text uses the Booch (1991) methodology 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 and 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 to gain familiarity with OOD, which you will apply in Unit 10.

Summary

Object-oriented design (OOD) requires detailed development of all required functionality in the operating system and how it interacts with an application. In this chapter we developed the seven steps to object-oriented design, linking them to the tables developed during object-oriented analysis. First, the objects are allocated to four subdomains: human, hardware, software, and data. The split of processing into these four areas accommodates the use of, for instance, firmware, distributed computing, DBMSs, and intelligent interfaces in what would otherwise be a monolithic development of an application. The second step of OOD is the development of time-event diagrams for all processes and all objects. The purpose of a time-event diagram is to allow the analysts to identify independent, sequential, concurrent, independent, and concurrent, dependent processes. Usually, several alternative ways of looking at the timing of processes emerge from this analysis, one of which is selected for development.

Once the types of process are defined, their service object needs are identified. Service objects closely parallel operations performed by an operating system (OS). ass have five main functions to manage: memory, job, task, I/O, and secondary storage. The memory, 1/0, and secondary storage management functions are directly translatable into object thinking. Job management functions are analogous to those performed at the control level for an entire application and/or user. Job management is more appropriately called session, or user, management in object terms. Similarly, tasks are individual steps of a job and are analogous to transaction-related modules when thinking in objects. Therefore, the term used here for task functions is transaction management. Each type of management function requires its own type of processing and the processes selected are particular to the application and implementation environment.

The fourth step of OOD is to develop a Booch diagram to summarize the objects-both application and service-and their interactions. Booch recommends a 3" x 5" approach for which each object and its processes are shown as a package on a 3" x 5" index card. The set of cards is moved into different configurations and message connections are drawn. The purpose of this exercise is to choose a message-passing scheme that minimizes the potential for bottlenecks and that provides information hiding and minimal coupling. The final configuration selected is documented for the application.

The message connections decided during design of the Booch diagram are elaborated in the next step, which is to define message communications. Each called object and its calling object, input message, output message, action type, and return object are identified.

At a higher level of abstraction, the next step is to develop a process diagram that shows the distribution of functionality and equipment for the application being developed. A process diagram depicts processors, for example, computers, and devices, that is, limited-intelligence equipment such as a disk drive. All equipment and their interconnections are identified. Multiprocessor interconnections show allowable message movement throughout a network, while the device connections show hardware configuration. The functions performed at each processor in a multiprocessor configuration are also on the diagram.

The last step of OOD is to develop package or module specifications for programming. The information from the various tables and graphics is rearranged to show the relevant information for each particular module. Also, details of each module's logic, if not already documented in a dictionary, are defined in the package specifications.

OOD CASE tools come in several varieties: object-oriented life-cycle development, object-oriented design without code support, object-oriented coding without design support, or object-based thinking through adaptation of existing methods.