ADA EVALUATION PROJECT

THE IMPACT OF THE ADA LANGUAGE

ON SOFTWARE TESTING "'i r C

: ,oMRWlO9cID

Prepared for

" HEADQUARTERS UNITED STATES AIR FORCEN Assistant Chief of Staff of Systems for Command, Control,

Communications, and ComputersTechnology & Security Division

U )

Prepared byStandard Automated Remote to AUTODIN Host (SARAH) Branch

COMMAND AND CONTROL SYSTEMS OFFICE (CCSO)Tinker Air Force Base

Oklahoma City, OK 73145 -6340Commercial (405) 734-2457

AUTOVON 864 - 2467/5152

10 JUNE 1988

90 02 28 009

Ada Evaluation Report Series 1y CCS0

Ada Training March 13, 1986

Design Issues lay 21, 1986

Security May 23, 1986

Micro Compilers December 9, 1986

Ada Environments December 9, 1986

Transportability March 19, 1987

Runtime Execution March 27, 1987

Modifiability April 29, 1987

Testing June 10, 1988

Module Reuse June 20, 1988

Project Management Summer 88

Summary Fall 88

Accesjon TOr

NTIS CRA&IOTIC TAIBUllalolvr".d

JoJstD IDt,,

STATEMENT "A" per Capt. AddisonTinker AFB, OK rI*,SC/XPTA By&._. _TELBCON 2/28/90 CG Oisjibulori i

AvwIlt-it ' Codcs

Avjt inj IorDimS,:C,-

fdk

THIS REPORT IS THE NINTH OF A SERIES WHICH DOCUMENT THE

LESSONS LEARNED IN THE USE OF ADA IN A COMMUNICATIOESENVIRONMENT.

ABSTRACT

')Testing on the Standard Automated Remote to AUTODINHost (SARAH) project was a continuous process. Developmenttesting provided a stabilizing environment for the

project. The early design interfaces were done in the

implementation code (Ada), developing confidence in both

the language and software engineering techniques it

supports. The Ada environment had the right tools to

allow incremental building. The packaging conceptprovided a continuous testing platform ensuring

functional isolation, verification of data integrity, and

an immediate decrease in the opportunity for the

introduction of errors. This supported the principles of

modularity, high cohesion, and low coupling. Sharedpackages of tools made the subsystem developers more

productive. Generics were used to reduce redundancy inthe development of code. Our greatest testing problems

occurred because of the tasking environment. The

library management system and the vendor developed debug

tools proved to be essential in development testing and

integration. Testing of software is not affected as

significantly by the language used as it is by the

engineering appl'ed during the design and development ofthe system./ .1j,).

\I

FOREWORD

The ideas expressed here are the thoughts and concernsrendered by tho actual staff that participated in thedevelopment of the SARAH project from its inceptionthrough the final acceptance test. These ideas andconcepts are the result of the oxperiences and reflect theattitudes at the completion of the project. The actualimplementation of the SARAH system does not necessarilyreflect the best of the ideas presented in this paper.The first project using the Ada language and itsassociated environment and software engineeringtechniques, as most experts advise, should not beexpected to, and does not, make proper use of all thebenefits available. That development staff consisted ofboth experienced programmer/analysts and inexperiencedprogrammers from varying backgrounds in computer s ftwaredevelopment.

TABLE OF CONTENTS

1. INTRODUCTION ............... o- .1.1 THE ADA EVALUATION TASK'.......1.2o PURPOSE ... o..... . . . . . . . . . . . . . . . . . . .

2. SOFTWARE DEVELOPMENT ENVIRONMENT .... .................... 1

2.1o EARLY EXPERIENCES ............ ................... I2.2. A CONTINUOUS PROCESS ..... o .... .... ........ 00....2

3. DESIGN LEVEL SPECIFICATIONS .............. ............ .. 23.1. TH -E ARLY DEVELOPMENT PHASE ...........o.............. 23.2. ADVANTAGES OBSERVED ............ o.......... ....... 33.3. ADVANTAGES OF DESIGN METHOD......................... .33.4. OTHER ADVANTAGES OF ADA ................. 0 ......... o

4. PACKAGING ........................... 000....**.... 34.1. PACKAGING COICEPT.................. ....... 34.2. ADVANTAGES OF PACKAGES ........... 0.00 0............ 4

4.2.10 Modularity .. ... ........ . ...... ....... 44.2.2. High Cohesion ......... .0.... ............. 44.2.3. Low Coupling ... . .................... 4

4.3. CREATING TOOL PACKAGES(SETS).......................... 44.40 UTILIZATION OF TOOL PACKAGES .......................... 5

4.4.1. ANALYST COMMENTS ON PACKAGING .... o............ 54.5. SEPARATE COMPILATIONS.0.0.. ............. 000. 0 0... 00.6

4.5.1. ANALYST COMMENTS ON COMPILER DIAGNOSTICS ....... 6

5. USE OF GENERICS ........................................... 65 . STABILITY OF CODE .... o... . ..................... 65.2. REDUCTION OF COMPLEX CODEo ....................... ... 75.3. EASE OF CORRECTION AND IMPROVEMENT .................... 7

6. USE OF TASKING ............................................ 8:..TASKING WAS DIFFICULT ..........................00..... 8

6.2. ANALYST COMMENTS ON THE USE OF TASKING ............... 8

7. THE ADA PROGRAMMING SUPPORT ENVIRONRENT(APSE) ..... 00 o.87.1. ADA LIBRARY MANAGEMENT SYSTEM ..... o...............o...8

7.1.1. AUTOMATIC LIBRARY FUNCTIONS .................... 87.1.2. DISADVANTAGES IN THE LIBRARY SYSTEM ............ 97.1.3. ANALYST COMMENTS O ADA LIBRARY MANAGEMENT .... 9

7.2. ADA CODE EXECUTION TEST TOOLS......................... 97.2.1. WHEN TO USE TEST TOOLS......................... 97.2.2. ALSYS ADAPROBE ....... o.............. o7.2.3. TEST HARNESSES ........................... .107.2.4. ANALYST COMMENTS ON THE PROBE DEBUG TOOL ...... 1o

8. LESSONS LEARNED .... ........................ .. . ..... 10

9. SUMMARY ................ o........**..... . .. . .. . ...... ... 11

1. INTRODUCTION

1.1. THE ADA EVALUATION TASK

This paper is one in a series which seeks to help potential Adadevelopers gain practical insight into what is required tosuccessfully develop Ada software. With this goal in mind, AirStaff tasked the Command and Control Systems Office (CCSO) toevaluate the Ada language while developing real-timecommunications software. The task involves writing papers onvarious aspects of Ada development such as training, Ada design,environments and security issues.

CCSO chose the Standard Automated Remote to AUTODIN (AutomaticDigital Network) Host (SARAH) project as the vehicle basis forthe Ada evaluation. SARAH is a small to medium size p roject(approximately 50,000 lines of executable source code) whichwill function as a standard intelligent terminal for AUTODINusers and will be used to help eliminate punched cards andpaper tape as a transmit/receive medium. The developmentenvironment for SARAH consists of a number cf IBM ?CATs and Zenith Z-248 microcomputers. Source code isdeveloped, compiled, and integrated on these machines. Thecompiler and symbolic debugger used are from Alsys, inc. TheSARAH software runs on the IBM PC ATs, Zenith Z-248s, andZenith Z-200 (TEMPEST microcomputer which is basicallycompatible with the PC ATs and Z-248s).

1.2. PURPOSE

The purpose of this paper is to examine the methods used to testan Ada software product. It addresses the advantages anddisadvantages of testing techniques used and makesrecommendations that may help future efforts take more effectiveadvantage of the Ada language and its associated developmentenvironment. It is to provide a forum for CCSO to share knowledgeabout testing in the Ada software development environment.

2. SOFTWARE DEVELOPNENT ENVIRONRENT

2.1. EARLY EXPERIENCESWorking with the Ada language was a traumatic experience early inthe project. The learning curve was difficult. The staff triedto use the development environment to get maximum advantage ofits capabilities. Experience, however, has shown that at best,many mistakes were made in this first project in Ada. Despite thelack of experience, the effort was successful in creating arelatively good product.

Software engineering methods and standards were establishedduring system development. The purpose was to improve aspects ofthe system in the area of modifiability, efficiency, reliability,and understandability. The design method used is described inthe CCSO Design Issues Ada paper dated May 21, 1987. Itsatisfied the requirements for modifiability throughout thedesign. The need for efficiency was not pressed as much becausewe were constantly behind schedule and efficient code was notgiven priority. Reliability was accomplished by havingadditional efforts applied during the initial development of apackage. Specifically, this was aimed at circumventing failureof the software due to a poor concept of operation, to anincomplete design, or to poor architectural structure. The issueof the understandability goal was handled by developing a set ofcoding, designing and commenting standards. These softwareengineering practices were evolved as the development progressed-- 3ome in a very formal manner and others by experience. Thecunulative effect of these efforts was positive on this project.They will be better defined as we gain experience to help evenmore in future projects.

2.2. A CONTINUOUS PROCESSTesting is a continuous process. Testing became an ongoingautomatic process done through various support programs availablein the Ada environment for the development team throughout thedesign and development process. It ensured the integrity of thebasic parts of the system. Ada was used to develop compilablespecifications. This provided the initial testing at the basicdesign level. The use of software engineering techniques andthe Ada environment that enforced strong typing standards helpedeliminate system level problems. These steps forced theprogrammers and analysts to recognize the effect of theirdecisions very early in the project, and continuously as itwas developed. Corrections were made much earlier and at muchless cost to the project. As a result, the stability of theproduct was greatly improved. This early enforcement ofstandards provided a positive step in the improvement ofthe software development environment. The final phase of thetesting process was the comprehensive tests done by anindependent test group using a suite of tests designed toensure compliance with requirements.

3. DESIGN LEVEL SPECIFICATIONS

3.1. THE EARL! DEVELOPMENT PHASEThe development process identified eleven (11) majorsubsystems in the SARAH design. The subsystem interfaces wereimplemented in code shortly after they were defined. This provedto be a great advantage. Those interfaces were then tested(verified by the compiler) immediately, allowing anopportunity to re-design and re-code when there was only a littlecode to be changed to implement a "now" design.

2

3.2. ADVANTAGES OBSERVEDThis was where confidence began to grow in the language and thesoftware engineering techniques it supports. These early stepswere the beginning of the continuous software testing process wewere to later recognize as one of the most beneficial aspects ofthe language and its environment. This beneficial effect occurredthroughout the development of the SARAH project.

3.3. ADVANTAGES OF DESIGN RETHODSince the resulting design was already in the implementationlanguage there was no chance for design errors to be introducedwhen the design was implemented into code.

3-4. OTHER ADVANTAGES OF ADAThe Ada environment had the right tools to allow incrementalbuilding of the system. It is easy to put in selected stubs, andselected segments of "real" code. This allowed the "analyzea little, design a little, implement a little, Pnd test alittle" approach (a more technical description might be"iterative development at increasingly lower levels ofabstraction"). This ability to develop and compile and testan incomplete system for proper operation was vital in thedevelopment testing. Problems uorrected at these higherlevels of abstraction proved much easier to fix becausedependent subordinate code did not exist. Also, the thoroughcompiler and strong typing characteristics found a lot of errorsbefore the code could be run.

4. PACKAGING

4.1. PACKAGING CONCEPTThis provided a forum for testing that ensured functionalisolation, verification of data integrity, and animmediate decrease in the opportunity for the introduction oferrors. The high level subsystem designs were each developed inAda packages. Subsequent decomposition of the SARAH systeminto subordinate packages and procedures re-enforced theseadvantages, each level providing the same advantages ofverification of interface and data type that was available forthe design level development work. The packaging concept thuspermeates the system allowing the total segregation ofsubsystems and associated data structures.

The SARAH project made use of this concept. However, majorcoupling problems were built into the implementation. The systemhas some good modularity but it has plenty of room forimprovement. Many of the current problems were caused by lack oftime for proper design in the latter stages of the project. The

3

packaging techniques used need improvements. These areas arecurrently being studied to improve this situation within thesystem.

4.2. ADVANTAGES OF PACKAGESThe communication package was developed using a stubbedsubprogram environment. This allowed the testing of the upperlevel design without having to worry with the operation of thedetailed low level programs that were hardware dependent. Thisstubbed version later became a formal version for trainingpurposes. The simulated communication package allows practicalhands-on operation of the system with responses as it would bein an actual operations environment.

Packaging in the Ada environment aids in the testing of theresultant system because it supports the principles ofmodularity, high cohesion- and low coupling. (It does notenforce these principles.)

4.2.1. ModularityThe system is partitioned into smaller understandable units.Understandable partitioning results in easieridentification of the guilty units when a bug is uncovered.

4.2.2. High CohesionMost of the data needed for a module is contained within themodule. This results in easier to fix modules since, ideally,changes will be limited to the one module to be fixed. As anexample take a bug occurring in the read routine of disk. Sincemost pertinent data is defined inside the routine, correctionsare required only inside that one routine. This one "Adaseparate module" could then be recompiled and rebound withouthaving to change any other code within the system.

4.2.3. Low CouplingThis is the corollary to high cohesion. Inter-moduledependencies are minimized. Accomplishment of this goal isdefinitely aided by the existence of package specificationsmaking package interfaces explicitly defined and enforced. Thisis a boon to the system integration phase. Many integrationerrors are uncovered by the compiler. Integration errors notuncovered by the compiler are often easy to identify sincesystem modularity provides well defined unit scope,responsibility, and effect.

4.3. CREATING TOOL PACKAGES(SETS)Shared packages of tools were developed, tested and madeavailable to the subsystem developers. These packages providedstability in the development environment. The eleven subsystemswere analyzed to identify common data types and facilities

4

needed throughout the system. The result* were used to establish

specifications for common tool packages. Packages such as the

buffer manager, video display terminal manager, and disk managerwere produced as a result of this process. After this formal

definition of the packages, each was developed and some weretested with test harnesses to verify proper operation. Once a

package was operable for the system environment it was madeavailable for the major subsystem developers.

4-4. UTILIZATION OF TOOL PACKAGESThese packages improved the stability of the SARAH system

development. They used proven logic and prevented the

introduction of errors that occur if many versions of the same

logic are peppered throughout the system. It centralized the

areas involved if and when error corrections or modificationswere needed, greatly reducing the potential for the introductionof errors. We experienced surprisingly quick and smooth subsystem

implementations because of this stability.

4.4.1. ANALYST COMMENTS ON PACKAGINGThese are a few of the comments made by the developmant staff

about the Ada environment and its packaging and modulararchitecture:

"Ada's packaging concept aids testing because it supports theprinciples of modularity, high cohesion, and low coupling.

"Ada can be a very valuable testing tool during the code and

checkout phase, and the system integration phase of development.

It is less valuable during formal system test."

"The other problem we encountered was the fact that we were

developing code before the support code(tool boxes) were written.

Going back and modifying code later to use this new supportcode caused all sorts of problems and resulted in a completeretesting each time a new subsystem was incorporated. (i.e..disk, buffer manager) .... I believe that if we would have hadthe support packages ... that the basic editor could have been

built and tested as each function had been coded and that thetesting would have been a lot smoother and easier."

"I think that the facility to modularize the code allows for

smaller chunks to be tested rather rapidly and new functions canbe added and tested with ease."

"Incremental testing (i.e. the testing of individual modules orsubsystems) was, however, aided by the use of Ada, primarily

because of the package aspect of the language. This facilitatedthe testing by allowing confirmability of the operation of aparticular function in isolation of the remainder of the system.

This aspect is of particular importance when desiring to ensurethat no -revious operation has been adversely affected by amodification to a previously tested module."

5

"The language structures of Ada made software testing easierthan previous assembler language projects done here at CCSO. Thestrong type checking and modularity prevented us from makingcostly mistakes. However, I'm not convinced that Ada providesgreater advantages than other modern high order languages(Pascal, Modula2, etc.)."

"Modularity is not unique to Ada. It is a programming techniquethat can be applied to many (maybe all) other languages. It is atechnique that could be good or bad regardless of the languageused. However, if modularity had not been used, a lot of theother features of Ada could not have been used. i.e. incrementalcompilation, information hiding, strong typing in passedparameters, software tools."

"In the long run, if we can make reuse of modules, Ada mayprovide an edge in testing because each individual module willhave been tested when it was developed and again when it isreused. The more testing (both in a test environment and in thefield) a module gets the more reliable it becomes."

4.5. SEPARATE COMPILATIONSThe compilation process produced advantages quickly for thesesubsystem packages. Almost everyone took advantage of separatecompilations. The strong object typing enforced by the compilerbetween modules and inside instructions improved the integrity ofthe resultant code dramatically. Basically, the programmer isforced to face the results of bad design before the software isexecuting as a program. Inconsistencies in these areas are notallwed and are brought to the attention of the programmer in theform of specific diagnostic messages. The result is that the codehas greater integrity in the overall system environment.

4.5.1. ANALYST COMMENTS ON COMPILER DIAGNOSTICS"These were good by themselves; but when added to strong typing

in passed parameters, modularity, constraint error exceptions,limited data manipulation, private types, incrementalcompilation; they were even more useful. This is a good exampleof where the whole is greater than the sum of its parts. Thecombination allowed test and debug solutions to be determinedeasier."

5. USE OF GENERICS

5.1. STABILITY OF CODEAnother facility of the Ada environment that proved beneficial tothe validity of the final product was the use of generics.Basically that is the use of a template program that can becreated (instantiated) in a module to accomplish a common

6

type function or. data struc tures unique to that module. Genericswere not used to any great extent in this im.plementation dueto our lack of understanding of their usefulness and to the factthat it appears that they cost an excessive amount ofmemory to instantiate.

Generics were used by some programmers to improve the stabilityof frequently used procedures. They did effectively prove to be astabilizing factor. After the generics were tested theyprovided no problems. The major difficulty encountered with thegeneric was that our debug tool Alsys "AdaProbe" would notoperate inside a generic instantiation. This made thedebugging of complex generics very difficult compared tostraight non-generic coding.

5.2. REDUCTION OF COKPLEX CODEWithin the SARAH zystem there is a screen masking systemdeveloped for the entry of different ,aessage formats. Eachmessage type requires different sets of screen masks o. templatesbecause of varying requirements for the different formats. Adata structure was developed to satisfy these differingmask requirements in a non-generic form. After the message maskwas implemented, a need for additional screen masks wasdefined for the SARAH configuration package. There was noway the implemented code could be used. The new requirementfunctionally operates the same way as the original mask. Thenew requirement also had to satisfy screen input requirementsfor both a large routing database file management system andthe site terminal specific table entries. The screen functionswere to be identical but the application and type of data wasentirely different. To meet these requirements, and to preventthe creation of two more screen management systems, a genericsolution was developed. The resulting generic wasinstantiated into each application. Problems wereencountered in the f-rst instantiation and corrected in atimely manner. The second instantiation worked with noproblems. The screen operation was stable and met allrequirements.

5.3. BASE OF CORRECTION AND IMPROVEMENTThe screen requirements were changed to improve the capability ofthe generic and to redAce the coupling of the applicationprograms to the data structures in the generic. The changes weremade in the generic and the implementation was tested in bothinstantiations. The fix in the generic took care of the problemin both applications of the packages. This provided a greatamount of confidence in the techniques being used and thedeveloping product because the product had less chance for theintroduction of errors during the correction and enhancementprocesses.

7

6. USE OF TASKING

6.1. TASKING WAS DIFFICULTTesting of the SARAH system was greatly inhibited at thedevelopment level because of tasking. Since little was known orunderstood about it, it was a trial and error process. Thecommunication and input/output systems had to use tasking. Ourgreatest testing problems occurred because of this environment.As noted by the analyst quote below, che diagnostic debugger didnot function well in the tasking environment. Therefore ourtesting and isolation of logic problems required the programmingof diagnostic logic. This was difficult and time consuming.

6.2. ANALYST COMMENTS ON THE USE OF TASKING"One feature of Ada that hinders testing is tasking. Because

the timing of tasks (which task will become active if several arewaiting, exactly how long a task will stay active, etc.) is notexact, we experienced what were apparently different results fromthe same sequence of events. Tasks are particularly hard tu debugbecause we could not use the Alsys AdaProbe. Trying to use itcharges the timing and many times the problem does not occur (youmay even be unable to breakpoint at the spot where you need to)."

7. THE ADA PROGRAMMING SUPPORT ENVIRONXRNT(APSK)

The Ada Programming Support Environment (APSE) consists of theconfiguration management, command processor, editor, compiler,debugger, and linker/loader. These facilities of the Adadevelopment environment provide capabilities that greatlyinfluence productivity and the stability of the software product.The concept of a programming support environment is probably morevaluable to testing than the Ada language. A proper APSE providesthe software engineer a cadre of interactive development andtesting tools. The Alsys system we used provided a librarymanagement system, a compiler, a debugger, and a linker/loader.

It is not a complete APSE. It did provide a good librarymanagement system that resolves some configuration problems andan excellent debug tool set that assists tremendously inintegration testing.

7.1. ADA LIBRARY MANAGEMENT SYSTEM

7.1.1. AUTOMATIC LIBRARY FUNCTIONSA strong reason for the improvement of the software product isthe library management system. It prevents the use of oldcompilations of subordinate programs when a specification isrecompiled. This automatically prevents the creation ofexecutable code from outdated subordinate program files. Thisfeature is another continuou' step throughout the development

a

process that tusts ir.d ensures th6 £rtgrity of the softwarebeing produced. in addition, the compiler checks the usage of apackage by other packages and automatically requires users of arecompiled package to be recompiled. This prevents theinadvertent creation of a system with the wrong version ofpackages included in the executable code.

7.1.2. DISADVANTAGES IN THK LIBRARY SYSTEMFile dating is not managed by the library management system underthe environment for the SARAH project. Thus generations of afile, i.e. father, grandfather, greatgrandfather, etc., are notmanaged by thia system. Current methods use MSDOS BAT files tocontrol configuration compilations. This allows the creation ofexecutable code using older versions of a program module withoutbeing aware that more current versions exist. it has proven tobe a source of major problems for our configuration environment.

7.1.-3. ANALYST CONMENTS 01 ADA LIBRARY NANAGEKENT"The object code library concept that Ada provi:-s car. aid

greatly in subsystem and integration testing. A separatelycompiled unit can quickly be compiled in, rebound and retestedwith confidence that the only code changed was the one unit thatwas recompiled (don't have to recompile the er tire system orsubsystem)."

7.2. ADA CODE EXECUTION TEST TOOLS

7.2.1. WHEN TO USE TEST TOOLSDebug tools proved to be essential in the development testing andintegration process. It was also necessary for diagnostic,isolation and correction of problems when the independent testinggroup identified them. In addition to all the previous proceduraland environmental circumstances that have helped create a morestable product, the system could not have been developed withoutthe vendor's debug tool system.

A tool to breakpoint and step through the executing programis an absolute necessity. There is no other way to check reasonand logic automatically. Development work was done during theearly stages of the system when it was very simple without theaid of a debugging tool. Ireat difficulties were encountered intrying to isolate the simplest problems. Debug tools wereordered when their criticality to the project was realized . Arexample of the problem iR an error that was present in the "EDIT"program. It was studied and tested for threu days withoutsolution. Then the Alsys "AdaProbe" arrived and the problem waslocated in about 5 minutes.

9

7.2.2. ALSYS ADAPROBEThe debug too! used was the Alsys "AdaProbe." This tool provideddirect visibility into the source code for walking throughproblem code as it executes. This debugging tool, however, didnot function well in the tasking environment.

7.2.3. TEST HARNESSESA technique used by some developers was the development of asubsystem driver that presented a series of controlled inputparaneters to a subsystem package. The output from the packagewas checked for the expected result to confirm proper operationby the driver. This proved to be a beneficial exercise forpackages such as the disk, vdt and buffer packages.

7.2.4. ANALYST COMMENTS ON THE PROBE DEBUG TOOL"Adaprobe is a very powerful symbolic debugger. Without this

tool SARAH development may well have taken an additional 6 to 12months."

"This was an excellent tool. Debugging would have been muchslower and more cumbersome if this tool had not been available."

"Some systems do not have good debug tools. With them, it isnecessary to stop the system at specific memory locations (whichmay involve hex or octal addition or subtraction with a hardcopyof the -oftware at hand); look at registers and memory locations;and translate data to a recognizable form (with a hardcopy of thesoftware at hand)."

"With probe, we were able to view the software on line, use thecursor to mark lines/data (without determining memory locations),and examine data easily and quickly without having to translateit."

8. LESSONS LEARNED

The continuous checking for conformance to interfacespecifications and data typing done by the compiler forcedadherence to design. This helps improve the validity of thesoftware product constantly throughout the development process.

Packaging in the Ada environment can greatly improve thecorrection and maintenance situations in the system and reducethe opportunity for the introduction of errors into the system.

The actual implementation of modular, highly cohesive, and lowcoupled environments is not easy and requires a deeperunderstanding of the complete environment than wns available onthe project.

10

The debug tools should be ordertd with the compiler. They are anecessity for diagnostic work to isolate problems.

Test harnesses are good for verifying the correctness of a set ofpackaged procedures. It helps ensure a good product before otherportions of a system become dependent on it.

The tasking and generic environments make testing difficult sincethe debug tool used did not work iell in these type of programswhen trying to diagnose runtime problems.

9. SURMARY

In summary, the Ada environment provides the tools to maketesting a more continuous, efficient and complete process. The

Ada language can be used in the absence of proper aesign andproper tools. You may be no better off than with FORTRAN or

any other language.

The Ada environment causes very early identificatioL of errorsand forces corrections. The reuse of modules and creation ofselected tool boxes for commonly used functions provide increasedreliability in the product. Generics are a potentially powerfulfacility that can be used to great advantage but it must be donecorrectly and administered properly to be beneficial. Theprogramming support environment provides the capabilities togreatly improve the products.

Ada is not a panacea. It is difficult to use to your advantagebecause of its versatility and infinite number of ways to applyit, but it can improve the 3tability of software products ifapplied using proven software engineering practices.

11