ADS(ID:1792/ads001)Automatic documentation languagefor Accurately Defined Systems Automatic programming system from NCR 1962 Related languages
References: After several years of internal use, NCR published the manual on ADS (Accurately Defined System), in 1968. ADS was an improvement over prior techniques because it provided a well-organized and correlated approach to system definition and specification. ADS used five interrelated forms to provide the system (application) definition, shown in Figure 9. The process began with the definition of output. Next, inputs were defined--on the second form. The third form provided the definition of computations to be performed and the rules of logic governing the computation. The interrelationship of computations were also defined on this form, as were the sources of information used in the computation. The fourth form, the history definition, specified information to be retained beyond the processing cycle for subsequent use. The fifth form provided the logic definitions, in the form of a decision table. Within ADS information linkage was accomplished in two ways. First, each data element was assigned a specific tag or reference. Next, each time the tag was used in the system, it was linked back to the previous link in the chain. All elements of data were chained from input to output, accomplished through the use of page and line numbers. The process of chaining facilitated identification of omissions and contradictions in the system. Once the information requirements were established, the system design phase determined the appropriate hardware mix to effect the system. Although NCR did not provide the means for computer processing of ADS, the technique paved the way for such use through its systematic approach to system definition. Extract: ADS Automated Automated ADS Although ADS provides a well-organized approach to cross-referencing system definition documents, modifications to the system are laborious to incorporate. Also, it is difficult to assess the consequences of a modification because ADS is based on backward referencing (i.e., from output back through intermediate processing to input). The logical sequence in designing a system is forward referencing. In automating ADS, the documentation medium is punched cards instead of paper forms. Each line of the original ADS forms is represented by one to three punched cards. The card file is analyzed by programs which 1) check for consistency and completeness, 2) check back references, 3) generate back references that have been omitted, 4) produce a dictionary of names, 5) generate incidence and precedence matrices, 6) flag errors, and 7) produce diagnostics. The inevitable system modifications can readily be incorporated. Cards for individual lines in the ADS definition can be revised and replaced and the effects assessed by computer analysis. The automated dictionary gives forward as well as backward referencing to aid the systems analyst in redesigning the system instead of serving primarily as a documentation tool. Incidence and precedence matrices permit analysis of the structure of the system and facilitate planning of implementation. Extract: ADS and TAG ADS (Lynch, 1969) and TAG (IBM) basically consist of a set of forms describing an entire application which are filled out by the user or system analyst and then machine-analyzed for use by programmers and file designers. If the forms could be translated to working programs, then we would actually have an extension of RPG concepts from a single program to a whole set of programs, i.e., a full application or system. in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details Historical and Technical Background To meet the needs outlined above, the Information Systems Design and Optimization System (ISDOS) Project at the University of Michigan has been studying the systems building process with the objective of developing a methodology for computer-aided design and construction of information systems. A description of the ISDOS Project can be found in Teichroew and Sayani [9]. ISDOS was born at Case Institute of Technology (now Case-Western Reserve University) in 1967 and was moved to the University of Michigan in 1968. Affiliation with Purdue University is also maintained through the efforts of Dr. Jay F. Nunamaker, an original member of the ISDOS Project at Case. The work at ISDOS has involved both the study of existing techniques for requirements statement and the development of new Requirements Statement Languages. All techniques view the problem in essentially the same way. They describe how to produce outputs from inputs. All techniques provide some method for describing data relationships as the user views them. They provide some facility for stating the requirements of the problem. Several provide some facility for stating other data such as time and volume. Young and Kent [i0] represent the earliest work. Information Algebra is the work of the CODASYL Development Committee [ii]. Two other efforts have been reported by Langefors [12 and 13] and Lombardi [14]. Accurately Defined Systems (ADS) is a product of the National Cash Register Company (IS] and is described by Lynch [16]. The Time Automated Grid (TAG) system, a product of IBM, was developed by Myers [17] and is described by Kelly [18]. ADS and TAG use a practical, straightforward approach without attempting to develop any "theory" of data processing. ADS and TAG are systematic ways of recording the information that a systems analyst would gather. ADS or TAG could be used by any experienced systems analyst with very little instruction. Young and Kent and Information Algebra represent a problem definition approach that is more concerned with developing a theory. Both use a terminology and develop a notation that Xs not at all natural to most analysts. Lombardi's approach requires the completion of the system design before it can be used and resembles a non-procedural programming language rather than an RSL. However, Lombardi's work is relevant because it presents a non-procedural technique for stating requirements once the file processing runs have been determined. Langefors' technique uses the concept of precedence relationships among processes and files without indicating how these relationships are obtained and is relevant to the analysis of a problem statement rather than to the design of a system. However, it does suggest a number of desirable features of a requirements statement technique. Despite the availability of these RSL techniques, their use has not been extensive. To the best of our knowledge, the languages of Young and Kent and of Lombardi have not been used except in an experimental way. Information Algebra has been used only once by Katz and McGee [19]. It appears that the development and use of TAG has been discontinued by IBM. ADS appears to be gaining in user acceptance. The U. S. Navy [20], in the process of designing a financial system, and a number of other firms [21] have used ADS as a requirements statement technique. This current work is the result of an evolutionary process involving several different RSL's. The first development SSL/I (SODA Statement Language/I) is the work of Nunamaker [22]. SODA (Systems Optimization and Design Algorithm) is an ISDOS software component that produces specifications for program module and storage structure and for hardware selection from the requirements analyzed by an RSA. Extension of SSL/I resulted in the development of PSL/I (Problem Statement Language/I) described by Koch, Krohn, McGrew, and Sibley [23]. Experience with PSL/I indicated its shortcomings and led to PSL/II possessing improvements suggested by Hershey, Rataj, and Teichroew [24]. Simultaneous with the development of PSL/II, experience with ADS demonstrated the value of a forms-oriented RSL for ease of requirements statement. in Proceedings of the 1974 ACM Annual Conference San Diego, November, 1974 view details Introduction The problems inherent in the increasing use of the computer for information systems applications have provided the motivation for the development of tools for automating the production of applications software. The current methods for building information systems contain numerous deficiencies [1], and so computeraided analysis of user requirements is proposed as the first step toward automated systems building [2, 3]. This approach follows the work of Langefors [4] and Teichroew [5, 6]. In this paper we describe a number of software systems for computer-aided analysis and how they were used to aid the Navy Material Command Support Activity in the design of a large information system. The activities performed by the systems for computer- aided analysis consisted of (1) procedures for stating processing requirements, (2) automatic analysis of processing requirements, (3) the design of program structure (i.e. determining how many modules must be generated and the size of each module), (4) the design of logical file structures and a logical database, (5) selection of hardware (central processing unit, core memory size, auxiliary memory, input/output configuration), (6) the allocation of files to storage devices, and (7) the optimal selection of blocking factors for each file. The software package for computer-aided analysis, design, and construction consists of problem statement, problem analysis, generation, and evaluation of alternative designs for process and data organization, code generation and implementation of the selected design. Extract: Computer-Aided Problem Statement Techniques and Analyzers Computer-Aided Problem Statement Techniques and Analyzers In 1971, when work began on the design problem discussed later in the paper, no existing problem statement technique was determined to be adequate for the complete expression of user requirements relevant to all aspects of systems design and optimization. Hence, two techniques, Accurately Defined Systems (ADS) and SODA Statement Language (SSL), were used. Features of ADS and SSL were eventually incorporated into Problem Statement Language (PSL) version 3.0 developed by the ISDOS Project [7, 8] at the University of Michigan. ADS is a product of the National Cash Register Company (NCR) and is described by Lynch [9] and NCR [10]. SODA Statement Language was developed by Nunamaker [1]. Combined, the two techniques were used to specify the requirements for the Navy Integrated Financial Management System. The time frame for the selection of equipment and design of the information system for the Navy did not allow development of a problem statement analyzer that ineluded the forms orientation of ADS and the time and volume features of SSL. The use of the two languages (ADS and SSL) was an operational convenience to take advantage of existing software. The combined problem statement consists of information on data volumes and frequency of input and output items. The data description, processing requirements, operational requirements, and time and volume information are expressed in units specified by the problem definer. ADS is forms-oriented and is used to obtain much of the basic problem definition. SSL is used to express system design parameters and performance requirements, e.g. I/O volumes and frequencies for system design and performance optimization. Extract: Accurately Defined Systems Methodology Accurately Defined Systems Methodology ADS consists of a set of forms and procedures for systematically recording the information that a systems analyst would gather during compilation of the user requirements for the information system to be implemented. The essential elements of an ADS requirements statement include descriptions of (1) inputs to the information system, (2) historical data stored by the information system, (3) outputs produced by the information system, and (4) actions required to produce these outputs and the conditions under which each action is performed. The ADS analyzer used on the Navy project was developed at the University of Michigan and extended at Purdue University. Computer-aided analysis of an ADS statement performs a number of checks and prepares a series of summaries of the statement of user requirements. The simplest kind of check performed involves the validation of ADS source statements to uncover any violations of the syntax rules of ADS problem statement. Rules relating to naming conventions, numbering conventions, information linking, and the like are specified to guide the user during problem definition. Summary reports produced by computer-aided analysis include a dictionary of all data element occurrences, indices to all data elements and processes, matrices indicating the data elements required by each process and the precedence relationships among data elements, and graphical displays of the ADS forms submitted for analysis. The description of the relationship between data elements, reports, and variables follows the work of Langefors. The data element dictionary consists of an alphabetical list of the data elements defined in the ADS statement, the places of occurrence of each element, and the information source of each occurrence. The indices assign a unique number to each data element and process to identify row and column positions in the matrices indicating incidence and precedence relationships. The incidence matrix uses process numbers as row indices and data element numbers as column indices to identify the data elements used in each computational process. The precedence matrix uses data element numbers as both row and column indices to indicate, for each data element, the data elements that must be computed before the first data element can be calculated. Complex cheeks of logical consistency and completeness indicate errors in data definition and linking of information sources. Finally, the graphical reports display the five kinds of ADS forms in the tabular manner as they would appear in manual use of ADS. Extract: Description of ADS and SODA Software Description of ADS and SODA Software The NMCSA project was mainly concerned with a macro-level evaluation of alternatives for equipment selection and logical design. The SODA components required for a micro evaluation of alternatives were not used in this project. This section describes the computer-aided information systems design software packages used on the Navy Material Command Support Activity project. The ADS requirements statement begins with the definition of all system outputs. The definition continues with the identification of information that enters the system in order to describe inputs to the system. The requirements statement is then completed with the definition of historical data retained in the system for a period of time, together with specification of computations and accompanying logic that subsequently use the input and historical data to produce system outputs. Linking of information elements among the various ADS definitions is accomplished in two ways. First, each data element is assigned a unique name that is always used whenever that element appears in an ADS definition. Second, each use of a data element in a report, history, or computation definition is linked back to its information source elsewhere in the ADS description. All data elements are chained from output to input and each output can ultimately be expressed in terms of inputs to the system. Chaining is accomplished by assigning page and line numbers to all ADS forms, so each use of a data element can be uniquely identified by the form, page, and line on which the element appears. The ADS example describes the requirements of a financial application for the United States Navy Material Command Support Activity. The financial application produces an output report entitled DIRECT CITATION ORDERS BY ORDER NO. Two data elements appearing on the report are of particular interest: M0002 MO-ENDG-DT (line 2 of Figure 2(d)) and Z053A (line 7 of Figure 2(b)). Also, the financial application includes a historical file DIRECT CITATION ORDER $& QUASI G/L having the following data elements of special interest on lines (2, 8, 20, 22, 23, 24) described in Figure 3(a). Input to the application is from the COMPUTER/ OPERATING SYSTEM with data element M0002 MO-ENDG-DT (line 2) being of special interest. The application requires one computation GROSS OBLIGATION- DIRECT CITE COMPUTATION that calculates Z053A from operands described on Figure 3(b). Since only one computation is required, no logic definition is necessary. Note the facility for cross-referencing data elements among the various forms. For example, Section III of the report definition form in Figure 2(b) specifies the source of each element on the report. Similarly, each entry in the history and computation definition forms in Figure 3 includes an indication of the source of the data element specified. Since this example includes only report production and not master file maintenance, the source of all history data elements cannot be specified here. Furthermore, the forms may be incomplete in other respects, owing to the omission of nonessential details of this example. In Figure 2(a), the Report Definition Form describes the printed output produced by the application. Section 1 documents the layout of the report by using the symbols identified in the upper right-hand corner to describe the printed fields. The number in parentheses below each field refers to the numbered items in Section III. Section III identifies the source of each data item appearing on the report. Cross-referencing is achieved by specifying H, C, or I for history, computation, or input, respectively, and by specifying page and line numbers that appear on every form. Section IV shows the sequence in which the output data is listed on the report. Figure 2(c) is the Input Definition Form, a description of the input to the source program. Section I describes the format of the input record and is linked to the complete description of each field in Section II (refer to Figure 2(d)). Section II identifies the alphabetic, numeric, or alphanumeric character of each field and its size in number of characters. The History Definition Form, a description of the master file maintained by the application, appears in Figure 3(a). Again, each field is completely described. The Computation Definition Form is displayed in Figure 3(b). The Computation Definition Form lists the variable to be computed and the factors needed to perform the computation. Again, the source of each factor is specified. The entry in the sign column identifies the arithmetic operation to be performed. ADS possesses obvious advantages over the traditional narrative requirements statement technique. Narrative statements are ambiguous and often incomplete, while ADS provides a standardized and systematic approach to system definition. ADS is both exact and precise while remaining hardware independent. ADS promotes effective communication among systems personnel by imposing a discipline that enables the efficient use of human and machine resources. The ADS technique enables checking for accuracy, consistency, and completeness of the requirements statement. To determine the computer resource demands of the information system for which the design process was performed, additional data supplementary to the ADS statement was necessary. This need required the following data for each input and report described in the ADS statement: (1) ADS page number, (2) frequency of occurrence, (3) volume, and (4) a brief description. This information was represented on SSL forms, along with query profile information which included frequency, size, source, and file reference information. Extract: ADS Analyzer ADS Analyzer The first module of the Problem Statement Analyzer for ADS (PSA/ADS) performs source deck validation, lists the input cards, creates a file containing all valid card images, and constructs a dictionary table to be used by other PSA/ADS modules. Source deck validation checks compliance with ADS syntax rules and detects errors that include (1) specification of an illegal form type, i.e. not Report, Input, History, Computation, or Logic, (2) improper form format, (3) an illegal data element name, and (4) invalid page or line numbering. For each valid ADS entry, the dictionary table records: 1. The place of occurrence such as form type, page number, and line number. 2. The data element name. 3. The information source that specifies form type, page number, and line number. The dictionary is sorted, in ascending order, according to the data element name and place of occurrence. The second module of PSA/ADS prints the data element dictionary and constructs a symbol table containing data element names. From the sorted dictionary table, the second module lists the data elements in alphabetical order and provides the place(s) of occurrence and information source(s) for each data element. An example of a dictionary entry for the data element D3231 DRCT-CIT-OTSTN-OBLN appears in Figure 4(a). The two occurrences of D3231 noted in the previous ADS example are indicated. During dictionary printing, the second module performs logical checks to detect the following errors and warnings: (1) no source of information, (2) no update for history data, (3) data element not used, (4) redundant inputs, (5) redundant histories, (6) a data element defined as both an input and the result of a computation, and (7) invalid back reference. Also, the second module assigns a unique number to each data element and prints an alphabetical list of the data elements used in the ADS statement. Then the sorted dictionary table is again sorted, in ascending order, according to form type (report, input, computation, logic, history), page number, line number, and entry type. The third module of PSA/ADS creates a file containing records of the computational processes defined in the ADS statement, prints a list of the computational processes, and generates matrices displaying the incidence and precedence relationships among the data dements and processes defined in the ADS statement. The third module reads entries from the twice-sorted dictionary table and, for each computation entry, the module writes one or more (depending on the number of operands in the computation) records on the file of computational processes. Each record has the symbol table pointer of the data element that appears as the result of the computation entry and the symbol table pointer of the data element that appears as an operand of the computation for which the first pointer identifies the result. The third module generates the incidence matrix indicating the data elements that serve as results and as operands for each process. These relationships are easily derived from the result-operand pairs in the sorted process file. An example of the incidence relation for data element Z053A and the relevant subset of the incidence matrix appears in Figure 4(b). Also, an alphabetical list of the processes is generated, with the operands of each process listed alphabetically. Finally, the twice-sorted process file is used to generate the precedence matrix indicating the direct precedents of each process. Data element I is said to be a precedent of data element J if I must be computed before J can be computed. A direct precedent of J is a precedent of J that is not also a precedent of any other precedents of J. The fourth and final module reads the sorted card image file and prints the input in a tabular format similar to that of the ADS forms developed by NCR. Examples of the ADS forms from the previous ADS example appear in Figure 5. Extract: ISDOS project Current Developments The work described in this paper used techniques and procedures developed prior to 1969. An overview of computer-aided procedures for information systems design and construction being developed at the University of Arizona [8] is illustrated in Figure 9. The application system problem definer (1) states the system requirements in a Problem Statement Language (PSL[5, 7] (2)). The problem-statement is analyzed by the Problem Statement Analyzer(PSA[6, 7] (3)) which determines the consistency and completeness of the problem statement and gives the problem definer feedback for modification of the problem statement. The PSL/PSA used in this effort was developed under the ISDOS Project at the University of Michigan. The language supports a' nonprocedural description of system requirements and facilitates a top-down approach to requirement statement. The process of defining the system requirements is handled in an iterative fashion using PSA, PSA serves as a tool in the problem statement process by continually giving feedback to the problem definer and maintaining a database containing the problem statement. PSA produces approximately 26 reports which describe process and data relationships and provide documentation as well as analysis of the problem statement. Once a complete and consistent problem statement is obtained, the PSA database contains sufficient information to proceed with the Logical System Design phase (3): Data Organization and Program Module Specification. It was decided that for purposes of standardization of procedure and portability, a subset of the data structuring techniques of the Data Base Task Group (DBTG) Report [16] would be used as the basis for data organizations generated by the system. This allowed a formal basis for file structuring while permitting considerable flexibility concerning the particulars of file design. Thus, the Data Base Management System, Data Definition Language Analyzer, and I/O interface requirements were stated in the Problem Statement Language (5), and a requirements database was produced (7). The dotted line indicates that this process was a one-time procedure, since the requirements database will be the same for each system generation. Program modules are derived according to target system specifications (hardware and system software) and operational (manual intervention) factors. Process characteristics and attributes of interprocess relationships are analyzed, and graph theory and multidimensional analysis techniques are used to derive program module specifications. The process of Logical Data Organization (9) can broadly be described as the definition of logical storage structures and their associated data relationships. It is the purpose of this phase to determine effective subschema for the various processing modules, the number and contents of the system databases, and an effective schema for each database. The automatic code generation and physical design (12) phase includes representation of data manipulation specifications in the form of functional primitives, determination of data structures required for processing of control sequences within the framework of the program module, generation of "bookkeeping" operations for program module invocation, termination and communication, and generation of target system code (13) for implementation. The design system maintains a database of information on system requirements. As design decisions are made the database is adjusted accordingly. The design models interface with the database through a central control processor which handles design questions through the use of a query processor. The design models include simulators, optimizers, and statistical and data summary analyzers. These models form the basis of computer-aided physical system design. Output analysis programs initiated by the control mechanism display information for the user or update the database as necessary. In addition to the logical design and code generation models, some of the physical system design models in present use are database load and edit programs, direct access storage device time generator, file organization processor, file assignment, channel subsystem, CPU-channel network queueing, line topology organizer, concentrator location, and blocking factor determination. in Proceedings of the 1974 ACM Annual Conference San Diego, November, 1974 view details Application Specification Media and Aids The direction that work in the DPS-type based approach has taken is toward making it easy for the user to describe his application. Simple and concise descriptive media for describing the user's processing requirements and the data his application uses and generates have been developed. The ISDOS APS uses the ADS, SSL and PSL languages, all of which involve RPGlike forms to be filled out by the user. Protosystem I makes use of HIBOL, an English-like statement language (like COBOL, but at a higher level of abstraction). The power and simplicity of these languages is most easily Illustrated by a short HIBOL fragment. If PAY, HOURS_WORI indicates that for each employee for which there is a record in the HOURS_WORKED file, the PAY file will have a corresponding record with an associated value obtained by multiplying the number of hours the employee worked by his hourly rate. The iteration through the files involved, the file i/O, record generation, EOF checking, and so forth, which would have to be explicit in a PL/I program equivalent to this statement, are all implicit here. The development of simple descriptional facilities for the full range of more complicated common data processing activities such as summation and the maintenance of running totals is the subject of continuing research. At USC/ISI a research effort is currently underway that is aimed at allowing the user to express his application specification in English. This promises the ultimate in user convenience, but natural language comprehension by machines is difficult. It is conjectured, however, that the usually formidable problems of ambiguity and detail suppression (e.g. anaphoric reference) will be mitigated to, some degree by the highly constrained nature of the processing described. That is, it is felt that tentative program attempts will act as effective filters of possible alternative interpretations of the English specifications. Another way in which the developers of APS's are seeking to make the description process easy for the user involves the use of consistency and completeness checks. Whenever parts of a user's description are inconsistent (e.g. he associates different keys with the same file in different places) the clever system will point this out and demand resolution. Completeness checking (e.g. is the source and destination of all data specified?) can be used to guide the user in his specification effort, too. The ISDOS and MODEL systems provide such aids to the user. Abstract: To meet the burgeoning software demands of the future the computer will have to take a more active role in the writing of its own software. Many computer tools have been developed that enable the machine to help human software developers. It would be preferable, and in the not too distant future it will be necessary, for the machine to actually take over a substantial part of software development. Automatic programming seeks to do this by moving the human developer up from the implementation level of programming (e.g. COBOL, where the human has to include such details as data and control structures), to a level of programming that is less specific, where it is left to the computer decide the best way to fill in implementation. This article provides a survey of current research and development in automatic programming and a dlscussion of future directions in this field. in Proceedings of the 1974 ACM Annual Conference San Diego, November, 1974 view details |