CONTENTS Title Page Copyright Page Information Map Information Table Preface Part I Beginning the Design Process 1 Introduction 1.1 Design Issues Inherent in TP Applications 1.2 Design Process 1.2.1 Application Design as an Iterative Process 1.3 Design Documents 1.4 DECintact Components 1.5 Products Involved in the Design Process 1.6 Choices to Make About Your Application 1.7 Overview of the AVERTZ Application 1.8 Application Design Checklist 2 Collecting and Analyzing Functional Requirements 2.1 Collecting Functional Requirements 2.2 Determining Tasks for Each Function 2.2.1 AVERTZ Reservation Processing 2.2.2 Customer Accounts 2.2.3 Statistics 2.3 Determining Future Business Needs 2.4 Analyzing Data Requirements 2.4.1 Defining Additional Requirements for Business Functions 2.5 Mapping Business Functions to Application Functions 2.6 Writing the Requirements Document 2.7 Completing the Requirements Analysis Process 2.8 Checking the Preliminary Application Design 2.9 Analysis Checklist 3 Designing the User Interface 3.1 Characteristics of a Good User Interface 3.2 DECintact User Interface Design 3.3 Presentation Services 3.3.1 DECforms Forms Manager 3.3.1.1 DECforms Form Structure 3.3.1.2 DECforms Session Caching 3.3.2 DECintact Forms 3.3.2.1 Using Escape Routines and User Edit Routines 3.3.2.2 Form Manager Considerations 3.3.2.3 Forms Performance and Design Considerations 3.4 User Interface Security 3.4.1 Security Profiles 3.4.2 Security Control with Menu Attributes 3.5 User Interface Checklist 4 Designing the Database 4.1 Analyzing Data 4.2 Selecting a Data Model 4.3 Choosing a Resource Manager 4.3.1 VAX Rdb/VMS Database 4.3.2 VAX DBMS Database 4.3.3 VAX RMS Files 4.3.4 Hash Files 4.3.5 DECintact Queues 4.3.6 Why AVERTZ Chose VAX Rdb/VMS and DECintact Queues 4.4 Database Checklist Part II Processing Steps 5 DECintact Methodologies 5.1 Determining Application Processing Steps 5.2 Characteristics of DECintact Methodologies 5.2.1 Per-Process Methodology 5.2.2 Multithreaded Methodology 5.3 Decide Which Methodology to Use 5.3.1 Advantages of Per-Process Methodology 5.3.2 Advantages of Multithreaded Methodology 5.3.3 AVERTZ Methodology Decision 5.4 AVERTZ Sample Processing Model 6 DECintact Queues 6.1 Considering Queues in Your Design 6.1.1 Deferred Processing 6.1.2 Recoverability 6.2 Deciding on Location of Queues 6.2.1 Memory-Based and Disk-Based Queues 6.2.2 Remote Queues 6.3 Queuing Capabilities 6.3.1 Queue Servers 6.3.2 Queue Sets 6.3.3 Using Priorities 6.3.4 Using Thresholds 7 Client/Server Model 7.1 Using the Client/Server Model 7.2 AVERTZ Server Pools 7.3 Client/Server Design Issues 7.3.1 Passing Data 7.3.2 Server Modeling 8 Distributed or Centralized Processing 8.1 Location of Application Processing 8.1.1 Remote User Systems 8.1.2 Clustered Systems 8.1.3 Remote Queue Systems 8.2 Distributing Forms 8.3 Processing Checklist 9 Data Integrity and Availability 9.1 Data Integrity 9.1.1 Using Journaling for Data Integrity 9.1.1.1 DECintact Recovery-Unit Journaling 9.1.1.2 DECintact After-Image Journaling 9.1.2 DECintact Support of RMS Journaling 9.1.3 Using Group Commit 9.1.4 Setting Syncpoint Backups 9.1.5 AVERTZ Application Strategy for Data Integrity 9.2 Availability 9.2.1 Using VAXcluster Failover 9.2.2 Using Volume Shadowing to Enable Continuous Disk Availability 9.2.3 Distributed Transactions 9.2.3.1 Benefits of Two-Phase Commit 9.2.3.2 Reasons for Using Distributed Transactions 9.2.3.3 Two-Phase Commit with AVERTZ 9.3 Data Integrity and Availability Checklist Part III Prototyping and Writing the Design Specification 10 Prototyping the Application 10.1 Defining the Role of Prototyping 10.2 Forms of Prototyping 10.2.1 Simulation Prototypes 10.2.2 Evaluation Prototypes 10.2.3 Base-Level Prototypes 10.3 Uses of Prototyping 10.3.1 Prototyping the User Interface 10.3.2 Prototyping an Rdb/VMS Database Design 10.3.3 Prototyping Transactions 11 Writing the System Design Specification 11.1 Developing the System Design Specification 11.2 Writing the System Design Specification 11.2.1 Defining the System-Level Design 11.2.2 Defining System Components 11.2.3 Defining System-Level Testing 11.2.4 Defining the Component-Level Design 11.2.5 Defining Component-Level Test Specifications 11.3 System Design Specification Checklist Part IV Appendixes A Template for Requirements Document A.1 Structure of the Document A.2 Headers for Requirements Document B Template for Functional Specification B.1 Structure of the Document B.2 Headers for Functional Specification C Template for System Design Specification C.1 Structure of the Document C.2 Headers for System Design Specification D Creating a Development Environment D.1 Digital Development Tools D.1.1 VAXset D.1.2 Common Data Dictionary D.1.3 DECdesign D.1.4 DECtrace for VMS D.2 Project Directories D.2.1 Initial Project Directories D.2.1.1 DEC/Test Manager Directories D.2.2 Build Directories D.2.3 Directories for Developers D.2.3.1 Summary of Project Directories D.3 Project Libraries D.3.1 CMS Library D.3.2 DTM Library D.3.3 SCA Library D.3.4 CDD/Plus Project Dictionary D.4 Define a Logical Environment D.4.1 DECintact Copies E Design of AVERTZ Application E.1 Components E.1.1 Function Design E.1.2 Report Program EXAMPLES 10-1 Modeling a Read-Only Transaction FIGURES 1-1 Development Phases 3-1 Reserve Function Panels 3-2 Information Contained in a Form 3-3 AVERTZ Menu 5-1 Per-Process Methodology 5-2 Multithreaded Methodology 6-1 Travel Agency Queues 6-2 Remote Queue Configuration 7-1 Client/Server Configuration 9-1 Two-Phase Commit D-1 Initial Project Directories D-2 DEC/Test Manager Directories D-3 Build Directories D-4 Directories for Developers D-5 Summary of Project Directories D-6 Multiple DECintact Copies TABLES 2-1 Function-Task Model for the Car Rental Application 2-2 AVERTZ Processing Steps 4-1 AVERTZ Documents 6-1 Comparison of Memory-Based and Disk-Based Queues 7-1 Advantages and Disadvantages of Multiple Server Pools 10-1 Sample Usability Specification Table