WIXLIB

SOFJNRRE LIFE CYCLEll 0UIR KEnTSII ,.J .I: Sft CIFICATIOHSI ,.fONT. - CODIHii JlHDDUUiiliiHii.PRELIUHJliYDESIIiHIDETrtiLEDDESI&H t-.,.TESTIHii anD UJlLIDRTIOH,.Of'ERATIOHS MDIIAIHTEnftHC .,.REVALIDATIONFig. 1.2Software Life Cycle6! ! ! !

DESIGNSPECIFICATIONSREQUIREMENTSCOOINGMODULE TESFig. 1.3Effort Required on Various SoftwareDevelopment Activities (Except SoftwareMaintenance (from: Principles of SoftwareEngineering and Design, M.A.Zelkowitz, A.C.Shaw, J. D. Gannon, Prentice-Hall, Inc.,1979)7

Contrary to beliefs, the time requirement for the coding anddebugging is only 20% of the overall effort (See Fig. 1.3).Anequal amount of time is spent on the development of the"specifications and requirements" of the software module.Justthe design of the software requires 15% of the total effort.Before the inception of any coding effort one should spend aboutone third of the allocated time and funding.The percentages given herein are to illustrate the extensiveplanning required prior to the coding of any software.Actuallysimilar rules of thumb exist for the idealization of data designprior to database-related activities, and/or conceptualization ofa problem prior to the use of a canned package. This presupposesthat the user is sufficiently familiar with the subject matter.One of the worst practices by engineering managers, especially atthe middle-management level, has been to direct the engineers tostart "getting computer results" without any initial planning."Saving" the first 20%-30% of the effort does not reduce the total cost of the project.In the coding, testing and implementation phases major stumbling blocks are usually encountered. Thisrequires a double take, and requires the repetition of previousefforts.1.3 TOP-DOWN PROGRAMMINGIf the "top-down programming" concept is literally applied, theprogram execution will be a sequential one, starting with thefirst executable statements until the "STOP" or "RETURN'' is encountered.Exception to this rule is the DO-loops.A programlike this will not require any "statement numbers," since thecontrol of the execution will not be "controlled."Even thoughsuch compilers exist, they are rarely favored by engineers. Actually, most FORTRAN-77 compilers contain extensive enhancementsto ANSI FORTRAN77 provisions.Thus, most compilers permit movement to an earlier statement in the program, even though it violates the spirit of the "top-down" practice.In programming everr effort should be put forth to makethe progra. top-dow.o, so long as this does not result inan absurd code.1.4 MODULAR PROGRAMMINGA program module is defined as a logically,self-contained unit ofa program with specific entry and specific exit points, and isaimed to accomplish a predefined mission. Each subroutine can beconsidered a module, so long as its mission is to perform onetask.Inspection of Fig. 1.4 shows that a part of the program can beisolated as a module, like the IF-THEN-ELSE block. Without knowing the contents of the blocks for the .TRUE. and .FALSE.8

,branches of the logical IF-check,sub-modules would not be proper.POSSIBLE DECOMPOSITION :further suggestions forotherIF-THEN-ELSE BLOCK ---- 7Fig. 1.4Decomposition/Isolation of a ProgramModule1.4.1 Rules for ModularizationOnce the basic module concept is understood, then the bestguideline for the establishment of modules and modular design iscommon sense.The following list gives additional guidelines tobe noted for modular software design:1) Decompose the program into independent, discrete modules.2) Structure sprogramtomodulereflectwiththethedesignfollowinga) The module is closed.b) The module has one unique entry point and one uniqueexit point.9

c) The module representsfunction.onelogical,self-contained1.5 STRUCTURED PROGRAMSThestructuredprograms essentially follow the "top-down"concepts; preferably not too rigidly for the sake of the programmers sanity in transition from FORTRAN66 to FORTRAN77.Ideallythese programs do not have any GOTO statements, thereby eliminating the statement labels,i.e. statement numbers. Conversely, aprogram without GOTO statements, which violates the long list ofrequirements described in this chapter, would not be a structuredprogram.1.5.1 Basic Building BlocksStrictly speaking,the structured program will consist of thebuilding blocks described in Fig. 1.5. So far there has not beena clear cut definition of the terminology for these blocks.Theproper terminology for the second block should be "decision."The third block could possibly be labeled as a "DO-loop" as well.Limited deviation from these blocks, depending upon the optionsand capabilities of a given compiler, may rarely result in theimprovement of efficiency of the program, and may also make itmore understandable.Any deviation should not violate the portability of the software; the consequences of which are presentedin this document.Proper composition of the basic building blocks is shown in Fig.1.6.If each basic building block can be considered as thelowest form of a module,proper composition of the blocks shouldlead to an acceptable format.Improper use of the modules can beseen in Fig.1.7.In the first case there are two entry pointsto the segment.From the description of the modular construction,it is known that there should be only one entry and oneexit.The second case is improper because of multiple exits.The third case is improper because of the improper entry to themodule.In the top-down approach,it is recommended to enter atthe top,and exit at the bottom. The fourth case looks improperbecause of the relative complexity of the flowchart.This moduleshould be decomposed into two modules.,1.6 PROPERTIES OF A WELL-STRUCTURED PROGRAM1. The program is divided into a set of modules arranged ina hierarchy defining their logical andexecution-timerelationships.2.The execution flow from module to module is restricted10

BASIC BUILDING BLOCKS OF STRUCTURED PROGRAMMING1. SEQUENCE I. .2. SELECTIONTRUEFALSE3.ITERATIONTRUEFALSEFig. 1.5Basic "Building Blocks" of StructuredPrograrruning11

PROPER PROGRAM SEGMENTSFig. 1.6Integration of Basic Building Blocks(Modular Construction)12

PROPER PROGRAM SEGMENTS (CONT.) Fig. 1.6 (Cont.) Integration of Basic Building Blocks(Modular Construction)It1PROPER PROGRAM SEGMENTS TWO ENTRY POINTS TO THE "MODULE 11)Fig. 1.7 Improper "Integration" of Basic Building Blocks13

IMPROPER PROGRAM SEGMENTS0CTWO EXIT POINTS FROt1 THE MODULE.)IMPROPER PROGRAM SEGMENTSC11MIDPOINT 11 ENTRY TO THE MODULE.)Fig. 1.7 (Cont.) Improper "Integration" of Basic BuildingBlocks14

IMPROPER PROGRAM SEGMENTS(SHOULD BE DECOMPOSED TO T O MODULES.) !)Fig. 1.7 (Cont.) Improper "Integration of Basic BuildingBlocksto a simple, easily understood scheme in which control mustenter the module at its entry point, must leave the modulefrom its exit point, and must always be passed back to theinvoking module.3.Module construction is standardized according to traditional modularization rules, and legal program control constructs are restricted concatenation, selection, repetition,and a "well-behaved" br nch.4.Each program variable serves only one program purpose,and the scope of a variable (i.e. the set of modules inwhich the variable is accessed) is apparent and limited.5.Error processing follows normal control flow except inthe case of unrecoverable errors where normal processingcannot continue.15

6.Documentation is required in the source code to introduce each module by explaining its function,its datarequirements, and its invocation relationship to othermodules in the program.1.7 STRUCTURED PROGRAMMING CODING STANDARDS1.The program is divided into independent pieces calledmodules.2.A module is a self-contained unit whose code is physically and logically separate from the code of any othermodule in the program.a) A module represents one unique logical program function.b) The size of a module should not exceed 100tions.instruc-c) A module is bounded by one entry point and one exitpoint.During the execution, the program control canenter a module only at its entry point and can leavethe module only from its exit point.3.Modules are related to one another in a hierarchicalcontrol structure. Each level in the control structure represents a more detailed functiona description of what theprogram does. It also dictates the transfer of program control from module to module during execution.Level-l (top of the hierarchy) contains one and only oneprogram module. Logically, this module represents the overall program structure and contains the "mainline" code forthe program.Program execution always begins with thismodule.Level-2 contains modules that are performed to execute theoverall program function. The modules at level-2 can be executed only by transferring control to them from the mainline module.Execution cannot cause control to "fall" intoa module.Level-3 modules represent functions required to furtherdefine the functions at level-2.Control is transferred tolevel-3 modules only from level-2 modules. This scheme continues from level to level down the entire hierarchicalstructure.Program control is always transferred from a module at onelevel to a module.at the next successively lower level (e.g.16

from level-3 to level-4). When a module completes executingits code, control is always returned to the module that"called" it.No loops are allowed in the control structure.This meansthat a module cannot call itself, nor can it call any modulethat has called it.4. Each module should begin with a comment block explainingthe function that the module performs, the values passed tothe module, the values returned,the modules that calledthis module, and the modules that this module calls.5. Comments embedded in the module code should be separatedfrom instructions by one blank line.6.All comments should be meaningful (e.g. a meaningfulcomment does not state that this is an add instruction).7.Avoid unnecessary labels; do not use labels as comments.8.All variable and module names should be meaningful.Module names should suggest the logical function they perform (e.g.INVERT) and variable names should suggest theirpurpose in the program (e.g. SHEAR or V).9. Names of variables that belong to the same table or thatare local (i.e. used only in one module) should begin withthe same prefix.(Editorial comments: This rule is highlydesirable,idealistic, but quite impractical.May clashwith #8 above!!!)10. The only allowable control constructs are concatenatio ,selection, repetition, and branch.(Editorial comment:This rule, as it is worded,is too rigid and clashes withthe current programming practice of the professionals.)11. At most, one instruction is coded on a line.If an instruction requires more than one line, successive lines areindented.12.IF-statements should not be nested more than threelevels.(Editorial comment: This rule could be consideredas a target goal. For some cases it is impractical!!!)13.The scope of a GOTO statement (branch instruction)should be limited to the module in which it occurs.Thismeans that the GOTO should not be used to transfer controlfrom one module to another; it is used only to branch to theentry point or the exit point off the module in which it occurs.17

14.NONSTANDARD LANGUAGE FEATURES SHOULD NOT BE USED AS(This is a cardinal rule of programming.)GENERAL RULE.15 OBSCURE (TRICK) CODE SHOULD BE AVOIDED.18A

2. SOFTWAREDEBUGGINGThe debugging,or "reprogramming(!)," of any given software hasnegative connotations to the uninitiated, however,this activityis carried out almost perpetually if the "computing environment"is not static.For example, if a given software is not fully independent of the operating system,the change in the operatingsystem require the recompilation of the program.Even thoughthe program might have been executing satisfactorily prior tothis change in operating system, after the change the program mayor may not give the correct answers.If the program had beencoded robustly and followed all the guidelines discussed in CE309, then at worst only a recompilation would have been required.However, since most "completed" programs are far from beingideal, prior to the recompilation modifications are usuallyneeded.The changes in the program that need to be undertakencan be labeled as "debugging" under the new environment.If a program which was executing fully satisfactorily in a givencomputer configuration has to be moved to another computer system,then changes to make the program run again may be inevitable.If the program was fully portable (an extremelyelusive goal to attain) than the source code should not requireany modifications prior to recompilation in the new environment.Sometimes changes in the hardware and software environment necessitate changes in the program.If,for example, a program wasmaking use of the plotting devices,an upgrading of the plottingdevice may require substantial changes in the parts of theprogram using the plotting devices.Numerous possible permutations on the compiler, operating system, peripheral devices, etc.may lead to the need to "debug" the program.The ''status" of the program may require differentdebugging:approachesin(a)You may have been "given," or more likely "leased,"only the "load module" of the program. You may not have anyaccess in any form or fashion to the 'source code.Underthese circumstances,you need to contact the "softwarevendor" for a new load module that will execute under thenew computing environment.This action may require "funds"for the transaction,in addition to the regular monthly orannual outlays. Extensive testing (?) of the new version ofthe program is supposed to have been completed by thesoftware vendor.However,select testing of the new loadmodule of the program by the principal users is in order.19

The cost of these tests would be borne by the users.(Example: ANSYS in the Civil Engineering Department'sLaboratory, NASTRAN at LUCC.)CAB-(b)Access to the source code may be restricted.Eventhough you may be the major user of the package you may nothave permission to have access to the source code, even tothe listing of the source code.Changes to the source codemay be undertaken by the "systems programmers," who may betotally unfamiliar with the "subject area" to which theprogram is applicable.In a situation like this, when theneed for the change to the source code is made and if theprogram has recompiled,you need to test the new versionwith as many "case studies" as possible.The cost of thesetests should be borne by the systems group and/or thedevelopers.If the software developers are not contractually required to make the changes,then the changes maynot be implemented up until the first "opportune period(?)."(Example: Programs FLMXPK, SAP4CNK, SPLT, and ADINA atLUCC.)(c)If you have full access to the source code, and if youare responsible for the maintenance of the software, thechanges in the code will have to be undertaken by you.Atthe completion of the reprogramming activity, extensivetests need to be conducted by you to confirm the reliabilityof the results. The cost of these tests may be borne by thecomputer center only if the computer system change is substantial and during the interim period you are "invited" totest the new configuration. This is a short duration windowof opportunity, and the tests can be conducted only atselect times and select dates. Other than this possibility,the cost of the tests is usually borne by the softwaredeveloper.2.1 COMPILATION AND EXECUTION .ERRORSIn order to initiate any debugging you have to have access to thesource code.If this is not the case, the only realistic actionyou can take is to inform the software vendor/developer of theexecution error you have encountered, and seek assistance.If you have access to the source code and f you have to initiatedebugging operations,the following paragraphs should be noted,and implemented.2.1.1 Compilation Errors:In debugging during the compilation all fatal errors must beeliminated.Various compilers generate informative messages fornon-fatal errors.A non-fatal error correspondstoan"operation," statement, usage, etc., that is not fully acceptable20

tothe compiler,and results in the compiler making an"assumption" in the interpretation of the "code.''Even thoughmost non-fatal errors may not have any detrimental effect on theresults of your program, all non-fatal errors should be expungedthrough rewriting the source code, and recompiling the program.After the successful compilation of the program with linkage, andwithor without execution,the following checks must beperformed:(a)"Maps" of each module must be carefully examined.Thereasons for "unused" variables must be determined.Thiscould be due to "clerical errors," e.g. typing IO instead ofIU.Should that be the case,the likelihood of executionerror arises.All unused and undefined variables must betaken care of.(b) Any error messages emanating from "linker" and "loader"must be checked. Corrective actions must be taken toeliminate these messages in the subsequent submissions.At the completion of the above activities the program is ready tobe executed. However,this does not indicate whether the sourcecode is correct or not.2.1.2 Execution Errors:Debugging of the program if execution errors are encountered canbe trivial, or as in most cases, extremely painful.To isolatethe execution errors a logical approach, as itemized later inthis document, can and should be employed.The most qualifiedindividuals to identify the source of the execution errors a

The first part of the CE 309: Computer Programming lecture notes covers the salient FORTRAN77 statements, their proper use in structured programming environment, and the interpretation of frequently used civil engineering formulae, specifications, and analysi