- Email: [email protected]
Ada programming language standardization
Ada* Programming Language Standardization Paul M. Cohen Defense Communications Engineering Center, Reston, Virginia
The need for software management and standardization of programming languages used in military systems was first identified by DOD in 1975. DOD at that time supported many limited use languages for what are now called embedded computer applications. This diversity of languages contributed to high software costs. In November 1976, DOD first established seven approved HOLS, FORTRAN, COBOL, JOVIAL-J3,
JOVIAL-J73,
TACPOL, CMS-2,
SPL-1.
Eventually the number of approved DOD languages may be reduced to three, Ada, FORTRAN, and COBOL. Ada was established as Military Standard 1815, on 10 December 1980. The ANSI standardization process for Ada is in progress. The Ada concept places restrictions on what may be called an Ada compiler. Compilers may not be called Ada compilers until they have passed validation tests. Up to 80% of software costs are incurred after the software has been put into service. Ada can promote a programming style that leads to maintainable software. It is in the program maintenance phase of the software life cycle where large savings will be achieved through the use of Ada.
DOD RECOGNITION OF THE NEED FOR LANGUAGE STANDARDIZATION
The need for software management and standardization of programming languages used in military systems was first identified by DOD in a Director of DeEngineering (DDRE) Research and fense memorandum dated 28 January 1975. This memorandum recognized that COBOL and FORTRAN have evolved as standards in their respective applications areas, each language having been widely used, and portable code having been developed with each. The memorandum further noted that DOD has sup-
*Ada is a registered trademark (Ada Joint Program O&e).
of the Department
of Defense
Address correspondence to Mr. Paul M. Cohen, Code R620, 1860 Wiehle Avenue. Defense Communication Engineering Center, Reston, Virginia 22090.
The Journal of Systems and Software 2.351-355 Q Elsevier North Holland, Inc,1982
(1981)
ported many limited use languages for what are now called embedded computer applications. There were some loose standards within each service. Each service had its own standard languages, the Army had TACPOL, the Air Force had JOVIAL, and the Navy had CMs-2. Not only did several incompatible versions of each language exist, but the services also used other languages, such as COBOL and FORTRAN. This diversity of languages caused problems in finding programmers with suitable experience. Compilers tended to be less reliable because each compiler was not exercised enough for early discovery of latent errors. This situation contributed to high software costs. The memorandum called for the formation of a working group with representation from the military departments and appropriate defense agencies. The initial guidance for the group was to determine what was a minimal set of high order languages to accomplish the DOD mission. In accordance with this guidance the High Order Language Working Group (HOLWG) was formed. The memorandum also established a DOD policy for not supporting further development of new high order languages; however, research into language technology was not forbidden. After the HOLWG was formed, a second memorandum, dated 2 May 1975, called for the HOLWG to develop the requirements for a new DOD language for embedded computer systems. DEFINITION OF AN EMBEDDED COMPUTER SYSTEM
The term Embedded Computer System was coined to define an integrated hardware/software system that forms part of a larger system. Examples of such systems are communications systems, command and control systems, on-board aircraft navigation and weapons control systems, and other real-time control systems. Note that size does not determine an embedded computer. One may range from a small microcomputer
351 0164-1212/81/040351-05$2.75
352
Paul M. Cohen
system, such as an aircraft autopilot, to a network of large computers, such as the ARPANET backbone system.
CHARACTERISTICS OF SOFTWARE FOR EMBEDDED COMPUTER SYSTEMS The characteristics of software for embedded computer systems, as opposed to that of scientific or business applications, are as follows:
Intertask
Communication
Processes occur in parallel rather than sequential. These processes must be able to speak to one another and exchange information. Such capabilities are missing from existing commonly used languages. Intertask communication is often done in assembler language inserts even when other portions of the code are in an HOL.
Real-Time Control The processes require a man-machine interaction. This type of interaction is not found in existing widely used HOLS.
Exception Handling These processes cannot stop when some exceptional situation, such as an arithmetic overflow occurs. The language must be able to specify a recovery action for such situations.
Unique I/O Control Z/O is not with the usual disks, tapes, typewriters, and printers. Input is often from sensors and output is often control information to a mechanical device.
EXISTING SITUATION IN 1975 The situation follows:
existing
in 1975 can be summarized
as
a. A diversity of programming languages existed. b. Languages were ill-suited to their applications. c. Languages did not support modern programming methodologies. In addition it was soon recognized that it is not sufficient to simply have a standard language and a compiler. What was needed was a new concept for the development of software that managed such software during the entire life cycle of such software. It was nec-
essary to define an integrated software environment and a set of software tools which included not only the compiler but also the editors, documentation aids, program development aids, and libraries which allowed one to build an engineering discipline and put software development on an equal scientific basis with other engineering activities. If DOD failed to develop such a facility, it would mean that software development would continue to be treated as an art, with little basis for predicting software costs and time durations. The consequence of such a situation is frequent occurrence of late, erroneous, and costly software.
THE Ada CONCEPT Consequently when DOD developed the new programming language Ada, the Ada concept did not stop at the development of a programming language. The Ada concept included the following: (a) the Ada Programming Language and (b) the Ada Programming Support Environment (APSE). A programming support environment is part of each Ada compiler effort currently being sponsored by DOD and coordinated through the Ada Joint Program Office (AJPO).
INITIAL DOD DIRECTION ON LANGUAGE STANDARDIZATION IN 1976 A DOD Directive issued in April 1976, DODD 5000.29, directed that DOD-approved languages be used in future defense system projects. This provision was not retroactive to systems currently in use or under development. Exceptions were permitted on an individual basis, with each DOD component developing its own waiver process. The directive further required a control agent for each DOD-approved language. It was recognized that it was not enough for a language to be simply specified as a standard language. A control agent was required for each standard language to assure that the use of a language and of the compilers for a language was consistent with the definition of the language. The Management Steering Committee for Embedded Computer Resources (MSC-ECR) was established under the Deputy Undersecretary of Defense for Acquisition Management to correct problems in the management of computer based systems and to implement this directive. The HOLWG which was already in existence became a committee of the MSC-ECR. In November 1976, DOD Instruction (DoDI) 5000.3 1, established seven approved HOLS, FORTRAN, COBOL, JOVIAL-J3,JOVIAL-.!73, TACPOL, CMS-2, SPL-I.
Ada Programming Language Standardization Of the seven languages, two were already American National Standards Institute (ANSI) standards and control facilities were already in existence (FORTRAN and COBOL). Two (CMS-2and SPL-1) were Navy languages and the Navy was designated the control agent. The two dialects of JOVIALwere under control of the Air Force, and TACPOLwas under control of the Army. DoDI 5000.31 is currently being revised to include Ada. In future revisions, as Ada becomes the standard for all DOD embedded applications, the service languages are to be phased out. It should be noted that the services have an extremely large investment in these languages, so that this phasing out will be a gradual process. DOD systems tend to be long lived, and it will not be practical to retrofit Ada to all existing software in current DOD systems. Eventually DoDI 5000.31 may contain three languages, Ada, FORTRAN,and COBOL. There is no plan to currently use Ada to replace the scientific applications now programmed in FORTRANor the business applications which now use COBOL. It is considered that Ada could be used for most applications currently using FORTRAN,but it will require a substantial investment in library software before the business data processing which is now programmed in COBOL could be as easily programmed in Ada. EMPHASIS ON THE DEVELOPMENT OF FULL Ada
Ada means FULL Ada. Subsets and Supersets are prohibited. This is one facet of the Ada standardization program which has generated much comments. There has been pressure to define subsets of Ada, particularly for small machines, on the grounds that full Ada will be impractical on such hardware. Such definition has been resisted for the following reasons: Enhanced program portability is desired. Program portability has been one of the prime benefits expected from language standardization. Subsets tend to reduce such portability. Extensibility features
are within the Language.
Many of the reasons for defining subsets in older languages are not valid in Ada. Ada contains a rich mix of features, as part of its generic capability. Such features make what is normally an extension in another language describable in Ada as a library package. Consequently, features are added through libraries rather than through extensions. It permits fewer, more widely used compilers. Subsets require subset compilers. Consequently, subsets breed additional compilers. This spreads the use of Ada over more compilers; consequently, each compiler receives less use, and the latent errors are more slowly uncovered and corrected.
353 d. Local restrictions may be enforced by a preprocessor. Local restrictions may be prescribed for the use
of certain language constructs. These restrictions could be enforced by a preprocessor which would detect unauthorized constructs before invoking the compiler. Presently, incomplete implementations of Ada are being offered as interim products by companies committed to developing complete compilers. These companies are permitted to call such interim products Ada, provided a statement of each company’s commitment to a full Ada compiler is included in the advertising of such products. Ada STANDARDIZATION
PROGRAMS
The following is the approximate Ada standardization timetable: a. DOD. Ada was established as Military
Standard 18 15, on 10 December 1980. b. ANSI. A 6 month ANSI canvass was conducted between April and October 198 1. This consisted of the development of a consensus for standardization of Ada by polling a list of 96 organizations. This list was compiled by the AJPO with the assistance of ANSI and was approved by ANSI.
Concurrent with the ANSI canvass a public review was held between July and September 1981. This public review is part of the ANSI canvass process and permits those not on the canvass list to comment on the proposed standard. The comments developed during the ANSI canvass and public review were answered by the AJPO in January 1982. Currently the AJPO in conjunction with the Ada design team and the group of reviewers known as the “Distinguished Reviewers” is in the process of revising the Ada manual in response to the comments received during the ANSI canvass. This revision is primarily an editorial revision, and corrects the minor manual and language ambiguities which have been uncovered since the manual was published in April 1980. If the comments received during the canvass so dictate then ANSI can request a recanvass over a 2-month period. The revised Ada manual was completed during the summer of 1982, and resubmitted to ANSI for approval, with the 2-month recanvass. It should be noted that the canvass method is not the normal method of establishing a language standard. Normally the language is given to the American National Standards Committee-X3 (ANSC-X3), which then sets up its own mechanism for controlling the standard. Under the canvass method, DOD essentially deals
354 directly with ANSI, not ANSC-X3. ANSC-X3 is in an advisory role. c. ZSO. An Experts Group (XG) under the International Standards Organization (ISO) was proposed in September 198 1. One organizational meeting has been held; however, the group has not yet been formally constituted.
Paul M. Cohen not part of the official definition, implementors have found it useful. The current status of the test suite is that a basic capability is available now for compiler implementors. A complete capability will be available after the updated Ada manual has been completed. TIMELINESS OF Ada STANDARDIZATION
CONTROL OF THE Ada STANDARD It is anticipated that the AJPO and ANSC-X3 will work together in developing the procedures for controlling the Ada standard. At the start of the Canvass period a draft proposal for a control organization was developed by DOD. This proposal called for the formation of an Ada Executive Committee which would have representation from the entire Ada community as well as DoD, and would be the Ada control board. The Ada Executive Committee would be assisted by a body of Ada experts called the Ada Council. The membership of the Ada Council would be international in scope. In the international standardization arena, the U.S. members of the Ada Council will form the U.S. “Technical Advisory Group” (TAG). CONTROL OF THE Ada COMPILERS
It has been previously noted that all standard DOD languages must have an appropriate control agent. The control agent for Ada is, of course, the Ada Joint Program Office (AJPO), with an important function of this office being the validation of Ada compilers. A capability for such validation is currently being developed. Prospective Ada compilers will be subjected to a set of tests consisting of a validation suite of approximately 1400 programs. This suite is being developed under contract to DOD. Any compiler used on a DoD program will be required to be certified before such use. The DOD has obtained a registered trademark on the term Ada as ap plied to a programming language. Through this trademark the AJPO intends to enforce restrictions on what may be called an Ada compiler. Compilers may not be called Ada compilers until they have passed the validation tests. It is the intention of the test suite to detect subsets, extensions, and full compliance with the Ada standard. An Ada Implementors’ Guide is available as an aid to organizations now developing Ada compilers. This Guide has been developed by the organization developing the validation capability. Although this guide is
There has been some objections to the current Ada standardization effort on the grounds that standardization of the language in its present form is premature. However, the current standardization effort is considered appropriate for the following reasons: It discourages subsets and supersets from proliferating. Without a standard, people will feel free to
make arbitrary changes in the language. Almost anything which resembles the Ada concept might be passed as Ada. Zt encourages the use of the language. People will be more encouraged to learn to use Ada when they are sure that what they are learning is the standard Ada. It supports the establishment of environmentaf tools.
The Ada concept has been previously defined as consisting of the language and the environment. It will be difficult to define the environment and begin to develop tools for the environment before the standard is established. It encourages the development of standard packages. Successful use of Ada depends on the devel-
opment and use of standard library packages. When one knows that such a package will be defined for the standard language there is more encouragement to develop such standard packages. ECONOMICS OF Ada AS A STANDARD LANGUAGE
The initial savings that will be realized in using Ada as a standard language will be realized when the same compiler and the same language is used from program to program. There will be no need to develop and debug new compilers and retrain programmers to use new languages. In the case of a compiler, the more it is used the more reliable it becomes. The use of Ada will have little effect on the amount of resources used during the program development cycle. A reasonable strategy for using Ada during the program development cycle is to use essentially the same amount of resources as is now used, but instead of a gain in productivity strive for the development of
355
Ada Programming Language Standardization “better” software. “Better” software is defined as software with the following properties: Software which is more modular. Such software
tends to be better structured, and hence easier to read. Software which is more easily maintained. More modular software is easier to maintain. The Ada concept will lead to less dependencies between software modules. Thus promulgation of errors from enhancements to the program will be fewer, and consequently the software will be easier to maintain. Software in which there is an increased conjidence of being correct. The programming discipline imposed
by Ada promotes less errors in the code. The basic building block in Ada is called a package. The package structure of Ada and the rules which must be observed, aids in the compiler catching more of the errors than in existing systems.
d. Software with potential reusability. With the Ada
concept one is more likely to find code already developed which can be transported to the application. Studies show that software must be built to be transportable. Software which can be reused must be built to be reused. THE BIG PAYOFF IN USING Ada
The program development phase is not where the big savings will take place with Ada. DOD systems tend to be long lived and subject to frequent changes and modifications. Up to 80% of software costs are incurred after the software has been put into service. Ada can promote a programming style which leads to maintainable software, and programmers should be trained to program in such a style. Consequently, it is in this program maintenance phase of the software life cycle where the big savings with Ada will take place.
The need for software management and standardization of programming languages used in military systems was first identified by DOD in 1975. DOD at that time supported many limited use languages for what are now called embedded computer applications. This diversity of languages contributed to high software costs. In November 1976, DOD first established seven approved HOLS, FORTRAN, COBOL, JOVIAL-J3,
JOVIAL-J73,
TACPOL, CMS-2,
SPL-1.
Eventually the number of approved DOD languages may be reduced to three, Ada, FORTRAN, and COBOL. Ada was established as Military Standard 1815, on 10 December 1980. The ANSI standardization process for Ada is in progress. The Ada concept places restrictions on what may be called an Ada compiler. Compilers may not be called Ada compilers until they have passed validation tests. Up to 80% of software costs are incurred after the software has been put into service. Ada can promote a programming style that leads to maintainable software. It is in the program maintenance phase of the software life cycle where large savings will be achieved through the use of Ada.
DOD RECOGNITION OF THE NEED FOR LANGUAGE STANDARDIZATION
The need for software management and standardization of programming languages used in military systems was first identified by DOD in a Director of DeEngineering (DDRE) Research and fense memorandum dated 28 January 1975. This memorandum recognized that COBOL and FORTRAN have evolved as standards in their respective applications areas, each language having been widely used, and portable code having been developed with each. The memorandum further noted that DOD has sup-
*Ada is a registered trademark (Ada Joint Program O&e).
of the Department
of Defense
Address correspondence to Mr. Paul M. Cohen, Code R620, 1860 Wiehle Avenue. Defense Communication Engineering Center, Reston, Virginia 22090.
The Journal of Systems and Software 2.351-355 Q Elsevier North Holland, Inc,1982
(1981)
ported many limited use languages for what are now called embedded computer applications. There were some loose standards within each service. Each service had its own standard languages, the Army had TACPOL, the Air Force had JOVIAL, and the Navy had CMs-2. Not only did several incompatible versions of each language exist, but the services also used other languages, such as COBOL and FORTRAN. This diversity of languages caused problems in finding programmers with suitable experience. Compilers tended to be less reliable because each compiler was not exercised enough for early discovery of latent errors. This situation contributed to high software costs. The memorandum called for the formation of a working group with representation from the military departments and appropriate defense agencies. The initial guidance for the group was to determine what was a minimal set of high order languages to accomplish the DOD mission. In accordance with this guidance the High Order Language Working Group (HOLWG) was formed. The memorandum also established a DOD policy for not supporting further development of new high order languages; however, research into language technology was not forbidden. After the HOLWG was formed, a second memorandum, dated 2 May 1975, called for the HOLWG to develop the requirements for a new DOD language for embedded computer systems. DEFINITION OF AN EMBEDDED COMPUTER SYSTEM
The term Embedded Computer System was coined to define an integrated hardware/software system that forms part of a larger system. Examples of such systems are communications systems, command and control systems, on-board aircraft navigation and weapons control systems, and other real-time control systems. Note that size does not determine an embedded computer. One may range from a small microcomputer
351 0164-1212/81/040351-05$2.75
352
Paul M. Cohen
system, such as an aircraft autopilot, to a network of large computers, such as the ARPANET backbone system.
CHARACTERISTICS OF SOFTWARE FOR EMBEDDED COMPUTER SYSTEMS The characteristics of software for embedded computer systems, as opposed to that of scientific or business applications, are as follows:
Intertask
Communication
Processes occur in parallel rather than sequential. These processes must be able to speak to one another and exchange information. Such capabilities are missing from existing commonly used languages. Intertask communication is often done in assembler language inserts even when other portions of the code are in an HOL.
Real-Time Control The processes require a man-machine interaction. This type of interaction is not found in existing widely used HOLS.
Exception Handling These processes cannot stop when some exceptional situation, such as an arithmetic overflow occurs. The language must be able to specify a recovery action for such situations.
Unique I/O Control Z/O is not with the usual disks, tapes, typewriters, and printers. Input is often from sensors and output is often control information to a mechanical device.
EXISTING SITUATION IN 1975 The situation follows:
existing
in 1975 can be summarized
as
a. A diversity of programming languages existed. b. Languages were ill-suited to their applications. c. Languages did not support modern programming methodologies. In addition it was soon recognized that it is not sufficient to simply have a standard language and a compiler. What was needed was a new concept for the development of software that managed such software during the entire life cycle of such software. It was nec-
essary to define an integrated software environment and a set of software tools which included not only the compiler but also the editors, documentation aids, program development aids, and libraries which allowed one to build an engineering discipline and put software development on an equal scientific basis with other engineering activities. If DOD failed to develop such a facility, it would mean that software development would continue to be treated as an art, with little basis for predicting software costs and time durations. The consequence of such a situation is frequent occurrence of late, erroneous, and costly software.
THE Ada CONCEPT Consequently when DOD developed the new programming language Ada, the Ada concept did not stop at the development of a programming language. The Ada concept included the following: (a) the Ada Programming Language and (b) the Ada Programming Support Environment (APSE). A programming support environment is part of each Ada compiler effort currently being sponsored by DOD and coordinated through the Ada Joint Program Office (AJPO).
INITIAL DOD DIRECTION ON LANGUAGE STANDARDIZATION IN 1976 A DOD Directive issued in April 1976, DODD 5000.29, directed that DOD-approved languages be used in future defense system projects. This provision was not retroactive to systems currently in use or under development. Exceptions were permitted on an individual basis, with each DOD component developing its own waiver process. The directive further required a control agent for each DOD-approved language. It was recognized that it was not enough for a language to be simply specified as a standard language. A control agent was required for each standard language to assure that the use of a language and of the compilers for a language was consistent with the definition of the language. The Management Steering Committee for Embedded Computer Resources (MSC-ECR) was established under the Deputy Undersecretary of Defense for Acquisition Management to correct problems in the management of computer based systems and to implement this directive. The HOLWG which was already in existence became a committee of the MSC-ECR. In November 1976, DOD Instruction (DoDI) 5000.3 1, established seven approved HOLS, FORTRAN, COBOL, JOVIAL-J3,JOVIAL-.!73, TACPOL, CMS-2, SPL-I.
Ada Programming Language Standardization Of the seven languages, two were already American National Standards Institute (ANSI) standards and control facilities were already in existence (FORTRAN and COBOL). Two (CMS-2and SPL-1) were Navy languages and the Navy was designated the control agent. The two dialects of JOVIALwere under control of the Air Force, and TACPOLwas under control of the Army. DoDI 5000.31 is currently being revised to include Ada. In future revisions, as Ada becomes the standard for all DOD embedded applications, the service languages are to be phased out. It should be noted that the services have an extremely large investment in these languages, so that this phasing out will be a gradual process. DOD systems tend to be long lived, and it will not be practical to retrofit Ada to all existing software in current DOD systems. Eventually DoDI 5000.31 may contain three languages, Ada, FORTRAN,and COBOL. There is no plan to currently use Ada to replace the scientific applications now programmed in FORTRANor the business applications which now use COBOL. It is considered that Ada could be used for most applications currently using FORTRAN,but it will require a substantial investment in library software before the business data processing which is now programmed in COBOL could be as easily programmed in Ada. EMPHASIS ON THE DEVELOPMENT OF FULL Ada
Ada means FULL Ada. Subsets and Supersets are prohibited. This is one facet of the Ada standardization program which has generated much comments. There has been pressure to define subsets of Ada, particularly for small machines, on the grounds that full Ada will be impractical on such hardware. Such definition has been resisted for the following reasons: Enhanced program portability is desired. Program portability has been one of the prime benefits expected from language standardization. Subsets tend to reduce such portability. Extensibility features
are within the Language.
Many of the reasons for defining subsets in older languages are not valid in Ada. Ada contains a rich mix of features, as part of its generic capability. Such features make what is normally an extension in another language describable in Ada as a library package. Consequently, features are added through libraries rather than through extensions. It permits fewer, more widely used compilers. Subsets require subset compilers. Consequently, subsets breed additional compilers. This spreads the use of Ada over more compilers; consequently, each compiler receives less use, and the latent errors are more slowly uncovered and corrected.
353 d. Local restrictions may be enforced by a preprocessor. Local restrictions may be prescribed for the use
of certain language constructs. These restrictions could be enforced by a preprocessor which would detect unauthorized constructs before invoking the compiler. Presently, incomplete implementations of Ada are being offered as interim products by companies committed to developing complete compilers. These companies are permitted to call such interim products Ada, provided a statement of each company’s commitment to a full Ada compiler is included in the advertising of such products. Ada STANDARDIZATION
PROGRAMS
The following is the approximate Ada standardization timetable: a. DOD. Ada was established as Military
Standard 18 15, on 10 December 1980. b. ANSI. A 6 month ANSI canvass was conducted between April and October 198 1. This consisted of the development of a consensus for standardization of Ada by polling a list of 96 organizations. This list was compiled by the AJPO with the assistance of ANSI and was approved by ANSI.
Concurrent with the ANSI canvass a public review was held between July and September 1981. This public review is part of the ANSI canvass process and permits those not on the canvass list to comment on the proposed standard. The comments developed during the ANSI canvass and public review were answered by the AJPO in January 1982. Currently the AJPO in conjunction with the Ada design team and the group of reviewers known as the “Distinguished Reviewers” is in the process of revising the Ada manual in response to the comments received during the ANSI canvass. This revision is primarily an editorial revision, and corrects the minor manual and language ambiguities which have been uncovered since the manual was published in April 1980. If the comments received during the canvass so dictate then ANSI can request a recanvass over a 2-month period. The revised Ada manual was completed during the summer of 1982, and resubmitted to ANSI for approval, with the 2-month recanvass. It should be noted that the canvass method is not the normal method of establishing a language standard. Normally the language is given to the American National Standards Committee-X3 (ANSC-X3), which then sets up its own mechanism for controlling the standard. Under the canvass method, DOD essentially deals
354 directly with ANSI, not ANSC-X3. ANSC-X3 is in an advisory role. c. ZSO. An Experts Group (XG) under the International Standards Organization (ISO) was proposed in September 198 1. One organizational meeting has been held; however, the group has not yet been formally constituted.
Paul M. Cohen not part of the official definition, implementors have found it useful. The current status of the test suite is that a basic capability is available now for compiler implementors. A complete capability will be available after the updated Ada manual has been completed. TIMELINESS OF Ada STANDARDIZATION
CONTROL OF THE Ada STANDARD It is anticipated that the AJPO and ANSC-X3 will work together in developing the procedures for controlling the Ada standard. At the start of the Canvass period a draft proposal for a control organization was developed by DOD. This proposal called for the formation of an Ada Executive Committee which would have representation from the entire Ada community as well as DoD, and would be the Ada control board. The Ada Executive Committee would be assisted by a body of Ada experts called the Ada Council. The membership of the Ada Council would be international in scope. In the international standardization arena, the U.S. members of the Ada Council will form the U.S. “Technical Advisory Group” (TAG). CONTROL OF THE Ada COMPILERS
It has been previously noted that all standard DOD languages must have an appropriate control agent. The control agent for Ada is, of course, the Ada Joint Program Office (AJPO), with an important function of this office being the validation of Ada compilers. A capability for such validation is currently being developed. Prospective Ada compilers will be subjected to a set of tests consisting of a validation suite of approximately 1400 programs. This suite is being developed under contract to DOD. Any compiler used on a DoD program will be required to be certified before such use. The DOD has obtained a registered trademark on the term Ada as ap plied to a programming language. Through this trademark the AJPO intends to enforce restrictions on what may be called an Ada compiler. Compilers may not be called Ada compilers until they have passed the validation tests. It is the intention of the test suite to detect subsets, extensions, and full compliance with the Ada standard. An Ada Implementors’ Guide is available as an aid to organizations now developing Ada compilers. This Guide has been developed by the organization developing the validation capability. Although this guide is
There has been some objections to the current Ada standardization effort on the grounds that standardization of the language in its present form is premature. However, the current standardization effort is considered appropriate for the following reasons: It discourages subsets and supersets from proliferating. Without a standard, people will feel free to
make arbitrary changes in the language. Almost anything which resembles the Ada concept might be passed as Ada. Zt encourages the use of the language. People will be more encouraged to learn to use Ada when they are sure that what they are learning is the standard Ada. It supports the establishment of environmentaf tools.
The Ada concept has been previously defined as consisting of the language and the environment. It will be difficult to define the environment and begin to develop tools for the environment before the standard is established. It encourages the development of standard packages. Successful use of Ada depends on the devel-
opment and use of standard library packages. When one knows that such a package will be defined for the standard language there is more encouragement to develop such standard packages. ECONOMICS OF Ada AS A STANDARD LANGUAGE
The initial savings that will be realized in using Ada as a standard language will be realized when the same compiler and the same language is used from program to program. There will be no need to develop and debug new compilers and retrain programmers to use new languages. In the case of a compiler, the more it is used the more reliable it becomes. The use of Ada will have little effect on the amount of resources used during the program development cycle. A reasonable strategy for using Ada during the program development cycle is to use essentially the same amount of resources as is now used, but instead of a gain in productivity strive for the development of
355
Ada Programming Language Standardization “better” software. “Better” software is defined as software with the following properties: Software which is more modular. Such software
tends to be better structured, and hence easier to read. Software which is more easily maintained. More modular software is easier to maintain. The Ada concept will lead to less dependencies between software modules. Thus promulgation of errors from enhancements to the program will be fewer, and consequently the software will be easier to maintain. Software in which there is an increased conjidence of being correct. The programming discipline imposed
by Ada promotes less errors in the code. The basic building block in Ada is called a package. The package structure of Ada and the rules which must be observed, aids in the compiler catching more of the errors than in existing systems.
d. Software with potential reusability. With the Ada
concept one is more likely to find code already developed which can be transported to the application. Studies show that software must be built to be transportable. Software which can be reused must be built to be reused. THE BIG PAYOFF IN USING Ada
The program development phase is not where the big savings will take place with Ada. DOD systems tend to be long lived and subject to frequent changes and modifications. Up to 80% of software costs are incurred after the software has been put into service. Ada can promote a programming style which leads to maintainable software, and programmers should be trained to program in such a style. Consequently, it is in this program maintenance phase of the software life cycle where the big savings with Ada will take place.