This chapter explains how to design a transaction processing application using ACMS. It describes the role of the design process in the overall application development life cycle. The steps in the design process are mapped to the remaining chapters of this manual.

This chapter also describes the documents used to outline the design: the Requirements Specification, Functional Specification, and Programming Specification.

2.1 Understanding the ACMS Application Development Cycle

As an ACMS application designer, you have been presented with the task of creating a TP application to automate a part of your business. This manual offers a design process that gathers and organizes the information needed to create an efficient and effective transaction processing application. The terminology of the design process outlined here is less important than information gathered through that process. Where the terminology is unfamiliar, or the steps seem out of sequence, consider in your own terms the need being addressed. The aim is to create an application design that accurately reflects the business need, and in which all the design implications have been acknowledged and addressed before the application is written.

A complete, logically coherent design for an ACMS application includes descriptions of the following components of the application:

• ACMS-specific parts of the application
• 3GL procedures
• User interfaces
• Database or databases

This manual provides you with design guidelines for ensuring that all components work together.

Section 1.1.3 describes the application development life cycle. Recall that the application development life cycle consists of:

• Orientation and installation of base products
• Planning and design
• Development and testing
• Implementation and management

This manual describes the planning and design phase of the application development life cycle. The following documents structure the planning and design phase:

• Requirements Specification
  During requirements analysis you collect and analyze information about the business functions the application must perform. You define specific requirements that the application must meet for performing each business function. The Requirements Specification describes why an application is needed.
• Functional Specification
  You carry out functional analysis to specify the TP technology the application will include to perform each business function. Determine atomic units of work ---or transactions---within each business function. Determine the need for deferred processing, distributed forms processing, and data location. The Functional Specification describes what TP functionality is required.
• Programming Specification
  You map business functions to ACMS tasks and define an ACMS implementation that provides the required functionality for the application. The Programming Specification describes how the functionality will be implemented.

The planning and design phase can also include an optional prototype effort to create simplified models of the application to test the design's structure. This manual does not address prototyping.

Application design is an iterative process. Each time you complete a step in the design process, you must validate that your design still meets your stated goals, which you define during requirements analysis. If not, you may have to modify either your design or your application requirements. Even though you typically cannot begin coding your application until your design is complete, keep in mind that the development process is not linear.

2.2 Relating Application Design and Database Design

Application design and database design are separate but related work. Application design and database design may be done by the same person, or by different people. In either case, although both designs can begin simultaneously, at some point application design must await some of the results of database design.

The design of an ACMS application and its accompanying database begins with the same requirements, which are defined in the Requirements Specification. Therefore, both application and database design must meet the same set of requirements.

Following the requirements analysis phase, database design proceeds to a detailed data analysis to ensure that data descriptions are complete and accurate, and to determine if anticipated business changes warrant modifications to data descriptions. Then, normalization of the database follows. Normalization eliminates data redundancy from the proposed database model. Generally, application design cannot proceed until database normalization is complete.

However, you cannot assume that database design is complete when application design begins; only the preliminary phases of database design precede application design. Once both design processes begin, they are interdependent. To ensure that all the requirements of the application are accounted for, consider the needs of the application design and the database design separately. Then, after each step in the design process, compare the application and database design to ensure that they match.

2.3 Using Software in the Design of ACMS Applications

ACMS design requires you to consider the following software components and products:

• Database software
  ACMS applications are designed to work with Rdb, RMS, and DBMS software. Consult the appropriate database documentation for guidelines on database design and use.
• Processing software
  You also need to understand the function of the OpenVMS operating system, and in particular DECdtm transaction services, which provide two-phase commit functionality. You also should be familiar with the CDD data dictionary, which stores ACMS data definitions, and the Oracle Trace facility, an optional layered product that logs ACMS performance events.
• User interface software
  ACMS applications use DECforms software as their default forms management product. Optionally, you can use the TDMS forms product or the ACMS Systems Interface or Request Interface.

You also need to select a CASE environment:

• Investigate DECdesign for applicability
• Consider the use of the following Software Engineering Tools (DECset) during the implementation and maintenance of your application:
  • DEC/Code Management System (CMS)
    CMS provides an efficient method for storing project files and tracking all changes to those files.
  • DEC/Test Manager (DTM)
    DTM organizes software tests and automates the way you run tests and evaluate test results.
  • Language-Sensitive Editor (LSE)
    LSE is a multilanguage programmable editor designed to help develop and maintain source code.
  • DEC/Module Management System (MMS)
    MMS automates and simplifies the building of software systems.
  • Performance and Coverage Analyzer (PCA)
    PCA helps you analyze the run-time behavior of your application.

  • Source Code Analyzer (SCA)
    SCA is a multilanguage, multimodule, interactive cross-reference and static analysis tool. It can help you to understand the complexities of a large software project by allowing you to make inquiries about the symbols used in the project's code.
  
  See Using DECset for VMS Systems for details about the DECset tools.
• Investigate the DECtp Implementation Toolkit
  The DECtp Implementation Toolkit is a set of recommended methods and tools for defining and creating a consistent transaction processing environment. The toolkit provides methods for using the DECset tools in Compaq's transaction processing development environment.

Table 2-1 summarizes the steps involved in designing an ACMS application, the design document that relates to each step, and the chapters in this book that describe each step. Table 2-2 describes each design document.

Table 2-1 Steps for Designing an ACMS Application

Step	Description	Design Document	Further Information
1	Define or reaffirm business problem that application will solve.	Requirements Specification	Chapter 3
2	Specify each business function that the application will automate. List distinct activities involved in performing each business function.	Requirements Specification	Chapter 3
3	Determine requirements, in business terms, for how each business function should be performed.	Requirements Specification	Chapter 3
4	Determine data entities accessed by each business function.	Requirements Specification	Chapter 3
5	Write Requirements Specification.	Requirements Specification	Appendix A
6	(Database designer performs initial database design)
7	Determine one or more transactions within each business function, and determine functionality used to implement those transactions, including the use of deferred processing and distributed forms processing.	Functional Specification	Chapter 4
8	Write Functional Specification. Review Functional Specification with users of the application and members of design team. Refine requirements, if necessary.	Functional Specification	Appendix B
9	Map each business function to one or more ACMS tasks.	Programming Specification	Chapter 5
10	Design task definitions.	Programming Specification	Chapter 6
11	Design code for step procedures.	Programming Specification	Chapter 7
12	Design user interface.	Programming Specification	Chapter 8
13	Design overall application structure, including task groups.	Programming Specification	Chapter 9
14	Write Programming Specification	Programming Specification	Appendix C

Table 2-2 Design Documentation for an ACMS Application

Name	Description
Requirements Specification	Specifies the business need and the requirements to solve that business need. The Requirements Specification is high level and can be produced in a limited time frame. It does not contain specific design details unless these are considered to be a business requirement. It bridges that gap between a customer's business need and the Functional Specification and Programming Specification.
Functional Specification	Specifies, in non-technical terms, what the solution does for the customer. It is a detailed specification of the functionality to be addressed by the solution. This document defines what functions the system will be capable of performing. It is the blueprint for the subsequent design and programming of the system. To write this, the designer must understand the functionality available in forms, databases, ACMS, and other software and hardware.
Programming Specification	Describes a design that provides the proposed functionality and meets the business requirements. Some of the activities can be included here instead of in the Functional Specification.

This chapter offers guidelines for describing the business problem that your ACMS application is going to solve. It illustrates how to break the business problem into discrete segments of work. It also describes characteristics of these discrete segments that are important to consider when designing an efficient application. Use these guidelines to create a Requirements Specification in which you:

• State the business problem your ACMS application is going to solve.
• Describe high-level requirements for each business function such as information flow, frequency of the use of the function, availability, user access to data, and so forth.
• Supply to the database designer the details about the information used by each business function. This information is the basis for the initial database design, which must be completed before you can proceed to mapping business functions to transactions (described in Section 4.2).

Before designing an application, you must analyze the business problem and produce a Requirements Specification that describes the business need addressed by the application. The goal of the Requirements Specification is to define, in terms of the business and at a high level of detail, what the application must accomplish.

For example, the work of the AVERTZ car rental company is to rent cars. For AVERTZ, the business problem is to create a TP system that allows car rental agents interactively to display, enter, and update data stored in a car rental database when serving customers. A description of the business problem includes not only a description of the need, but also the goals with related measurements.

The Requirements Specification also defines constraints on an application that are independent of the step-by-step analysis of the work being performed. Constraint information includes who will use the application, how frequently the users will access the application, and what users will be granted access to different parts of the application. It also includes data security requirements, minimum acceptable performance, and time and cost for delivery of the working application. Section 3.3 describes how to collect these additional requirements.

Appendix A contains a sample template for a Requirements Specification.

3.2 Analyzing the Work Requirements

This manual analyzes the work done by AVERTZ employees by breaking down the work into the following hierarchy:

• Business areas---the major organizational areas of the company
• Business functions---types of work handled within the business area
• Business activities---discrete steps taken to complete the work within a business function

The following sections describe a requirements analysis based on the description of business areas, business functions, and business activities.

3.2.1 Business Areas

Most areas of the AVERTZ business support its primary business function, which is renting cars. Table 3-1 lists the AVERTZ business areas that support renting of cars.

Table 3-1 Business Areas in AVERTZ

Business Area
Reservation processing
Site management
Car information
Customer accounts

Note that the AVERTZ sample application handles only the reservation processing business area of the AVERTZ company.

3.2.2 Business Functions

This section describes the business functions that comprise the reservation processing area of the AVERTZ business.

Car rental agents enter or modify reservations at the central office or at any AVERTZ site. This business function has the following responsibilities:

• Entering 3000 new car reservations daily. Initial reservation information consists of the pickup date, customer name, location, preferred car type, and rate. Half of the reservations are made over the phone and half are walk-in.
  The system has estimated load of 90,000 reservations at any given time, an average of one reservation per customer.
• Checking out an average of 2,500 cars per day, finding the reservation by the reservation identifier or the customer's name. The checkout data needs to record the date, car number, and mileage.An average of 500 reservations a day are canceled.
• Checking in an average of 2,500 cars per day, finding the reservation by the reservation identifier or the customer's name. When the car is checked in, the rental charge is calculated, based on the car type (compact, intermediate, full size), the rental location, the length of the rental, and discount (if any). Finally, a bill is processed (payment can be made in cash or through a credit card), and the car is returned to the system at the current site.

Each business function consists of a set of business activities. These activities are the logical transactions that the application system must perform and that the database must support. To determine database and application requirements, first develop a description of each discrete business function. Then list activities that users perform to carry out each business function.

Table 3-2 lists the business areas for the AVERTZ company, and business functions for each of those areas. Table 3-3 lists the business functions in the reservation processing area of AVERTZ's business and lists the business activities required to perform each function.

Table 3-2 Business Areas and Business Functions in AVERTZ

Business Areas	Business Functions Within Areas
Reservation processing	Reserve a car
	Check out a car
	Check in a car
Site management	Add new sites
	List site directory
	Create car/site report
Car information	Add new car information
	Create car history report
Customer accounts	Create customer report

Table 3-3 Business Functions and Activities in AVERTZ Reservation Processing Area

Business Function Within Area		Activities Within Business Function
Reserve a car	1	Enter any of the following information: Customer ID Customer name Site ID City name Rental dates Car type
	2	If no site ID is supplied, and there is more than one site in the city, choose from a list of sites.
	3	Once site ID is identified, if multiple customers have the same name, choose from a list of customers.
	4	If it's a new customer, add information. If it's an existing customer, update information, if necessary.
	5	Provide a reservation number and ask if the customer wants to check out car.
	6	If checkout is requested at the time of the reservation, begin the checkout by finding if a car is available (go to step 4 below).
Check out a car	1	For a customer who made a reservation previously and did not checkout a car then, enter either the customer ID or the reservation ID, or both.
	2	If the customer has multiple reservations, choose from a list of that customer's reservations.
	3	Once a single reservation has been identified, update the customer and reservation information, if necessary.
	4	Once the customer and the reservation information is complete (either from an on-the-spot reservation and checkout, or when the customer comes in some time after reservation to check out the car), ask for cars of the specified type.
	5	If no cars of the specified type are available, select a more expensive type.
	6	Choose from a list of cars of the specified type.
	7	Allow the user to check out the car, cancel the reservation, or quit without canceling the reservation.
Check in a car	1	Enter either the reservation ID or the customer ID, or both.
	2	If the customer has multiple reservations, choose from a list of that customer's reservations.
	3	Once a single reservation has been identified, update the customer and reservation information, if necessary.
	4	Enter the new odometer and gas gauge readings.
	5	Compute the customer's bill.
	6	Update the reservation record, reset car availability flag and the actual odometer reading, and the return date of the car.