Logical construction of software

COMPUTING PRACTICES

Logical Construction of Software Donald R. Chand and Surya B. Yadav Georgia State University

1. Introduction

Although the literature on software engineering makes a clear distinction between the software design phase and the software implementation phase, where the programming activity occurs, one still sees a great deal of confusion between software design and program design. The reasons for this confusion apparently are twofold: First, since programs are the ultimate product of any software development activity, it is natural to mix the two activities; second, many system design methodologies, such as Yourdan and Constantine's structured design or Myer's Composite design techniques, perpetuate a false impression that software design is the same as program design, and that the difference, if any, is a matter of detail. Permission to copy without fee all or part o f this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title o f the publication and its date appear, and notice is given that copying is by permission o f the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee a n d / o r specific permission. Key words and phrases: software design methodology, software construction CR Categories: 3.29, 4.9 Author's address: D.R. Chand and S.B. Yadav, Department of Information Systems, Georgia State University, Atlanta, GA 30303. © 1980 ACM 0001-0782/80/1000-0546 75¢.

SUMMARY: The authors contend that it is both possible and necessary to clearly demark and explicitly define the transition between the software design and software implementation phases of the software life cycle. The output of the software design phase is defined to be a logical design of software, and the logical design can be described explicitly if the software is viewed as a system of data sets and data transforms. Logical Construction of Software (LCS) is a software design methodology that guides the designer in defining and describing these software components and their relationships. The methodology is illustrated via a practical application.

We contend that it is both possible and necessary to separate and clearly demark the software design activity from the programming activity. This view is consistent with the software design and the software implementation phases of the software development life cycle. This paper makes the transition point between the two phases explicit, but to achieve this one needs a fresh view of software itself. Software is commonly defined as a system of programs and associated documentation. This view of software is inappropriate for the software design process. We recommend that software be viewed as a system Communications of the ACM

of data sets 1 and their transforms. This view o f software is derived from the observation that programs are basically an ordered set of instructions which transform some input data sets into some output data sets. The question to be asked is: What have we gained? The prime insight gained is a fresh perspective on the parts and components of a software system. In other words, for the purpose o f software design we no longer think o f a software part as a program but instead as a data set or a data transform. 1 Throughout this paper we will use the term "data set" to refer to a group o f data elements treated as a unit. October 1980 Volume 23 Number 10

A skeptical reader may wonder whether this is merely a play on semantics. We feel that this view of software makes the goal of software design clearer and more explicit. Specifically, it suggests that the software design activity consists of identifying and defining data sets, data transforms, and their relationships. Formally defined, the Logical Construction of Software (LCS) is a software design methodology that deals with problems of identifying, defining, and describing the software system parts and their relationships in a form that facilitates the activities of the succeeding phases, namely the software implementation and software maintenance phases, and enables the designer to validate the logical design. In essence, LCS is largely a synthesis of current ideas on program design and system design. One can immediately perceive in LCS the influence of Langefor's principle of systems work [5], Warnier's ideas on program design [6], Codd's normalization schemes [2], and Yourdan's structured design concepts [8]. It should be stressed, however, that familiarity with these techniques is not essential for appreciating and understanding LCS. 2. The LCS Methodology LCS is a collection of tools, techniques, and procedures that guide and aid the software architect in identifying, defining, and describing data sets, data transforms, and their relationships in a form amenable to the detailed physical design which is necessary in the software implementation and maintenance phases. The starting point of LCS is the development of an information systems model of the software requirements which describes what the software system shall do in terms of abstract data sets and abstract data transforms. We know every model must limit detail in some respect. In the information systems model we ignore the "how" (implementation-oriented) details and substitute the functional description in place of detaft. In fact, one may view the information systems model as a functional 547

J (INPUT) DataSet

!

(OUTPUT) DataSet Fig. 1. Open Systems

Model.

description of the software requirements. The information systems model of the software is developed recursively using the open systems model. The reason for this stepwise development is that we initially do not know enough about the system requirements to specify more than its most ostensible characteristics. Modified Gane and Sarson [3] data flow diagrams are used for documenting the process of developing the information systems model. The principle of an open systems model is that only the outer boundary of the system is estimated (this corresponds to a user's defmition of desired outputs and given inputs), and all inner boundaries are deduced logically using the structure shown in Figure 1. The input-transform-output subsystems are the classical triad of systems approach. The addition of the control element is an attribute of open systems and it provides the means for validating the workability of the system at each stage of the recursive procedure. The next step is to describe the data sets and the data transforms. In LCS the data sets are described as a group of fiat fdes, which in database terminology are relations in third normal form. The motivation for this stems from the fact that one must express the structure of data sets in some canonical form to allow the intended user to specify data structures that can easily be implemented and/or modified. The data transforms, on the other hand, are deCommunications of the ACM

scribed in terms of directly implementable functions. LCS recommends the use of the bubble charts of Yourdan's structured design method to identify the set of functions that define the information transform. The stepwise process invoked yields a hierarchic relationship between functions. This hierarchic relationship, although quite useful for someone who is interested in understanding the transform, is not very helpful for implementing the transform. LCS uses Warnier's ideas on program design to postulate the structure of the transform and graft the functions at appropriate places on the corresponding Warnier structure chart. This is called the logical design of the transform. The relationships between the two kinds of software system parts, namely data sets and data transforms, give rise to three types of relationships. A type-1 relationship is the relationship between data sets and data transforms. Clearly, a type1 relationship is captured by our information systems model of the software. A type-2 relationship is the relationship between the data sets themselves. Once again, a type-2 relationship appears implicitly in the information systems model. However, the representation for it is not very useful. In LCS we recommend the use of a precedence matrix [5] to record a type-2 relationship. It enables the software architect to identify inconsistency and loops in the logical design. Finally, we defme type 3 as the relationship among data transOctober 1980 Volume 23 N u m b e r 10

COMPUTING PRACTICES

chy chart that shows the structural relationship among data transforms. The diagrams (a)-(e) form a complete description of software design at the logical level.

forms. A type-3 relationship is, again, embedded implicitly in the information systems model. The stepwise recursive development process for the information systems model provides a convenient means for extracting the type-3 relationship and presenting it in a hierarchy diagram. The purpose of presenting these relationships explicitly is to enhance the understandability and verifiability of the software. In short, a logical design of software consists of the following: - - a description of data sets as a set of relations; - - a description of data transforms as a system of directly implementable functions organized on a Warnier diagram; - - a n "input-transform-output" type relationship between data sets and data transforms described by the information systems model of the software; - - a precedence relationship among data sets; - - a hierarchical relationship among the data transforms. A compact overview of the tools, techniques, and notation of the LCS methodology appears in Figure 2. Diagram (a) represents the abstract information systems model of software. It is essentially the functional architecture of software; it shows the software as a network of data sets and data transforms. Diagram (b) is a logical description of the data transform. It uses the standard Warnier notation. A description of the data set as a collection of fiat files is given in diagram (c). The relationship between data sets is shown as a precedence matrix in diagram (d). If the entry on the intersection of a particular row and column is 1, then it means the data set on that column is precedent to the data set on that row. The value - 1 , on the other hand, indicates the data set on the row is precedent to the data set on the column. Diagram (e) is a hierar-

3. An Application of LCS XYZ company has decided to use a service bureau to generate its expense accounting reports. The input to the system are copies of checks written to pay expenses. Each check contains the following information:

548

Communications of the ACM

--check number; --date of check; --payee name; - - a m o u n t of check; --expense note (this occurs 1-20 times per check and contains the following information: expense description; accounting code consisting of product line number, cost center n u m b e r , and expense account number; expense amount).

(a) Abstract Information Systems Model

Frl

-

(b) Data Transform T4 where the letters A-H denote functions C (0, 1) + D (0, 1)

A (N)

T4

B (M)

E (1) F

(c) Data Set I6

I6F 1 (Key [, key, - - - ] , item, - - - ) I6F2 (. . . . . . . . . . . . )

I G

(1)

......

H (l)

...... ......

(1) (d) Relationship Between Data Sets

I1

I5 16

I2

13 14 I5

1 1

1

1

(e) Relationship Between Data Transforms

¢

16 17 -1 -1

Fig. 2. A Logical Description of Software Using LCS.

October 1980 Volume 23 Number 10

©

Q

XYZ management needs the followhag reports for planning and controlling its operations: (1) A weekly edit report of expense checks that lists all input data and makes the following tests: Is the expense account number valid? Is the concatenation of product line number and cost center number a valid combination? For each check, does the amount of check match the sum of all the expense amounts listed on that check? (2) A monthly report of expense accounts that contains: expense account number; expense account description; previous year-to-date amount for this expense; details of current month expenses; updated year-to-date amount. (3) A monthly report of product line expenses that contains: product

line number; product line description; cost center number; cost center description; expense account number; expense account description; previous year-to-date amount for this product line, cost center, and expense account; total of current month expenses for this product line, cost center, and expense account; updated year-to-date amount for this product line, cost center, and expense account. We shall illustrate the LCS methodology by developing a logical design of the Expense Accounting Software System (EASS). 3.1 Construction of the Information Systems Model The first step in LCS is the development of an information systems model of software requirement. The

--t

BANK I CHECKS

1

EO~MII wee,E0,e0or, ! I O° 'H xoe se ] I Account Report

3.2 Logical Description of Data Sets

Expense Report

Fig. 3. An Overview of EASS Requirements.

t-! .....

1 CHECKS BANK

I

Line ExpenseReport Fig. 4. A Detailed Description of EASS Requirements,

549


problem statement suggests the first level description of the expense accounting system requirements illustrated in Figure 3. Notice that both the transform TO and the control CO are abstract entities. All we know at this point is that TO transforms the input consisting of checks into the required three output reports and that CO is a data set which contains control information TO may need to accomplish its required task. An analysis of the requirements suggest a composition of TO in terms of T I and T2, where T I processes the data set BANK CHECKS and generates the weekly edit report and T2 produces the two monthly expense reports. The software architect may postulate an abstract data set that provides the interface between T1 and T2. This consideration leads to the description of the software system requirements as shown in Figure 4. The problem now is to describe the abstract data sets EXPENSEACCOUNTING-DATABASE, C1, C2 and to design the abstract transforms T 1 and T2. We shall illustrate the use of LCS in describing data sets.

r

The motivation for selecting a particular description for a data set is our desire to structure the information in the data set in a form that allows the transform to produce the specified output conveniently. The starting point, as in the Warnier approach, is the description of the out, put sets which are specified by the user. The software architect then postulates a logical input fde of records whose sequential processing would yield this output report. For instance, consider the expense account report. The user specified the format illustrated in Figure 5 for the expense account report. Clearly, an input file with records of the type shown will generate the expense account report. If we assume that the input file is October 1980 Volume 23 Number 10

COMPUTING PRACTICES ordered on the E A # as the key, we can express the input file as follows: Exp Acc File (EA#, EA-Descrip, Prev-YtdEA-Exp, Curr-Mth-EA-Exp, Updtd-YtdEA-Exp)

Since the data item updtd-YtdEA-Exp is immediately derivable from the two data items, Prev-YtdEA-Exp and Curr-Mth-EA-Exp, there is no need to hold the value of Updt-Ytd-EA-Exp in the input file. We can easily omit the data item Updtd-Ytd-EA-Exp and the new input file, EA-File, is sufficient to produce the expense account report:

PL-CC-EA-FILE (PL-#, CC-#, EA-#, PrevYtd-PL-CC-EA-Exp, C--~-'~7--Mt--ff,PL-CCEA-Exp)

The simplification procedure illustrated above is a direct application of Codd's normalization scheme [2]. Essentially, a relation is a flat file in the sense that no data item is repeti-

EA# [

EA-File (EA-#, EA-Descrip, Prev-Ytd-EAExp, Curr-Mth-EA-Exp)

For a complete description of the expense accounting database we need to perform the same analysis for the second output report. The structure of the product line expense report is illustrated in Figure 6. We need to first postulate an input file which would generate the specified report shown in Figure 6 while its records are processed sequentially. A little reflection will convince the reader that the following input file does produce the desired report:

EA-Desc I I

Prev-Ytd-EA-Exp I J

Curr-Mth-EA-Exp I I

Uptd-Ytd-EA-Exp i I

I

I

I

I

f

I

I

I

I

I

I

t

I

I

I

I Prev-Ytd:EA-Total Fig. 5. F o r m a t o f E x p e n s e

I

I

11

I

I

I I.

I

I

I

l

11

Uptd-Ytd-EA-Total

Curr-Mth-EA-Total

Account Report.

Prev-YtdPL-# PL-Descrip CC-# CC-Des EA-# EA-Des PL-CC-EA-Exp I

I

I

t__I

Curr-Mth Updtd-ytdPL-CC-EA-Exp ' PL-CC-EA-Exp

I

II

I I

I I

I

t

i i

I l

I I.--

l

tl

II

II,

l

L_JI

Prev-PL-CC-Totall Curr-PL-CC-Total Updtd-PL-CC-Total I

t_..J i

P I__J i

J [ I I

I I

I

I I

I

I

I

I I

l

I

I I

Prev-PL-CC-Total Curr-PL-CC-Total Updtd-PL-CC-Total I I

I

I

I

I

I I

I

I

i

I

i

i I

, ,I I II

I

11

J 1 I

I

I

II

J I

jl

I

I

I

I I

I I

I

!

il

II

I

PRODUCT (PL-#, PL-Descrip) COSTCENTER (CC-#, CC-Descrip) EXPENSEACC (EA-#, EA-Descrip)

550

Updted-ytdEA-Exp

EA-# I I

I

The remaining information in the input file can be collected together and an analysis similar to the one performed for the expense account

Curr-mthEA-Exp

Prev-YtdEA-Exp

EA+Descrpt

PL-CC-EA-FILE (PL-#, PL-Descrip, CC-#, CC-Descrip, EA-#, EA-Descrip, Prev-YtdPL-CC-EA-Exp, Curr-Mth-PL-CC-EAExp, Updtd-Ytd-PL-CC-EA-Exp)

It is interesting to note that the values of the data items PL-Descrip, CC-Descrip, and EA-Descrip are repeated each time the same value of either PL-#, CC-#, or E A - # occurs in a record. One way to eliminate the repetition of this information is to create separate files for each of these descriptions. In other words, the following three separate files avoid the duplication mentioned above:

tive. Codd studied the properties of relations and discovered update and deletion anomolies when data items in a relation are not fully functionally dependent upon the whole key or when nonkey items are derivable from other nonkey items. He developed an intuitive scheme to identify such dependencies and suggested a procedure for removing them. Codd proved that no information is lost when transforming files into a set of nondependent fiat files, which are

report suggests that the derivable data item UPdtd-Ytd-PL-CC-EAExp can be omitted. Thus, our original PL-CC-EA-FILE file reduces to a simplified form as shown below:

I I

I

I

i I

Prev-Grand-Total CuE-Grand-Total Updtd-Grand-Total I

I

I

Fig. 6. F o r m a t o f P r o d u c t L i n e E x p e n s e R e p o r t .



I

I

I

called relations in third normal form. This is the reason for representing data sets as a collection of relations in third normal form. Interested readers are referred to Chamberlin [1] for a good tutorial on relation. The above process leads to the following description of the expense accounting database: PRODUCT (PL-#, PL-Descrip) COST CENTER (CC-#, CC-descrip) EXPENSE ACC (EA-#, EA-Descrip) EA-FILE (EA-#, Prev-Ytd-EA-Exp, CurrMth-EA-Exp) PL-CC-EA-FILE (PL-#, CC-#, EA-#, PrevYtd-PL-CC-EA=Exp, Cu~-Mt---~i---PL-EAExp)

Next we look at the problem of defining the data set C 1. The description of a control data set requires an analysis of the associated input, process, and output subsystems. For C 1 weneed to analyze the input data set BANK CHECKS, the abstract transform T1, and the two output sets, namely the edit report and the expense accounting database. The user specified the format of the input data set. A logical description of the BANK CHECKS data set consists of the following relations: CHECK-FILE (check-#, check-date, payeename, check-amt) EXP-NOTE-FILE (check-#, PL-#, CC-#, EA-#, Exp-Amt, Exp-Descrip)

The editing requirements on the above relations suggest that C 1 must maintain a list of valid EA-# and a list of the valid combination of C C - # and PL-#. The simplest solution consists of using the EXPENSEACC relation and an operation on PRODUCT and COSTCENTER

relations which selects the valid combinations.

3.3 Logical Design of Data Transforms To complete the software design we need to design and describe the data transforms. It should be emphasized that the description of the data transforms must be in a form which facilitates the eventual programming and implementation of them. In LCS we define a data transform in terms of a set of single objective functions that are directly implementable. We shall illustrate this LCS methodology by applying it to the abstract transform TI. The first stage in the design of a data transform is to identify and def'me the set of function (Fi) that perform the processing for T1. At this stage we know the input and output of T1. Therefore, the basic procedure for identifying the functions {Fi} is to model the flow of input transactions until it merges into another abstract data transform and thus loses its identitY or else becomes an output. We need a tool for recording this modeling process. LCS recommends the use of bubble charts popularized by the structured design methodology of Yourdan and Constantine [8]. The bubble chart, sometimes referred to as data flow graph, is a tool for depicting the logical flow of data through a system (or program). The bubble chart evolved from charting paper flow in manual processes and the product development flow in manufacturing appli-

Fig. 7. Steady State Description o f the Transform T1.

551


cations. The bubble, represented by a circle, contains a narrative description of the function that makes this model of the abstract transform meaningful. The model may be developed in a stepwise refmement manner but, at each step, one models the steady state behavior of the system. As a result, the model is not cluttered with programming type housekeeping details. Figure 7 contains a steady state description of T 1, obtained by modeling the flow of two kinds of input records, namely check data and EXP-NOTE data. The steady state description provides the means to identify the components of T 1. That is, the design of T 1 requires the design of the following five functions: Fl F2 F3 Fa F~

: : : : :

GET NEXT INPUT RECORD; EDIT E A # AND CC/PL#; EDIT TOTALS; OUTPUT ERROR MESSAGE; OUTPUT RECORD TO TEMP FILE;

and one transform P E R F O R M UPDATE. The PERFORM UPDATE transform may be refined as a set of functions using the same process. The functions needed are: F6 : GET NEXT TEMP FILE RECORD; F7 : UPDATE EA-FILE; Fs : UPDATE PL-CC-EA-FILE.

The steady state description is a means of deriving the functions and should not be viewed as a logical description of T1. The logical description is necessary for developing the programs needed for implementing TI. LCS uses Warnier's approach for deriving the logical structure of the transform T l" and the logical design is completed by attaching the functions to the logical structure. The Warnier chart was developed by J.D. Warnier and his colleagues at Honeywell-Bull as a means of viewing and recording both the structure of programs and the structure of input and output files. It is essentially a very precise hierarchy chart positioned on its side, where each level of hierarchy is composed of one or more of the following three structures: October 1980 Volume 23 Number 10

COMPUTING PRACTICES 1. Sequence

(

ology upon the maintenance phase of the software life cycle. Since LCS generates only the logical design of software, it is almost mandatory to discuss the effect upon the logical description as the software undergoes modification and enhancement. We assert that the LCS methodology

makes enhancement easier and more convenient. We shall illustrate this by requiring that one more monthly report be included in the expense accounting system after the system has been designed. Specifically, management needs a cost center expense report that contains:

[(l) 2. Selection

A (0, 1) CHECK-DATA

B

(o, l) 3. Repetition

IA

! (N)

EXP-DESCRIP

(1) BANK CHECKS

CHECK (0-)

(1)

EXP-NOTE (1--)

EXP-ACC-CODE

EA-#

(1)

(1) Fig. 8. Structure of Input Data Set (Bank Checks).

BANK CHECKS Transform

BEGIN Transform {

BEGIN CHECK {

PROCESS CHECK

PROCESS EXP-NOTE {

END Transform {

END CHECK {

Fig. 9. The Transform Structure to Process BANK CHECKS.

BEGIN T1 { F~ : Get next input record (Check type);

Transform Process Check Until End-of-File T1

BEGIN CHECK

I Initialize Total;

PROCESSING

t FI : Get next input record (Exp-Note;)

PROCESS EXP-NOTE Until New Check Or End-of-File

END CHECK PROCESSING

F2 : Edit EA# ( valid {F5 and CC/PL# I invalid {F4 FI : Get next input record Invalid {F4

F3 Edit Total { Valid {Perform Update

END T1 Fig. 10. A Complete Logical Description of the Transform T1.

552

(1)

(1)

CHECK-AMT

3.4 Maintenance of Logically Constructed Software

Empirical studies of large-scale software development and maintenance indicate that the effort and cost of software maintenance is two or more times that of software development. Therefore, it is necessary to evaluate and assess the effect of any new software development method-

CC-#

(l) EXP-AMT

where the quantity in parentheses below the objects A and B indicates the number of times that object occurs, and @ is the symbol for an exclusive or logical operator. The Warnier method is described in further detail in [7]. One begins by describing the structure of the input file, using the Warnier diagram as shown in Figure 8. The next step is to derive the transform structure by introducing B E G I N / E N D brackets as illustrated in Figure 9. To complete the logical design we need to attach the functions {Fi} identified earlier to the logic chart and fill in the necessary housekeeping details. A complete logical description of T 1 appears in Figure 10. One must validate that the functions appear at the appropriate positions by comparing this structure to the structure of the output report. The method described in Figure 10 will lead to the description of T2 contained in Figures 11-13.

PL-#

Transtbrm .~ Generate Monthly Expense T21 ( Account Report Transform T2 Transform J Generate Monthly Product T22 [ Line Expense Report Fig. 11. Description of T2 in Terms of Subttansforms T21 and T22.



- - c o s t center n u m b e r and description; - - e x p e n s e account n u m b e r and description; - - p r e v i o u s year-to-date a m o u n t for this cost center and expense account; - - t o t a l o f current m o n t h expenses for this cost center and expense account; - - u p d a t e d year-to-date a m o u n t for this cost center and expense account.

Begin

t Initialize Prev, Curr & Updtd TOTAL(S);

!

Get first input record BEGIN RECORD PROCESSING

Transform T21

Process EA-File until End-of-File

COMPUTE Updtd-Ytd-EA-Exp; OUTPUT Line record; UPDATE Prev, Curr & Updtd TOTAL(S); END RECORD PROCESSING { GET next input record

END

{ OUTPUT Prev, Curr & Updtd TOTAL(S) Line

Fig. 12. Description of the Transform T21.

A n analysis o f the existing expense accounting system suggests that the new requirement o f the m o n t h l y report on cost center expenses m a y be grafted in the information systems model as shown in Figure 14. The m a n n e r in which we added the new requirement directly affects the expense accounting database. In other words, this enhancement requires that the expense accounting database be modified in a way that allows the abstract transform Tnew to conveniently generate the cost center expense report. W e shall use the techniques discussed earlier to postulate the structure o f the input file that would produce the desired report on a sequential reading o f input records. T h e structures o f the m o n t h l y report on cost center

eKpenses, o f the input file to generate this report, and o f the input file appear in Figures 15-17. This leads to the following new description o f the expense accounthag data set. EXPENSEACC (EA-#, EA-Descrip) COSTCENTER (CC-#, CC-Descrip) PRODUCT (PL-#, PL-Descrip) EA-File (EA-#, Prev-ytd-EA-Exp, Curr-MthEA-Exp) CC-EA-File (CC-#, EA-#, Prev-ytd-CC-EAExp, Curr-Mth-CC-EA-Exp) PL-CC-EA-FIle (PL-#, CC-#, EA-#, Prevytd-PL-CC-EA-Exp; C'~-rr-M t----if2--PL-CCEA-Exp) T h e existence o f a new relation in the expense accounting data set re-

quires a modification o f the U P D A T E transform so that this relation is maintained each time the input is processed. T o complete the enhancement one needs to describe T . . . . W e have chosen not to deal with the p r o b l e m o f structure clash here. It occurs due to the timing difference between the processing o f T1 and T2. One trivial solution is to place the update transform in T2 instead o f in T1. 4.

Summary

Initialize Prev-Grand,Curr-Grand, Updtd-GrandTotals; BEGIN

GET first input record; 1

BEGIN / InitializePrev-PL,Curr-PL,Updtd-PLTotals; Initialize Prev-PL-CC,Curr-PL-CC,Updtd-PL-CC BEGIN Totals; BEGIN

Transform T22

ProcessPL-Exp ProcessPL-CC-EA-File UntilPL-# changes Until EOF or EOF

COMPUTEUpdtd-Ytd-PL-CC-EA-Exp; ProcessCC-Exp until CC-# changes OUTPUTLine record; or PL-# changes or EOF UPDATEPrev-PL-CC,Curr-PL-CC, Updtd-PL-CCTotals; END { GET next input record;

t OUTPUTPrev-PL-CC,Curr-PL-CC,Updtd-PL-CC END ~ Totals Line; | OUTPUTPrev-PL,Curr-PL,Updtd-PLTotals Line; f

END END

{ OUTPUTPrey-Grand,Curt-Grand, Updtd-GrandTotals;

Fig. 13. Description of the Transform T22.

553


and Conclusions

L C S is a m e t h o d o l o g y that aids the software architect in developing a logical design o f the software, start-


COMPUTING

BANK CHECKS,

PRACTICES

D ing from the broad user's input/ output requirements. The output of this activity is a description of software in terms of information sets and an information transform. The form in which these information sets and transforms are created and presented makes the software implementation and maintenance process straightforward and relatively mechanical. LCS is composed of a variety of current ideas on system and program design. Although the notation and ideas used here have existed for the past several years, no attempt has been made to synthesize these program and system design concepts in a unified methodology. In our opinion, the organization of software viewed as a system of data sets and data transforms, as opposed to the classical view of software as a system of programs, appears to be the key point of LCS. This view immediately pinpoints the strength and limitation of the existing program and system design techniques. The logical design of software has technical as well as managerial implications. The ability to describe explicitly the output of the software design phase provides management with another important control mechanism and, in fact, management can require that implementation activity not begin until the logical design is complete and certified by the users and implementors. The authors have developed a formal documentation tool for the logical design and description of software. References

1. Chamberlin, D.D. Relational data base management system Comptng. Surveys 8, 1 (March 1976), 43-66. A good tutorial on the essential concepts of the relational data model, normalization, relational languages, and advantages and implementations of relational systems. 2. Codd, E.F. A relational model of data for large shared data banks. Comm. A C M 13, 6 (June 1970), 377-387. A classic paper on the relational model of data. 554

I

L I

I Expense Accounting Database

II

Account Report

I

Line Expense Report

Center Expense Report

Fig. 14. Enhancement

to the S y s t e m .

CC-#

C-Des

EA-#

EA-Des

Pre-ytdCC-EA-Exp

Curr-MthCC-EA-Exp

Updtd-ytd CC-EA-Exp

It

I

t

J

I

l

I

l

i

t

I

t

l

i

,J

I

I

i

I

i

, I

I

, ,,I

I

,|

t

I

i

I

I

I

I

I.

I

I

I

I

Prev-CC-Total

Curr-CC-Total

Uptd-CC-Total

t

I

I

I

I

,.,l

I

I

I

I

I,.

I

~

I

L_.--J

1

1

I

I

1

I

I

I

I

I •

I

I

I

I

'

I

,J

1

I,

Fig. 15. Format

( CC-#

I

of Cost Center Expense

!

I

I

I

., I

Report.

( CC-Descrip EA-# EA-Descrip

Prev-ytd CC-EA-Exp

Curr-MthCC-EA-Exp

Updtd-ytd CC-EA-Exp

CC-EA-File (CC-#, CC-Descrip, EA-#, EA-Descrip, Prev-ytd-CC-EA-Exp, Curr-Mth-CC-EAExp, Updtd-y-~-CC-EA-Exp) Fig. 16. S t r u c t u r e o f I n p u t File to G e n e r a t e

t h e R e p o r t o f Fig. 15.

COSTCENTER (CC-#, CC-Descrip) EXPENSEACC (EA-#, EA-Descrip) CC-EA-FILE (C-~-2~,EA-#, Prev-ytd-CC-EA-Exp, Curr-Mth-CCEA-Exp) Fig. 17.

I n p u t File as a S e t o f N o r m a l i z e d

Relations.

[



Gane, C., and Sarson, T. Structured Systems Analysis: Tools and Techniques. IST, Inc.,

3.

N.Y., 1977. Describes a structured approach to the design of logical models of commercial data processing applications. This approach uses logical data flow diagrams to show the sources and destination of data, data stores, and functions. Decision trees are used to describe "external" business logic of functions. The contents of each data store (fde) are defreed in a data dictionary. 4. Jensen, R.W., and Tonics, C.C. Software Engineering. Prentice-Hall, Englewood Cliffs, N.J., 1979. This textbook represents the culmination of many studies delving into the nature and methods of software development. Coverage includes project management, software design, structured programming, verifi-

555

cation and validation, legal and security aspects of software development. It is a good book on software engineering. Langefors, B. Theoretical Analysis of Information Systems. Auerback Publishers, Inc., Philadelphia, Pa. 1973. This is an excellent book on the analysis of information systems. It emphasizes the system approach for information systems analysis. Langefors concentrates on information structure and data and their relations associated with the information. He discusses systems algebra and makes extensive and comprehensive use of a precedence matrix to analyze relations among information sets. 5.

Orr discusses the use of the Warnier approach for systems development. 7. Warnier, J.D. Logical Construction of Programs. Van Nostrand Reinhold, N.Y., 1974. This book describes a technique to construct programs based on the inherent structure of input data. The Warnier technique is very useful for capturing various kinds of structures inherent in input and output files. 8. Yourdon, E., and Constantine, L.L. Struc-

tured Design: Fundamentals of a Discipline of Computer Program and System Design..Your-

6. Orr, K.T. Structured Systems Development. Yourdon Press, N.Y., 1977. Basically,

don Press, N.Y., 1978. This book describes a set of proposed general program design considerations and techniques for making coding, debugging, and modification easier, faster, and less expensive by reducing complexity.

