This section covers three major topics on Ada 95 tools:
This section covers three major topics on Ada 95 tools:
Many Ada compiler vendors have already released versions of their Ada 95 compilers. Many of these compilers process both Ada 83 and Ada 95 code and provide the user with a switch to choose the appropriate mode. A switch-selectable Ada 83/Ada 95 compiler will reduce the project's risk, since the project can use one tool to move back and forth from Ada 83 mode to Ada 95 mode until the project completely transitions to Ada 95.
The AdaIC tracks currently available compilers and vendors; to contact AdaIC, see Appendix A. PEOs and PMs should also directly contact vendors for up-to-date information. For more information on validation of Ada 95 compilers, see the issue later in this subsection.
By Tri-Ada 94 and the Ada 95 standardization, most Ada compiler vendors had announced their plans to produce compilers in 1995. Many had already begun to ship partial implementations of Ada 95. However, information on the status of products is subject to change. PEOs and PMs are encouraged to contact vendors directly for up-to-date information. No validated compilers exist yet, since the validation suite will not be available until March 1995.
For project use, compilers must be "production ready". PEOs and PMs should have their staff and contractors measure the compilers to verify their usability. The next subsection addresses this issue.
Ada 95 vendors are building on 10 years of Ada 83 experience and compiler technology, not starting from scratch. Therefore, early Ada 95 compilers are likely to be significantly more mature and stable - in terms of compilation speed, compiler code quality and compiler reliability - than were early Ada 83 compilers. Just as Ada 95 is an incremental upgrade to the language, it is no surprise that Ada 95 compilers are upgrades to Ada 83 compilers. No major compiler vendors are known to be creating Ada 95 technology from scratch. All are building from a decade's worth of stable and mature technology.
Ada 95 compilers provide projects with new opportunities; however, these lead to new risks. To reduce the risk associated with using new Ada 95 compilers, PM Offices, their development staff and/or their contractors must take steps to assess compiler maturity and usability on upcoming projects.
The most important techniques are:
PEOs and PMs should use these techniques to determine whether it is too early, just right, or too late to adopt Ada 95. Also see Table 6 for additional information.
Many methods help measure the quality of a compiler. Most of the Ada 83 techniques will still be very useful for the evaluation of early Ada 95 compilers and may be used while these tests are being enhanced with Ada 95 specific additions. It is strongly recommended that projects benchmark and evaluate all potential compilers early. Some methods for evaluating Ada compilers may be found in the following sources:
See Appendix A for more information.
PEOs and PMs should use these test suites to evaluate the quality of new Ada 95 systems with respect to known compiler baselines of Ada 83 and other languages.
Ada compiler validation provides a measure of minimal quality. It assures the user that the compiler adheres to the standard as defined by ISO and ANSI. However, validation does not ensure that a compiler is "bug free". To determine "usability", Program Offices should sponsor compiler evaluation and benchmarking using suites of tests such as those described in the previous section.
In Chapter 2, the letter from the Assistant Secretary of Defense (C3I) stated that unvalidated Ada 95 compilers may be used on projects. However, non-R&D projects must upgrade to a validated Ada 95 compiler in time for the project's final delivery. A validated compiler is one that passes the Ada Compiler Validation Capability (ACVC) suite of tests, which is used to certify that a compiler implements the Ada language standard.
This suite is currently undergoing revision. The first Ada 95 version, ACVC Version 2.0, will be available in March 1995. The validation certificate will list the ACVC modules the compiler was validated against. This version of the ACVC will include tests covering all areas of the language arranged in a modular fashion to give compiler vendors the opportunity to implement those new features that their customer base wants first (e.g., OOP or real-time enhancements) and delay implementing less essential features. Compilers will be validated under ACVC 2.0. This validation suite will be in use for two years.
The second version, ACVC 2.1, will be released in 1996 and will include a full suite of tests for the Ada 95 core and all annexes. It will be put into use starting in 1997. The approach will be similar to the current ACVC, in that a compiler must pass all applicable tests to be validated. ACVC Version 2.1 will require vendors to implement the entire core language and will allow validation against each of the optional specialized needs annexes. This version's validation certificate will list the language annexes the compiler supports.
PEOs and PMs must consider the portability of their Ada software. Validation of compilers increases portability and lowers risk by ensuring that compilers are measured against the same yardstick of conformity, the ACVC.
As with Ada 83, the ACVC will ensure that a compiler implements the language as it is described in the Ada standard. In this sense, a compiler must implement the full core language as specified in the standard. Unvalidated compilers may be a partial implementation of the language features.
Users, on the other hand, have always had the freedom to use only a subset of the language. This has historically been true when teaching the language to novices; they are encouraged to use only a subset of the full capabilities at first and add more concepts incrementally as they learn. Ada 95 also encourages the use of a subset of features in the Safety and Security Annex - where the use of certain features is discouraged to enhance program provability.
With regard to extensions of capabilities of the language (i.e., features outside the language definition), the standard gives limited permissions for implementations to add functionality through implementation-defined pragmas, attributes, and packages.
Tools will be sold in many ways: some will be bundled with Ada compilers, others will be in the public domain (i.e., free), still others will be sold as third-party add-ons. Those available from compiler vendors will generally become available in increments along with the Ada 95 compilers. In many cases, third-party tools will be available sooner, because the compiler vendors will be concentrating on compilers before working on support tools. However, there will be exceptions. Table 5 gives examples of the kinds of tools and discusses their availability. The table lists general categories of tools rather than specific products. Some tools will be available from the compiler vendor, both bundled with the compiler and as extra add-on tools. Others will be sold by third-party vendors for multiple compilers and platforms.
PM Offices should have their contractors and/or development staff develop a tool integration matrix that shows the interactions between the following concepts: tool availability, platforms that the tool runs on, dependency on other tools, and support technology (and version) required (e.g., operating system and version or DBMS and version). The matrix will identify if a suite of tools must be coordinated for early handling.
Table 5: Example of Some Support Tools and Their Availability
(As of Spring 1995)
Check with the AdaIC for more information on these types of tools.
Incremental adoption of Ada 95 will help ensure that the cost does not affect the project's budget in ways not accounted for. PEOs and PMs should exploit several of the creative options available to reduce the tool costs of Ada 95 adoption. Some compiler vendors are making inexpensive upgrades available (e.g., the cost is built into current maintenance agreements). Other vendors are charging prices equal to that of a new compiler. Pragmatic PEOs and PMs should re-evaluate their vendor sources and comparison shop for the best deal.
There are several risk mitigation techniques PEO and PM offices should employ to reduce the risk that tool costs will cause disruption of the project budget:
Previous Section - Project Planning Risks
Next Section - Upward Compatibility Risks