Object-Oriented Design

Introduction

Object-oriented analysis defines classes and class/ objects, processes, and the assignment of objects to processes, resulting in encapsulated objects. In object-oriented design (OOD), we continue this analysis of the problem domain to assign the encapsulated objects to one of the four subdomains, elaborate component definitions to include service processes, design module interactions, and define the required messages and their type.

Conceptual Foundations

Encapsulation and inheritance are the basis for OOD, just as they were for object-oriented analysis. In addition, the scope of the thinking process is expanded. The design approach is holistic, designing, people, hardware, software, and data as the four components of object-oriented systems. As figure 12-1 shows, the four components all relate to each other and can all communicate with each other. This design methodology makes a valuable contribution to methodological thinking by integrating the components, many of which are frequently ignored. As multiprocessor computing, such as in client/server, increases, this type of classification will be required of any methodology. Object method developers have led the thinking about multiprocessor applications because of the closeness between object-oriented applications and operating systems from which many concepts are borrowed.

OOD explicitly uses an iterative approach to detailed design that Booch calls "round-trip gestalt", meaning the incremental development of whole applications. Each prototype is the entire application as currently defined. As the prototype is examined, further details of operation are explicated for incorporation in the next iteration of the prototype. Following the format of previous chapters, we first define terms used in the OOD process, then move on to developing guidelines for each step and an example of the step and thinking processes for ABC Video's rental application.

FIGURE 12-1 Object-Oriented Subdomains

Definition of Object-Oriented Design Terms

The seven steps to performing an object-oriented design are: 

1. Allocate objects to four subdomains, including human, hardware, software, or data. 

2. Develop time-event diagrams for each set of cooperating processes a.'1d their objects. 

3. Determine service objects to be used. 

4. Develop Booch diagrams. 

5. Define message communications. 

6. Develop process diagram. 

7. Develop package (i.e., module) specifications and prototype the application.

In this section, we define the terms used in these steps, again integrating and extending the work of Booch with that of Coad & Yourdon. Keep in mind that while the terms are fairly well-defined, the manner and order of implementing the steps is not. The documentation created by these steps is summarized in Table 12-1. 

In the first step, problem domain objects are assigned to one of the human, hardware, software, or data subdomains. The human subdomain defines human-computer interaction in the form of dialogues, inputs, outputs, and screen formats. A dialogue is interactive communication that takes place between the user and the application, usually via a terminal, to accomplish some work. A dialogue defines actions of users and actions of the application and hardware. Inputs (i.e., data entry), outputs (e.g., reports), and screens are the three modes of communication used for a dialogue. The task being performed is usually a transaction relating to a business event (e.g., sale of goods), but could also relate to application-generated events, such as sensor readings in process control or a data request in a query application. A screen design alone is a static definition of field formats while the dialogue is a series of interactions that takes place via a dialogue.

The hardware subdomain defines object assignment to physical processors or firmware. The hardware interface is significant as we develop applications using more firmware, mainframes augmented by local intelligent devices, and distributed processing. To support these types of processing, allocation of tasks to hardware must explicitly be part of the methodology.

TABLE 12-1 Object-Oriented Design Documentation

The software subdomain defines service control and problem-domain objects. Service control objects, also known as utility objects, manage application operations. Depending on the complexity of the application, synchronizing, scheduling, or multitasking services to control object/process work might be required. Problem-domain objects are the class/objects and objects (hereafter, both are referred to as objects) defined during analysis and describing the application functions. 

The last subdomain relates to data, which are the actual instances of the objects in the solution set. During the data design, data are normalized and redesigned to accommodate operational efficiencies. Depending on the 'purity' of the object implementation, the physical data storage mayor may not implement encapsulated data and processes in the database. The most common variation of data storage is a template definition that uses physical address pointers to reference the physical data store for data and processes. The template is analogous to the File and Working-Storage Sections of a COBOL program, but includes a process template as well as a data template.

The second step for all processes, regardless of their subdomain assignment, is to develop time-event diagrams. Time events are the business, system, or application occurrences that cause processes to be activated. Time-event diagrams show sequences, concurrency, and nesting of processes across objects. The time-event diagram, then, shows the relationships between processes that are triggered by related events or have constraints on processing time. Process relationships are either sequential or concurrent, determining the types of service objects required in the application. Processes that are not concurrent are sequential and related only by data or parameters passed between the processes. Concurrent processes operate at the same time and can be dependent or independent. Dependent concurrent processes require synchronization of some sort. 

Above, we defined service control objects as managers of application operations. The third OOD step is to determine which service objects are needed to control the application. There are three broad categories of service objects: synchronizing, scheduling, and multitasking.

Synchronizing is the coordination of simultaneous events. Synchronizing objects provide a rendezvous for two or more processes to come together after concurrent operation (see Figure 12-2).

FIGURE 12-2 Diagram of Synchronizing Object Functions

Scheduling is the process of assigning execution times to a list of processes. Scheduling objects can be for sequential, concurrent-asynchronous (i.e., independent), or concurrent-synchronous (i.e., dependent) processes. In the terminology of COBOL, scheduling objects are analogous to a mainline routine (see Figure 12-3), but the scheduler performs many functions beyond those of a COBOL mainline. 

Multitasking is the simultaneous execution of sets of processes (see Figure 12-4). Each set of concurrent processes is called a thread of control. These threads are initiated by the scheduling objects and controlled by multitasking objects. Multitasking objects track and control the execution of multiple threads of control and can be in both the problem domain and the service control domain. These three types of service control objects provide the structure within which problem domain objects execute.

Service object definition is based on time-event diagram analysis. If all objects are sequential and used one at a time, then only scheduling objects are required. If concurrent processing takes place, synchronizing and scheduling objects are used. If many users are supported concurrently, multitasking objects are added to the other types.

FIGURE 12-3 Scheduling Object Functions

After service objects are identified, the next step is to begin to develop a Booch diagram. A Booch diagram depicts all objects and their processes in the application, including both service and problem domain objects. First, a draft diagram is created. Then, several message passing schemes are evaluated. After a message passing scheme is identified, Message contents are defined.

essage contents are defined. The basic graphical forms used are rectangles and ovals (see Figure 12-5). Vertical rectangles signify a whole package. A package in OOD is a set of modules relating to an object that might be modularized for execution. Service packages are single purpose and do not usually have subparts that are visible to the rest of the application. Service objects have no visible data, that is, no oval identifying a data part to the object. Problem-domain packages have data identifiers for objects and processes. The object in the oval and the process names are each in their own horizontal rectangle (see Figure 12-5). In Figure 12-5, the lines connecting modules show allowable paths for messages. 

Next, messages are defined. A message is the only legal means of communication between encapsulated objects. Messages are clear in their intention, but not clear in their implementation which is completely determined by the language. For instance, at the moment, Ada does not implement message communication. In this text, a message is the unit of communication between two objects. Messages contain an addressee (that is, the object providing the process, also called a service object), and some identification of the requested process.

FIGURE 12-4 Multitasking Management of Multiple Threads

FIGURE 12-5 Sample Booch Diagram- Simple Inquiry Process

Messages may be unary, binary, or keyword (see Figure 12-6). Unary messages contain only an addressee and service identifier. Binary messages contain addressee, service identifier, and two arguments (that is, variable object names or addresses upon which the service is performed). Keyword messages contain addressee, service identifier, and one or more keywords, each with an argument to show optional process selection. Message definitions probably will expand as languages capable of expressing and processing object-oriented designs develop.

FIGURE 12-6 Example of Message Types

The next step is to develop a process diagram that defines the hardware environment and shows process assignments to hardware. The first activity is to draw a hardware configuration showing processors (shadowed boxes in Figure 12-7) and devices (plain boxes in Figure 12-8). Lines connecting processors identify allowable message paths. At this summary level, multiple messages may travel each path. 

When the process diagram is complete, the Booch diagram is divided and redrawn for each processor in the configuration. These subdiagrams show the extent of replication in the application and may identify new service object needs to control interprocessor communications. The message list is reexamined to ensure that all interprocessor messages are accommodated and complete. For multiprocessor applications, the timing of processes is reverified to ensure correct definition.

Using the information from the problem domain analysis and the OOD diagrams describing object interrelationships and timing, the next step is to develop package specifications and prototype the application. These are not the last steps in the design, only the last steps in an iteration of the design process which may have several iterations. As a result of prototype development, other service objects might be recognized as needed. Iterating requires review of all design steps and redoing analysis as required to support development of a complete application prototype for each iteration.

Package specifications define the public interface for both data and processes for each object, and define the private implementations and language to be used. The public interface is that part of the data and process definitions visible to all objects in the application. The private interface describes the physical data structure and actual functions (i.e., data manipulations, calculations, or control processes) to be coded for the application. Multiple implementations of the same function that operate on different data types might be required. The function that has one name but multiple implementations is called polymorphic. Polymorphism is the ability to have the same process, using one public name, take different forms when associated with different objects.

the language to be used. Process timing (i.e., sequential or concurrent) and a need for polymorphism determine the type of implementation language required. Some languages are more constraining than others. To understand these language differences, binding and client/server relationships should be understood. Binding is the process of integrating the code of communicating objects. Binding of objects to operations may be static (fixed at compile time), pseudo-dynamic (parameter driven and decided at the beginning of a session), or dynamic (decided for each object while the system is executing, that is, at run time).

FIGURE 12-7 Process Diagram Example of Convenience Store/Gas Station Network

A major difference between object orientation and other methodologies is the shifting of responsibility for defining the data type of legal processes from server (or called) objects to client (or calling) objects. A server object is one that performs a requested process. A client object is one that requests a process from a supplier. For instance, you might need to translate a date from month-day-year format to year-month-day format. As a client object, you request the translation of the supplier object and pass it the date to be translated. If the language supports dynamic binding, you also pass the data type of the date (for example, binary string or packed matrix). This shift, to client/server logic, plus the notions of inheritance and dynamic binding, support the use of polymorphism. 

Let's return to the idea of binding and work our way through these ideas and how they work together. In most business applications, we think of processes as always operating on the same type of data. For example, items on an order have an order quantity (for example, 2), quantity type (for example, each or dozen), and price (for example, $1.20) that is expected to match the quantity type. To compute the line item total, we multiply quantity times price for a given quantity type. But what if the type quantity is not known beforehand and the formula must change based on the type? Then, we have three choices.

First, we could write many routines that are all resident in the compiled code as static binding requires. This is the most common COBOL solution. 

Second, we could write many routines that use information passed to the computation procedure to identify which routine to use for the session (for instance, only dozens will be processed in one session).

his is the most common COBOL solution. Second, we could write many routines that use information passed to the computation procedure to identify which routine to use for the session (for instance, only dozens will be processed in one session). This is called pseudo-dynamic binding (e.g., in Ada at the moment). 

Third, we can write many routines and pass the quantity type to the computing object in the request message to dynamically bind and select the routine it needs to compute the total (as in Assembler, C++, or Smalltalk). Dynamic binding is done on-the-fly at run time. When the computation is complete, the quantity type code no longer is kept in the computer's memory.

Binding time is a function of the language used and the application's requirements. If the application is batch, single-thread, and sequential, there is no need for any but static binding. If the application is anything else (multithread, concurrent, real-time), dynamic binding is desirable, but many languages only support pseudo-binding. Then, the application requirements, in the form of business needs for response time or process time, should drive the language selection decision. 

We no longer assume that a called object can do only one thing in only one way; instead, a called object can do only one thing but it can do it in many ways. This ability to do one thing many ways is polymorphism. Polymorphic processes take different forms when associated with different objects, but a process always takes the same form with a given object. Client-object message requests contain both the process and the form of the process. The polymorphic process then loads its correct process code to service the request via the dynamic binding mechanism of the implementation language. An example of pseudocode for polymorphic pairwise item comparison is shown in Figure 12-8.

This discussion summarized the major terms, diagrams, and procedural steps in object-oriented design. Next, we discuss the steps of OOD in detail, including allocation of objects to the subdomains, developing time-event diagrams, determining service objects, developing Booch diagrams, developing process diagrams, and developing module specifications. Prototyping is beyond the scope of this text.

FIGURE 12-8 An Example of Polymorphic Descriptions for a Comparison Process

Object-Oriented Design Activities

In ABC's rental application, we are using off-the-shelf software in an off-the-shelf hardware environment. In the environment, the operating system, network, database, and form of human interface are all given. Because of our choices-PCs, MS-DOS, Novell Netware, and a SQL DBMS-the application does not easily lend itself to object-oriented design that assumes none of the services and functions provided in our target environment. Because of the differences, we will discuss ABC at two levels: one for SQL DBMS which becomes unobject-like, and one for a Unix/C++ environment that stays object-like. First, we follow ABC through the process of design keeping in mind that the off-the-shelf software will be used. Think of this design as object-based, that is, based on object thinking, but decidedly not object-oriented in implementation. Object-based design is what is practiced by most novice object-designers, and is what most CASE tools being retrofitted for object orientation will be. In the chapter appendix, we present a second design for a Unix/c++ environment that is completely object-oriented. Without both discussions, the view of object orientation that you would get is not complete, and some of the discussions would be inaccurately stated for object-oriented design.

Allocate Objects to Four Sub domains

Heuristics for Allocating Objects to Human, Hardware, Software, and Data Subdomains 

The first step is to allocate the problem domain processes to one of the subdomains: hardware, software, data, and human interface. Each process and the data it requires from its object3 are examined to determine whether they are best implemented as part of the human interface, hardware, software, or data subdomains. There is no particular order to the allocation process. It is recommended to allocate the software domain last, because it is the default for all processes not allocated elsewhere. Since these implementation alternatives are usually not broken apart by other methodologies, and since hardware is usually completely ignored, the consideration of these subdomains and explicit allocation of objects to them provides useful detail that is explicitly documented for maintenance. Also, since hardware options are becoming more numerous and common (e.g., automated teller machines have local intelligence and some of the application code for deposit and withdrawal processing), this mechanism accommodates hardware and firmware in design decisions.

We will discuss data first, because current guidelines demonstrate some of the shortcomings of current OOD writing. Booch suggests that standard database activities should be assumed to be under the control of the data domain, including create, retrieve, update, and delete processes (i.e., CRUD). All other data manipulations or computations are allocated 'somewhere else.' Coad & Yourdon, and most authors published after 1992, assume the use of a DBMS and usually an object-oriented one that includes the properties of persistence, inheritance, and abstract object-oriented data definition. Some authors assume use of an SQL-compatible database with an equally unobject-like language, recommending that the data functions should be separated from the application which will maintain its object-like properties for all non-data operations. 

Keep in mind that this is an inexact process that is highly dependent on the implementation language and the implementation environment. For example, if we were using Smalltalk, in which everything is an object, separation of data access and manipulation is usually more efficient than keeping the functions all together. Conversely, if an OODBMS, such as Gemstone, were used, the DBMS object performs the physical CRUD actions and the application objects usually control the logical CRUD functions that are grouped by object. The key idea is that judgment on allocation of functions is required and needs to be done with knowledge of the entire implementation environment.

If the application needs to use a nonOODBMS, then evaluating whether data integrity, security, and access controls can be adequately maintained by not using the DBMS language is required. If the application can both perform the functions faster, and provide for integrity and so forth, then there should be a real analysis of where the functions should be. The application requirements for execution and response time may force use of a programming language when constraints are tight, and default to use of the DBMS language when there are no constraints. Table 12-2 summarizes this discussion, showing that allocation of physical and logical read, write, and delete actions and the control over security, integrity, and access be tied to constraints and t~e type of database environment used. If no DBMS IS used, the alternatives are either to allocate DBMS functions to each object, or to design data control objects that perform DBMS functions, or to design a polymorphic reusable object that performs all DBMS functions. 

We said before that DBMSs illustrate the problem of all authors in object-oriented design. For the most part, 00 authors do not work in commercial business and do not build commercial applications; they work in defense-related businesses and build real-time, embedded applications which function as part of some larger system. For instance, defense applications might include building a guidance system for a missile, a monitoring system for airplane radar, or a reporting system on the Hubble microscope. These applications all have no persistent data; rather, they work on sensor data and pass on the information they filter for processing or feedback by other systems.

TABLE 12-2 Heuristics for Data Allocation Processes 

The problem with applying embedded-system thinking to persistent object problems is that there is little overlap in designing for temporary and persistent data. Persistent data and, in particular, DBMS-stored persistent data, have entirely different thinking processes that the computer-scientist authors of most object -oriented methods do not recognize. Because of this lacking recognition, these heuristics on object allocation are more crude than those of, say, process methods which have been tried for the last 20 years.

A similar problem occurs in the hardware domain. Object-oriented authors most often are designing state-of-the-art hardware as part of their application design including customized operating systems and software. Most business applications use off-the-shelf hardware that is generalized in function and has many user features. The only custom development in most business applications is the application software itself. So, the design problem with hardware is opposite that of DBMSs. For hardware, the methodology authors do more detailed levels of development than is necessary in most business applications. You will see this problem again when we discuss service object definition.

Now let's consider allocation of functions to the other subdomains. The human interface is exactly what you think it is, the interactions with people, usually through a terminal device, that provides the essential inputs and outputs of the application. The human interface is discussed poorly in the OOD books that do exist (including all of those in the references of this chapter) because of the traditional lack of human users in object-oriented applications. Because of this lack, they are discussed in Chapter 14 as one of the 'forgotten activities' of systems analysis and design.

In general, the activities that provide human interface control, such as screen interactions, are recommended to be relegated to the human component of the application. Again, there are no compelling reasons for blindly making this decision, therefore it is subject to analysis. Activities that can be grouped across objects, such as line control, error message display, and screen reads and writes can all be abstracted out of the individual objects and placed in reusable, generic objects. The actual editing of data from screens should remain with the original object unless there are sufficient similarities across screens and data items to warrant abstracting them out as well, or unless the functions will be assigned to human interface hardware. To perform this abstraction requires listing all the detailed, primitive actions required of screen interactions for each object, identifying which actions are performed automatically by the DBMS or other application software and removing them from the list, and reevaluating the remaining items to determine whether or not there are commonalities across objects. 

This primitive level of detail may be deferred automatically when you relegate all screen interactions to the human interface. This deferral allows you to build the interface during proto typing even though you may not know all of the primitives during the first iterations. In other words, allocating screen interactions to the human interface is a means of deferring detailed design decisions until initial prototype development.

The more distributed devices and processors, the more likely that processing might be allocated to firmware embedded in otherwise unintelligent devices. For instance, automatic teller machines include some intelligence for editing magnetic strip information from the cards used for withdrawal and deposit of funds from banks. They can, for instance, tell what type of card, such as Visa, is being used, and whether or not the personal ID number (PIN) is a valid combination of digits. They cannot tell whether or not the PIN matches the card number entered because that requires access to a database that is not stored locally. In addition, specific hardware functions, such as accepting a deposit envelope, are functions that would be allocated to hardware. 

Allocation of processes to hardware/firmware is determined by the need for fast response time, minimum communication delay, and minimum processing time. Whenever any of these three constraints are present in an application's functional specification, hardware process allocation should be investigated. Some authors recommend that allocation to hardware can include functions to be performed by the resident operating system. When there is access to these functions and they can be used as generics, this is a useful, time-saving idea. So, for instance, in systems such as Unix and Smalltalk, where the environment, operating system, and application are essentially inseparable, thinking of operating systems and hardware as one simplifies design thinking.

Finally, we have allocation of processes to software. This allocation assumes that all problem-domain processes not already allocated elsewhere will be implemented in software in the software domain. This allocation includes remaining service and problem domain objects after the other allocations are complete. Now, let us tum to ABC Video to see what allocation means in this application.

ABC Video Example of Subdomain Allocation 

ABC's rental application will be an interactive, multithread set of processes which will service up to six threads of control, with growth to some higher number. Therefore, the concurrent processing requirements of the application should be considered when allocating processes to subdomains to ensure that timing requirements will be met. 

To refresh your memory, we had decided to use an SQL-compatible database to implement the application. We can interface the SQL language with other languages, but, as is typical of most DBMS software, all data accesses must go through the DBMS. This implies that the create, retrieval, update, and delete (CRUD) functions will all be allocated to the data subdomain as discussed above.

By doing this allocation, we explicitly are deciding what is and is not object-oriented. SQL is not object-oriented. Therefore, any functions performed in SQL are not object-oriented. The design can proceed in an object manner until the primitive level is reached, then the design is completed in SQL. 

If we look at the output from the analysis where we allocated objects to processes, we can identify all those processes relating to these functions. Each object has simple CRUD functions as well as a need for CRUD functions on a user-view of the database that incorporates Customer, Inventory, and VideoOnRental. Eventually, for SQL implementation, we will collapse the superset objects back with the class/ objects and will control the use of add and read functions by logic in the SQL DBMS application code. Any access control on superset objects is controlled by the DBMS.

Figure 11-20 processes are listed in Table 12-3 with their subdomain allocations. First, consider the data subdomain. From Table 12-2 we know that we can allocate the data functions based on application requirements. We are using a non-object DBMS and have no constraints on processing. Part of the attraction of the fourth generation database is its ease of use, therefore, anything that can be allocated to the DBMS should be. As Table 12-3 shows, all CRUD functions are allocated to the data function. Similarly, printing, which interfaces with external devices, is allocated to hardware. Print control is allocated to hardware because in a LAN, spooling and printing are network operating system functions that are not under application control. 

All data entry functions are allocated to the human interface for design and control. Remaining processes are allocated to the software subdomain.

Draw Time-Order Event Diagram

Rules for Drawing a Time-Event Diagram 

A time-event diagram graphically depicts the timing constraints and events that trigger related objects, showing sequences of processing, concurrent processes, and nesting of processes across objects. Time-ordered event diagrams show neither flow of control nor if-then-else logic. These diagrams are showing what can happen in time, including required timing. The time-order event diagram becomes the basis for decisions about concurrent processes and is helpful in identifying service-object needs of the application. 

The diagram is a two-dimensional graphic with objects listed down the left axis and time, broken into segments corresponding to events in the application, along the horizontal axis. For processes that might run concurrently, multiple lists of the objects are shown. Synchronization of concurrent events is shown by the divergent lines returning to one event at some point (see Figure 12-9).

Two formats for time-event diagrams are used. One shows deviations from an otherwise horizontal line with events and critical times demarcated by vertical bars (see Figure 12-10). The other format shows rising steps to mark events and critical time slots within the main object (see Figure 12-11). If one diagram per transaction is created, the rising step method is preferred because it is easy to see the points of change. If one diagram per application is drawn, the information can be presented more compactly with the horizontal line method.

FIGURE 12-9 Potentially Concurrent Processes

TABLE 12-3 Process Subdomain Assignments

Diagram segments are defined as event-driven or clock-driven. For time-constrained segments of the diagram, the allowable maximum time is labeled along the horizontal axis (see Figure 12-12). For event-driven segments, the event is identified on the horizontal axis. Actual drawing requires knowledge of the problem domain requirements for processing. The steps to creating a time-event diagram are:

1. Define all allowable transactions in the application. 

2. Define the processing steps for each transaction. 

3. For each transaction, design a time-event diagram reflecting the dependence or independence of processing steps.

FIGURE 12-10 Horizontal Time-Event Diagram

ABC Video Example of a Time-Order Event Diagram 

For ABC, Table 12-4 shows the transactions allowed in the application. The transactions should have no surprises by this stage of design, and should be closely related to the processes defined for each object. Some objects, such as TempTrans, have processes that relate to more than one transaction, while other objects each have processes that reflect one transaction, such as for Customer.

FIGURE 12-11 Rising Step Time-Event Diagram

FIGURE 12-12 Diagram Segments Identified as Time-Driven or Event-Driven

Of the transactions shown, we will discuss two that are representative of the others: video inventory additions and rental processing. 

First, we describe what happens for a Video Inventory addition. This step requires detailed knowledge of the specific processing to be performed. This knowledge comes from user interviews, study of current procedures, and so on. Subprocess details should be based on the processobject assignment list (Figure 11-20). If there are discrepancies between the use of objects here and the list, the list should be revised to reflect this more detailed level of thought. The steps to adding inventory are:

1. Enter a new VideoId and remaining infonnation for a particular film.

2. When the NumberOfCopies is entered, add the new video infonnation to Videolnventory. Begin prompting for BarCodeld until the number of bar codes is equal to NumberOfCopies. 

3. As each BarCodeId is entered, add the new BarCodeVideo entry to the database. 

4. When the number of BarCodelds entered is equal to NumberOfCopies, signal completion of the transaction to the clerk and end processing.

Figure 12-13 shows the time-event diagram for the processing steps about video inventory creation. Notice that two objects are involved: Videolnventory and BarCodeVideo. Even though Videolnventory is begun first, its processing is completed before BarCodeVideo processing takes place. The processes are related in that the Videold is passed to the BarCodeVideo process, but they are otherwise independent. There is no necessary concurrency within the transaction.

TABLE 12-4 ABC Transaction List

The rental transaction shows that several processes might be concurrent. First the steps to completion of a rental process are: 

1. Get the entry and determine its type (either CustomerPhone or VideoId). 

2. If the entry is CustomerId, get all relevant customer information (e.g., name, address, and so on). 

3. If the entry is VideoId, get the corresponding VideoOnRental and place it in memory. 

The first event, data entry, results in one of two possible processes being invoked. These are shown with dotted lines on the diagram to show that only one is running at a time. If the VideoId is entered, then we have a choice to either nest getting the customer or transfer control. If we transfer control, the video information must have been stored in memory for the first VideoOnRental to avoid passing unnecessary data. If we do not transfer control, and nest retrieval of customer information, then the customer information is unnecessarily passed through the retrieval process for VideoOnRental. The best object-oriented decision would be transfer control to maximize information hiding here, but we can treat these accesses as one if the DBMS supports a user view that links the relevant information. SQL DBMS does provide user views and we select that option. (Make sure you read the appendix for true object-oriented design of this information. It is significantly different.) Once VideoOnRental is accessed, then, the related information from VideoInventory, BarCodeVideo, and Customer are all present automatically (see Figure 12-14).

Eventually, we loop through getting all current outstanding rentals from VideoOnRental. This iteration can be programmed to run until a return code indicating no more videos on rental are present. This return code, then, becomes the event to trigger the next step of the process.

FIGURE 12-13 Time-Event Diagram for Inventory Creation Transaction

Control is passed to compute Late Fees on returned tapes that will require a count of the number of VideoOnRentals in memory to be maintained and passed to control this process. Having processed late fees until this count is reached triggers the next step to compute TotalAmountDue. This is a one-time event at this point, and its completion leads to display of all current customer and rental information on the user screen. 

At this point, if there are new rentals, the BarCodelds are entered. This triggers obtaining BarCodelnventory and Videolnventory information. To simplify memory processing, we have a choice similar to that above for customer and VideoOnRental in step 3. In this case, the decision is between treating BarCodeVideo and Videolnventory as separate and independent or nested or the same. In order to treat them the same, we must be accessing a user view that contains the relevant information. Again, SQL allows user views, and we use the user view that collapses this activity from two to one. As each video's information is displayed, the TotalAmountDue is recomputed and redisplayed. 

Upon receiving the trigger that the rentals, or returns, are complete, payment processing takes place and continues until TotalAmountDue equals zero. At that time, all of the VideoOnRentals, BarCodeVideo locations, and video history counts (for returns) are updated. These are once again assumed to be in the same object as a result of having user view capabilities in SQL.

Determine Service Objects

Guidelines for Determining Service Objects 

Service objects perform background scheduling, synchronizing, and multitasking control for the application. The activities performed by some service objects are analogous to those of an operating system in a mainframe environment which provides job management, task management, memory management, I/O management, and data management. For that reason we will digress a minute to discuss these operating system functions, relating them to service objects.

FIGURE 12-14 Time-Event Diagram for ABC Video Rental Transaction

Job management routines initiate processing for individual applications. In multitasking applications, that means that the first scheduling tasks are loaded and turned over to the task management routines for execution. In mainframes, there are multiple jobs, sometimes as many as 50, executing concurrently. The job management routines keep track of all jobs active in the system. 

The task manager monitors and tracks individual steps within a multistep set of sequential processes (i.e., a job). Task management is similar to monitoring done for multiple threads of control for concurrent processes. The work of job and task manager routines are similar and include: 

• Load, schedule, execute 
• End, abort 
• Get/set process attributes 
• Create/terminate process 
• Wait for time 
• Wait/signal event 
• Get/set process attributes for jobs, files, or system data

Multiple-thread management requires both job and task management. Think of individual transactions as analogous to jobs to be managed, and of individual steps to completing a transaction as tasks, or processes in OOD terminology. The job management, transaction routines manage whole transactions, and task management routines manage atomic processes to perform the transaction. 

Monitoring of individual processes (or transactions) and sequences of processes, one per thread, is accomplished either by stacks (sometimes called heaps) or queues, depending on the operating system software. The stack commands are push to add something to the stack and pop to take something off the stack. The queueing commands are enqueue and dequeue, to add and delete items, respectively. The stack (or que) items, in multithread control, include the name of the task, its current execution status (i.e., running, idle, or waiting), and the address of the next command to be executed. One set of stacks is managed for each transaction, and one set is managed for each process. Stacks operate on a last-in, first-out principle while queues are first-in, first-out.

Similarly, the I/O manager and data managers act together to perform physical inputting and outputting of information to central processing unit (CPU) memory. The I/O manager interacts with terminals, printers, and other devices that are moving information physically into and out of the computer. The data manager interacts with secondary storage devices, such as disks. The activities performed by these managers include file manipulation and device management. The key activities include:

File Manipulation: 

• Create/delete file 
• Open/close 
• Read, write, reposition 
• Get/set file attributes 

Device Management: 

• Request/release 
• Read, write, reposition 
• Get/set device attributes

These tasks are usually provided in primitive form by the operating system and in a more abstract form by a DBMS. The more sophisticated the software environment, like a DBMS, the more likely the services are provided by the environment. 

Finally, memory management keeps track of the location of each item, in random access memory (RAM). Recall that all data and programs must be memory-resident to be executed. In dynamic applications in which modules and data are being moved into and out of memory constantly, memory management is a crucial function. The main functions provided by the memory manager include:

• Allocate/delete memory (can be dynamic or static) 
• Track used and free memory location by task 
• Track used and free memory within each task's allocation 
• Garbage collection (identify and erase or write-over unused objects)

All operating system management is accomplished by cooperating processes that use event-driven interrupts to provide services in the system. Interrupts at the operating system level are called supervisor calls (SVCs). The implementation of SVCs differs across operating systems.

Now, let's relate this operating system information to applications. All of these functions are required for the three types of control provided by service objects. If you are working in a Unix or Smalltalk environment, which already have been used for application development, then many of these functions should already be available for reuse. If you have to write your own, you need to test and retest these functions very thoroughly to ensure proper application functioning. In any case, you need to decide which of the service object functions are needed and provide them for your application. 

The steps to identifying the service objects are:

1. Examine the event diagram and identify each process as sequential or concurrent, and, if concurrent, as independent or cooperating. 

2. Define the service needs for loading the object, processing the object, synchronizing the process to others, and sending any messages the object might generate. 

3. Compare this list to one specific to the target operating environment that identifies reusable service objects that can be used by this application. 

4. Enter the name, language, and any other information needed to identify the reusable object. For all service objects, make sure that the class, object, event, and/or process using the service object are identified. 

5. When all reusable objects have been identified, the remaining service objects included in the remaining tasks are divided among the four subdomains as appropriate for module specification.

In general, all applications need scheduling objects (see Table 12-5). The need for synchronization and multitasking are determined by the time event diagram and whether or not the objects are concurrent and multiuser. Table 12-5 shows that concurrent, single-user processes need synchronization while concurrent and multiuser objects need synchronizing and multitasking services. Multiuser, sequential processes, like ABC, require both scheduling and multitasking services.

TABLE 12-5 Decision Table for Service Object Type Requirements

ABC Video Example of Service Objects 

First, we examine the time-event diagram to identify each related process as sequential or concurrent, and independent or cooperating. 

There are three possible sets of concurrent processes within one rental transaction shown on Figure 12-15 as circled and numbered sets. The other processes are sequential. Our decision on concurrency, then, is based on the implementation environment. Let's say that SQL supports multithread but not multitasked processing, therefore, we need to decide sequential ordering of the processes and how the processes will be performed in SQL.

Next, for each process, define the service needs for loading the object, processing the object, synchronizing the process to others, and sending any messages the object might generate. SQL supports user views. By creating user views to link VideoInventory to BarCodeVideo, and VideoOnRental to Customer, VideoInventory, and BarCodeVideo, the opportunity for most concurrency disappears in one database access that retrieves all the related information.

FIGURE 12-15 Potential Concurrent Sets of Processes

Even though we have removed concurrent object processing from the diagram, we still have both transaction level and process level service object requirements. Transactions and processes all need scheduling, including processes that load, store in memory, initiate, terminate, monitor events, and possibly provide message communications between objects. 

This list is compared to our target operating environment: SQL on a PC LAN running Novell Netware.™ The services are all provided transparently by the operating environment and are not needed to be developed in primitive form for ABC's application. Even though the target environment is not object-oriented, the need for service objects disappears because these are all services provided in the operational environment.

The next step is to examine a current library of reusable objects for use as problem domain processes. Since ABC's environment is new, there is no reusable library; therefore, any modules would need specification and development.

Develop Booch Diagram

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.

Define Message Communications

Rules for Defining Messages 

The next step after the Booch diagram is to actually define message contents to provide inter-object interfaces for the application. A table is created to document the specific requirements of each message (see Table 12-7). The objects that act as clients are listed in the Calling Object column, service objects are in the Called Object column. This information should come from the Booch diagram coupled with the Process table generated during analysis that identifies objects with the processes that act on them. The Input Message column describes the data that is sent as part of the calling object message to be processed. The output message is the result data that is sent on (or returned) by the called object after processing. The columns Action Type and Return Object are optional. The action type describes the process to be performed in terms of CRUD or other processing. The return object provides continuity of processing logic when the called object does not return directly to the calling object.

TABLE 12-6 Consolidated Process Subdomain Assignments for Oracle

FIGURE 12-19 ABC Rental Booch Diagram Objects

FIGURE 12-20 ABC Booch Diagram Message Passing Scheme

For each process-object pair defined in the Process Definition List, we will have one input message to initiate processing and, if needed, an output message which reports the results of processing. The message list contains one column for each of the types of information shown in Table 12-7. The steps to creating the message list are:

1. Make a table with headings as listed in Table 12-7. 

2. Refer to the list of all object-process combinations. The objects from that list are listed in the' Called object' column. The processes from the process list are placed in the 'Input message' column. 

3. Next, decide both the 'Calling object' and other 'Input message' entries.

These two definitions seem to go together because as we define the input message, we know the information required to perform the process. Once we know the information to perform the process, we decide which object has that information to pass it on. This step determines much of the logical process flow from one encapsulated object-process to another. The logical process flow defines the sequence of processing in the application.

TABLE 12-7 Message List Contents

4. Define the 'Output messages' by determining what type of information is required next from each process as it completes. For data entry type processes, frequently the output message is only an acknowledgement of processing (ACK = successful, NACK = unsuccessful). For some processes, no response is required. 

5. Complete the 'Action type' column. The action type summarizes the type of processing for designers to determine possible implementation consolidation of activities, or to decide on further allocation of processing to hardware, software, or firmware. 

6. Define the return object column.

This column usually refers to the calling object which is ordinarily the object to which control returns, but some nested subprocess might take place. When subprocessing occurs, the return object column identifies the next object entered to help other software engineers understand the logic flow. 

Completeness and correctness review of the message list is done to ensure that each process-object pair has an associated message in the table and that the calling/return objects are correct.

ABC Video Example of Message List 

First, we make a table with the above headings. Then, referring to the process list that we used to draw the Booch diagram, we list all object process combinations. The objects from that list are listed in the 'Called object' column. Make sure that all process-object pairs have one entry in the table. 

Next, we decide both the 'Calling object' from the Booch diagram and the 'Input message' for each entry (Table 12-8 shows the completed list). Then the 'Output message' is completed for each entry. As the output message is complete, we complete each line with the 'Action' and 'Return Object' definitions. 

Table 12-8 shows the message list for ABC's application. It reflects the consolidated data objects, the messages decided during the development of the Booch diagram, and the details of information that must be provided for each object-process. Notice that many processes are called from within an object itself. This localizing of processing is desirable to simplify inter-object communication and ensure information hiding, but it also can encourage development of nonobject-oriented designs. Make sure that each message contains all, and only, the information required to perform the process. Make sure that each message returns only the information required by the client object.

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

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

Develop Package Specifications and Prototype

Guidelines for Package Specifications and Prototyping 

At this point in the design, the functions to be performed are translated into package specifications for translation into program code. A package is an encapsulated definition that contains both data and process specifications that define an execute unit. The data might be defined in the form of a class, class/object, or object, with specific attributes and identification. There may be one or more processes in a package; they result in individual module specifications and are independently executed under the control of service objects. 

Packages have both public and private parts which are specified. The public package part identifies the data and processes to the application without any indication of how they are physically implemented. The private package part defines the physical implementation. If there are polymorphic definitions of a function, each version of the function is defined separately, and the control mechanism for interpreting the message and activating the appropriate function is defined. Service objects should be used for this interpretation and activation if at all possible. 

The steps to package specification are: 

1. Review the diagram/list set. 

2. Redraw a subset of Booch diagrams, one per processor in the process diagram, to depict objects and processes by processor. 

3. Document packages. 

4. Design physical database if not already designed. 

5. Develop pseudocode specifications for all processes and messaging handling routines.

ABC Video package specifications are not created for this step as it is beyond the scope of this text.

What We Know and Don't Know from OOA and OOD

Object orientation, based on the contents of tables and diagrams, provides a detailed, reasonably complete view of an application. Exceptions to this view are human interface design and specific attention to database, input, and output design. Object-oriented design is distinguished by three characteristics: detail, all potential environments are accommodated, and the need for an object-oriented implementation environment to obtain the payoff from the exercise.

The extensive detail generated in object-oriented design leads directly to module specification which should be straightforward since the definition of process details, the class/object data, constraints, and message communications are all completely defined.

Object orientation, as seen by the exercise in the chapter, can accommodate even nonobject-oriented environments. The benefit of OOD's ability to accommodate any application environment is that, for on-line, object application environments, the methodology does lead to information hiding, minimal coupling, and maximal cohesion by virtue of the thinking processes. Object orientation requires good understanding of operating system concepts, object thinking, and interactions between services and applications. The design process, as the chapter appendix shows, requires iteration and proto typing to get required levels of detail and to ensure efficient processing of message traffic. Most important, object thinking IS NOT the same as entity thinking or as process and data methodology thinking. Object orientation requires a paradigm shift to be done correctly.

Object orientation is not very object-oriented in an SQL implementation environment. The choice of SQL changes the entire design from what it would be in an object environment to be object-based. Like COBOL, the methodology can be made to do anything. Is this the best use of OOD? Not in my opinion. Unless an application is at least on-line and will be in an object-oriented environment, the work required for object-oriented design is not worth the effort. Especially with a fourth-generation DBMS, like SQL, the undesign that must be done wastes tremendous time and could result in a worse design than use of some other methodology. While this compromise is acceptable for a small, on-line application such as ABC, it would not be acceptable for applications with real-time or more complex processing requirements. Much of the effort to develop an object-oriented design is wasted when the implementation environment is not object-oriented. Therefore, the choice of methodology should be driven by the expected implementation environment.

Automated Support Tools for Object-Oriented Design

There are a vast number of object-oriented CASE tools that have all come on the market in the last few years. Some are more complete in life cycle coverage than others. Some environments, such as 001 Tool Suite, cover most of a development life cycle, in this case, from analysis through code generation. Some tools, such as ObjectView, are more object-based than object-oriented. Some, like Software Through Pictures, try to shield the user from code altogether by sophisticated graphics that generate objects for that environment. Their existence attests to the object revolution that is beginning to be felt in business organizations.

TABLE 12-9 Automated Support Tools for Object-Oriented Design

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.