SSL(ID:7159/ssl005)Systems specification languagefor SODA Statement Language Incorporated into PSL Related languages
References: in [AFIPS] Proceedings of the 1971 Spring Joint Computer Conference SJCC 38 view details in [AFIPS] Proceedings of the 1971 Spring Joint Computer Conference SJCC 38 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 in Proceedings of the 1974 ACM Annual Conference San Diego, November, 1974 view details External link: Online copy Extract: Introduction 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: Systems Optimization and Design Algorithm Systems Optimization and Design Algorithm The SODA components used on the Navy project were: (1) SODA Statement Language (SSL), (2) SODA Statement Analyzer (SSA), (3) SODA Generator of Alternatives (SGA), and (4) SODA Performance Evaluator (SPE). SSL consists of a set of forms for systematically gathering data on the volumes and frequencies of system inputs and outputs described in the ADS statement. SSL provides design parameters not available in the ADS description. The essential elements of an SSL statement include requirements data for: (1,) inputs to the batch processing subsystem, (2) queries to the teleprocessing subsystem, and (3) reports produced by the information system. SSA produces a number of networks which record the interrelationships of processes and data and passes the networks on to the SODA program concerned with the generation of alternative designs. Each type of input and output is specified in terms of the data involved, the transformation needed to produce output from input, and stored data. Time and volume requirements are also stated. SSA analyzes the statement of the problem to determine whether the required output can be produced from the available inputs. The problem statement stored in machine readable form is processed by SSA, which: (1) checks for consistency in the problem statement and checks syntax in accordance with SSL, i.e. verifies that the problem statement satisfies SSL rules and is consistent, unambiguous, and complete; (2) prepares summary analyses and error comments to aid the problem definer in correcting, modifying, and extending his problem statement; (3) prepares data to pass the problem statement on to SGA; and (4) prepares a number of matrices that express the interrelationship of processes and data. SODA Generator of Alternatives (SGA) begins after the requirements have been stated, verified, and analyzed in SSA. SGA accepts, as input, the output of SSA and a statement of the available computing resources, hardware, and utility programs. The hardware and software file consists of data for the computer systems under consideration. Fundamental to the SODA approach is the automatic generation of designs of program structure and file structure. This is the point at which SODA differs from other techniques such as SCERT [13] and CASE [14]. In order to use either SCERT or CASE, it is necessary that a system already be designed to obtain answers regarding feasibility. With SODA, the user has three options with respect to the generation of alternative system designs: (1) consider only SODA generated designs, (2) consider only designs generated manually, and (3) consider both sources of designs. SGA takes the information from SSA, analyzes the alternative hardware and software information with respect to a specific design, and generates the specifications for the necessary CPU, core size, program structure, and data structure. SGA essentially computes the expected processing time required for alternative designs for each period of time. SODA Performance Evaluator (SPE) involves examining feasible designs in an attempt to improve system performance. The optimization and performance evaluation phase searches for ways to improve the IPS (Information Processing System) design. SPE may return control to SGA to select another CPU or core size or to select another set of program modules and files. SPE consists of a number of mathematical programming models and timing routines that are used to (1) optimize the blocking factors for all files, (2) evaluate alternative designs, i.e. specify the number and type of auxiliary memory devices, (3) assign files to memory devices, and (4) generate an operating schedule for running program modules. These reports include: (1) a list specifying which of the available computing resources will be used, i.e. which computer system is required to do the job, (2) a list of the program modules specifying the input, output, and computations to be performed in each, (3) a list of files to be maintained specifying their format and manner in which they will be stored, i.e. an assignment of files to memory devices, and (4) a statement of the sequence and manner in which the program modules must be run to accomplish all the requirements. 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. Extract: SODA Macros SODA Macro Simulation In most cases, it is not appropriate to perform a micro-level performance evaluation, when many system design factors have not been specified. Therefore, a macro simulation can be useful as an aid in the specification of the complete systems design. The SODA macro simulation model was used to evaluate the performance of the alternative computer systems under various simulated workload conditions. The macro simulation reports serve as an aid in design and performance evaluation of alternative design factors. The macro simulation was used to test the sensitivity of the performance considerations on various hardware and software design parameters. Among the system factors simulated at the macro level were (1) the number and capabilities of various devices, (2) specification of system software organization, (3) distribution of teleprocessing arrivals during various periods in the day, (4) query profiles, (5) scheduling of I/O devices to channels, (6) resource queue characteristics and (7) batch scheduling and job profiles. The macro simulation was used to isolate potential problem areas and determine bottlenecks. This analysis was used to evaluate resource utilization, system throughput, batch turnaround, query response time, overall system behavior, etc. The SODA Macro Simulator is an event oriented simulator not unlike that presented by MacDougall [15]. The major structures maintained by the model during simulation are a job status table, a list of events, various queues, resource status tables, and job and resource utilization statistics tables (Figure 6). Examples of the SODA Macro Simulator output are presented in Figure 7. The manner in which the model simulates job interaction with the database was of particular interest, owing to the sensitivity of the data management system with respect to particular applications. The procedure differs from that used for ordinary I/O requests to and from disk. Database accesses were classified by function and complexity. The primary functions were updating and retrieval. In addition, each function was further subdivided into various categories of access complexity. Complexity was characterized by such factors as the number of keys specified in a retrieval request and the number of indices that must be searched in order to find the desired database record. Overall, database performance was determined by the size of the database and by the type of physical storage structures employed to represent logical data structures. The characteristics, e.g. size and physical storage structure, of the database were specified initially in the simulation model. Each type of database request, e.g. update or retrieval, was characterized by the various levels of complexity permissible. Based on this data, the model generated estimates of the processing time of each type and of the complexity of database request made by the jobs in the simulated mix. in Proceedings of the 1974 ACM Annual Conference San Diego, November, 1974 view details |