Application generators: a case study

Application generators: a case study by JAMES H. WALDROP Hamilton Brothers Oil Company Denver, Colorado ABSTRACT Hamilton Brothers Oil Company recently implemented a complex accounting and finance system. This system contains 157 reports, 53 online screens, and 1,320 data elements. The system was designed, developed, and implemented in 20 months. Most of the approximately 300 programs contained in this system were developed with an application generator. Using an application generator allowed the project team to complete the coding and unit testing in three months. Based upon the experience acquired in this effort, many benefits appear to be gained by using an application generator in the system development process. These include reduced coding, faster testing, and enforced structured development. However, these benefits must be weighed against the constraints associated with an application generator. These include potential file and processing inefficiencies, limited language syntax, and minimal debugging facilities. 363

Application Generators: A Case Study 365 INTRODUCTION Hamilton Brothers Oil Company recently developed anew, comprehensive accounting and financial information system. The development of this complex system was accomplished under an extremely difficult schedule. A key ingredient of this project was the use of an application generator language to address the programming requirements. An application generator is a software tool designed to anticipate standard user requirements in a functional area such as accounting and finance. It provides data 'management facilities, autoinated common functions, and a specialized language. The following narrative presents a brief project background, the project's goals, the impact of an application generator language on the system development process, and several key areas to consider for future use of application generators. PROJECT BACKGROUND Hamilton Brothers' senior management decided in January 1980 to terminate its service bureau computer support and implement an inhouse Financial Reporting System (FRS) consisting of five integrated subsystems: accounts payable, accounts receivable, general ledger, joint interest billing, and budget. After a thorough four-month evaluation of 19 different vendors, it was determined that Hamilton Brothers' requirements could only be met either through a total custom development or through significant modifications to an offthe-shelf software package. Amplifying the magnitude of the challenge, the company simultaneously began a major expansion effort. This expansion led to an increase in new key users who would determine the design of the system. In addition, the company had to establish and staff a complete medium-size computer installation. Furthermore, the data to be used in the new system would also require a complex conversion effort from the previous service bureau environment. The target date for implementation of the new system was January, 1982-20 months elapsed time. The plan to accomplish this substantial effort encompassed several critical phases. First, a detailed evaluation of the request for proposal (RFP) responses from the qualifying vendors was accomplished. The selection criteria focused on several topics: optimum use of off-the-shelf software to address user requirements; utilization of the most current software architecture; maximum software flexibility; and a financially and technically sound software vendor. This phase was accomplished in two months, culminating in the selection of the Corporate Financial System (CFS) marketed by American Management Systems, Inc. This system was developed using their application generator (Generation Five) as the under- lying software. It would become the core of FRS after considerable custom modifications. Second, a system concept definition phase was performed to refine the general requirements presented in the RFP. This phase also required two months. Next, a general system design stage was completed requiring six months. With the completion of the general design, there were only 10 months remaining to accomplish the detail design, programming, testing, and implementation phases. It was obvious that new techniques must be evaluated to maximize the efficiency within the programming, testing, and implementation stages. This requirement, coupled with the fact that CFS had been developed using an application generator, led to the consideration of using an application generator to perform the custom development work. PROJECT GOALS As with any project, the ultimate goal is to provide a sound system which meets the user's requirements. However, because of the special nature of the FRS project, there were several ancillary goals to be addressed. First, FRS must be user friendly. To accomplish this, we introduced the concepts of online processing, user controlled parameters, and user report development with minimal support from the data processing staff. We also required a table-driven architecture to provide flexible data modification by the users. Second, FRS must be capable of easy technical modifications and provide a solid base for future expansion. This consideration introduced the need for a structured development methodology and selfdocumenting code. Third, the system development process must take advantage of key development productivity tools. This aspect included online program development, simple report writers, online screen generators, a data dictionary, and a project task plan. Since this was the department's first project, its success was crucial to establishing the department's credibility. The following synopsis of the characteristics of the system provides an insight into the magnitude of the project: 1,300 pages of general design narrative 6,000 mandays for concept definition, general design, detail design, and implementation 25 people assigned full time at the peak point in the project 3,000 pages of automated technical documentation on a data dictionary 1,320 data items 285 programs (most of these were developed in Generation Five or its associated report writer) 157 reports

366 National Computer Conference, 1982 53 online screens 102 master tables 132 data files 48 input forms The selection and use of an application generator contributed to the achievement of the project's goals and its timely implementation. The FRS project was completed within one month of the plan which had been developed nearly two years earlier. IMPACT OF THE APPLICATION GENERATOR ON THE PROJECT'S DEVELOPMENT The programming effort was started six months prior to implementation. The project plan allocated approximately 30% of the elapsed time (50% of the total man days ) for all technical facets of the project. At this point, the project leaders reviewed the application generator (Generation Five) marketed by AMS. It appeared to offer several programming advantages over a standard programming language such as COBOL or PLIl. The syntax appeared easy to code and did not seem to require significant training. General housekeeping functions such as opening and closing files were eliminated. Several application unique keywords were included in the syntax. For example, REJECT-BATCH and REJECT DOCUMENT offered easy techniques to reject an entire batch of data or only an individual document within the batch. The online screen generation facility of Generation Five also appeared to provide a relatively simple, high-level technique for developing input/output screens without acquiring the knowledge necessary to develop native teleprocessing code. The structured methodology inherent in Generation Five coupled with its editing facilities offered the potential of eliminating the occurrence of a program dump. The "forced" structured methodology should also require fewer compiles to complete a program developed in Generation Five. The obvious benefit to be gained was increased programmer productivity and reduced machine utilization. The above expectations were developed by the project team prior to using Generation Five for the first time. As the project progressed through the remainder of the development effort, the actual experiences encountered using Generation Five were somewhat different from the expectations. The following narrative is a synopsis of the benefits gained from using Generation Five as an application generator, a discussion of the key problems encountered in its use, and a review of the project team's expectations of Generation Five compared with its actual performance. Problems encountered The initial obstacle encountered by the project leaders was the project members' occasional resistance to using a new software language. The programmers preferred to use COBOL, a familiar tool, to do the development. This issue and the lack of previous experience with any similar product presented many unknown problems in the design process. Without any previous Generation Five experience, the staff was not aware of the constraints inherent in the software. As each design issue arose, such as file merging/sorting or data element storage and retrieval, the options and capabilities supported by Generation Five had to be reviewed. The conclusions reached from the review of supporting documentation occasionally did not match the actual required implementation of the design issue. For example, a file that required both random and sequential processing could be accomplished with only one copy of the file in a COBOL designed system. Under Generation Five, the random file must be copied to a sequential file for sequential processing. For small files, this was not a critical issue; for large files, it introduced excess processing requirements. The thought processes used by the programming team for such typical data processing functions as file access, edit error message generation, and online screen generation also had to be altered. The file access method used by Generation Five is a non-standard technique. This becomes critical when other program languages are used to access the data stored by the application generator. For example, when non-generation Five software is used to update Generation Five data files, those updates are not integrated with the Generation Five recovery facility, thereby increasing the complexity of the backup and recovery function. One of the unique aspects of Generation Five is its ability to automatically generate online and batch edit error messages based upon the section (or paragraph) name used for the portion of code performing the edit. However, this feature eliminates the dynamic characteristics of edit error message presentation. (For example, "COMPANY CODE xx IS INVALID" where xx is replaced by the invalid company code.) The online screen generation capabilities provided by Generation Five allow extremely easy and fast development of either input only screens or output only screens. It does not provide online interactive screen facilities. Other limitations encountered using Generation Five included constraints on the number of data elements allowed in a random file (master table) record plus the inability to allow multiple record types in a file. These two constraints required an increase in the number of random files that had to be defined in the system leading to suboptimal use of storage space. Also, the architecture of Generation Five presented critical throughput problems during compiling and testing. Simultaneous compiles/tests occurring against the same database were prohibited. This forced the project team to create multiple copies of the database to avoid single thread compiling of Generation Five code. While the limitation of simultaneous executions against a single database is inherent in many non-generation Five systems, the single thread compile requirement is unique to this software (because compilation accesses the database). This fact has had a negative effect on the simultaneous development of multiple programs using Generation Five. Benefits gained While several unexpected problems were encountered using Generation Five, it is also true that several benefits were

Application Generators: A Case Study 367 gained from its use. The structured architecture and selected keywords enforced programmer standardization. It als-o provided an excellent technique for developing common code included in many programs. These characteristics reduced the amount of code that otherwise would have been required for a typical program. The online screen generation facility eliminated the need to train the project team to program in native teleprocessing code. The code developed to process the online input data could also be used to process the same data in a batch mode. This eliminated the need to develop two sets of processing code, one for batch and one for online. This was a significant benefit given the 53 online screens that were required. Simple "read-a-record, process, write-a-record" applications were coded and tested rapidly. These last two facets of the system allowed very junior programmers to be immediately productive on the project. A major benefit provided by Generation Five is an automatic transaction suspense processing facility. This is implemented through its document database feature. Input transactions captured through online or batch processing techniques reside in a holding file (the document database) awaiting subsequent processing. After processing, the rejected transactions are retained on the document database until corrected, while valid transactions proceed through the remainder of the processing cycle. The invalid transactions can then be corrected as necessary. This feature eliminates the sizable effort required to design, develop, and implement complex transaction-master file processing requirements. A subtle feature of Generation Five is the ability to use identical names for multiple data fields. This feature offers several advantages. First, data fields with the same name are moved automatically from the input record to the output record (without regard to their relative position within the records). This eliminates encoding numerous MOVE statements to accomplish the same objective. Second, data fields can use standard naming conventions not only among multiple programs but also within a program without the use of qualifying syntax. This reduces the coding required and also greatly simplifies tracing the life cycle of a data element throughout all of the software acting upon it. Third, the use of a data dictionary to document Generation Five code is greatly simplified. With standardized data element names enforced through the Generation Five architecture, the number of unique data element names are minimized. This reduces the information to be captured within the data dictionary and enhances its consistency and accuracy. Coding in Generation Five also eliminates the need to open and close data files. While this is advantageous, a greater benefit is achieved by not coding end-of-file logic. Depending upon the application, this may be a very complex function to accomplish in a traditional programming language. Expectations versus actual performance The actual experiences encountered in using Generation Five when compared to the project team's original expectations highlighted areas where Generation Five could be improved. The language syntax did turn out to be relatively easy to code and was no more difficult to learn than another highlevel language. However, while the structured aspect of the language made it self-documenting, the syntax was occasionally confusing to follow. Portions of the software allowed a PERFORM capability (the EDITOR segment of Generation Five) but did not allow nested IF logic. The remainder of the software (the report writer) allowed nested IF logic but prohibited the use of a PERFORM. Several general housekeeping functions were supported and directly contributed to improved programmer productivity both in the coding and testing stages. The use of selected application unique keywords such as REJECT-BATCH or REJECT-DOCUMENT also eliminated the need to code and test these types of routines. Other application unique keywords such as POST or GENERATE (another form of WRITE or PUT command) offered virtually no productivity gains but did relate the function (WRITE) to application oriented terminology (POST). The online screen generation provided the greatest increase in programmer productivity. Fourteen of the sixteen programmers on the project team had never used a teleprocessing monitor and, therefore, had no experience in generating online screens. The Generation Five screen facility provided each programmer with an easy-to-learn tool to perform that function. However, it does lack the interactive characteristics desirable in some applications such as receiving input parameters, retrieving data from multiple files, performing a calculation, and displaying the results. Perhaps the most criticial disappointment in the use of Generation Five was the frequency with which program dumps were encountered. Unlike using COBOL or PLil where the programmer knows how to interpret the dump, this generally was not the case under Generation Five since it would have required highly specialized training. Unfortunately this facet removes a valuable tool from the programmer's arsenal for solving problems. Unless the problem is fairly simple, it may be very difficult to track down under Generation Five. The obvious solution to this problem is to incorporate significant debugging aids within the application generator language to address this area. Perhaps the best measure of the productivity gains provided by this application generator was the relatively brief time required to develop the code through unit testing. The elapsed time for this task was approximately three months, certainly a significant testimony to the potential value of an application generator. Key considerations in selecting an application generator The Hamilton Brothers FRS project team derived several factors that should be considered prior to the future use of an application generator. The initial point to be evaluated is the size and complexity of the impending project. A complex project requiring unique access methods, specialized processing techniques, and/or sophisticated online requirements may not be suitable for development using an application generator. Whereas for less complex systems, project teams should carefully consider the beneficial contribution of an

368 National Computer Conference, 1982 application generator to the system development and testing phases of a project. Once a project team concludes that an application generator is an appropriate tool for the project, a careful evaluation of its technical capabilities should be performed. Application generators are inherently oriented to specific functional areas. The selection of the correct application generator for a given functional area is paramount to the ultimate success of the project. The design of a system is directly correlated to the technical capabilities of the underlying software. A limited software tool generally leads to an inefficient system design. Once an understanding of the application generator's capabilities and constraints is developed, the project team must be willing to live within those constraints. The following list identifies several key characteristics desirable in a mature application generator: Provide code usable for both online and batch processing Incorporate facilities to eliminate or minimize program dumps Provide integrated program looping and nested IF processing with self-documenting code Provide online inquiry/retrieval facility with data manipulation and selection features Support a structured development methodology Support standard file access methods Enforce consistent data element naming standards Provide high-level application oriented features such as automated batch balancing and file open or closing facilities Offer easy-to-use debugging aids Provide thorough and accurate documentation with sets of complete examples Provide a simple facility for interfacing with programs developed in a traditional language such as COBOL Offer flexible data storage techniques (i.e., variable length records with multiple record types per file) Provide an integrated online recovery facility for all software (including non-application generator programs) which updates an application generator data file Provide table processing features CONCLUSIONS Hamilton Brothers' use of Generation Five as an application generator language provided several key benefits. It did, however, introduce inefficiencies into the design process that could have been avoided under a COBOL or PLl1 based system. How effective was the project team in meeting the goals of FRS as outlined above? The user friendliness of the system is superior to what existed in the old batch system. Users have complete control, primarily through online techniques, of system parameters. The user report development facility (using the report writer associated with Generation Five) is yet to be attempted. However, it appears that simple reporting can be accomplished by selected users with minimal data processing support. More complex reporting will require direct data processing support. The table-oriented design of Generation Five provides extremely flexible data file modifications, thereby dynamically changing most edit criteria without programmer intervention. Future technical modifications can be easily incorporated into FRS if the code is developed in Generation Five. Non Generation Five online routines will still require extensive technical evaluation prior to implementation. The structured coding requirements of Generation Five were beneficial but were somewhat offset by limitations in the syntax. The implementation of key development productivity tools such as online program development, report writers, screen generators, a data dictionary, and project task planning exceeded the original goals. These tools were critical factors in the success achieved by the project team. The concept of application generators is an innovative technique for improving the quality and timeliness of system development. The facilities provided by Generation Five are beneficial as they exist today. However, the product could be greatly enhanced with a few additional capabilities such as more data manipulation and retrieval flexibility, interactive online processing, and more variable file processing options. American Management Systems has indicated their intention to address these areas in future releases of Generation Five. Generation Five offers a good tool for accounting applications. Its use for other application areas appears, by design, to be limited.