CS302: Software Engineering

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