Computer-aided analysis and design of information systemsThis approach follows the work of Langefors...

Management H. Morgan Applications Editor

Computer-Aided Analysis and Design of Information Systems J.F. Nunamaker Jr. and Benn R. Konsynski Jr. University of Arizona Thomas Ho and Carl Singer Purdue University

This paper describes the use of computer-aided analysis for the design and development of an integrated financial management system by the Navy Material Command Support Activity (NMCSA). Computer- aided analysis consists of a set of procedures and computer programs specifically designed to aid in the process of applications software design, computer selection and performance evaluation. There are four major components: Problem Statement Language, Problem Statement Analyzer, Generator of Alternative Designs, and Performance Evaluator. The statement of requirements was written in ADS (Accurately Defined Sys- tems) and analyzed by a Problem Statement Analyzer for ADS. The ADS problem definition was supple- mented with additional information in order to create a complete problem definition. The analyzed problem statement was translated to the form necessary for use by the SODA (Systems Optimization and Design Algorithm) program for the generation of alternative specifications of program modules and logical database structures.

Key Words and Phrases: computer-aided analysis, information systems, logical system design, problem statement language, problem statement analyzer, physical system design, accurately defined systems, systems optimization and design algorithm

CR Categories: 2.44, 3.50, 4.33, 4.9, 8.1

Copyright © 1976, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part of this material is granted, provided that ACM's copyright notice is given and that reference is made to the publication, to its date of issue, and to the fact that reprinting privileges were granted by, permission of the Association for Computing Machinery.

Authors' addresses: J.F. Nunamaker Jr. and B.R. Konsynski Jr., Computer Science Department and Management Informa- tion Systems Program, College of Business Administration, Uni- versity of Arizona, Tucson, AZ 85721; T. Ho, and C. Singer, Department of Computer Science and Krannert School of Industrial Administration, Purdue University, Lafayette, IN 47907.

1. 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 computer- aided 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 con- figuration), (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. An overview is shown in Figure 1.

1.1 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

674 Communications December 1976 of Volume 19 the ACM Number 12

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 in- eluded 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.

1.2 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 Michi- gan [l l, 12] 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 viola- tions 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 relation- ship between data elements, reports, and variables follows the work of Langefors [4]. 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.

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

Fig. 1. SODA (Systems Optimization and Design Algorithm).

~iagnost icsl I Problem . and. -- 1.

on Timing

Calculatio~sl "

ia,:ostiosl r L

L

@ i ta ..... Requirements in

ADS with Supplementary

Information in SSL

Problem Analyzer ADS SSL

SODA [ performance Evaluator (SPE)

Complete Specificatxons of •[Selected Computer Systems

675 Communications of the ACM

December 1976 Volume 19 Number 12

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 [1].

SODA Performance Evaluator (SPE) involves examin!ng feasible designs in an attempt to improve system pertormance. 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 CP~J 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)

676

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.

2. Description of ADS and S O D A 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 Sup- port Activity project.

The ADS requirements statement begins with the definition of all system outputs. The definition con- tinues 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)).

Communications December 1976 of Volume 19 the ACM Number 12

Fig. 2. Report and Input Definition Forms.

P O R T • H G Appl i lot lon [ I

• REPORTLAYOUT . . . . . .

I , l l I I I I I I I I ' I I I I I I I I I I I I I I I I I I I I I I I J I I I I I I ' I I I I I I ! I I ! I I I I I I I I I I I I I I I [ L L I U

[ n l l l l l l l l l l l l l l l l N ~ l ) I l l l l l l ! l l l l l t x l x l l l l l l l x ~ l l i l x l i l : l i I l l l l ~ i [ fP, J- I , l l l l [ l l l l l l l I l l l l l q ~ l l J l l l l l q ' 4 ~ l l l l l l l l l l l l l l i I | I~ Is 6l!!!!!!!!!,~llllllllllllllllllllllllllllllllll~tll! !1~1![~-1-~_ 141111 l l l l l l l l l l l q ~ ) l I { l l l l l I I I I I I I I [ I I l l 11 i I I ) lll(:~|~i I 111 ] l t , z l l l l l l l l l l ~ . . . . . . . . . . . . l l l l j . j jam LJJ.U I II I I I I II I I~ . . . . . . . . I]

, ) -""~qd,~ [ ! t I 1 l !~,i~ t 11 | I1~

(a)

h i * CROSS REFERENCE TO FIELD NAMES JWHEN FIELD HEADING INCLUDES MULTIPLE CODES, LIST ALL CODES ON ATTACHM~NTI

~JP_PO! AOt~L~-O,CC-C

~Oa~9 ooc -N~ I

~lL~£Clcdz~ t~r .or .~r tq - . r# t r~ l I lt41/~fl l l l ~ l ~ l z l . a R c t - c z r . or&rl~-~.elre~ 1 [t4l/~.f J l l l~, i [O..~A I ] l c l $31 11-1 pAoo3 P/ , . . /ve I I I I ' I~.oH t l n l

,o00,;0.,.o722_J L E V I : L 2 p o o l 7 # o c - i v ¢ I

1

(b)

IF I ' I .~ ( P A L S ) INPUT DEFIN I I lON foe J'~/PUT Appll¢l f ion N ~ OFINPUTCO.IVIPUTEI(/OPERATt ~V~" WHAT I$ SO|T KeY AdD NORMAL INPUT IIECOR D 5Y~ 1"dE/~'1

~DLa, TYRF PllePAgE0 BY VOI.UMIE AV JPEAK D A T L PAGe I[ a •OF. 6 o~

FOIl VAIIAIL~ NAME OF FORMAT~ ~ T S , ENTel

LID. ¢OOE, ,~

O o'l i

t t ~ 7,

(c)

r r COMPIE]E DESCRIPTION BELOW Ol c EACH FIELD| IN S[CTIOI, I I - - INPU' MEDIA LAYOUT " l

r ~ g e o z L ¢ ~ p r . p r - - 7

~OOOt /'10 3 ) L£oo3 Y~AR 1

L__7. o&o_oy p A A _

_.. t~ o_Oa~_JZlO_ "~_go_e .£~___ ._ At _,1

,12 .13 14 ~ g 0 $ ) R e G - / V R N 3

11~ B 0 I O T - ~ -COD _ _ _ _ A _ I _ ~ l l 6 OEOl,~, 0 0 P ' ¢ o o $ N I

(d)

VAtIDAItON-IUt E$

J

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 OB- LIGATION-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 in- complete 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

6 7 7

1 documents the layout of the report by using the sym- bols 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

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

Communications December 1976 of Volume 19 t h e ACM Number 12

Fig. 3. History and Computation Definition Forms.

I zHISTOIIY DI~I~INITION f~--Z'/~J~ ','__AppIIcaflon[P,,M~OF GIIOUPIN{~ ~ t ~ t e r ctrdTlOat

r#~@ s r * r u s ] OgPER # + I ~UASI ~ / L PII£PAIi D In' _ _

| l FIELDS THAT IDENTIFY THIS HISTORY: P..rOq_7__~.~_C_o~._~.~_~P_9~/~._¢~O0~,

I U WHAT IS THE EXPECTED VOLUME? ^v, " ~*x,

p DESCRIBE EACH FIELD OF 'THE GROUP

OOl;' OP_~z_rJ . . . . . . __2.LO_o 0 / 7 poc_-qg J3 3__~_e_g o ~ t ~ ! _ ~ c r - c.D

_8 !_,;_oo i 4p.~ jN_~-~op_~-~ - 9 [C o~C~OIt cNr&.y~ogLp IO ~$~7 D ~ C T - C I r - ~ D K , - L N - I N ~ I

i-2 .

I' .... ~15 ' "

5ff -i 9 zO ~JO~tL~Jc3"~I.r=_~TJL~RS-v_p 13 -2T FFJ.~I__D..I~fT'¢II_'.t~,Y_C_'~_O-"_IdPtO~tO [ I ~1,- tJ I I [ "z~ J)'tYrt°-~Rcr'--cLr'~!'-~--rN'-£~-tr~ ~ vl~'~' l i~ I J i

-Z4 ~ L ~ t i ~ _ ¢ ¢ L--¢¢ r'-o-r:tr#'--_oa ¢._,V Vl *- I t31 I [ 26 _@l_o&O _ D _ ~ r - C J r . F D _ ~ I ) S f f B _ _ _ _ _ f " I I

~",,~ I I . I I I J /

(a)

(b)

ADS possesses obvious advantages over the tradi- tional narrative requirements statement technique. Narrative statements are ambiguous and often in- complete, while ADS provides a standardized and systematic approach to system definition. ADS is both exact and precise while remaining hardware inde- pendent. 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.

2 . 1 A D S A n a l y z e r

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, Com- putation, 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.

2.2 Process Generation and Program Module Specifications from A D S Definition

The ADS problem statement contains the basic information required to generate program module specifications from processes that may be grouped into program modules to eliminate unnecessary trans- port of data from history files to program modules. For example, if it is determined that two processes require the same inputs and occur in the same processing cycle, e.g. daily, then the two processes become candidates for grouping into a single program module.

SODA Generator of Alternatives (SGA) performs process generation by compiling four comprehensive summaries for each ADS-described report: (I) an input summary, (2) a history input summary, (3) a computation summary, and (4) a history output summary.

Fig. 4. PSA/ADS dictionary and incidence relation entries.

(a) n

p I C T I O | A ~ !

VA~IABL~ N~NE

ADS~III

OCCUBS 0 H :

i | u

Bgr EASE 1 PAGE 7 9

lXTH BACK BE~BBEJC~ : PORE PAGE L I E S USE PORE PAGE L I J S ASGE MOTK

D3231 D B C T - C Z T - O T S T | - O B L E C 9 2 5 1 L T . 0 0 ( E / A I C 9 2 5 2 L T . 0 0 ( ~ / A ) C 9 2 5 3 L T . O 0 ( g / l ) C 9 2 5 ~ L T . 0 0 ( ~ / A ) C 9 2 5 5 L T . 0 0 - - - ( u / l } C 53 1 RT. H 169 2~ F5 C 122 90 ~ T . B 169 2¢ PS * C 122 1 0 6 BT. B 169 2q PS C 126 2 BT . R 169 2~ P$ C 126 6 ET. H 169 2~ PS C 9 2 5 1 i T . E 169 - 2~ P$ ~- C 9 2 5 2 E~ . B 169 2~ pS e 9 2 5 3 BT . E 169 2~ PS C 9 2 5 q ~ T . B 169 2q PS C 9 2 5 5 I T e H 169 2¢ PS

169 2~ C 9 2 5 1 PS u

(b) I : C I . D S / c s R S L A T I O H S

PEOC VAE

6 3 2 1

i m i _ I i l l l i

l O S / ZZX ~ E L ~ A $ | 1 PAGS 3 7 8

~ESOL?AN? VARIABLE TAB XGPUT YAEZABLE(S}

ZOS3A 2 1 8 D 1 0 6 0 DBCT-CXT-ED-DSOD

679

, ~ , , . . D 2 1 3 0 D R C T - C I T - C O B T R - H B K . . . . . . ~ O J 2 3 1 D E C T - C Z T - O T S T ~ - O B L N

~ C ~ C K E A T R I I I ADS / l l I EULKAS~ I /

O 2 0 5 210 2 1 5 2 2 0 . L 2 2 s 2 3 0 2 3 5 2 q o 2 a 5 2 5 0 2 5 5 ~ - - - Y - - v " v v y v v V v • • •

~B7 ° e e o c ° e B B . 9 ~ e ~ o o e e o . e ~ , e e e o e e o ° e e o c o o o e o o e o e # o ~ o ~ e ~8R ~ 9

I " .~90

2 6 0

I , o o e o e o e o

e o e * o o e o l J J e o o l eoTl [ I i I g e * o e o e l * * o , * l e * e e e e l o J o l e o , e * e e o o e l , o

1191

~ 9 ] ooeoQ . B o o , , e l ~ o t o e ~ . o ° o , e ooooo ~ o o o , ° o 0 1 o oeooo o o . ° , e l o o o o o o . o ~9~ o e o e ° e o o . o o ° e e o e e o e o ooeo0 e e e e e B e ° e * ° o e o . B e ° c o eeooe o o e ~ t r i o t °

~95 t t o ~ o o , , o ° oooeo ~ , o ° , ° . o o l o , e e o o o . . o o e e e e o . o e , e o . o , , l e o l i , e o ~ I I I II | [I-- [ -- - "HI I " I - -


Fig. 5(a). PSA/ADS Report Definition Form.

I I i i

I ~ O R T eRR5

I I I

ADS / I ] [ [ H E L E I S I | 1 FLGE 1115

I I I E P O I I ~ D E ~ I I I I T I O I I FOg I 1 IF811 FUIID I IT&TOS EEPOHTIIIG

I I I A H E 0 7 ~ F O ~ T I I I I

1 - - __L . . . . . . . J D I I I ~ C T C I T I T I D H OgOgH5 B I e i D E l l gO I I I I

I P g L I C I T I O I J I PIIEPIII IED I I I OlTE 1 2 / q / 7 2 P&GB 53 0 7 192 I 1 I I

I l I CI1055 I I I IFEREiCH TO F I E L D NAUEII ( i1888 F I E L D 8 £ L D I I I G IMCLOOES n U L I I E L I

CODESjt L I I I T I L L C 0 0 ~ 5 OlD TABLE HELOII ) .

I l I I . . . . . . . . . . . . . . . I L I I 8 [ - g I P I | I I II s n g ! E I C I & I I I 9 I I 8 K i I I G I M I _ _ ~ I I o I I I I I m I . . . . . I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I . . . . . I - ° + 1 - - - I . . . . . I ~ : I I I I I I I

1 I AO001 ~DRZl iG-OFC-C I 0 I I e I 1 6 9 I e • - i i ~ l l 2 I nO002 RO-E.OG-OT ! 0 I I I I 2 0 1 I 2

I 9 I [ :001" / I I O C - I I H I 0 I I U I 16--9- I 2 I Ii I_ 0 1 0 3 1 DIICT-CIT-AAUTHR-RCVD I 0 I I 8 I 169 I 20 I 5 I 0 9 8 1 0 D B C T * C I T - O T I I T I I - I R I T I I I 0 I i 8 I 169 I 22

A. . , , ~ : 76 JL D3221 D R C T - C I T - O T S T I I - C B T S , I EOS)A ~ H I 169 l i 0 I I C 53 231 i

L e I F i R e 5 PG*88 I O J ~ I I 201 I 1

I CHECK COLUIII I TO I I I O I C & T g T f lAT i F I B L D DOES l O T PHIHT D][CDPT l l O l i TFlB ¥ 1 L O I t ~ T R I I F I E L D C8&IIGRS a 011 I T ' I8 II TO~ OF l+ l E D PIG It

~ - - - H l k l O n L E I I I L 1 1 0 0 0 1 | D B I I G - O F C " C l l Z l O £ L£TIIL 2 0 0 0 1 7 OOC* IB

Fig. 5(c). PSA/ADS History Definition Form. II I

t l i IIITO g I 70~.qll io.s / I Z t I I I

II leLI&S II 1 | | G I 811] I _ I

p f~(* l+ l l ' + i i ' Y i # ( , ! I ~

I r l l l ~g89 S~ATOLL

IFPLECITIOII

I II&HL OF X I S T O I Y l

D I I I C f C Z T I X I O I O I D I I i • O l i l l I D / L l I I I P I I | 9 I I g U I T | I DATg ~ 1 i / ? ] F I G I 189 OF 2~O I ! . . . . . . . . . | . _ _ _

s o i l [ I I ( l l ) a & J O l L( I I I IL 1 O:OO7 O P C ? * C I f - r O ~ - L I - I I R I

L~VEL 2 &CO~5 ICC¢-CL-CL I&gG8 L ~ l ~ L 9 10001 IIDRIBG-O~IIE°~ L E V e l q C00~8 CiTIFY-rOUGH ~[V~L ~ 0 0 0 1 8 O O C ~ L ~ I E L 6 8¢ i i~1 I £ - U O C ' N l l LEIEL 7 I IEO?8 I I Q I I G - ~ t l i - R G i " ~

l l ~108 L ~ I E L R 0 0 0 1 7 O O C * I 8

I I l I I 8 I sool lcs i L I II I $ II i II I I o I . . . . . . . . . . . . . . I

, I 8,., I II I I/I / I z I , O , L O , + , 9 t~t., , ~ L , I I a I o / G I g I D&2A I R T I L I I I D I , _ . _" I" ' i , I I

.. I I I A 0 I C I I I II I II I I I I I G I I I I I 9 I I I s I I ~ "I [ I

i * - - - - f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . " + . . . . t - * " ' f ' - ' f . . . . t . . . . . t . . . . . . . . - - ? - - - t - - - t . . . . . t . . . . I I I

1 ~ o ~ 8 u o ~ - T t I ~o+ I o I I I I ) I 2 00017 DOC-IIR 101 I 0 & I 1~ |

o + , , ~ ¢ , + T - c o i o l O ~ l l , j 11

I D~G;U 7 I C ~ S

I i p C C I ? COOC8

I 10 I I I C ~ 7 13 1111078

_ _ L _ z o I I~c3 | 21 0 J 2 1 1

• 22 o j p l O . ~ ~ 23 0J221

~ I OJZ31

I Z6 I 0 1 0 6 0 I 21 I 09811 I ~8 ! a9~ ! ~ I 2 9 I 111012 t 3 0 1 G E O 0 2

DIICTG-AR~-FB-OTM-511VCII | ACCT-CL-Cf i&I IGS A D e ; s ; O P : C J Cn~aT-WOmLD O R C ~ - ~ I T - r ~ G - L I * t l U I I | B~kG-p=~+R~B+C D I I C T - C I T - ~ U ~ H ~ - I I C T D I I IDC~-C I¢ -O~CRD-OI IO~LD D # C T - C [ T - J T S ~ - I N I T S D 3 C ~ - C Z ; - O ~ S T N - C R T F I ~ O B C ? - C [ ~ - G T S T N - C ~ L I I OSC~-C :~ °CONT] -R I I I I O R C T - C [ T - p D * ~ S B D D J C ? - C I ? - Z I I Z ? I I * L t Q U O I I C ~ - C I ? - Z l Z ? I I * C O I T I I 8 I ~ A I ~ L C O - I I Q I I ' C O I - I I I I G I I I H ' C O D I

o I u I II I . * I 81 1 O I II 4 I aO I O l , O l i l I z l o I o i I 2 t O I O I k I I _ 1 1 O I 0 I I i I o I O l U l * - + 111 0 I 0 I t - I 1 3 1 0 I 0 I II * - I *.+ I O I 0 I II I * - I 13 I 0 1 0 I I I + - I 1 3 1 O I 0 1 II I * ° ! 1] I 0 1 0 l I * - I 1 i

- - 0 I 0 1 II I + - I 1 1 : 0 1 0 I II I * - I 1 3 1 U I 0 I & I I 1 8 1 0 I 0 1 1 I I ~I I

I I I I I I I ! 3~0 1 I I I Z l ) W O l z I

I Is7 T 3 I ~ I c | 157 17 I 1% I 31o I 5 l I I I 3 1 0 9

I c | 157 76 I ! T F 3 I o + 1 - - 2 ~ F - I ¢ I 900 1 I - - - - I - C - f + } 1 5 - - [ - - - - 1 7 - ~ I C I 930 1 I I c I ~ u i I I I C I 925 I ]

I - - i i - c - ] 91O--F- - - -~ i ! I C I ? 0 5 1 I I C - ' 1 " 9 3 5 - 1 • - I ¢ I 9 ~ 0 1 1 I I ~; I 1:>,r I I ' i I C I 1 S ? I 1 8

6 8 0

| 0 ~ | 1 * • L t r : B L D I I i I I I T g l i i l i C I I H i l l I E ¢ 8 p i i O T ~ g D


Fig. 5(b). PSA/ADS Input Definition Form.

I I P O T WO/RE ADS / Ill OBELBISE 1 D i G g q 1 8

I IMPUT DEWZNZTZOE FOE

I ZFOBS (PARS) INPUT I

i I NAaE oe z l lvuz

I I C O ~ r U T E E / O P E N I T I E G S X S I E E I [

A P F L I C A T / O E I I PHZPAE~D aX 1 . . . . . 1 D A T B - B / I O / ) I - - I " / I 0 / 7 3 W i l l 4 U I

. - - - - I I

u~ b 0 4

SOET IIEE IS ) a i J O B LEVEL 2 p L 0 0 8 P L O S - H I N U S - I N D C O B

~ K V E L 3 ~G53 BEG-SO L E V E L ~ R g 0 6 2 ISS-EEQ-CONTB-PRT-HTC L~VEL - - S - T R 0 1 8 T~AllS-STUS-IllDCH LEVEL 6 TUB019 TF~llS-ITER-CET L ~ V Z L -- 7 - 0 ~ 0 1 3 DOD-COD~ LEVEL 8 n I 0 1 3 llIL~Cte-r~nT-iPllToB LE¥i~--9--~q0T~~LSCA~-LOG-DA~A-COD~ LEVEL 10 l l R 3 0 3 llBFC-R~G-RO LEVbL-- 11 -¢o08~ CCNCOB-FD-TRANS-COD~ LEVEL 12 C 0 0 8 5 CONTB-OOBLN-VAR-COD| LEVEL--~) - - D A O i l BAT-SE~-CODE LEVEL 1~ oAO~2 E X r - S E ~ - . ~ L E V E L ~ - - ~ L ~ G ~ C i : C - 6 6 k - ; - W S E - 6 3 2 ~ V E L ~6 ~ o o o 2 n O - E E U G - D ~ L ~ W L ~7 N o 0 0 1 a n L ~ V E L ~e Ze00~ V~&OB L~VUL 19 DA00~ DA

E l l l O E LEVEL 20 D I 0 2 1 D E B G - O F C - $ T R - H E

II COBPLLT| DESCOBIPTION BELOW OF EACH WIELD Ii SECTIO| I - mlllPUT BEDIi LAIOUT"

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I I I I I V I L I D A T I O H I I I I I I ~ U L g I

L I l I i I S I II 1 I r I W I Z L D I • I I i • i / I I i g I S " Z LOGIC I " I , . O I . n . . I Z I II IrOOBOB: I D I L I I l I O I I

I . . . . . f . . . . T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . " . . . . . . . l' . . . . . t ' ' - t . . . . . f . . . . . t . . . . . . . . . . I

I 1 B - i , , i 2

. . . . 1 _ _ _ 3 . I I 5 I 6 I 7 I e I 10 I 11 I l i t I 15

I I 1 I P t O 0 5 pG- l lB

X 0 0 0 2 ~O-EHDG-DT _ hE02~EPT-DT FEE06 F~D-CVED

_ Boo01 ~0 l e O 0 3 % E l l DAOOq Ok 8 0 0 0 1 e o - c

_ . a O 0 0 5 HO-PROCES HI011 FISC-VE-PEOCES RE053 BEG*liE O B A 0 1 1 B a T - S E Q - C O D E DSO13 D O D ' C O D |

I I I I I 0 1 . ~ ~ 1 0 1 I 0 t I 7 0 I I o '*1 7 o I I 0 t I I i 0 t

. J ' 0 i l 3 0 1 I 0 i I 2 8 1 l o a I 2 I 0 i l l 2 0 I I O N _ . I 2 o I . I 0 I i I 2 0 I L _ O . j u ~ 2 _ l 5 : ! I 0 l A I 1 1 ' i I O l a l 1 1 S O B

! 0 0 0 O 0 0

0 I 0 0 0

0 0 6 0

Fig. 5(d). PSA/ADS Computation Definition Form.

COllPaTaTlOll WOOBRRS ADS / I l l

l COMPUTATION DKfZN~TIOB FOR I I i'IPBS WOlD STITOS BEPOOBTING I I I l . . . . .

I I 7ACTOOB TO BE COIIpOTED

i i L I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i I TBIGGEB |

I . . I I I P - - I I, ! . . . . I I I O l i I l I l i I I L ! i ! j _ l I I

I A , . , . , , , , | _ l - - - -_- ~ - _ - t - - - _ ' - t . . . . . t - _ - - - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - :

I I i I I • - , l i , I i i i o o z o s 3 i C__ ,

I ~ l i - - I l I 2 I

&PPLICATIOJ

RELEASE I PAGE 6 5 0

I IA l l l l OF C O l l V U l i f i O i I I I I GROSOB OOBLIGATION'DIBBCT C I T E COOBIUTiTIOi I

T i I e a [ e i R l a a l I I EaT4 1 2 / 8 # ' 7 2 . . . . . . . . . . . . e l u n ~ 3 ~ o l ~ q ~ - - - - -

~ , . . . . . _ _ - 4

I EACTOE i FOLLOEID B I EICTOB OB J

" : . . . . . ; . . . . . ; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , ; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . " ' , 1 " " ~ - - - - I ~ i - - - - I . . . . . . . . . " ~ " ~ " • i i I I ! . . . . I 5 I I l i I P I L I n I I I i I a I I I ] l i - X n s 1 - C - - ~ 1 z - l r - - T i ! I I , I G I I t I G I l I I I I I I I I I 1 ~ - - I ' - ~ ~ + i l

t t t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . t - - - t : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . t - - - t . . . . . t . . . . . t . . . . I I I I I I ] . . . . I - - - I - - - l - - I I l l I I I ~ I I D3231 OBCT-CIT -OTSTB-OOI .N I a I 159 I 21 I 0 I I I i I I I • I D Z I I O - - D E - - C ~ ; C ] Z ~ O I ~ ; U E E -" l - g - ( 1 5 T | - 2 5 - I - - 0 7 F I I I I I * I D lO60 DRCT-CIT-FD-DSOBD I E I 169 I 26 0 I I I

m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . m COMNOII AOBITIJIIETIC SI ' I IOOL$ e i - r * ~ S


Since the source of each report item is specified in the ADS statement, all sources that are either input items or history items are included in the input and history input summaries, respectively. For report items whose sources are computation items, the input and history input items that are used as operand factors in the computations are placed into the input and history input summaries, since the sources of all computation operand factors are specified. Also, the computations required to produce the report items are placed into the computation summary. Finally, the history output summary is compiled by listing all history items whose sources are items listed in either the input, history input or computation summaries. Therefore, the history output summary indicates those history items that might be updated by the elementary module being specified.

After generating a process for each ADS-specified report, SGA searches for candidates for program module grouping in two ways. First, if some process requires history inputs (or inputs) either identical to or forming a subset of the history inputs (or inputs) required by another process, the two processes are identified as candidates for grouping. Second, if a predominant (approximately 90 percent) subset of the history inputs (or inputs) of some process is identical to a predominant subset of some other process, the two processes are identified as candidates for grouping. Finally, if the two candidates for grouping occur in the same processing cycle, grouping into a single program module is recommended by SGA.

SGA generates one complete feasible set of program module specifications. Phase 1 of SGA is a deterministic algorithm and traces the sources of data items that appear on reports in order to generate elementary processes. Phase 2 of SG, A is a heuristic algorithm and searches for elementary processes to be grouped into program modules according to the specified decision rules.

2.3 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

682

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). Ex- amples of the SODA Macro Simulator output are presented in Figure 7.

The manner in which the model simulates job in- teraction 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 sub- divided 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.

3. Experience With a Large "Real World" Application

The work specifically reported in this paper was done for the United States Navy Material Command Support Activity (NMCSA). The statement of requirements for a financial management system was expressed in ADS by a large accounting firm. The ADS analyzer was used to check the ADS statement of requirements for completeness, consistency, and logical accuracy.

The ADS analyzer produced information and reports that were used by the SODA Statement Analyzer. SODA was then used to generate preliminary designs of program structure and logical database structure


for the batch application part of the system, and to recommend a computer system for the entire financial management system.

3.1 Organizational Environment NMCSA financial management personnel are cur-

rently using ADS to state the requirements of a large information system. This Integrated Financial Man- agement System (IFMS) is a large-scale design and implementation effort for more effective financial management, particularly procurement accounting, within the agency. The systems design effort com- menced in May 1971, and is expected to continue for four to five years at a cost of twelve million dollars.

The purpose of the system is to centralize information flow and satisfy the information requirements of a variety of decision makers. The principal communi- cators in the system are the requiring manager or financial manager, participating manager, and procurement manager. The decision makers observe a hierarchy of authority delegation and reverse order for ac- countability.

Initial authority is received by the Comptroller of the Navy from the office of the Secretary of the Navy. In the case of a fund allocation, the Comptroller issues a program fund allocation with program values at the line item budget level. The funding then is routed through the responsible office to the administering office. Here, funding proceeds to the requiring/financial manager level where responsibility lies for execution, modification, and delivery of the system within cost and schedule objectives. At this level, monthly ap- proval is considered for interim actions. The requiring/ financial manager issues project directives which dele- gate specific authority to the participating manager level operatives. Figure 8 describes the organizational hierarchy (left) and the corresponding budget level (right).

Fund status inquiries are used to maintain fund control at the project directive line item level. Contract status inquiries are used to control delivery dates and funds for contract items.

Fund status inquiries are characterized by funded project directives and planning project directives. The planning project directive allows for procurement of long lead-time items. The funded project directive serves a shorter cycle time and therefore has a high activity level of inquiry and update.

Contract status inquiries are primarily identified with the procurement manager. Once a funded project directive is established, the information updates revolve around completion status of tasks in line with procurement. The procurement manager updates the contract status, which is observed by the participating manager and the requiring/financial manager.

The basic objective is to significantly improve the timeliness of accounting/financial management information reported by the agency's accounting system

Fig. 6. Job processing steps in SODA Macro Simulator.

Job Queue Job Input Queue

Scheduling

CM Queue

I Preempted

I

to reduce input, processing, and reporting time. This facilitates elimination of most memorandum record systems.

The first module of the system to be implemented is the Procurement Accounting and Reporting Sub- system (PARS). This subsystem is intended to nor- malize information flow concerning procurement accounting. This subsystem includes: (1) funds accounting, (2) planning documents, (3) contract accounting, (4) fiscal and program status, and (5) other items related to appropriations.

3.2 Behavioral Experience With ADS The first objective of the introduction of ADS into

any environment is gaining user acceptance. ADS represents deviation from the established practices and initial resistance to change often occurs. As a result, many questions are raised regarding ADS and its impact upon the organization.

In response to this initial user reaction, an ADS training program is advisable. However, ADS is so simple and straightforward that less than one day of intensive training is all that is necessary to adequately prepare individuals in its use. Then further training is required only to deal with the specific restrictions imposed upon the use of ADS by the ADS Analyzer

683 Communications December 1976 of ,Volume 19 the ACM Number 12

Fig. 7. Examples of SODA Macro Simulator Output.

RESOURCE

CM CTLBLK CPU C~NI CHAN2

SUP~VtRy FOB HOt't{ (14-15)

RESOURCE U~IGE/QUEUEIr~ STATISTICS

USE-TI~ USE-CT WAIT-TI~ WAtT-PbLX Q-LENCTIi QL-MAX TI~-GLN NO. WAITS AVG "-LEN

0.000 3 0.OO0 0.0O0 0 0 0.O00 0 0.00 9218.977 3 0.000 0.000 O 0 0.000 O 0.00 2106.012 ~573 1263.008 1.107 0 3 1263.608 4343 .35 1888.370 3126 908.948 2.139 0 2 908.948 980 .25 1887.526 3182 872.237 2.245 1 2 871.829 993 .24 288.842 1132 .932 .932 0 1 .932 I .00

HOURLY SU ~L~q.y

95216 LINES PRINTED TP JOBS HA~)LED 1130 AV[; RESPONSE TI~ JOBS ST.~d~TED 1132, JOBS CO,~LETED llJ2 JOB COM~I~TION KATE 1132.000 JOB5/i~.

5.02 SEC

TIME 15.0.0 15.0.2

15. 0. 5 15. 0.5 15.0.6 15.0.7 15. 0. 7

15. 0.12 15. 0.12

15. 0.17 15. 0.17

15. 0.21 15. 0.22

15. 0.30

8YSTEMLOG

MESSAGE JOB 1 COMPLETED OUTPITT 191 CHRS TIME IN SYSTEM 4 . # 6 SEC. TP JOB REQUEST.

JOB PROFILE FUND STATUS QUERIES REQUEST FROM P#~RH

ASSIGNED JOB h~ I CM OK. JOB 3 COMPLETED OUTPUT 169 Ch.~S TIME IN SYSTEM 1719.10 SEC. B-JOB 3 CO?[PLETED ~TH 4000 LINES PRINTED. TIY~ IN SYSTEM 1719.10 SEC. JOB 2 CO~LETED OUTPUT 96 CI~5 T!}~ IN SYSTZM. 7.69 SEC. JOB i COMPLETED OUTPt~ 137 C}~S TIY~ I~l SYSTEM 5.16 SEC. TP JOB REQb~ST.

JOB PROF ILE FUND C~TI~ICATION REQUEST FROM PARM

ASSIGNED JOB N~ i CH 26K. JOB I COS~LETED OUTPLq 152 CHES TIME IN SYSTEM 4.57 SEC. TP JOB REQUEST.

JOB PROFILE FUND CERTLFICATIONREQUEST FROM PROM

ASSIGNED JOB ~ i C~I 24K. JOB I COMPLETED OUTPUT. 81 CNRS TI~ IN SYSTEM 4.13 SEC. TP JOB REQUEST.

JOB PROFILE FU~) CERTIfICatION REQUEST FROM PROM

ASSIGNED JOB h~ i CM 36K. JOB I COMPLETED OUTPUT 119 CHES T~ IN SYSTEM 4.49 SEC. TF JOB REQUEST.

BAI~H JOB 5U3HITTED.

EESOURCE USAGE/QUEUEING STATISTICS

]LESOUR£E USE-TI~"~ USE-CT WAIT-TIME WAIT-MAX G-LENGTH QL-MAX TIP~-QL,N NO. WAITS AVG-Q-LEN

CM 28535.314 1 4240.243 25.071 0 $ 4240.243 706 .15 CTLBLK 77779.241 1 4784 .039 14.280 0 6 4784 .039 1148 .17 CFJ 19629.986 54978 28152.518 3.391 0 4 26152.518 28960 .91 CHANI 12.286.307 20312 2850.203 2.383 0 2 2850.203 3475 .10 CHAk~ 12218.O62 20344 2770.283 2.255 0 2 2770.283 3453 .10 MPL,XR .1837.264 7161 34.618 18.333 0 2 34,618 9 .00

SIMULATION S ~ Y

TI~Z 28800.045 SECO~:DS 754637 LINES PRINTED

TIP JOBS HANDLED 6996 AVG RESPONSE TIME 8.89 SEC BATCH JOBS cOMPLETED 11 AVG TURNAROUND 11S0.73 SEC CPU BATCH 810.40 TP 12305.12 JOBS STARTED 7163, JOBS CO~TED 7161 ,JOB COMPLETION HATE 895.124 JOBS/HE.

W O K K LOAD SUMMARY

NO. NO. JOB CPU AVG JOBS JOBS COMPLETION UTILIZATION CM/JOB

STARTED COMPLETED RATE ( S E C ) (K-SYTES)

TP 6996 6996 874.50 12305.116 25.4

12 11 1.38 810.400 32.7

INTERFACE 0 0 0.00 0.000 0.0

DEVELOP 154 154 19 .25 6468.000 89.9

STS MAINT 0 0 0.00 0.000 0.0

SHIWT I 7163 7161 595.12 19629.986 26.8

END OF RUN

AVG (SEC) PERCENT PERCENT PERCENT RESPONSE CHANNEL CPU TIME

(TUR/4AROUND) UTXLIZAT. UTILIZATION IDLE

8.89 71.34

1180.73 20.47

0.00 0.00

68.80 8.19

0.00 0.00

11.98 100.00 68.16 92


software. For example, the Analyzer restricts the length of data element names to forty characters.

The use of a form-oriented procedure such as ADS still requires a significant investment of time and effort to realize the return of a complete and consistent logical systems design. Still, a number of users with ADS experience agree that ADS has saved them considerable time during the specification of logical system design, because of the capability of the ADS Analyzer to provide feedback information to the user. The user

• should be able to do a better job of specifying his requirements, because he receives feedback much sooner in the system design cycle utilizing computer analysis of ADS. Ordinarily, in a completely manual narrative system, ambiguities and omissions in the logical system description are not discovered until physical design or even coding is well under way. By then, many aspects of the system design have been specified, so that resolu- tion of difficulties may be impossible.

Physical system design is not the responsibility of the ADS user. Completion of the ADS logical description is followed by the physical system design process that provides the specifications for programming.

3.3 Performance of ADS One physical year, consisting of 12 man-years of

effort by problem definers, was required to generate a consistent statement of requirements. Though no actual logs were kept, approximately five iterations of each form were required before the final statement Was found to be complete and consistent.

However, even though the problem statement was complete and consistent, this did not guarantee that the problem was defined correctly, i.e. the wrong requirements may have been stated properly.

Experience has demonstrated that ADS is adequate for specification of the logical system. However, an ADS description does not provide sufficient information for generation of physical system design. Data on system performance requirements was collected to supplement the ADS description in SODA Statement Language. Relevant data include specification of the frequency of occurrence of each ADS-described input and report and of the volume of each input, report, and history.

Other needed enhancements to computer-aided ADS include facilities for describing data structures and lookup tables and for decision tables expressing processing logic and input validation rules. Finally, additional software for generating report layouts and program test data would add significantly to computer aided ADS capabilities. Many of these enhancements are included in the SODA Statement Analyzer.

3.4 Program Module Grouping for the Navy Example A large number of alternative designs were evalu-

ated in determination of a hardware software configu- ration. The hardware options were manually reduced

Fig. 8. Organizational hierarchy and corresponding budget level

Apprepriat:o:t

I Subhead

I I Administering Office PI Budgqt I~,em

l I Requiring M~=ir,.'Financial Mgr (RM/FM) Major Category Code (MCC)

( I Partrci~a:mg Manager (PARM) Proiec~ Directive (PO)

t I Procurement Manager (PROM) Project D*rec:ive Line !tern (POLl)

I I I

Pr~ul-ement Work Requ~ t Request

Fig. 9. Overview of the information systems design and construction process.

I Application System (21 I Problem Statement

,,, C s 0 . . . , .....

DBMS ODL

(31

(6)

(91 Logical Svstern Design

I Progrlm DIt= I Module

Organlsation ~ Specification I

1121

(13)

Pr t~cessi~g Specification (11} and Module Structuring

i ,ol ...... CoclQ G0nerl|ion

to three CPU classes. A feasibility study revealed the importance of maintaining a high degree of compati- bility with another Navy 360/50 system, and due to interface problems the file design was constrained to IMS files. The alternatives to be evaluated were reduced to an IBM 360/50, 65 and 370/155 with a wide range of memory choices. This wide range of memory options led to the evaluation of 50 hardware configurations within the framework of the SODA Macro Simu- lator. The program designs were generated as a result of partitioning the application areas. This was done in an iterative fashion consistent with the generation of


the more than 50 alternative configurations. Software designs in general were generated.

For the information system under consideration SGA generated 62 program modules to produce the 79 ADS-specified reports. The PARS Module of IFMS for the Navy consisted of 647 processes and 791 unique data items. The size of the incidence matrix was 647 X 791 and the data element precedence matrix was 791X791.

For each program module, the module size and the number of arithmetic operations are derived from the quantity and complexity (e.g. alternative logic paths) of computations in the summary produced by SGA. Volume and size of history records input are derived from the history input summary produced by SGA. SGA performs summary analyses on all ADS-specified inputs required to produce each history item. User- provided data on input requirements was then used to derive the volume of the history item under scrutiny. The size of the history item is provided in the ADS description. Finally, twenty record groups were generated with each group containing history items that are used together in a fashion that implies logical con- nectivity. Each group of records forms the basis for defining history file structures. An overview of the program module specifications for fiscal reporting tasks is presented in Table I.

Note that process grouping into modules and history record grouping into flies were performed in a manner that spreads the workload equally among the modules to the greatest extent possible. Workload sharing is made possible by minimizing the variance in the number of computations in each module and by minimizing the variance in the number of records in each file group-

ing. The computer-aided designs "looked like" manually generated designs with respect to program structure.

The most prominent difference between manual and computer-aided generated designs is that the automated designs allow program structures to cut across functional boundaries unless constrained. This creates organizational problems with respect to maintenance and updating.

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

Table I. Batch Program Module Workload Summary.

Application/program ID

Memory Task required type Freq./month (K bytes)

Avg. Avg. record output

Lan- Medium length Record length guage File ID code (char.) volume (lines)

Fiscal reporting 1. Program budget Print 1 150

status 2. Appn. status by FY Print 1 50

and acct. 3. Report on reim- Print 1 35

bursables 4. Report on obliga- Print 1 100

tions 5. Analysis of appropri- Print 1/year 50

ations and fund June balances

6. Line item report Print 1 35

7. Summary line item Print 1 50 report

8. Procurement program Print 1 35 progress report

9. Worksheet Print 2/year 25 June, Dec.

Cobol H1 H4 Disk 861 2200 340 H5 Hll

Cobol H1 H5 Disk 243 2200 23000 Hll

Cobol H1 H4 Disk 232 225 24000

Cobol H1 H4 Disk 437 2000 1000 H5

Cobol H1 H4 Disk 476 2200 800 H5 Hll

Cobol H1 H4 Disk 232 225 24000



Cobol H1 H5 Disk 141 2000 4000


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 ob- tained, the PSA database contains sufficient information to proceed with the Logical System Design phase (3): Data Organization and Program Module Specifi- cation.

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 per- mitting considerable flexibility concerning the par- ticulars of file design. Thus, the Data Base Manage- ment 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 multidi- mensional 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 sub- schema 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 loca- tion, and blocking factor determination.

Acknowledgments. We would like to thank Robert Taylor and William O'Brian of the Navy Material Command Support Activity for their cooperation and assistance in the project. In addition we wish to thank an anonymous referee for his constructive comments.

Received October 1973; revised January 1975

References 1. Nunamaker, J. A methodology for the design and optimization of information processing systems. Proc. 1971 AFIPS SJCC, Vol. 38, AFIPS Press, Montvale, N.J., pp. 283-294; reprinted in System Analysis Techniques, J.D. Cougar and R. Knapp, Eds., Wiley, New York, 1974, pp. 359-376. 2. Nunamaker, J., and Whinston, A. A macro approach to the planning and cost allocation of computer services. Management Informatics 2, 4 (Aug. 1973), 177-189. 3. Nunamaker, J., Ho, T., Konsynski, B., and Singer, C. SODA: Systems optimization and design algorithm--an aid in the selection of computer systems and for the structure of computer program modules and data base. In Information Systems and Organizational Structure, E. Grochla and N. Szyperski, Eds., Walter de Gruyter Pub., Berlin and New York, 1975, pp. 127-150. 4. Langefors, B. Some Approaches to the Theory of Information Systems. BIT3, (1963), 229-254; reprinted in System Analysis Techniques, J.D. Cougar and R. Knapp, Eds., Wiley, New York, 1974, pp. 292-309. 5. Teichroew, D. Problem statement languages in MIS. Proc. Int. Symp. of BIFOA (Management Information Systems--A Challenge to Scientific Research), Cologne, July 1970, pp. 253-270; reprinted in System Analysis Techniques, J.D. Cougar and R. Knapp, Eds., Wiley, New York, 1974, pp. 310--327. 6. Teichroew, D. Problem statement analysis: Requirements for the problem statement analysis (PSA). In Systems Analysis Techniques, J.D. Cougar and R. Knapp, Eds., Wiley, New York, 1974, pp. 336-358. 7. Teichroew, D., Hershey, E., Bastarache, M. An introduction to PSL/PSA. ISDOS Working Paper No. 86, Dep. Indus. and and Operations Eng., U. of Michigan, Ann Arbor, Mich., March 1974. 8. Nunamaker, J., and Konsynski, B. From problem statement to automatic code generation. Systemeering 75, Studentlitteratur, Lund, Sweden, 1975, pp. 215-240. 9. Lynch, H. ADS: A technique in system documentation. Database, 1, 1 (Spring 1969), 6-18. 10. A Study Guide for Accurately Defined Systems. National Cash Register Co., Dayton, Ohio, 1968. 11. Merten, A. and Teichroew, D. The impact of problem statement languages in software evaluation. Proc. 1972 AFIPS FJCC, Vol. 41, Pt. II, AFIPS Press, Montvale, N.J., pp. 849-858. 12. ThaU, R. A manual for PSA/ADS: A machine-aided approach to analysis of ADS. ISDOS Working Paper No. 35, Dep. Indus. and Operations Eng., U. of Michigan, Ann Arbor, Mich.; Oct. 1970. 13. Herman, D.J., and Ihrer, F.C. The use of a computer to evaluate computers. Proc. 1964 AFIPS SJCC Vol. 25, AFIPS Press, Montvale, N.J., pp. 383-390. 14. The Case for CASE: Computer Aided System Evaluation. Tesdata Systems Corp., Chevy Chase, Md., 1971. 15. MacDougall, M.H. Computer system simulation: An introduction. Computing Surveys, 2, 3, (Sept. 1970), 191-210. 16. CODASYL Data Base Task Group Report. ACM, New York, April 1971.


Computer-aided analysis and design of information systemsThis approach follows the work of Langefors...

Documents

Transcript of Computer-aided analysis and design of information systemsThis approach follows the work of Langefors...