Compaq ACMS for OpenVMS
Concepts and Design Guidelines


Previous Contents Index

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:

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.


Chapter 5
Mapping Business Functions and Transactions to ACMS Tasks

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:

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:

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

Note

The ACMS documentation includes other tasks and server procedures that use the AVERTZ example. However, these additional tasks and procedures are provided as illustrations of specific ACMS features, and are not an integral part of the working sample application.

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:

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


5.3.2 The Checkout 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:

Figure 5-5 shows the flow of the VR_CHECKOUT_TASK.

Figure 5-5 The Structure of the VR_CHECKOUT_TASK


5.3.3 The Checkin Task

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

Figure 5-6 shows the flow of the VR_CHECKIN_TASK.

Figure 5-6 The Structure of the VR_CHECKIN_TASK


5.3.4 Get Reservation 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_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


5.3.5 The Complete Checkout 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



Previous Next Contents Index