Table 4-2 shows how discrete transactions occur in more than one business function, thereby, encouraging modularity.

Table 4-2 Business Functions and their Shared Transactions in AVERTZ Reservation Processing Area

	Business Functions
Transactions	Reserve a car	Check out a car	Check in a car
Find a site	x
Read existing information about the customer	x		x
Update the customer information	x	x	x
Write a reservation	x
Find a car		x
Complete check out		x
Cancel	x	x
Write the checkout or cancellation history		x
Find the rental history			x
Complete the checkin			x

4.3 Using Distributed Forms Processing

An ACMS application usually consists of forms processing and database processing. In an ACMS application without distributed forms processing, all ACMS components are on a single node, and the databases are usually on the same node as the ACMS system.

In a typical application with distributed forms processing, one or more nodes, called the back-end or application nodes, handle the database processing and computation. The front-end or submitter node or nodes handle the forms processing. Distributing the forms work of an ACMS application across nodes has specific advantages:

• Improved performance
  In a distributed system the more powerful machines can be dedicated to database processing while smaller machines handle the forms processing. For example, local offices can have access to a central application and database without overburdening the central node with terminal processing. Tasks that do terminal I/O in processing steps cannot be separated into front-end and back-end processing and therefore cannot be part of a distributed-forms application. To distribute the forms part of an application, you control terminal I/O through exchange steps.
• Flexibility of system configurations
• Wider availability
  More applications are available to the users, because they can have access to applications on nodes other than their own with better performance and a more convenient interface than by using the SET HOST command.
• Better reliability
  With a distributed system, you can install applications on more than one node of a system. If a node fails, ACMS can process a search list so that users are automatically switched to an alternate node where the same application is running.

However, with distributed forms processing, consider the issue of increased DECnet overhead that results from passing workspaces during task processing. Keep workspaces to an acceptable size and do not pass them unnecessarily.

This chapter provides guidelines for mapping business functions and transactions to ACMS tasks.

This information serves as the framework of a Programming Specification by identifying the forms, ACMS tasks, task groups, server procedures, menus and applications used by each business function. Tasks (and steps within tasks), procedures, and forms can be used and reused in a variety of combinations and in differing orders to carry out most efficiently the work outlined in the Requirements Specification, using the transactions described in the Functional Specification.

See Chapter 6, Chapter 7, and Chapter 8 for specific design guidelines about tasks, server procedures and user interfaces. Chapter 9 offers design guidelines for task groups and applications. Appendix C contains a Programming Specification template.

5.1 Deciding on the Relationship Between Business Functions and Tasks

There are several approaches to mapping business functions to ACMS tasks:

• Create one task for each business function.
  A single task for each business function allows for clear mapping between the business function and the ACMS implementation. However, this design does not efficiently reuse sections of the task definition. Figure 5-1 illustrates this model.

  Figure 5-1 Mapping One Business Function to One Task

  ---

  
• Combine several logically associated business functions into a single task.
  This solution adds user-friendliness by minimizing the need for the user to return to the menu. By combining similar tasks, you can avoid coding similar task work multiple times. This solution allows for a clear structure because of close correspondence between the menu and the task. However, the task becomes more complicated. Also, security issues arise because all users use the same task; multiple tasks allow for different ACLs depending on security requirements. Figure 5-2 illustrates this model.

  Figure 5-2 Mapping Multiple Business Functions to One Task

  ---

  
• Create tasks consisting of unique components which multiple business functions can use.
  If similar work must be performed in more than one business function, create tasks that isolate that work. Then use task calling to combine these finer-grained tasks as needed for each business function. The AVERTZ task design follows this model. Figure 5-3 illustrates this model.

  Figure 5-3 Mapping Multiple Business Functions to Multiple Tasks

  ---

  

The mapping of business functions to ACMS functionality highlights the modular design of ACMS. A business function often consists of more than one task, because the operations necessary for that business function often are necessary for another business function as well. Therefore, two or more business functions can share one or more tasks that contain the needed functionality. Likewise, server procedures called from within tasks are often shared.

5.2 Planning Tasks for an Application

Tasks are the main building blocks of an ACMS application. Task design must take into account the following:

• Sequence in which users supply information
• Characteristics of transactions
• Need for flow control
• Distinction between work at the task level and at the step procedure level

The following sections offer high-level guidelines for these task design issues.

5.2.1 Considering User-Supplied Information When Designing Tasks

Information supplied to the application is a key factor in task design. Users often supply the initial information. Or, initial information comes from a combination of users and databases.

When you design a task, consider the sequence in which information is gathered. For example, when a customer checks in a car, the AVERTZ clerk must associate that customer to a car, and to information about that car that is stored in a database. The clerk must collect this information before calculating the bill.

So, an ACMS task often starts with an exchange step that asks the user for information---either new information, or a key field for access to information previously stored in a database. For example, all three of the AVERTZ business functions represented on the main menu (RESERVE, CHECKOUT, and CHECKIN) begin by invoking the single DECforms form to gather basic customer information. (See Section 5.3 for an outline of all components in the AVERTZ application).

Moreover, key identifying information is often required in several locations in an application. Modular design allows you to isolate a common sequence of operations into a task that can be called as needed by other tasks. In the AVERTZ application the CHECKOUT and CHECKIN menu choices invoke the Checkout and Checkin tasks, respectively. Both choices invoke the form to gather identical information (customer name or reservation ID). Therefore, both the Checkout and Checkin tasks immediately call the get reservation task to identify the customer's reservation. Once the reservation has been identified, control returns to the Checkout or Checkin task to handle the operations specific to checking out or checking in a car.

Similarly, you can use your business functions to identify other exchange steps and order them sequentially within the outline of a task. If you plan to create called tasks for repeated sequences of operations, you can begin planning the exchange steps to be isolated in the called tasks.

5.2.2 Considering Transactions When Designing Tasks

Just as the order of the business activities described in Chapter 3 affects the sequence of exchange steps in the task, the nature and order of the transactions described in Chapter 4 affects the processing steps.

Transactions result, directly or indirectly, from information gathered in exchange steps. When you order your transactions to reflect the business activities which they carry out, take into account the characteristics of transactions. For example, do not include an exchange step within a distributed transaction. Even if your analysis indicates that an exchange step fits logically within the transaction, the cost of maintaining locks in the database s while awaiting a user response is likely to be prohibitive.

5.2.3 Considering Flow Control When Designing Tasks

You often need the information derived from an exchange or processing step to decide the next operation. This often entails the use of REPEAT STEP, GOTO, GOTO STEP <step-label> syntax, nested blocks, or conditional logic. As you outline your tasks, consider the information flow.

Note where work flow leads to an exchange or processing step that can cause ambiguity for the user. For example, in the AVERTZ reservation task the user can specify the exact rental site by entering the site ID. A user who does not know the site ID can alternately enter a city name. If there is more than one rental site in the city, a list appears with all the site IDs for that city. The user can then choose a site. The reservation tasks handles this anticipated problem with conditional logic and GOTO PREVIOUS EXCHANGE syntax. If the user knows the site ID, the task flows directly to displaying customer information. If not, the task gets the possible site IDs and loops back.

5.2.4 Considering Task-Level Work and Procedure-Level Work When Designing Tasks

You sometimes have the choice of placing the work of the application at the task level or at the step-procedure level. For example, you can use task syntax or procedure code to handle conditional logic. Conditional logic is best placed in the task definition, if the resolution of the conditional logic avoids calling a step procedure. More complex conditional logic related, for example, to the results of computations, is better placed in procedures.

5.3 ACMS Tasks for the AVERTZ Application

The AVERTZ application consists of the five tasks listed in Table 5-1.

Table 5-1 The Five Tasks of the AVERTZ Application

Task Name	Task Definition Name
Reservation task	VR_RESERVE_TASK
Checkout task	VR_CHECKOUT_TASK
Complete Checkout task	VR_COMPLETE_CHECKOUT_TASK
Checkin task	VR_CHECKIN_TASK
Get Reservation task	VR_GETRESV_TASK

The Reservation, Checkout, and Checkin tasks are selected by ACMS menu choices that correspond to these tasks. The Get Reservation and Complete Checkout tasks are called by one or more of the tasks that are menu selections. The following sections outline the work of the five tasks with respect to the business functions identified in the Requirements Specification. Succeeding chapters detail elements of the ACMS functionality used to carry out the work of the application.

5.3.1 The Reservation Task

The Reservation task in the AVERTZ application is named VR_RESERVE_TASK. The Reservation task is not synonymous with the "reservation processing" business area nor even with the "reserve a car" business function within that business area. (See Table 3-3.) VR_RESERVE_TASK prepares the reservation by:

• Gathering all the customer information necessary to make a reservation
• Identifying the site at which the customer wishes to check out a car
• Identifying available cars and allowing the user to choose one

To make the reservation, VR_RESERVE_TASK uses the DECforms form named VR_FORM, as well as the step procedures listed in Table 5-2.

Table 5-2 Step Procedures Used in AVERTZ Application

Procedure Name and Description	Server	Task Used in
VR_FIND_SI_PROC Lists rental sites by city	VR_READ_SERVER	Reservation
VR_RES_DETAILS_PROC Identifies a single customer	VR_READ_SERVER	Reservation
VR_STORE_CU_PROC Updates customer information	VR_UPDATE_SERVER, VR_LOG_SERVER	Reservation, Checkout
VR_WRITE_RS_PROC Stores the reservation number	VR_UPDATE_SERVER	Reservation, Get Reservation
VR_WRITE_HIST_RECORD_PROC Writes the reservation to the history file	VR_LOG_SERVER	Reservation, Checkout, Complete Checkout
VR_FIND_VE_PROC Finds available cars	VR_READ_SERVER	Checkout
VR_CANCEL_RS_PROC Cancels the reservation at the user's request	VR_UPDATE_SERVER	Checkout, Complete Checkout
VR_FIND_VE_VRH_PROC Gets the car's rental history	VR_READ_SERVER	Checkout
VR_COMPLETE_CHECKIN_PROC Updates the rental history	VR_UPDATE_SERVER	Checkout
VR_COMPUTE_BILL_PROC Calculates the bill	VR_READ_SERVER	Checkout
VR_FIND_CU_PROC Finds the customer asked for and checks for any existing reservations	VR_UPDATE_SERVER	Get Reservation
VR_COMPLETE_CHECKOUT_PROC Sets a flag indicating that the car is checked out	VR_UPDATE_SERVER	Complete Checkout

A customer can make a reservation in advance, or can take a car immediately upon reserving it. The process of checking out a car is common to either of these situations. Therefore both the Reservation task and the Checkout task call a common task, the Complete Checkout task. (See Section 5.3.5.) Figure 5-4 shows the flow of the VR_RESERVE_TASK.

Figure 5-4 The Structure of the VR_RESERVE_TASK

The Checkout task in the AVERTZ application, named VR_CHECKOUT_TASK, is used when a customer who has previously made a reservation arrives to take a car. Recall that the customer can also check out a car immediately upon making a reservation. Checking out a car at reservation time does not use VR_CHECKOUT_TASK. So, the checkout business function is initiated either by the VR_RESERVE_TASK or the VR_CHECKOUT_TASK. In either case, it is completed by the VR_COMPLETE_CHECKOUT_TASK. (See Section 5.3.5.)

VR_CHECKOUT_TASK is a simple task that, in fact, does not directly check out a car. This task uses the VR_FORM and does the following:

• Calls VR_GETRESV_TASK to check the reservation and customer information. The Checkin task also uses VR_GETRESV_TASK. (See Section 5.3.4.)
• Identifies available cars and allows the user to choose one.
• Updates the customer information.
• Calls VR_COMPLETE_CHECKOUT_TASK to complete the checkout of the car.

Figure 5-5 shows the flow of the VR_CHECKOUT_TASK.

Figure 5-5 The Structure of the VR_CHECKOUT_TASK

The Checkin task in the AVERTZ application, named VR_CHECKIN_TASK, handles the checkin business function. VR_CHECKIN_TASK does the following:

• Calls VR_GETRESV_TASK to identify the unique reservation and to modify any customer information, if necessary
  VR_GETRESV_TASK is a separate called task, because the Checkout task requires the identical work performed.
• Uses the procedures listed in Table 5-2 to get information needed to check in the car.

Figure 5-6 shows the flow of the VR_CHECKIN_TASK.

Figure 5-6 The Structure of the VR_CHECKIN_TASK

The Get Reservation task in the AVERTZ application, named VR_GETRESV_TASK, is used both in the checkout and checkin business functions. VR_GETRESV_TASK consists of the following:

• VR_FORM---asks for reservation ID and customer ID, displays multiple reservations for the customer, if necessary, to identify a single one, and displays customer and reservation information that can be modified if necessary.
• The procedures for finding and updating customer information, as listed in Table 5-2.

VR_GETRESV_TASK operates only in the context of the Checkout or Checkin tasks. Once its work is completed, control returns to whichever of those tasks called it.

Figure 5-7 shows the flow of the VR_GETRESV_TASK.

Figure 5-7 The Structure of the VR_GETRESEV_TASK

The Complete Checkout task in the AVERTZ application is named VR_COMPLETE_CHECKOUT_TASK. This task is used both in the reserve car and checkout business functions. VR_COMPLETE_CHECKOUT_TASK completes or cancels the reservation, based on the choice made by the user after choosing a car (either in the reservation task or the Checkout task).

To do this, the task the procedures listed in Table 5-2 to complete the checkout of the car.

VR_COMPLETE_CHECKOUT_TASK operates only in the context of the Checkout or Reservation tasks. Once its work is completed, control returns to whichever of those tasks called it.

Figure 5-8 shows the flow of the VR_COMPLETE_CHECKOUT_TASK.

Figure 5-8 The Structure of the VR_COMPLETE_CHECKOUT_TASK