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.
3. 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
|Process Assignment to Object Table
||Contains all solution space objects and, for each, the processes that act on the object|
|Subdomain Allocation Table||List of processes and subdomain assignments|
|Message Table||Contains, for each process, the calling object, the called object, the input message contents, the output message contents, and the object to which control is returned|
|Subdomain Allocation Diagram||Optional graphical depiction of process-subdomain assignments|
|Time-Ordered Event Diagram||Depicts required sequencing of processes|
|Booch Package Diagram||Depicts objects and message flow for the entire application. Lower-level Booch diagrams, one per processor, are created to show objects and processes with message flow.|
|Process Diagram||Shows hardware configuration and process assignment to processors|
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,
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 communications 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
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-5 Sample Booch Diagram-Simple Inquiry Process
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 (sh,adowed 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.
U sing 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).
FIGU RE 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
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.
If A = B
return-code = 1else
return code = 0.Return return-code.
Set sub = 1
Set return-code = 0.
varying sub by 1Return return-code.
until sub = 1st entry.
If A(sub) not = B(sub)
return-code = 1.Compare-exit. Exit.
FIGURE 12-8 An Example of Polymorphic Descriptions for a Comparison Process