370 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOl,. BE-I, No.4, DECEMBER 1975

added, although the effects of them may be altered byadding more deltas. At various times, S. F. Coppage,S. T. Feczko, and A. L. Glasser worked with the authoron the design and coding of enhancements to the IBM 370implementation. The idea of the Programmer's Workbenchcame mostly from E. L. Ivie, and a dozen or so peoplehave worked on various p,arts of it; the author was re­sponsible only for the SCCS component.

[7] N. Wirth, "A programming language for the 360 computers,i'J. Ass. Comput. Mach., vol. 15, pp. 37-74, Jan. 1968.

(8) Information Management System Virtual Storage (IMS/VS)General Information Manual, IBM, Form GH2Q-1260.

[9] BICSll00 System Information Manual, Univac, Form NA8300.[10] H. M. Brown, "Presentation on Clear," Software Engineering

Techniques, (Proc. of con£. sponsored by NATO Sci. Com­mittee) Apr. 1970 (available from Scientific Affairs Division,NATO, Brussels, Belgium).

REFERENCES[1] D. M. Ritchie and K. Thompson, "The UNIX time-shaHng

system," Commun. Ass. Comput.Mach., vol. 17, pp. 365-375,July 1974.

[2] OS/VS Linkage Editor and Loader, IBM, Form GC26-3813.[3] L. P. Deutsch and B. W. Lampson, "An online editor," Com­

mun. Ass. Comput. Mach., vol. 10, pp. 793-799, 803, Dec. 1967.[4] R. E. Griswold, J. F. Poage, and I. P. Polonsky, The SNOBO'L.t,

Programming Language, 2nd ed. Englewood Cliffs, N. J.:Prentice-Hall, 1971.

[5] R. B. K. Dewar, SPITBOL Manual, Version 2.0, Illinois Inst.of Technol., Chicago, Ill., Feb. 1971.

[6] W. A. Wulf, D. B. Russell, and A. N. Habermann, "BLISS: Alanguage for systems programming," Commun. Ass. Comput.Mach., vol. 14, pp. 780-790, Dec. 1971.

Marc J. Rochkind was born in Baltimore,Md., on June 12, 1948. He received theB.S.M.E. degree from the University ofMaryland, College Park, and the M.S.M.E.degree from Rutgers University, New Bruns­wick, N.J., in 1970 and 1972, respectively.

Since 1970 he. has been a member of theTechnical Staff at Bell Laboratories, MurrayHill, N.J. He is currently engaged in thedevelopment of software systems for useby Bell Telephone companies.

Program Design by ·a Multidisciplinary Team

SUSAN VOIGT

Abstract-The use of software engineering aids in the designof a structural finite-element analysis computer program for theCDC STAR-IOO computer is described. Since members of the de­

.sign team came from diverse backgrounds, both the unique featuresof the CDC STAR computer and structural analysis concepts andcomputing requirements had to be understood before design began.

Nested functional diagrams to aid in communication among teammembers were used, and a standardized specification format todescribe modules designed by various members was adopted. Thisis a report of work in progress where use of the functional diagramsprovided continuity and helped resolve some of the problems arisingin this long-running part-time project. '

Index Terms-Modularity, program design, program specifica­tions, software engineering, structural finite-element analysis,top-down design. .

INTRODUCTION

GENERALLY, a computer program begins as an ideain the head of a potential user. The user enlists the

aid of a software analyst to help design a program, and a

Manuscript received August 5, 1975:The author is with NASA Langley Research Center, Hampton,

Va. 23665.

program development project is born. Over the years,experienced programmers and analysts have developedtechniques which are useful in designing programs. Forexample, a flow chart is one way of diagrammi~ thesequence of operations to be performed in a program.Flow charts are a convenient way for assembly languagepr<;>grammers to gain insight into program logic. Since theadvent of higher level languages, flow charts are no longeressential to sequence the logical steps of a program. Forexample, experienced programmers think in Fortran and,consequently, can write a program directly without firstdiagramming the logic with a flow chart. Flow charts,therefore, often have become an "after the fact" means ofdocumentation and have ceased to be an aid to program de­sign. In many cases, functional flow charts describing thegeneral logic flow in a program are developed as part of aprogram's documentation after implementation of theprogram.

For most large program developments, more than oneprogram designer is involved, more than one user must besatisfied, and usually other programmers implementthe design. In large program developments program

VOIGT: PROGRAM DESIGN 371

where, typically, the vector of unkowns x represents dis­placements at the nodal points, the vector P representsthe forces or loads applied at nodal points, andK, com-

'Tate (40 ns). Sparse vectors are handled by the hardwarein such a way that only nonzero values are stored, ac­companied by an auxiliary bit vector. This bit vector usesones to indicate the locations of the nonzero values in anexpanded sparse vector.

The STAR word size is 64 bits, with an option to usehalf words. The virtual memory on STAR is based ontwo page sizes: a small page of 512 full words and a largepage of 65536 full words (or 128 small pages). For com­putation, data must reside in central memory, which isnominally a half-million words (524288) with the capabIl­ity to expand to twice that size. The transfer of data tocentral memory is done in blocks of small or large pages.Since the data transfer time is considerably slower thancomputation time, several computations are desirable perdata item to balance central processing unit (CPU) withinput/output times. This fact and the vector processingcapabilities are overriding considerations in the designand development of new algorithms for the STAR-1oocomputer [6].

THE FINITE-ELEMENT METHOD

The analysis of complex structures is an area that hasmade extensive use of large computers. Structural problemsare generally solved by generating a mathematical and acorresponding numerical model of the physical structureto be analyzed. The numerical model yields a large matrixto be solved or manipulated. Many matrix computationscan be treated as a series of· vector computations, sinceeven matrices are sets of vectors. Hence, the STAR vectorcapability appears very appropriate for structural analysisproblems. In addition, the magnitude of these problemstaxes both the memory and computation speed of currentcomputers, so more sophisticated analyses can be per­formed only with advances in computing capability.

It was decided to develop a pilot program designed spe­cifically for theSTAR-1oo to perform structural analysis.The development of such a program was intriguing,~ot

only to structural engineers and computer scientists,but also to numerical analysts interested in new algorithmsfor vector computers. The problem selected for STARapplication was the linear static analysis of a structuremodeled with finite elements.

In the finite-element method a structure is modeled as afinite collection of elements which are connected at pre­selected nodal points. Each element has specific physicaland geometric properties. The individual element descrip­tions, along with the element connectivities and boundary(or support) conditions, describe the structure. A linearstatic analysis determines displacements of a structuredue to static external forces. Mathematically, the keypart of this analysis is expressed in the following matrixequation:

designers need :to communicate with other designers,programmers, and users; hence, ad hoc design and codingare not feasible and a more forIlial approach to programdesign must be established. The design team must be or­ganized and its mode of communication must be defined.In general, no formal discipline or guidelines have existedfor program design, so each,project has been simply or­ganized to the best of the project leader's ability.

Recently, attempts have been made to collect designand development techniques into a formal discipline calledsoftware engineering [1]-[4]. Many of the principles be­ing labeled and taught have actually been appliedhygood programmers for years, but having these techniquesformalized is a great aid in coordinating efforts, in codifyingfragmented approaches of the past, and in providingless experienced programmers with guidelines for goodprogram design and development.

This paper discusses the currrent application of somedesign techniques inspired by recent developments insoftware engineering. The planned acquisition of a uniquenew computer, the Control Data STAR-lOO, providedan opportunity to apply these techniques to the design ofa finite-elementprogram for' structural analysis withalgorithms specifically tailored to the STAR capabilities.Interest in this program development activity was wide­spread, from the design of a new finite-element system forstructural analysis to the development of numericalalgorithms for a pipeline processor, and included a chanceto practice some of the principles of software engineering.Subsequent sections describe the circumstances surround­ing this program design activity and the software develop­ment aids and procedures used.

ELEMENTS OF THE PROBLEM

To understand the motivation for applying softwareengineering techniques, the' environment in which thisprogram design was undertaken is described. The com­puter is new and relatively untried, new algorithms infinite-element analysis are involved, and the nature ofthe team of designers introduces problems.

THE COMPUTER

Features of the STAR-lOO, which are of particulnrnote for scientific computing, inclu<;le vector and sparsevector pipeline processing capability and virtual memory[5]. The central processor contains two pipelines forfloating point arithmetic which allow very efficient per­formance of vector instructions involving one operationon a long sequence.of operands. Each arithmetic unitdoes this by segmenting computation into a sequence of

,basic operations (such as exponent comparison, coefficient"alignment, add, and normalize shift). These basic opera­tions can be performed simultaneously on different pairsof operands. A complete operation requires a pair of dataelements to stream through the' entire pipeline (e.g.,eight segments). However, if many successive pairs ofdata elements require the same operation, these canstream through the pipeline as vectors at the minor cycle

Kx =P, (1)

372

monly called the global stiffness matrix, represents thephysical properties of the structure based upon the indi­vidual elemental properties occurring at each nodal point.Stiffness properties of the individual elements are expressedin matrix form with typical matrices ranging in order from6 to 50 or more. These elemental stiffness matrices areassembled into the large sPitrse matrix K which may be ofthe order of 10 000. A basic reference for the finite-elementmethod in structural engineering is reference [7].

The specialpipeline capabilities of the STAR-100 apeearto be particularly well suited to the computation of 'theglobal stiffness matrices, and the solution to (1) [8]. Thevirtual memory aspect of the STAR-100 can be bestutilized by a modularly designed program. Such a modulardesign also is consid,ered essential to facilitate analysis ofvery large structures through substructuring techniques(partitioning), to extend the capabilities to more complexstructural problems such as nonlinear analysis, and tooptimize structural designs.

THE DESIGN TEAM

Once the general goal of designing a finite-elementsystem for the STAR-100 had been established, an ad ho,cteam representing several disciplines was organized tostudy the STAR-100 computer features, to determine howthese features could be exploited in solving structuralanalysis problems, and to define some interim goals. Theproject was designated Finite-Element System for Star(FESS). The approach was to take a fresh look at thefinite-element method for solving structures problems andto identify areas in the solution process where specialfeatures of the STAR would be useful. This requiredseveral areas of expertise: knowledge of the STAR com­puter capabilities and software, structural analysis,numerical techniques, and software design. The ad hocteam included specialists from each of these areas, butthere were several inherent problems.

Although everyone spoke English, the first major prob­lem was communication among the disciplinary specialists.Sessions were held on finite-element'methods, the develop­ment and definition of finite-element models, concepts ofstructured programming, modularity, good programmingtechniques, and algorithms formulated for the STARvector capabilities. Also, progress reports on the STARsystem development and features in STAR Fortran (whichwas selected as the target language) were received anddiscussed.

The second major problem was the part-time nature ofthe activity. Unlike the typical program design projectwhich involves intensive, concentrated effort, all themembers of the ad hoc team had other primary responsi­bilities, came from a variety of functional organizations,and could work on FESS only when time was available.This 'low commitment caused delays and breaks in thecontinuity of the FESS development.

The third problem was the lack of a detailed definitionof a specific problem to be solved, complicated by the

IEEE TRANSACTIONR ON SOFTWARE ENGINEERING, DECEMBER 1975

varying interests of team members. The problem defini­tion tended to evolve as the team tried to bound theproblem in line with grmving knowledge of special featuresof STAR software.

SOFTWARE ENGINEERING APPROACH

This project provided an excellent opportunity toexercise some software engineering techniques, and theinherent problems with the design team provided themotivation to do so. Most FESS team members were notfamiliar with software engineering, so techniques wereadopted gradually. At first, a top-down analysis of theproblem to be solved was undertaken using nested func­tional diagrams described below. As the top-level view ofthe finite-element program to be developed was formu­lated, three major areas of concern were identified: solu­tion to large sparse linear systems, formation of the smallmatrices representing characteristics of the individualelements in the structural model, and data manipulation,especially the assembly of information from the individualelemental matrices into the large, sparse global stiffnessmatrix. The FESS team was divided into subgrQups tolook more carefully into these three areas. The subgroupsworked indE;lpendently and met together about twice amonth to, share findings. To provide for coordination be­tween the subgroups, standards were adopted. Theseincluded a format for specifying the implementation de­tails of functional modules and the interfaces to other partsof the FESS program. These are also described below.

NESTED FUNCTIONAL DIAGRAMS

The standard technique adopted by the FESS projectteam for presenting functional actiVities in the softwaredesign is based on "nested functional diagrams." Eachdiagram presents a breakdown of an activity or functioninto several subfunctions which, in turn, might be furtherdetailed in other diagrams. The nested breakdown ofactivities permits a top-down view of a program ~esign

with each activity presented in a bounded context. Asimple illustration of the concept of these nested functionaldiagrams is shown in Fig. 1. The function GO TO WORK canbe broken into three steps: GET UP, HAVE BREAKFAST,

and DRIVE TO WORK. Each of these can be further sub­divided. Two more levels of detail are shown in Fig. 2for part of the function GET UP. These might be subdividedeven further.

A computer program design can be approached in thesame nested functional manner, by considering eachfunction in its bounded context and breaking it into sub­functions. Each diagram is restricted to one page and nomore than eight functional boxes. In this way, each pagerepresents a function and its primary subfunctions, andfurther investigation either up or down in the functionalhierarchy means reference to other pages of functionaldiagrams. The graphic nature of these diagrams providesa visual presentation of a few distinct activities in abounded context which can be readily grasped.

VOIGT: PROGRAM DESIGN 373

6.1

SOLVE .

KBB .• XB = PB

NAME IBY IDATE MARCH 5. 1975W, POOLE

PURPOSE. INOTESSOLUTION Of STRUCTURE EQUATIONS 6

INPUTS KBB, KBI, KBICI, KBIRC, IOUTPUTS'KII. NB. NI. l'J. PI XB. XI

Fig. 5. Nested functional diagram of box 6.

LOOP ON SUBSTRUCTURES

Fig. 4. Nested functional diagram of box 3.

Fig. 3. Top-hivel nested functional diagram for FESS.

even though different individuals would be deveiopingthem. The standard format also made it .easier for ~ewb~r13of the FESS group to exchange and reVlew module speClfi­tions written by others. The specification format chosen isillu13trated in Fig. 7.

The purpose of .the implementation specifications isto provide a formai descriptiori of each module beforecoding is started. This document . together with nestedfUnctional diagrams replaces a detailed flow chart and isto be used by the programmer in writing the code. Thespecification provides detailed information including:parameters which interface with other modules, descrip­tion of data structures, a prose outline of the programusing structured .programming constructs [12J, anddiscussions of perforinance, test plans, and alternativemethods which were considered. An actual implementationspecificatIon deveiopedfor the solution technique usedin the FESS project is given in the Appendix to indicateuse of the format and to explain some of the items byexample.

Experience in using these implementation specifIcations

GET UP H-· HAVE H DRIVE TO IBREAKfAST. WORKL..-__

Fig. 2. Nested detail for function GET UP.

Fig. 1. GO TO WORK functional diagram.

TURN Off DO

ALARM EXERCISES

The format of these diagrams was inspired by SofTech's"structured analysis" [9J; Dijkstra's levels of abstraction­[IOJ; and Liskov's approach to achieving good modularity[ll} Nested diagrams were chosen rather than functionalflow charts because of the ability to limit the context ofany activity and to expand in a top-down manner to anylevel of detail. This 'allowed a top-level view of the FESSprogram (see Fig. 3), with the assignment of subfunctiondetailing to the appropriate subgroups of the ad hoc team.

To illustrate the actual use of these diagrams iri theFESS project, the function shown in box 3 of Fig. 3 wasexpanded into subfunctions,as shown in Fig. 4. The assem­bly process of the global stiffness matrix, the K in (1),is viewed as composed of five basic subfunctions. Anotheractual diagram, drawn by a different individual, is shownin Fig. 5. This is an expansion of box 6 of the top-levelnested functional diagram Fig. 3. To go one step furtherdown the hierarchy of the function, Fig. 6 illustrates thesteps in the matrix equation solution process. .

The,format chosen for the nested functional· diagramsincludes other information in addition of the functionalactivity boxes. This auxiliary information helps to definethe interfaces to other parts of the software design. Thename of the function, its designer, and its purposei arebriefly stated. Names of program variables required asinput and those which are' output from the functiondiagrammed on the page are included. Cross referenee tothe parent diagram is allowed bY' the numbering systemon the boxes. Notes related to particular design decisionscan be made so the reasons for choosirig the particuiardesign approach are kept together with the chosen design.Comments also Can be included relating to testingl1fidperformance evaluation.

IMPLEMENTATION SPECIFICATIONS

When several .levels of detail had been defined withthe nested functional diagrams and program modules had

. been identified, each subgroup developed implementationspecifications for the modules within its purview. Astandard format was adopted for the specifications so allimportant information would be given for all the modules,

374 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, DECEMBER 1975

NAME IBY IDATE MARCH 5, 1975W. POOLEPURP05E INOTES lI, DI, FROM 4.1.1

SOLVE FOR XI, 6.2 Yl, Y1 CAN USE SAME STORAGEINPUTS DI, KBI, KBICI, KBIRC, lI, IOUTPUTS

NB, NI, PI,XB XI

Fig. 6. Nested functional diagram of function 6.2.

NAME OF ROUTI NEBRIEF DESCRIPTIONFORMAL SPECIFICATION

PARAMETERSRELATIONS BETWEEN PARAMETERSSI DE EFFECTSLABELED COMMON VARIABLES

ASSERTIONS AT ENTRYASSERTIONS AT EXITKEY INTERNAL DATA. STRUCTURESEXTERNAL DATA STRUCTURES. REFERENCEDTOP-LEVEl STRUCTURED PROGRAMAlTERNATIVE METHODS CONSIDEREDCRITICAL PERFORMANCE AREASPERFORMANCE TRADE-OFFS CONS IDEREDPLAN FOR TESTI NGERROR HANDLINGPROCEDURES CALLED

Fig. 7. Format for FESS implementation speQifications.

is still limited.. The expected information will provide thespecifications and most of the precoding documentationfor the program. The specifications will also be used as thebasis for independent testing.

OTHER STANDARDS

Another aid to improved communication is a glossaryof program variables. Selected names for all the "global"program variables :were established so that all the FESSsubgroups would be consistent in references to parameterswhich crossed between major functions. Each subgroupwas free to select local names for all those variableswhich were not parameters interfacing to modules de­signed by other subgroups. The "global" variable nameswere used in the implementation specifications and inthe input and output boxes of the nested functionaldiagrams.

Fortran coding conventions were established, includingguidelines for coding format, comments, and programingconstructs. The implementation plans call for coding ofsome of the modules by contractor personnel and initialtesting of the Fortran modules on aCDC 6600 at LangleyResearch Center prior to the availability of the STAR-lOO.Special STAR Fortran statements will be simulated in theCDC 6600 version of the program, and results from themodule and integration tests on the CDC 6600 will beused for checking the STAR version.

Two references which have been particularly usefulin preparing for the coding phase of FESS are McCrackenand Weinberg's discussion on writing readable Fortranprograms [13J, and Kernighan and Plauger's article onprogramming style [14].

DISCUSSION

After almost 2 years, theFESS development is stillunderway. The survivability of this minimum effortproject is duein large part to the use of nested functionaldiagrarris and the continuing interest of the FESS teammembers. Initially, a top-level functional diagram wasdrawn and used in the education process of theFESSteam members. In a subsequent breakdown of the func­tions, three major areas of concern were identified and theFESS team divided into three subgroups to further studythese areas. The glossary was established when the sub­groups began, to develop their nested functional diagramsand implementation specifications. Experience in writingimplementation specifications is still limited alidl ascoding begins, improvements :will probably be ma~e to thecontent and level of detail until a statisfactory specifica­tion level is reached. At the present time, about half of theprogram modules have been diagrammed and specified.

Despite limited experience, some conclusions can bedrawn ab<;mt the utility of these software design aids. Thenested functional diagrams have served to document theactivities to be included in the program and have helpedto bridge the interdisciplinary communication gap amongthe FESS team members. The glossary and the imple­mentation specifications also have helped to improvecommunication on the project and provided the basisfor questions and discussiOIis at team meetings.

The part-time nature of the FESS project has hinderedprogress, but the software engineering techniques havebeen helpful in providing continuity over the protractedperiod. These techniques were also useful in clarifying theproblem to be solved and in bounding the first version of

VOIGT: PROGRAM DESIGN

the program so a basic capability can be developed todemonstrate the potential of a finite-element program onthe STAR-IOO.

. .It has been difficult for some experienced programmersto adapt to this approach to designing and specifying aprogram. Part of the difficulty apparently lies in a lack ofunderstanding of the purpo~e of these software designtools. The nested diagrams are intended to express, in afunction,al way, the approach to be used in solving thegiven problem. The implementation specifications detailthe actual techniques to be used in developing the pro­gram to solve the problem. The specifications should besufficiently complete so that the programmer can writecode (ina higher level language such as Fortran) directlyfrom tht'J specifications.

A shortcoming encountered in .using the specificationsto date has been difficulty in describing the programmodule functions in prose in the section called Top-LevelStructured Program. This probably is due to the Fortran ~

orientation of the individuals involved. As a temporarymeasure, flow charts and even sections of Fortran code maybe used to detail procedures and iterations which seemdifficult to express in other ways. As more experience isgained in working with these techniques and with struc­tured programming constructs, it is hoped that the flowcharts will not be needed.

CONCLUDING REMARKS

This paper describes the use of nested functional dia­grams and a format for implementation specifications inthe design of a Finite-Element System for the STAR-1oocomputer (FESS). A multidisciplinary team of individualsfrom different organizations working part time with ratherlow commitment is implementing this system. This ar­rangement presents many 'problems, and the recent em­phasis in the literature on software engineering techniquesprovided inspiration for applying such techniques to thisunique situation. Nested functional diagrams and imple­mentation specifications adopted as software design aidsin the FESS project have helped to overcome many of theinherent problems of such a loosely organized program de­sign activity. Actual examples taken from the FESSactivity illustrate the use of both the nested functionaldiagrams and the specifications format. The assessment isincomplete, but the experience to date indicates that suchaids have helped the success of this programing venture.Although the orientation of this activity has been towardthe STAR-100, these software design techniques could beuseful in many large design projects.

APPENDIX

SAMPLE FESS IMPLEMENTATIONSPECIFICATION

The following implementation specification was devel­oped by the FESSsubgroup concerned with the solution

375

to large sparse linear systems. This specification cor­responds to the nested fuilctional diagram shown in Fig. 5.

IMPLEMENTATION SPECIFICATIONS

, Name of Routine: SOLSEQ (DI, IBKII, KBB, KBI, KBICI,

KBffiC, KII, NB, NI, KBB, PB, PI).' .

Brief Description: This subroutine solves the uppertriangular block system:

[Kii Kbi

T] [Xi] [~i] .

Symm Jibb Xb PbThe corresponding FESS nested functiona~ diagram is 6.0.

Formal Specifications

Parameters

NameInputj

Definition Type Dimension Output

DI Inverse of the diag- R NI Ional factor of K ii.

mKII (Semi) bandwidth of I 1 IK ii.

KBB Lower triangular R

~NB X NB I

p_art of reducedKbb, by rows.

KBI Values of nonzero R Problem Ientries of Kbi, by dependentrows.

KBICI Kbicolumn index I Same as KBI Ifor each entry inKBI.

KBIRC Number of nonzeros I NB Iin each row of K bi.

~ IBKII X NIKII Lower triangular R Ifactor of K ii, byrows.

NB Number of boundary I 1 Inodes.

NI Number of interior I 1 Inodes.

PB Reduced load vec- R NB IjO(Xb)tor, Pb, for bound-ary nodes.

PI Load vector for R NI I(~i)interior nodes.

Side EffectsPI is overwritten by Xi.PB is overwritten by Xb.KBB is overwritten by Lb.

Assertions at Entry

1) NI, NB >1; 0 ~ IBKII < NI; KBICI ~ 0; KBffiC ~ O.2) K bb is. symmetric and positive definite. .3) KII contains the banded lower triangular factor of

K ii and is stored so that L i (J,L) is in KII (J,IBKII + 1 ­(J - L)).

4) KBB is the reduced lower triangular part of Kbb and isstored so that Kbb (J,L) isin KBB (J * (J :- 1)/2 + L).

5) The nonzero values of K bi are stored by rows in thearray KBI. The column index of the jth element of KBI isstored in KBICI (J). The number of nonzeros in the jthrow of K bi is stored in KBffiC (J).

376

6) DI contains the Inverse of the diagonal factor ofK ii = LJ);LiT.

.Assertions at Exit

.The system has been solved with X i stored in PI andX b stored in PB.

Key Internal Data Structures ,

DANDY is a temporary of length max (NB, NI) used inNFD 6.1 and 6.2.

External Data Structures (See Parameters)

Top-Level Structured Program

Call subroutine DENFCT to perform factorization K bb =Lb * D b* LbT with Db-l stored in DANDy.

Cail subroutine LDSLV to solve L~ = PB with resultstored in PH.

Compute Db-l * PB with result stored in PB.

'Call subroutine UDSLV to solve LbTX = PB with resul.tstored in PB.

Call subroutine SMXVC to compute KbiT *PB with resultstored in DANDY.

, Subtract DANDY from PI with result stored in PI.

CaU subroutine LBSLV to solve L iX = PI with resultstored in PI. '

Compute Di-l *PI with result stored in PI.

Call subroutine UBSLV to solve LiTX = PI with resultstored in PI.

Alternative Methods Considered

Storage of K ii and K bb by columns of the lower half wasconsidered. See specification for subroutines BNDFCT andDENFCT for details. .

Critical Performance Area

It is expected that the majority of the time required forthe program will be spent in subroutine DENFCT.

Subroutine SMXVC consists almost entirely of scalar code.

Plan for Testing

Include a matrix which is not positive definite.

Error Handling

1) Check that all elements of Db > O.2) It is assumed that all matrices are of the correct

dimension for meaningful operations ~nd that this ischecked in a higher level routine.

IEEE TRANSAm'IONS'ON SOFTWARE ENGINEERING, DECEMBER 1975

Procedures Called

DENFCT, LDSLV, SMXVC , UDSLV.

REFERENCES[1) B. Randall, " Toward a methodology for C0il!puter system de­

sign," in Conf. Ree. Software Engineering, Conf. NATO Sci.Committee, Garmish, GerPlany, Oct. 1968, pp. 204-208.

(2) E. W. Dijkstra, "The humble programmer," Commun. Ass.Comput. Mach., vol. 15, pp. 859-866, Oct. 1972.

[3) F. L. Bauer, "Software and ·software engineering," SIAM. Rev., vol. 15, pp. 469-480, Apr. 1973. .

[4] J. P. Benson, "Structured programming techniques," in IEEE, Symp. Comput. Software Reliability, 1973,pp. 143-147.

[5) Control Data STAR-l00 Computer Features Manual, ControlData Corporation Publ. 60418100, Oct. 1973.

(6) J. C. Knight, W. G. Poole, Jr., and R. Voigt, "System balance. analysis for vector computers," to be presented at Ass. Comput.

Mach. Nat. Conf., Oct. 1975.[7) O. C. Zienkiewicz, The Finite Element Method in Engineering

Science, 2nd ed. New York: McGraw-Hill, 1971.[8) A. K. Noor and R. E. Fulton, "Impact of CDC STAR-loo

computer on finite element· system!!,." J. Struct. Di,v. (Proc.Amer. Soc. Civil Eng.), vol. 101, pp. 731-750; Apr. 1975.

[9) " How to increase programmer productivity through softwareengineering using 'PL/ l ," SofTech, Inc., Waltham, Mass.,Course Notes, Nov. 1973. '

_ [10) E. W. Dijkstra, "The structure of the "THE" multiprogram­ming system," Coinmun. A ss. Comput. Mach., vol. 11, no. 5,EP. 341.:..356, 1968.

[11] B. H. Liskov, "A design methodology for reliable softwaresystems," in 1972 Fall Joint Comput. Conf., AFIPS Conf.Proc., vol. 41. Montvale, N. J.: AFIPS Press,1972, pp.191-199.

[12] J. Donaldson, "Structured programming," Datamation, vol. 19,pp. 52-54, Dec. 1973.

(13) D. McCracken and G. Weinberg, "How to write a readableFORTRAN progr!\lll," Datamation, vol. 18, pp. 73-77, Oct.1972.

(14) B. W, Kernighan and P. J . Plauger, "Programming style:Examples and counterexamples," Ass. Comput. Mach. Comput.Surveys, vol. 6, pp. 303-319, Dec. 1974.

Susan Voigt received degrees from AmericanUniversity, Washington, D,C., and PurdueUniversity, Lafayette, Ind,

She has worked at the Naval Ship Re­search and Development Center, where ,erexperience ranged from applications programdesign and development to operating systemmaintenance and enhancement. She is thelead software·person in the IPAD Develop­ment Section, . NASA Langley Research

. , Center, Hampton, Va. Her interest in soft-ware engineering is motivated primarily by the IPAD system, aNASA. sponsored computer-aided design and information manage­ment system for the aerospace industry. As a software consultimt tostructural engineerS, she has also participated in designing softwarefor the CDC STAR-IOO, expected at the Langley Research Center inlate 1975. " . '