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.
4. Object-Oriented Design Activities
4.3. 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:
- Create/delete file
- Read, write, reposition
- Get/set file attributes
- 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, 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
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.
|Service Objects Required:|
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
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
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.