Compaq ACMS for OpenVMS
Concepts and Design Guidelines

Previous Contents Index

Chapter 9
Designing Task Group and Application Definitions

This chapter provides guidelines for grouping tasks into task groups, and for defining applications.

9.1 Designing Task Groups

A task group describes a collection of tasks and the resources available to those tasks. Resources include workspaces, request libraries, forms, user request procedure libraries, message files, and the procedure servers in which processing is done.

9.1.1 Grouping Common Elements in a Task Group

You group tasks together into a task group based on common resources used by the task:

Also, if you use the task-call-task facility, you must include both parent and called tasks in the same task group

9.1.2 Determining the Number of Task Groups in an Application

Combining tasks into a single task group offers the advantage of:

Single task groups have the disadvantage of:

Consider using multiple task groups during the development of an application, and then combining those groups when the application is put into production. Using multiple task groups during development has advantages such as decreased build time. Combining the task groups before the application is put into production allows you to realize the benefits of fewer, or a single task group.

9.1.3 Improving Performance with the Task Group Definition

This section discusses task group definition syntax likely to have significant positive or negative effects on performance.

9.2 Designing Applications

In the application definition, you describe the application environment by defining control characteristics for the application. Access to tasks is always controlled from the application definition. An application definition does the following:

You can optionally assign characteristics that:

You control procedure servers in an application by assigning server control attributes in the application definition. These attributes determine the processing characteristics of a procedure server.

Compaq ACMS for OpenVMS Writing Applications gives details about writing application definitions.

9.2.1 Determining the Number of Applications

Combining applications has the following advantages:

Multiple applications have the following advantages:

9.2.2 Improving Performance with the Application Definition

Application design and hardware configuration together have the greatest effect on the performance of the ACMS system. Tuning the OpenVMS parameters of the ACMS system itself after implementation has a lesser effect. Tuning the definition of your application, however, can have a significant effect on performance. For example:

Some OpenVMS and ACMS system parameters also require monitoring before they can be set optimally. Working set sizes for the Application Execution Controller (EXC) and server processes can be monitored after installation of your application and changed to meet your requirements. For information about tools with which to make these observations and change corresponding parameter values, see Compaq ACMS for OpenVMS Managing Applications, which includes sections on ACMS system monitoring, tuning, and setting the OpenVMS SYSGEN parameters that ACMS affects.

Performance problems often have their root in database performance. You can determine if your database is responsible for your problems through monitoring. Each of the following database management system documentation sets includes a manual on tuning and performance:

Appendix A
Requirements Specification Template

The Requirements Specification specifies the business need and the requirements that must be met 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.

A.1 Overview

This section presents an overview of the system and basic requirements.

A.2 Business Objectives

This section covers the business needs to which the eventual solution will respond, and the business goals with related measurements.

A.2.1 Business Needs

Identify the business needs of the customer.

A.2.2 Business Goals and Measurements

Identify the business goals of the customer and how they are measured.

A.3 Solution Requirements

A.3.1 Current Business System

The following sections describe the scope of the analysis in terms of business areas being looked at and the business functions carried out by these business areas:

A.3.2 Proposed Business System

A.4 Scope

This section covers the business-related system environment needs. It also covers the business related general solution needs, which typically are defined by strategies external to the project. Training, documentation, and support requirements are presented here. It specifies any requirements that will not be met by the project and explains why they will not be met:

A.4.1 Environment

A.4.2 Proposed Implementation

A.4.3 Forecast Benefits

A.4.4 Quality Requirement

A.4.5 General Solution Requirements

A.4.6 Project Limitation

List any limitations to implementing the solution.

A.5 Alternative Solutions Rejected

Any other solutions with the reason why they were not selected.

Appendix B
Functional Specification Template

The 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.

Functional specifications are used for monitoring progress during system development, and are the basis of final customer acceptance of the complete system. A definitive Functional Specification ensures that the Customer's functional needs are correctly identified.

B.1 Overview

The overview is a brief description of the system allowing the readers an understanding of the aims of the system. The system can also be depicted pictorially, typically using data flow diagrams. A brief description is given of each external entity covering its interactions with the system. Processes and data stores are also described. The overview consists of:

B.2 Solution Detail

This is the main section of the Specification. It provides sufficient detail to constitute the definition of the system. It describes what is required, how the requirements will be met, and includes a logical model of the proposed solution.

B.2.1 External Interfaces

B.2.2 Transaction Analysis

Transform the business transactions defined in the Requirements Specification into logical transactions:

B.2.3 Inputs/Outputs

B.3 Environmental Requirements

This section describes the characteristics of the system's users, software and hardware requirements for installing, operating and interfacing the system, and security requirements:

B.4 Quality Requirements

This section describes the customer's quality requirements in terms of:

B.5 General Requirements

Any general requirements not covered in the sections above are described here:

B.6 Solution Limitations

Any stated requirements not met or specific limitations imposed for the new system are listed here.

B.7 Documentation

This section describes the publications to be provided for the system, including user, system, and technical documentation.

B.8 Training

This section describes training requirements and how they will be met. The training may include user, operation, and technical training.

B.9 Definitions

B.10 Glossary

Previous Next Contents Index