CS302: Software Engineering

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.