AdaIC News
Fall 1996

Ada Information Clearinghouse
The Official Source for Ada Information

Vol. XIV, No. 3
ISSN 1064-1505
No Charge

AdaIC Sponsored by the Ada Joint Program Office and operated by IIT Research Institute

In This Issue

Improving Ada Portability Trade Association Moves Towards Common Set of Interfaces

One obstacle to portability of Ada programs among the widest possible range of platforms is that there is no commonly accepted set of standards or products for interfacing to resources controlled by other standards. Interfacing to other languages (such as C++) is usually handled by pragmas unique to each compiler vendor. Also, developers wishing to access a given standard -- such as X-Windows/Motif or the Portable Operating System Interface (POSIX) -- may have competing Ada bindings available.

Standardizing how Ada is used with external services

On July 16, the Ada Resource Association (ARA), the professional trade association, announced it had begun a program to provide a set of standards establishing how Ada is used and implemented with external services.

The Association has formed the Ada Common Environment (ACE) project, which will coordinate with Ada compiler and tool vendors to ensure that all Ada implementations compatibly support popular external interfaces. The ARA will build on Ada 95 -- and its facilities for integrating multi-language software systems -- with the goal of making Ada the most portable language in software development.

The program will focus on customer needs and enable third-party vendors to build more powerful tools and supplemental systems with the assurance that all Ada systems can support them. A common set of standards will benefit Ada software products by increasing the range of platforms to which applications can be ported. The advantage to application developers will be greater portability for their code from compiler to compiler and target to target.

ACE expects to address a wide array of technical issues; however, the initial focus will be on identifying connections to the most popular external standards. Among the first to be studied will be Microsoft Windows (Win32), the Common Object Request Broker Architecture (CORBA), X-Windows/Motif, C++, and POSIX.

Initial output

ACE's technical output will be documentation for application developers and compiler vendors, enabling them to move immediately into production of compatible products. The first documentation is expected on Sept. 30, 1996. Where technical issues warrant, the ARA may provide free software to implement standards and help third-party vendors write portable Ada interfaces to their products.

Coordinating with vendors

The Ada Common Environment is comprised of technical representatives from each of the ARA member companies -- responsible for selling 95% of all Ada compilers and tools. The companies are: Ada Core Technologies, Inc.; DDC-I, Inc.; Intermetrics, Inc.; OC Systems; Rational Software Corp; Thomson Software Products; and Texas Instruments/Tartan, Inc.

Invitations are being extended to companies in the worldwide Ada community who are not ARA members. For more information, contact the AdaIC at 1-800/232-4211.

Letter from the AJPO: The End of an Era?

In this issue of the newsletter, I think it is important to discuss some of the rumors that have been flying around the Internet about what is happening here at the Ada Joint Program Office. I will try to clear up the wrong impressions and correct the rumors by presenting the facts and the motivations for our actions.

Ada study at National Academy of Science

First, Mr. Emmett Paige, Assistant Secretary of Defense (C3I), asked the National Academy of Science to conduct a study of the current Ada policy within the Department of Defense (DoD). This task was given to the Academy's National Research Council (NRC). The NRC then selected the chair of the study group, Dr. Barry Boehm, and the 12 additional members.

The charter for this study group is to examine the current policy to determine whether it is still viable and relevant in today's world, and, if not, to suggest an alternative policy. Recall that the last time such a study was conducted was over 20 years ago!

The study group has had two meetings in which invited people presented their facts and suggestions. They have at least one more scheduled meeting and will then render their report to Mr. Paige not later than 31 October 1996. It is still too early to tell what the outcome of the study group will be, but all indications are that this is a fair and well balanced group of people, and that the result will be in the best interests of the DoD.


Second, many of you have heard that the AJPO may close. Let me put this rumor to rest. Yes, we will be closing, but that is exactly what we should be doing.

A program office is established to create a product. It identifies requirements, and designs, implements, tests, and refines the product until it is ready for full-scale production. At that point, the program office has done its job and is closed; maintenance of the product is accomplished by other people. The "PO" in AJPO stands for Program Office. The AJPO and its predecessor, the High Order Language Working Group (HOLWG), were established to create the Ada programming language. This was done. We then matured it through its first international restandardization. It is now time to be disestablished.

This does not mean that the functions of the AJPO will go away; nor does it have any link whatsoever to the policy of the DoD with regard to the use of Ada. The F-16 Program Office was established to create the F-16. When it went from R&D to Maintenance, the program office was scheduled to be closed, but the F-16 will still be with us and is very much an essential part of the nation's arsenal. So will it be with Ada.

Transitioning tasks

Over a year ago, we selected a target of June 1997 as the time to close the AJPO. We have been progressing along a glide slope to that date. If we can accomplish what we need to sooner, we will close sooner. If it takes a little longer, then we will stay open a little longer. But we will close.

We started the transition of the AJPO by first enumerating our functions. We moved the obvious things first. The validation of compilers for all languages but Ada is done by the National Institute of Standards and Technology (NIST). Why should Ada be different? Accordingly, we have entered into an agreement with NIST, which calls for them to assume responsibility for validation effective 1 October 1996. They have effectively taken over as of 1 July 1996.

This was not done without extensive coordination between NIST, the Ada Validation Office, the Distinguished Reviewers, the Ada Rapporteur Group, and other interested parties. The agreement we signed satisfied all parties, and the movement of the validation responsibility will be transparent to the Ada community.

Another function of the AJPO is the maintenance of the Memoranda of Understanding and Agreement with various official parties, among them the American National Standards Institute, the International Standardization Organization, the North Atlantic Treaty Organization, etc. This function will be moved to the Center for Standards in the Defense Information Systems Agency. Again, this move will be transparent to all Ada community members.

The Ada Information Clearinghouse will be expanded into a consolidated Information Clearinghouse, run by the same contractor, IIT Research Institute (IITRI). In addition to information about Ada and reuse, the Clearinghouse will provide information about the Defense Information Infrastructure (DII) and the Common Operating Environment (COE). This way, the AdaIC will stay open and perform the same functions, sponsored by DISA instead of the AJPO.

Other functions of the AJPO will become fee-for-service activities conducted either by IITRI or the Ada Resource Association (ARA). These organizations have entered into extensive discussions about the future of these services and how they can provide them to the community.

For example, the AJPO was able to provide free Language Reference Manuals and Rationales to DoD personnel. Access to these resources will still be free, on-line at the AdaIC. However, a free hardcopy can be obtained only by downloading the files and printing them yourself. With binding (or a notebook in which to keep the pages together), this can get expensive. However, IITRI can sell bound copies of the printed LRM and Rationale for approximately $40 a set. Similarly, the ARA can sell them for the same price; cheaper than downloading and printing!

So I hope that this discussion has cleared up some rumors. Yes, the AJPO is going away. However, its functions will still be in the sustaining base of the government. The Program Office accomplished its mission and will now fold its tent.


As mentioned earlier, this should not be taken as a lessening of the DoD commitment to Ada. Indeed, the newly release DoD Regulation 5000.2 specifically states that Ada is still the required language for software development when the government is responsible for maintenance of the software. This is not an old policy; it was signed in March of 1996! It is clear that the policy is unchanged, even though the AJPO is finishing its mission. Like the F-16, the Program Office may close, but the product will be maintained as an effective part of the DoD's arsenal.

Software Reuse Initiative

Now that I have cleared up rumors regarding Ada, I would like to discuss some very positive facts regarding Software reuse.

The SRI is a success. The SRI, under the leadership of the SRI Program Management Office in DISA, has effectively defined and implemented the Software Reuse Infrastructure. This infrastructure includes a reuse repository mechanism, educational and marketing initiatives, an on-line Reuse Information Clearinghouse, SRI Vision and Strategy, planning documents, and identified Service and Agency focal points.

The key emphasis of the established DoD Software Reuse Infrastructure is to use an architecture-centric, product-line approach. This approach is reflected in present efforts described within this newsletter. The SMART Initiative has as an objective the definition and implementation of a business model that describes how a software architecture-centric approach can be effectively implemented within the DoD. Product-line reuse is described from an Automotive Perspective in an article by Dr. Fred Maymir-Ducharme. CelsiusTech Systems AB of Sweden has demonstrated successful reuse on the level of architectures on the STRIC project.

In the next issue of the newsletter, I will discuss in more detail the elements of the DoD Software Reuse Infrastructure. Also, there will be articles on the tools being developed by DISA to help the Program Manager do software development within this infrastructure.

Charles B. Engle, Jr.
Chief, Ada Joint Program Office

WebAda -- Try Out Ada 95 Code and Tools on the Web

If you're moving up to Ada 95, and if you have access to the World Wide Web, check out the Ada Information Clearinghouse's Web site.

One of the recent advances is WebAda. When your Web browser accesses the AdaIC site, just click on "Compilers" and go down to the WebAda link (or go directly to WebAda lets you find out how well you've learned Ada -- checking your code to see whether it compiles, and showing any errors. Right now, WebAda functions as a syntax checker, "validating" whether your code will compile. Soon, it will run your programs so you can see the results of executing your code. On each page, you'll find links to other Web resources -- such as the Ada 95 Language Reference Manual and the Quality and Style guide.

Additionally, work is underway to make WebAda a tools showcase. You will be able to configure it to use a number of products available on the market.

Several vendors of Ada products have expressed interest in providing their tools for you to try out with WebAda. As WebAda is enhanced, tools will be integrated with it. The first to become configurable was David Wheeler's Lovelace Ada 95 tutorial.

The near-term plan for WebAda is to integrate AppletMagic from Intermetrics and an Interface Description Language (IDL)-to-Ada utility from Objective Interface Systems (OIS). WebAda integration software with "how-to" instructions is also in the works. This will give vendors an opportunity to reach a growing audience and at the same time promote the use of Ada 95.

Doug Smith, WebAda's developer, said, "WebAda works well for both Ada developers and Ada tool vendors. Usually, to reduce the risk of purchasing tools, vendors distribute and developers install evaluation copies. WebAda can be the evaluation mechanism for many of the tools currently on the market."

Comments on WebAda can be sent to Doug Smith (e-mail:

Ada, Java, & Reuse, Too -- A Natural Match

"Java really exists only in the Web, and C++ only off the Web... Ada lets you bridge that gap." S. Tucker Taft, Chief Scientist, Intermetrics, Inc.

New Markets -- ready made for Ada

If you've been wondering why people on the World Wide Web are talking so much about Sun Microsystems' new programming language, Java, then perhaps this article will fill in some of the blanks.

Of course, if you're already familiar with the whys and wherefores, and you write in Ada, you may be wondering how you can tap into the growing market the Java programming language is opening up. For you, the bottom line is simple: You'll soon be able to write in Ada for the Java market.

But a larger benefit is also possible: You may be able to reuse Ada code you've already written; and code you write for the Web may be reusable outside it. According to S. Tucker Taft, Chief Scientist at Intermetrics, Inc., "Java really exists only in the Web, and C++ only off the Web, whereas Ada lets you bridge that gap."

(To find out more about obtaining bridge-building tools, see the inset to the right, "ATIP-P Supports Ada Java Compiler".)

Why Java?

"Java" has the potential to become a lot more than the buzzword of the day. A programming language that was wending its way through Sun Microsystems, Inc., Java has turned out to be ideally suited to adding yet new bells and whistles to the World Wide Web.

Moving beyond the buzzword stage, however, two questions arise: What does it do that other languages can't? And why should Ada engineers take notice?

The answers are that it will let the Web use the processing power of the user's own computer, and that Ada programmers interested in reaching that market may already have written some of the code needed to do so.

Remember p-code?

Java's approach may sound familiar. In most languages, you write the code, you send it through a compiler, and eventually the compiler produces the binary code that will execute on the intended hardware. If you want to run the program on another target, and if your code is portable, you recompile on another compiler.

A Java compiler, however, doesn't produce the executable. Instead, it produces bytecode, or Java-code (J-code); the bytecode is intended for the Java "virtual machine". To perform the desired task, a Web browser such as Sun's HotJava must execute the bytecode. Other browsers, such as Netscape or Mosaic, can similarly incorporate the capability.

The approach may sound familiar -- it's a lot like the "pseudo-code" of UCSD Pascal of many years ago. In a world in which not even disk formats were standardized, p-code could be used as an intermediary step. With p-code compilers on the various end-user machines, your code could reach the widest possible market. When the market settled on fairly well-defined standards such MS-DOS and Macintosh, there was no need for that intermediary. In fact, it seemed a waste for user machines to spend the processing time needed to compile p-code.

Now, however, the "waste" can provide a benefit -- a profit, not an expense.

A need and the opportunity to meet it

The World Wide Web is experiencing major growth right now. As a display medium for text and graphics, it provides a Windows/Mac-like interface that beginners find simple and easy to use. Underlying that interface is the HyperText Markup Language (HTML). An HTML file is basically simple: an ordinary text file with formatting commands embedded between corner brackets. A Web browser on a Mac translates them into the appropriate code for a Mac, a browser on a PC or a workstation does likewise.

But users and developers want to take the Web further. For instance, there are enormous database resources that could be brought onto the Web -- but accessing them takes processing power. Right now, that processing has to take place on the Web host being accessed. Every time a user invokes a process, it has to run on that Web host. Increased demand for information will take up valuable time on Web hosts, and passing complex information takes up valuable bandwidth on the Internet itself.

Java has the potential to make it easier to meet the need for information while conserving bandwidth.

Java bytecode isn't processed on the Web host -- it's processed at the end user's site. With Java, the Web can now tap into a virtually source of processing power. Java won't cure all the Web's growing pains, but it may ease some of them, and open up new opportunities at the same time.

So, should software engineers rush to learn Java?

Well, perhaps -- unless they program in Ada! In which case, the Ada Java compiler (described in the inset) may be an even better idea.

ATIP-P Supports Ada Java Compiler

If Ada is to let you bridge the gap between the Web and non-Web worlds, the first tool you need is an Ada compiler that will produce Java code for Java applications (applets).

The Ada Joint Program Office (AJPO) has provided initial assistance for production of "AppletMagic" -- developed by Intermetrics, Inc., and based on their AdaMagic compiler. A beta version is already completed, and available for downloading over the Web. An initial public release is expected by mid-to-late summer, in the $100-200 range, with added tools in the works thereafter.

At this writing, the integrated development environment is perhaps the most important work taking place. According to S. Tucker Taft, Chief Scientist at Intermetrics, the work taking place in spring had to do with the run-time system. "Since we're taking an existing frontend," he said, the beta version already "supports all the frontend features of Ada" such as generics and enumerated types. With porting the runtime system to Java, features such as tasking and protected objects will be coming in, hopefully before September.

Taft also said this is intended to be "a very open development environment, so you can add tools to it, basically by writing more applets in Java Ada or Java or whatever. You can just add them into the development environment in sort of the way Visual C++ works.... But this will be even more flexible, that is, you can add even more things -- a little more like emacs, if you're familiar with that."

(Assistance to the Ada Java compiler is part of the AJPO's Ada Technology Insertion Program-Partnership (ATIP-P), in which the DoD acts as a sort of venture capitalist to encourage development of products it needs. For more on ATIP-P, see "ATIP-P Makes Awards to Spur Development of Commercial Ada 95 Products", in this issue.)

A good match permits reuse

"From my perspective, one of the most interesting things is that the two languages are completely interoperable. From Java, you can call anything written in Ada, and from Ada, you can call anything written in Java. There's no sort of 'additional effort' involved in calling between the two languages."

Although Java is syntactically an offshoot of C/C++, technical factors appear to preclude a C/C++ Java compiler. A translator might be used to take C/C++ source and give a starting point, but it would still need a fair amount of work to produce usable Java code.

Of course, it is straightforward for a C++ programmer to learn Java. But Taft pointed out that, "you can't actually reuse any C/C++ code. Whereas with Ada, I would imagine that you can actually reuse Ada code that you already have."

One of the advantages here is that "if you put an investment in building, let's say, some complicated applets with a fair amount of packages that you developed and so on, you can use that same code with a conventional Ada compiler and develop a standalone product that runs off the Web -- and recover some of that investment. You can move code in both directions."

"One of the directions we'd like to go is to make that even easier. One of the things that makes it not trivial is that a lot of the applet code will probably be using the graphical user interface libraries that come with Java. We have an Ada interface to that, but you need an Ada implementation for that in your native environment, whatever it might be. So one of the things we are thinking about is taking the Ada interface that exists for the AppletMagic Ada Java world and developing actual native implementations of it. Then you could really take the same code that you had running in the Web world and run it in the non-Web world and still have it work."

For further information

For information on Java in general, Sun's Web site is:

For information on the Ada Java compiler, Intermetrics' Web site is:

See also:

New DoD 5000.2-R Reaffirms Ada Adds Reporting Requirements for Major Information Systems

5000.2: "Software shall be managed and engineered using best processes and practices that are known to reduce cost, schedule, and technical risks."

On March 16, 1996, the Secretary of Defense signed the new DoD Directive 5000.1, "Defense Acquisition", and the Deputy Secretary of Defense signed DoD Regulation 5000.2, "Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs".

The new 5000 documents supersede 1991 versions. (The policy on Ada will also be stated in a new version of DoD Directive 3405.1 "Computer Programming Language Policy". Work is presently underway on revising DOD Directive 3405.1, the current version of which is dated 1987.)

The Ada requirement

In the new DOD 5000.2-R, the Ada requirement is found in section 4.3.5, "Software Engineering".

"Software shall be managed and engineered using best processes and practices that are known to reduce cost, schedule, and technical risks. It is DoD policy to design and develop software systems based on systems engineering principles, to include:

1. Developing software system architectures that support open system concepts; exploit commercial off-the-shelf (COTS) computer systems products; and provide for incremental improvements based on modular, reusable, extensible software;

2. Identifying and exploiting software reuse opportunities, Government and commercial, before beginning new software development;

3. Use of the Ada programming language to develop code for which the government is responsible for life-cycle maintenance and support. Additional guidance is contained in DoDD 3405.1;

4. Use of DoD standard data. Additional guidance is contained in DoDD 8320.1;

5. Selecting contractors with the domain experience in developing comparable software systems, a successful past performance record, and a demonstrable mature software development capability and process; and

6. Use of software metrics to effect the necessary discipline of the software development process and assess the maturity of the software product.

7. Ensuring that information warfare risks have been assessed (DoDD TS-3600.1)."

Reporting requirements for Major Automated Information Systems

The new reporting requirements are in Appendix V, "Major AIS Quarterly Report".

Section I.F, "Management Structure", calls upon projects to describe "key program and software development measures that support the program management process." Among the measures that should be addressed, paragraph (6) lists "Technical Adequacy -- regarding software reuse, use of Ada for software development, and use of approved standard data elements."

Under Section I.H, "Major AIS Interface", projects are called upon to "state compliance with the Technical Architecture Framework for Information Management (TAFIM) and Ada standards". Also, they are to show how "standard data and reused software will be utilized".

Obtaining copies

For those with suitable browser software (Netscape, Mosaic, etc.), electronic copies of the new documents are available via the World Wide Web. You can link to them via the Ada Information Clearinghouse's Web site, under the "Policy and History" page. Or you can go directly to the Acquisition Systems Management Home Page maintained by the Defense Acquisition Board Executive Secretary.

DODD 5000.1 takes up approximately 51 kilobytes in the Microsoft Word 6.0 file available on the Web; it prints to 14 pages hardcopy; the main part of 5000.2-R is nearly a megabyte and prints to 121 pages; there are also additional files of interest.

DoD installations without Web access may be able to obtain hardcopies through their normal document channels. If you need further information on obtaining copies, please feel free to contact the Ada Information Clearinghouse:

P.O. Box 1866
Falls Church, VA 22041
tel: 1-800-AdaIC-11 (232-4211),
703/681-2466; fax: 703/681-2869

The ASEET Team -- Ada's Foot Soldiers A Decade of Service to the Ada Community, and still counting!

Anyone involved in Ada and software engineering since 1986 has probably come in contact with products from the Ada Software Engineering Education and Training (ASEET) Team. Even if you haven't, the chances are that some of the training and educational products you have been exposed to had some of their roots in the ASEET Team. Over the past decade, the ASEET Team has produced literally thousands of slides of course material, been involved in numerous DoD reports, and conducted several hundred courses, lectures, workshops, tutorials, and symposiums.

Founded in 1986, the ASEET Team grew out of the Software Engineering Working Group (SEWG). Funded by the Ada Joint Program Office (AJPO), the ASEET Team was initially chartered to promote the growth of Ada and software engineering within the DoD, other Federal agencies, and academia. The "foot soldiers" of Ada, the ASEET team is composed of DoD volunteers (both civil service and active duty) -- members who willingly give their time to promote Ada and software engineering wherever and whenever an audience willing to listen can be found.

Currently, ASEET Team members have a combined total of over 100 years of Ada/software engineering experience, and over 50 years of academic and training experience. All Team members have technical degrees, and approximately 40% have Ph.D.s. Their expertise encompasses real-time flight systems, nuclear reactors, command and control, simulation, information systems, and supercomputing.

The track record

The ASEET Team's goal was not to compete with commercial organizations; there were sufficient companies available for in-depth education and training. Instead, they have provided a nucleus to organizations that wanted experts to come in and start the Ada and software engineering effort rolling. Their role has been to help Ada proponents bootstrap their organizations.

Over the last 10 years, the Team has produced over 25 different courses, ranging from "Introduction to Ada" (and now Ada 95!) to more advanced technical courses covering real-time programming, reuse, management techniques and transition, and object-oriented programming. In addition to assisting Ada-insertion efforts at such schools as the Univ. of West Virginia, the Univ. of California-Northridge and others, they have also provided assistance at all Service academies and military training centers.

One of their most visible efforts has been the annual ASEET Symposium. (This year's was the tenth.) These symposiums have brought in distinguished educators from as far away as Russia and Australia. The symposiums are targeted to smaller colleges and universities interested in Ada. The symposium provides educators a low-cost alternative to other Ada conferences and workshops. This effort also gives these schools access to experts willing to help them introduce and use an Ada curriculum.

In addition to the symposiums, they also hold annual hands-on workshops, where they can work with faculty and commercial developers to explore the Ada language in depth.

The viewpoint

The ASEET Team never views Ada as an end in itself: rather, Ada is viewed as the best tool for implementing software engineering concepts and principles. This viewpoint ties in perfectly with the current AJPO-assisted megaprogramming effort. This project is designed to introduce modern software development practices, including software engineering with Ada, at the high-school level. This allows students, who might otherwise initially learn ad hoc software development, to learn proper software engineering and design concepts. This summer, the ASEET Team worked with Sacred Heart University (Fairfield, Conn.) on a workshop for high-school teachers. Funded jointly by the National Science Foundation and the Connecticut Department of Education, this workshop gave Connecticut teachers a chance to attend an intensive two-day hands-on workshop to help them insert Ada and software engineering at their schools. Another workshop, given in conjunction with the State of Utah, will also help to educate high-school teachers.

Looking to the future

The ASEET Team recently joined the Federation of Government Information Processing Councils (FGIPC). As a council within the FGIPC, the ASEET Team will be spreading its vision of Ada and software engineering to a broader spectrum of government agencies that could benefit from their pool of experts and educators.

Among other things, the ASEET Team is going to offer general software-engineering courses for a fee in cooperation with FGIPC Training Seminars. Earnings will help support ASEET as part of their transition to a self-sustaining approach. Seminars will address software design and analysis, object-oriented design and program development.

Although not specifically Ada, the courses fit well with the ASEET Teams' view of Ada as a key enabling tool for the principles of software engineering. If you have ideas for courses to reach a wide audience, the ASEET Team welcomes your input.

Interested in learning more?

The ASEET Team is developing a World Wide Web home page, courtesy of Embry-Riddle Aeronautical University, Prescott, Ariz.

Additional information can be obtained from:

Major David Cook (current chairperson)

Eugene W. P. Bingue

Leslie Dupaix

AJPO Assists Service Academies Moving Up to Ada 95

The various Service academies play a critical role in providing the foundations for a future officer's approach to Defense computing, and later in refining skills and understanding for the officer who seeks advanced study.

For this reason, the Ada Joint Program Office (AJPO) has been active in providing assistance to the academies as they move up to Ada 95. Assistance has been provided depending on the needs and resources of each institution. Some times, this has taken the form of mentoring; other times, it has been provided in the form of needed software or hardware.

Following are some of the activities currently taking place.

West Point: Ada 95 for First-Year Programming Courses

The U.S. Military Academy (USMA) Electrical Engineering and Computer Science Department (EECS) at West Point is migrating from Pascal to Ada 95 in their ACM CS-1 equivalent freshman-level programming class, with a phase-in to Ada 95 in higher-level courses to be accomplished over time. The AJPO is funding faculty Ada 95 training, and mentoring to assist with courseware development and implementation.

Approximately eight faculty members are involved in developing Ada 95 course materials for distribution on the Academy's local-area network and World Wide Web site ( The students will be working on PCs equipped with Windows for Workgroups, as well as a Unix environment.

Naval Postgraduate School to use Ada 95 as introductory language

On March 22, 1996, the Computer Science Department at the Naval Postgraduate School made the decision to use Ada 95 as the first computer language in its graduate education. It will be the main language used to teach principles of programming and information-systems management.

The significance of this change will go beyond the classroom because it will encourage Ada's use in research projects leading to theses. More importantly, it will encourage the use of Ada in solving open research questions challenging DoD research scientists. According to Dr. Luqi, Professor of Computer Science and Chair of the Software Engineering Track, the change to Ada 95 will affect all of the Naval Postgraduate students as well as "distance-learning" graduate students from DoD and Government labs. Their theses will directly impact DoD and Navy software research and development projects.

The AJPO will assist in creation of appropriate graduate-level courseware by providing training and the Academic Ada textbook/compiler and expert mentoring in curriculum development. The new courses will be taught at the Naval Postgraduate School using a hardware lab supported by the AJPO. The AJPO is also supporting upgrading the Computer-Aided Prototyping System (CAPS) to Ada 95. This system is a research tool that generates Ada prototypes of real-time systems. CAPS is used in teaching software engineering and real-time systems design at the Naval Postgraduate School and other universities.

Air Force Academy converting courses, software to Ada 95

The U.S. Air Force Academy's Astronautics Department is in the process of converting their computer problem-solving curriculum to Ada 95. The Academy plans to use Ada in six different courses ranging from freshman to senior level. The Department's goals are to train faculty in Ada 95; to implement the AJPO-supported Academic Ada 95 compiler; and to develop courseware for six Ada-95-centered courses. Additionally, the astrodynamics software library will be converted to Ada 95.

The AJPO is providing training, hardware, and software support to the Academy with the goal of supporting implementation of a prototype Ada 95 curriculum in a military academy, involving majors other than Computer Science and Electronics Engineering. Starting this fall, Ada 95 will be the introductory programming language taught to freshmen by the Computer Science Department.

The Academic Ada 95 Compiler and Textbook was used for the first time in a summer-school Computer Science class taught at the Air Force Academy. At the conclusion of the course, the students favorably evaluated the compiler and textbook as easy to use and understand.

ATIP-P Makes Awards to Spur Development of Commercial Ada 95 Products

One of the major goals of the Ada Joint Program Office (AJPO) is to continue to improve Ada's position in the commercial marketplace. An important initiative in this regard is the Ada Technology Insertion Program-Partnerships (ATIP-P) -- which recently sought competitive proposals by commercial companies for tools, bindings, and other products supporting Ada 95.

Under ATIP-P, vendors will own their products and be encouraged to commercially market them to the general user. The government will recoup its investment by receiving significant discounts or a certain number of free product licenses.

Managed by the Department of Energy's Idaho National Engineering Laboratory (INEL), ATIP-P received proposals for a wide range of products, and recently announced ten awards. The products will provide additional resources for Ada 95, and will be available in the fourth quarter of 1996.

The products

The ten private sector companies and the areas their tools will address are:

* AdaSoft, Inc., Laurel, Md. -- Provide Internet-accessible Ada 95 training.

* DDC-I Inc., Phoenix, Ariz. -- Provide Ada 95 software test tools based on the Ada Semantic Interface Specification (ASIS 95) standard.

* Intermetrics, Inc., Cambridge, Mass. -- Enter Ada 95 into the expanding needs of the World Wide Web and Java "applet" market by providing an Ada 95 to Java J-code compiler. (For more on this, see "ATIP-P Supports Ada Java Compiler" in this issue.)

* McKee Consulting, Littleton, Colo. -- Provide an Ada 95 development environment for the Apple Macintosh.

* Noetic Software, Inc., Willow Grove, Penn. -- Provide bindings to the MIL-STD-1553B data-interface bus standard and the designated commercial standard.

* Objective Interface Systems, Inc., Reston, Va. -- Provide distributed processing and client/server interfaces using the Object Management Group's Common Object Request Broker Architecture (CORBA).

* OC Systems, Inc., Fairfax, Va. -- Provide Ada 95 extensions to the IBM VisualAge programming environment and object libraries.

* R.R. Software, Inc., Madison, Wisc. -- Provide object-oriented bindings to the Microsoft Windows' Win 32 development environment.

* Stony Brook Software, Thousand Oaks, Calif. -- Provide a fast/optimized compiler and graphical user interface (GUI) development environment.

* WPL Laboratories, Inc., Haverford, Penn. -- Produce Web-based Ada components to position Ada 95 to share in the Web's rapid growth.

As these projects develop, further information will be available through the Ada Information Clearinghouse (800/232-4211, 703/681-2466.

National Science Foundation Sponsors Its First Ada Workshops

For the first time, the National Science Foundation (NSF) sponsored a workshop specifically geared to Ada. Held June 3-14, at Illinois State University, the workshop was titled "Ada Throughout the Undergraduate Curriculum". It focused on Ada's suitability for teaching concepts such as data abstraction, software engineering, and object-oriented programming at all levels of a computer-science curriculum.

The workshop was intended for faculty planning to use Ada in their courses; participants were expected to initiate curriculum projects to be completed during the 1996-97 academic year.

Also, the NSF jointly funded a summer workshop on Ada with the Connecticut Department of Education. This was an intensive two-day hands-on workshop to help high-school teachers move up to Ada and software engineering at their schools. Held at Sacred Heart University in Fairfield, Conn., the workshop also had participation from the Ada Software Engineering Education and Training (ASEET) Team. (For other ASEET Team efforts, see "The ASEET Team -- Ada's Foot Soldiers".)

Information on the Illinois workshop is posted on the Web.

SMART Initiative -- Reuse Trade Association Forming

"...the SMART Initiative is to define and implement a business model that describes how a software architecture-centric approach can be effectively implemented."

The U.S. Army Communications-Electronics Command (CECOM) Software Engineering Directorate (SED), Fort Monmouth, New Jersey, has initiated an effort focused on solving the business issues associated with architectures and software reuse. Between June 1995 and January of this year, several Software Reuse Roundtable discussions with Industry representatives were held to discuss business issues and alternative business models to describe how architecture technology can be adopted in the marketplace. The Software Market-driven Architecture Trade Association (SMART) Initiative resulted from these sessions.

The challenge

Much has been published on the benefits associated with common software architectures and software reuse, including decreased development costs and time, increased productivity and quality, reduced risk, etc. To date however, Department of Defense (DoD) and Industry initiatives have not been effective in realizing all of these benefits.

The lack of effectiveness is primarily due to two issues. The first of these issues has been the historic lack of focus on software architectures as the key technical "enabler" to realizing such benefits. Only lately has the importance of software architectures begun to be recognized.

The second issue has been the inadequate attention paid to the business issues associated with the development and adoption of common software architectures and reusable software. These business issues include ownership, licensing benefits and profitability (write once, license many), liability issues, market size, market share, etc.

SMART Initiative's objective

The objective of the SMART Initiative is to define and implement a business model that describes how a software architecture-centric approach can be effectively implemented within the DoD and the CECOM SED environment, while considering and addressing business and technical issues.

To define and successfully implement the model, the following steps are being taken:

1) Define a business model and resolve the business issues and barriers associated with implementing the model.

2) Conduct a pilot project that demonstrates the feasibility and benefits of the business model.

3) Gain widespread adoption of such an approach.

The business model

As mentioned, several Industry Software Reuse Roundtable sessions were held to discuss business issues and business-model alternatives. These initial sessions produced an outline of a business model for implementing an architecture technology. The model can be characterized as follows:

* The desired outcome is to improve the cost effectiveness of the application software business.

* The focus is to be on application product lines and the development and adoption of architectures for these product lines.

* The architectures are to be developed by domain-specific trade associations.

* The intent is to incentivize broad Industry participation, both defense and commercial, in the trade associations.

* CECOM will require conformance to the architecture in the development of systems and technology demonstrations. In addition, CECOM will allow software developers to retain the rights to the software implementations developed either under corporate investment or under contract. This should enable SED and its customers to leverage a broader marketplace.

Steering Council, Pilot Trade Association

With the emergence of the SMART Initiative, a SMART Steering Council (presently 22 companies) was established, which is based on the same model as the Software Reuse Roundtable sessions previously held. Members of Industry, previously defined as those who do significant system and software development for CECOM and SED, have been and will continue to be invited to participate. In addition, commercial industry will be invited to participate. The product, therefore, of the SMART Steering Council is the business model and resolution of the associated barriers and issues. The Steering Council does not directly oversee any of the activities of the trade associations.

The first part of the pilot project is the establishment of a trade association for a specific application domain. The SMART Initiative has selected the area of resource management planning/mission planning as the subject of the SMART Pilot Trade Association. The product of the trade association is to be an architecture standard for the selected application domain. The second part of the pilot project is the independent Industry development of software implementations or implementation components that comply with the architectural standard developed by the Pilot Trade Association. The resulting implementations should represent "plug & play" components that become part of the competitive process associated with developing or evolving implementations of the domain functionality. The third part is the specification of the application domain architecture and the solicitation of implementations as part of a future CECOM solicitation.

The final and target goal is the demonstration of the business model through resulting widespread software implementation at multiple levels within the DoD and the commercial community.

For further information

For information on the SMART effort, see their Web site, or contact:

John Willison
tel: 908/532-2342


Mike Lombardi
tel: 908/532-2029

The STARS Web Site: A Goldmine for Both Ada and Reuse

"I would suggest browsing through all of the STARS Web pages for an overview understanding of the product-line approach." -Linda Brown, STARS Program Mgr.

For the past several years, software engineers have been able to look to the Software Technology for Adaptable, Reliable Systems (STARS) Program for important, sometimes breakthrough, work on the challenges facing software development today. Sponsored by Defense Advanced Research Projects Agency (DARPA), STARS has an impressive record in areas vital to software engineering, Ada, and reuse.

With its three cooperating prime contractors (Boeing, Loral Federal Systems, and Loral Defense Systems-East -- the latter two have recently become part of Lockheed Martin Tactical Defense Systems) and a large number of subcontractors, STARS has focused on accelerating a change in the way software is developed within the Department of Defense (DoD). That change is a shift to a product-line approach/paradigm that is process-driven, domain-specific, reuse-based, and technology-supported.

Now, with a large body of work to its credit, the STARS Program's work for the past year or so has included implementing its planned termination -- and ensuring the widest possible public access to its products.

The Ada Joint Program Office's (AJPO's) Ada and Reuse Library, for instance, recently received a number of hardcopy documents when the STARS Technology Center closed. More important, however, are the software and key technical documents stored at DARPA's Asset Source for Software Engineering Technology (ASSET).

These are now available to the public at large via the World Wide Web -- no account or other registration needed. The Web site is, and Web browsers such as Mosaic, Netscape, etc., can take you through STARS' impressive resources.

Linda Brown, STARS Program Manager, discussed some of those resources. As a beginning, she pointed out that, from an Ada perspective, the Ada courseware (much of it supported by the Ada Joint Program office -- AJPO) is "one of the more interesting things." ASSET, she said, is "probably the only place you'll find all of that material highlighted and made readily available..."

"From a reuse perspective, there's so much interesting material that I would suggest browsing through all of the STARS Web pages for an overview understanding of the product-line approach -- and then accessing the papers for information on specific topics like reuse, architecture, process, and so forth. Or view the demo project pages and then go to their experience reports for lessons learned."

For architecture issues, she suggested the Software Architecture Home Page, which can be accessed through the Loral Defense Systems-East button on the STARS home page. And she also mentioned a "really nice tutorial on cleanroom".

The scheduled closing of the STARS Program Office was 30 June 1996. However, even with the resources already available via the Web, more will be coming on line as a few remaining STARS efforts finish up and deliver their products to ASSET. Check out the STARS site frequently to keep tabs on what's being added.

Product-Line Software Reuse from an Automotive Perspective by Fred Maymir-Ducharme, PhD

My son understood the value of reuse at quite the early age. His friend Bobby next door had a new 4-wheel drive truck to play with, and he didn't. His allowance wasn't enough that week to go out and buy one like his friend, so he decided to make his own from the array of cars and trucks in his toy box. He took the axle and wheels from a big plastic car to replace the little wheels on one of his average-looking play trucks. He then ripped out the shiny engine from a model-kit car and glued it on the hood of this project. He ended up with a pretty mean-looking 4-wheel drive truck, similar to Bobby's and yet unlike anyone else's in the neighborhood!

Reuse is basic to every engineering discipline; and it's taking software engineering quite some time to realize this is the fundamental key to becoming a "disciplined" engineering practice. Electrical engineers understand the value of having standardized computer chips -- where their functionality and interfaces are well defined and understood (taught in schools, readily available and documented in numerous manuals). Chips may include merely simple "and," "or," "nand," and "nor" operations (component reuse in the small) or go all the way up to Very Large Scale Integration (VLSI) (component reuse in the large).

Electrical engineers also have breadboards and schematics (analogous to software architectures) to help them combine and/or interchange chips and develop (or reengineer) new electronic devices. Granted, electrical engineers are only dealing with binary bits (0's and 1's), while software engineers can have an unlimited range of data and messaging types; but the size and complexity of an oscilloscope, a mainframe, or a massively parallel computer give credence to the size and complexity of their problems and solutions. When asked to develop a new computer, an electric engineer will not go back to the drawing board, capture the requirements, design the computer from scratch and then move into wire-wrapping and-gates, or-gates, etc. (analogous to the way we develop most software these days). To put together a new computer, the electrical engineer will (re)use existing schematics, breadboards, VLSI chips -- even bigger components like disk drives, monitors, and printers. Likewise, a civil engineer builds a house from a variety of architectural blueprints and standardized components: nails, screws, hinges, 2x4's, 2x8's, doors -- or sometimes, on an even larger reuse scale, prefabricated home components for roof and wall structures. These exemplify the publicly-held, formally transmitted, experience-based technology base of engineering models essential to a mature engineering discipline.

But the intent of this paper is not to discuss reuse in other engineering disciplines. We will look at how simple reuse looks to the automobile business. It's easy to explain terms like domain-specific, process-driven, architecture-centric, and technology-assisted engineering to someone who understands cars. Reuse is a major element of any mature, disciplined engineering practice, even aspects of "automotive engineering" that aren't commonly called "engineering".

Engineering paradigms

The automobile industry has many desirable attributes, analogous to those sought by a disciplined software-engineering practice; for example, successful software factories mirror automobile factories in a number of ways.

* Domain-specific -- Auto shops and dealers specialize in different ways and from many perspectives. Some distinguish between cars and trucks, while others specialize in performance vehicles.

Analogously, software domains distinguish families of related systems from different perspectives. Within the context of software, a domain (as used in terms such as domain engineering and domain analysis) refers to a group of common or related systems. These systems may share a common design and components (e.g., relational databases), common capabilities/services (e.g., software-engineering environments include the capability to compile, edit and debug software) or common technology (e.g., compilers are all built on lexes and parsers.)

* Process-driven -- Assembly lines revolutionized the automotive industry. Factories put cars together, and dealerships sell and repair them -- all using well defined steps and rules. The software analog, the application-engineering process, is pretty simple to see.

* Architecture-centric -- Automotive architectures include: the chassis, standardized parts/components (e.g., engines, transmissions, wheels, etc.), and connections (e.g., 1/2" nuts and bolts, 14" rims and P195R14 tires, etc.).

Likewise, a software architecture is made up of components -- e.g., a command center includes a database management system (DBMS), message handler, geographic information system, etc. The connections might be varying application program interfaces and middleware such as the database language SQL. The architecture would also include constraints (e.g., realtime system constraints and application-specific component constraints) and the associated decision rationales.

* Technology-based -- Technology can include concepts, methods, processes, and tools. The automotive industry has leveraged numerous concepts such as automation, assembly lines, and repair shops. To ensure the safety of automobiles, there are Total Quality Management methods, such using crash test dummies. Automotive factories have very well defined and continuously improving processes. And there is certainly no shortage in the automotive field of power tools and robotics to support auto engineering and manufacturing.

Software technology includes concepts such as domains, assets, software architectures, and reuse libraries; methods such as Rumbaugh's Object Modeling Technique for object-oriented analysis and design; processes such as application engineering, domain engineering, and information/enterprise engineering; and tools for compiling code, modeling analyses, specifying architectures, etc.

Auto repair and maintenance share considerable similarities with software maintenance:

* The life span of a car (or DoD software) may be 20+ years.

* You may need to take it back for defects (version control, recalls).

* May need to replace parts (shocks, battery, tires, etc.) -- likewise, a software application or system may need a module replaced to use a new algorithm or be upgraded to a more recent release of a commercial off-the-shelf (COTS) component.

* It can be repaired or serviced by the dealer (original developer) or by a repair shop (analogous to a maintenance organization).

And an auto customization shop is very much like a reengineering shop.

* You may want to improve performance (bigger engine or transmission).

* You may want to add safety (traction bar or air bags), etc.

* Major reverse engineering may include stripping a car down to the chassis and drive train, and then forward engineering with a new engine and body.

Software can be reverse engineered from code to design and if necessary, from design to requirements. There are tools and techniques to reverse engineer applications to discover their software architecture.

Product lines are primarily an economic decision -- based on supply and demand

Automobile dealers really understand the product-line approach. The product-line approach extends and constrains systematic, domain engineering to meet the business-specific needs of an organization, based on business analyses and product-specific market lifecycles.

They may not be familiar with the term "domain," but maybe the old "line-of-business" analogy will bring them back into the discussion. The automotive market (in software terms, the "problem space") can be described from different perspectives. Some dealers (and manufacturers) deal only with the automobile domain (e.g., Saturn), while others broaden the scope to include trucks and recreational vehicles (e.g., Ford and General Motors).

Obviously, there's considerably more commonality across a small, well-bounded domain like passenger cars -- they all have a chassis, a steering wheel, an engine, four wheels, and a body. There's still a considerable amount of commonality across a broader-scoped domain that includes trucks and recreational vehicles -- they include steering wheels, engines, wheels, etc.; yet they may have six wheels instead of four, more ruggedized chasses, suspensions, and engines, etc.

So also, a small software domain (e.g., compilers or DBMSs) has more commonality to exploit than broader and larger domains (e.g., a family of related systems such as the Army's Sustaining Base Information Services (SBIS) or the Air Force's Global Combat Support System (GCSS) where common data/objects and functions are shared, but considerable variance across the systems reduces the "density" of commonality. But it is in these large systems that a disciplined engineering approach is most needed. Domain engineering not only exploits the commonality across these systems, but engineers the variance to ensure interoperability and avoid "stovepipe" (non-interoperable) applications.

In either case, all of these offer various product lines (in software terms, "a solution space"). Most auto makers (e.g., Chevrolet, Ford, Chrysler, Honda, Toyota, etc.) offer a variety of product lines. They offer a variety of styles: e.g., small, medium, and large cars, coupes, convertibles, two-door, four-door, hatchbacks, etc. And they offer a variety of options: e.g., AM/FM radios, AM/FM/cassette stereos, stereos with CD players, leather or vinyl seats, air-conditioning, etc.

The key to product lines is market demand -- there are unlimited options in the automotive market, but not all are available from any single automotive manufacturer or dealer. The automotive domain is continuously analyzed to identify the most economically advantageous subset of automotive styles and options that meets the majority of the market demands. An automotive company can meet 80-90% of the market needs (domain requirements) with only 40-50% of the market-defined solutions.

Likewise, the equivalent software (product line) approach is to support the capabilities/requirements within the selected domain that makes the most economic sense. This approach has been very effective for several software companies in very specialized domains. AT&T Bell Labs, for example, has a well defined 5ESS (System 5 -- Electronic Switching Systems) product line, where the features and capabilities of each product release are predetermined and the list of available features and capabilities are the same for all of their customers.

It is important to consider the business model behind product lines. A product line optimizes production to meet a majority of the market with the minimal set of components -- maximizing the potential for profit. A product line includes a well defined (and limited) set of options and has made the decision not to support additional options or specializations because of economic analyses.

It's important to differentiate here between market products and market product lines. DeLorean, for example, developed and sold a single product, as did Ferrari, Yugo, and others. These products obviously leveraged off existing auto industry-standardized auto architectures and auto components, but they customized their products to meet specialized market needs not met by the major auto manufactures like Honda, GM, and Ford. It should be noted that in these cases, either the custom-made product is very expensive and for a small portion of the market (e.g., Ferrari) or the company was unable to remain in business (e.g., the Yugo and DeLorean).

A software development organization that hasn't optimized to a product-line, software-engineering discipline likewise runs the chance of failure and cannot compete efficiently against a product-line-oriented organization.

Reusable components and component brokerage

The automobile industry has matured to the point where de facto standards govern most of the automobile architecture -- components, connections, and controls.

* Components: nuts/bolts, parts, engines, chassis, etc.

* Connections: gaskets, threads, etc.

* Controls: the engine runs the transmission, which turns the axle(s), etc.

Auto shops can be viewed as equivalent to centralized software repositories. If they are properly organized, and if the specs for your model are available in the shop, you can generally find what you are looking for. Otherwise, you can take a chance.

Looking ahead

In software, the state of the practice is somewhere between the horse and buggy days and Henry Ford's manufacturing line. The production of software is evolving into an engineering discipline -- which leverages a stable technology base (domain models, software architectures, product-line components, etc.), applies routine engineering, and develops reliable products using validated components and processes.

Class libraries are a modest example of this process, akin to the stock room an ordinary worker can access. Software factories will evolve as a larger demonstration of the process.

Automobile manufacturers have learned to separate factory costs (e.g., facility, tools/equipment, training and research) from product costs (e.g., raw materials, labor and utilities. They have learned that the additional capital investment in the factory yields increased productivity and reliability, resulting in lower costs per product. A software factory must likewise separate the factory costs (e.g., domain engineering, domain management, process engineering, integrated software-engineering environments, software architectures, training and metrics) from the product costs (e.g., application engineering, integration, testing, COTS licensing and configuration management). A disciplined, software-engineering product-line paradigm can then realize the same benefits: faster, better and cheaper.

What will the impact be? What will things look like? We don't know -- any more than Henry Ford could have predicted the social consequences of the Interstate Highway System. We can suspect, though, as the automobile industry found in the 1970s and 80s, that if we don't meet the needs of the market, others will!

CECOM Issues Reusable Software Catalog

In pursuit of efforts to reuse software, it is sometimes easy to overlook the fact that the Department of Defense already possesses probably the world's largest "repository" of potentially reusable code. One organization that is aware of these potential resources is the Software Engineering Directorate (SED) at the U.S. Army Communications-Electronics Command's (CECOM) Research and Development Engineering Center (RDEC).

The SED has been particularly concerned with development of software that is carefully designed, modular, and maintainable -- key factors in reuse. While the SED is making significant strides in efforts to get government and industry to design all new software for reuse, they also recognize the potential opportunity for reusing portions of the vast repository of existing software used in deployed weapon systems that they maintain.

Now other DoD projects will find it easier to avail themselves of those resources. A large quantity of CECOM software can be made available to organizations with a bonafide need, and the SED has created CECOM's Battlefield Software Catalog to give you a look at what's available.

The catalog is accessible via the World Wide Web on's Homepage or via the Web site.

The catalog

The SED Software Catalog provides an index to deployed CECOM software that can be reused in part or in full for the development and/or evolution of other systems. The catalog contains descriptions of the software applications used in CECOM-supported weapon systems, and is organized by the system functional areas: avionics, command and control, communications, fire support, intelligence/electronic warfare (IEW), satellite communications, tactical communications, and training-modeling-simulation.

For each system, the catalog provides a functional description of the weapon-system application, identification of the system's hardware computer platform, and identification of the host environment. A lower-level breakdown is also provided, which consists of all Computer Software Configuration Items (Computer Program Configuration Items) that make up the weapon system software application, together with the size, programming language(s), and a functional description for each CSCI.

More coming on-line

The catalog is restricted to "deployed" weapon systems that CECOM presently supports, because these software baselines are under government control. Systems under "development" will be added to the catalog as they are accepted and transitioned to the government.

CECOM invites widespread access to this catalog, and welcomes any comments/suggestions for improving its utility.

For further information

Fort Monmouth, NJ 07703
tel: 908/532-2423; DSN: 992-2423

STRIC: A Full-Scale Proof of Reuse and Portability By Bjorn Kallberg, PhD, Senior Scientist, CelsiusTech Systems AB

"By reducing the amount of programmers' unscheduled improvisations, the design team was able to recognize in full the benefits of reuse and portability."

For reuse to live up to its potential, it is not enough to reuse individual code components. Reuse can benefit the entire application universe -- architectures in particular. An example of successful reuse on the level of architectures comes from CelsiusTech Systems AB of Sweden and the STRIC project (Stridslednings-central -- Combat Control Center.)

The STRIC system is a large command, control, and communication system for the Swedish Air Force. Its tasks are fighter-interceptor control and all the additional functions needed in such a system. The first version of the system was delivered, on time, to the customer a year ago. The customer response has been very favorable.

Two further updates are on schedule; the second is just now taking place. The current delivery has approximately 1.3 million lines of Ada code, and the last one will have 1.6M lines of code.

Development of this system involved two interesting challenges: porting a system architecture to a new application area, and porting to a new platform.

Applying the architecture

CelsiusTech had earlier developed a number of ship systems based on the Ship System 2000 system architecture (SS2000), but wondered whether the architecture could also be applied on a system in a completely new application area. During the preliminary design, the answer appeared to be "Yes." It was estimated that more than 50% of the system could be reused.

The degree of reuse varied among the different layers. In the general application framework, the base system, almost everything could be reused. Moreover, much of the application layer also had similar functionality, with a corresponding degree of reuse. Other areas were completely different, offering little or no opportunity for reuse. The table below shows the estimated level of reuse; the percentages listed here document the portion of the delivered code that is reused from SS2000:

        Area                    Level of Reuse
        Command and control     10%
        Surveillance            40%
        Communications          20%
        Man-Machine Interface   80%
        Base system             80%

Changing the platform

The other challenge to system design was the change of computer platform. The SS2000 ship systems are based on M68000 processors, running a real-time kernel called OS9; the STRIC system, however, was to be based on a POSIX platform.

Fortunately, the SS2000 was designed to be portable. The application does not directly use the existing operating-system calls, but uses only the base system components, which define a relatively narrow interface. By porting only the base system components that isolated the operating system, the complete application could be ported. An initial project was set up to verify the portability. In less than 1000 man hours, the initial port was done: 400,000 lines of code in 6,000 modules. The porting rate was more than 500 lines per hour.

Ada's role

How much of STRIC's success is due to Ada?

While no system is portable or reusable just because it is written in Ada, the use of the programming language has made it possible to ensure that the intent of the system architecture is followed and that no short cuts are taken. By reducing the amount of programmers' unscheduled system improvisations, the design team was able to recognize in full the benefits of reuse and portability.

[This updates an earlier report by Dr. Kallberg, which can be found in Ada-Europe News, October 1994, No. 19, pp. 25-26.]

AJPO Mentors, Assistance Smooth the Path for DoD Projects Moving Up to Ada 95

As more projects within the Department of Defense move up to Ada 95, it is important to have the most up-to-date information and to share lessons learned with other projects. The Ada Joint Program Office is assisting that process with selected Ada 95 Transition Projects (a follow-on to the Ada 95 Early Adopter effort).

Under this effort, the AJPO supplies in-kind support in the form of both formal classroom training and hands-on mentoring. The project thereby reduces the risk of adopting new technology, and the AJPO and the Ada community gain valuable lessons-learned about Ada 95. In turn, these lessons help reduce the risk to follow-on projects and help to mature Ada 95 technology by providing feedback on its usage under project conditions.

Six such efforts are described below. (Others include those described in "AJPO Assists Service Academies Moving up to Ada" on page 8.)

Air Force Technical Applications Center, Special Studies Workstation

This Special Studies Workstation project is being conducted in Melbourne, Florida, under the auspices of the Air Force Technical Applications Center (AFTAC) at Patrick Air Force Base. AFTAC supports treaty monitoring activities associated with the Nuclear Test Ban and Comprehensive Test Ban Treaties. The Special Studies Workstation will provide a site-specific meteorological modeling and analysis environment to manage day-to-day mission-support activities.

The Special Studies Workstation is part of the Integrated Research and Evaluation System (IRES). IRES provides a suite of transport and diffusion models, database interfaces, local file management, and a wide range of data-visualization capabilities. The Special Studies Workstation will augment IRES with a host of new graphical display programs that will visualize weather data, model results, and atmospheric pollutant measurements. In addition, the Special Studies Workstation will provide site-specific configurations that allow users to quickly set up their work environment for a selected area of interest.

The current software consists of 500,000 lines of Ada 83 code running on Sun Solaris. It was developed by the contractor, ENSCO, and represents a layered functional approach, to maximize reuse throughout the system. Each layer embodies a certain capability of the system. To create a new model or display, an engineer makes use of the capability layers already in place. This has allowed several models and displays to share the same code, thus reducing maintenance and new development time. This approach requires the engineers to build software from existing units whenever practical.

The application is being ported to Ada 95 from Ada 83. The new features are being designed using an object-oriented (OO) approach, specifically Object Modeling Technique (OMT). The resulting OO design will be implemented with Ada 95. The project staff is highly skilled in Ada 83 and has received training in Ada 95 and OO. The system also interfaces with several commercial, off-the-shelf (COTS) products -- including X-Windows, Motif, Oracle, UNIRAS ag/X Toolmaster graphics support system, and a variety of datasets containing geographical information. An Ada/Motif binding is being employed to support all GUI development.

This project is an excellent opportunity to see the results of introducing Ada 95 and OO technology to experienced Ada 83 programmers. The development is on schedule for a September 1996 delivery.

Joint Strike Fighter (JSF) Ada 95 risk-reduction activities

The JSF Program is chartered to create a family of affordable airborne strike warfare systems for the Air Force, Navy, Marines Corps, and allied air forces. (Formerly called the Joint Advanced Strike Technology -- JAST -- it was described in the Summer 1995 issue.)

The products of the JSF effort will include fully validated operational requirements, proven operational concepts, and transition of mature technologies to support successful development and production of affordable next-generation strike weapons systems. Several JSF Ada 95 risk-reduction activities are completed or underway, including the following.

Modular Mission Computer (MMC) -- Lockheed Martin Corp./Texas Instruments:

The existing F-16 MMC Operational Flight Program (OFP), written in Ada 83, will be reused to investigate Ada 95 tool sets and several aspects of the Ada 95 language. The MMC OFP implements the mission-control functions of the F-16, including navigation, electronic instrument presentation, and weapon delivery. The distributed and real-time features of Ada 95 will be of particular interest in this project. Demonstrations will be performed in an F-16 avionics simulation environment.

Harrier flight software module -- McDonnell Douglas Aerospace (MDA), Naval Air Warfare Center-China Lake, and Computing Devices International (CDI):

The joint industry/government team in this demonstration program will employ Ada 95 to develop an air-to-ground ballistics flight software module for the AV-8B Harrier, with expected reuse in the JSF effort. The module will be flight tested on a Harrier aircraft at NAWC-China Lake, equipped with a Power PC mission computer and an IEEE 1003.1 POSIX-compliant real-time operating system (VX Works). The Ada 95 module will be linked with an operational flight program (OFP) made up of C/C++ legacy code from MDA. Numerous features of Ada 95 will be exploited for this demonstration, as will Ada 95/POSIX bindings, Ada 95 development tools, and mixed-language systems.

Safety-critical and Ada-83/Ada-95 issues -- Hughes Aircraft Co.:

JSF is interested in exploiting the new Ada 95 features and in porting reusable Ada 83 avionics software to Ada 95. JSF is also interested in Ada 95's support of high assurance safety critical and secure systems. Pilots' lives and mission success depend on the software executing properly. Secure avionics systems such as JSF are also required to protect code and data at different security classifications, to protect technology, and to enhance system reliability.

Hughes is comparing Ada 95 features considered useful to avionics software with Ada 83 implementations. For example, Ada 95's type extension is being compared with Ada 83's variant record, and Ada 95's protected objects are being compared with Ada 83's passive tasks. Comparisons are made in terms of source code size, complexity, modifiability, execution speed, and object code size. Hughes is also evaluating how Ada 95 supports the development of safety-critical and secure avionics systems by helping make code more reliable, reviewable, and predictable. Finally, to help mature Ada 95 compiler technology, Hughes is evaluating the quality of existing Ada 95 compilers.

NRaD Software Support Activity System (SSAS) Project

The SSAS project is being conducted under the auspices of the Navy Command and Control Ocean Surveillance Center (NCCOSC) Research, Development, Test and Evaluation Division (NRaD) in San Diego, Calif. The SSAS is being developed for use by the Joint Maritime Command Information System (JMCIS) and the Global Command and Control System (GCCS).

The SSAS was developed internally at NRaD for the purpose of creating portable, maintainable tools out of existing scripts and instruction sets for operators. It is a collection of on-line software utilities designed to facilitate centralized approval and dispersion of JMCIS/GCCS applications, and allows JMCIS/GCCS developers and administrators to perform automated integration of software and to monitor the integration process.

The SSAS provides capabilities to automatically receive and process electronic submission and registration of software applications and program segments. Users can create and archive workstation and system variants. The tool will maintain an on-line library of available applications, variants, documents and tools. Finally, the SSAS performs automated standards verification and test tracking, and perform application dependency analysis. The SSAS project is expected to be delivered in the fall.

DISA GCCS Airfields

The Airfields system is one of the first successful Ada 95 technology transfer projects, completed recently on an aggressive schedule. The original system was part of the World Wide Military Command and Control System (WWMCCS). It consisted of some 60 KSLOC, mostly COBOL, running on a mainframe and accessing flat files. It was re-engineered for Ada 95 and targeted for Sun SPARC running Solaris. A graphical user interface was incorporated, as well as bindings to ORACLE. The AJPO assisted by providing training and mentoring for the development team. The resulting application is approximately 50 KSLOC with over 22 percent reuse achieved.

Airfields has been incorporated into the Global Command and Control System (GCCS), and provides a wide range of data about domestic and foreign free-world airfields. The data are supplied by the Defense Mapping Agency Aerospace Center (DMAAC) and are updated monthly. Airfields provides reports in several different formats on-line and off-line, including one-line reports, one-page reports, multi-page reports, selective data retrievals, and turnaround reports. Extensive new functionality was added in phases, including Aerial Ports and Air Operations Bases File (APORTS) and Country Name Country Code (CNCC) systems.

For more information on Airfields, see "Airfields -- An Ada 95 Success Story" in the previous issue of this newsletter.

Air Force Financial Management Modernization System (FMMS)

The FMMS Ada 95 transition focuses on Phase I of the multi-phase, re-engineering of the Air Force's Future Budget System (FBS). The Air Force seeks to modernize all of its budget information systems, covering the entire budget process. FMMS will build upon the business process re-engineering of the Planning, Programming and Budget System (PPBS), using an object-oriented software design methodology.

FMMS will track the chronology and funds management of all Air Force money from initial Presidential budgets through final disbursements to the work centers. FMMS will be deployed in parallel with the existing systems for concurrent use.

FMMS will re-engineer a series of legacy Management Information Systems (MIS) into a single, comprehensive system. Several advanced tools will be put to use in this effort. Rational's Booch Method will be used for object-oriented analysis and design; the implementation will be done on the APEX development environment. OIS's Common Object Request Broker Architecture (CORBA) and Microsoft's Component Object Model/Object Linking and Embedding (COM/OLE) have been chosen for application frameworks; IONA's CORBA-COM/OLE Gateway for Framework Integration & Object Communication will also be incorporated.

The re-engineering effort will include migration from character-based interfaces executing on RS6000s and Unisys 2200s to a graphical user interface (GUI) executing in a client-server environment consisting of microcomputers running MS-Windows and Unix workstations. The GUI development will make use of the Intermetrics Ada 95 bindings to the Win32 API for Windows and OLE. Integration with the Sybase relational database will be achieved with the OIS Ada 95 bindings to Open Database Connectivity (ODBC).

In March 1996, the project successfully demonstrated that Ada 95 could be used to communicate from client to server via the capabilities of the Win32, OLE, CORBA and ODBC bindings.

Marine Corps Portable Recording System

The Portable Recording System (PRS) Ada 95 effort is taking place at the Marine Corps Tactical Systems Support Activity (MCTSSA) at Camp Pendleton, Calif. The PRS is associated with the Tactical Air Operations Module (TAOM) of the Air Command & Control Systems (AC&CS).

The PRS is used to extract data messages from the digital data bus within the TAOM. The current system resides on an 80286 PC connected to its own TAOM Bus Interface Controller (BIC), and writes to a 9-track tape drive. The BIC is a modified proprietary card that is expensive and not easily acquired. The 9-track tape drives are fragile and unreliable. The software is written in four different languages, posing reliability and maintainability problems.

The PRS project is rehosting its systems to a Sun SPARC 20 workstation. Messages are received via fiber-optic cable (rather than the BIC) and recorded on an 8mm tape drive. The software has been re-engineered and implemented in Ada 95 to alleviate reliability and maintainability issues. A secondary goal of the project has been to rehost and enhance data-reduction and analysis software to the extent feasible within schedule and budget constraints.

New Source for Hardcopy Ada 95 Reference Manual

There's a new source for hardcopies of both the Ada 95 Language Reference Manual (LRM) and Rationale. Both manuals are available as a set from IIT Research Institute (IITRI) in Lanham, Md. The cost per set is $40, which includes shipping and handling.honey (Contact IITRI for special pricing on orders over 10 sets.)

To order, send a note indicating the number of sets ordered and a check or money order payable to IIT Research Institute, to:

IIT Research Institute; Attn: Judy Hively; 4409 Forbes Boulevard; Lanham, MD 20706-4211. (Be sure to include payment for all sets ordered; no CODs accepted.)

Previous sources still available

Other sources for the LRM and Rationale (and the Annotated LRM) include:

Electronic copies

* The AdaIC's Standards World Wide Web page.

* As part of a 2-disk Ada CD-ROM set ($39.95)from Walnut Creek CDROM (1-800/786-9907; e-mail:; WWW:


You can continue to obtain printed copies from:

* the Defense Technical Information Center (DTIC -- which sells to the military, other Federal government, and defense contractors who are registered users of DTIC), and

* the National Technical Information Service (NTIS -- which serves the general public).

For DTIC and NTIS, you must specify the accession number: the Language Reference Manual -- AD A293760 (NTIS price: $61); the Rationale -- AD A293708 (NTIS price: $52); the Annotated Ada Reference Manual -- AD A293867 (NTIS price: $92). Add $6 shipping & handling.

Defense Technical Information Center (DTIC)
8725 John J. Kingman Road, Suite 0944
Fort Belvoir, VA 22060-6218
703/767-8274, DSN 427-8274

National Technical Information Service
5285 Port Royal Road
Springfield, VA 22161


"Top 5%"

The Software Engineering World Wide Web site, home page for both the Ada and Reuse Information Clearinghouses, has been judged among the "Top 5% of the Web" by the Point Web Reviews (part of the Lycos company's search activities on the Web). Sites are chosen based upon their content, presentation, and experience.

Thomson, IDE to merge

Thomson Software Products of San Diego and Interactive Development Environments, Inc., (IDE) of San Francisco, companies with expertise in Ada development tools and computer-aided software engineering, are merging, according to Ben Goodwin, Thomson's president and CEO.

Familiar product names, such as IDE's Software Through Pictures engineering environment and Thomson's Object Ada software tools, will remain intact, Goodwin says. The combined company's new name has not yet been chosen.

["Thomson Software to merge with IDE," Military and Aerospace Electronics, June 1996.]

Ada 95 Booch components available on Net

An Ada 95 set of the popular Booch Components has been released and is available for free on the Internet. This release provides only the Queues sequential hierarchy, but near-future releases will include other components. Make sure to read the supplemental data given. Via ftp, this release can be downloaded from (Select the .zip file if using a Microsoft operating system other than Windows 95 or NT.)

On the Web, the Ada 95 Booch Components home page is

Tartan acquired by TI

Tartan, Inc., a leading provider of Ada compilers, has recently been acquired by Texas Instruments. Tartan is a leading third-party provider of highly optimizing software tools for developers of real-time, embedded digital signal processing (DSP) applications.

The companies believe their combined expertise should result in producing the industry's highest performance DSP software tools. "This acquisition doubles our DSP development support resources," said Mike Hames, TI Semiconductor Group vice president and worldwide DSP manager. "TI will be able to take advantage of Tartan's expertise and technology to dramatically accelerate TMS320 DSP technology development and to provide the best DSP customer application support in the industry,"

[Texas Instruments, May 6, 1996.]

Latest Ada 95 compiler validation suite on line

The newest version of the Ada Compiler Validation Capability, ACVC 2.0.1, is available for downloading via anonymous ftp from the AdaIC Internet host. It is located in directory

Ada news by e-mail

The Ada Information Clearinghouse has reactivated the Ada News Brief service. To get the News Briefs e-mailed to you, send a message to:

In the body of the message, write:

subscribe adanews

(No signatures please.)

IEEE mock ballot: Ada binding to POSIX

The P1003.5c working group of the Portable Applications Standards Committee (PASC) of the IEEE Computer Society is conducting a mock ballot of the draft IEEE POSIX standard for an Ada binding to P1003.1g, "Protocol Independent Interfaces" (i.e., sockets and XTI network interfaces).

If you would like to participate in the mock ballot, or take an active role in the working group, or if you simply have an interest in observing the flow of information exchanged on this subject, you can subscribe to an e-mail list on the topic. Send e-mail to:

with the word "subscribe" in the body of the message.

[Shane P. McCarron, Testing Research Manager, P1003.5c Working Group; e-mail:]

ASIS moves ahead on standardization path

In February, the Ada Semantic Interface Specification (ASIS) passed another ballot on the way to becoming a New Work Item for the International Standardization Organization (ISO).

Important as a standard interface between an Ada environment and Ada tools, ASIS continues to progress -- both through ISO channels and in work to produce more ASIS-compliant tools and other support. The next balloting step expected is with Working Group 9, the ISO Ada Working Group (ISO/IEC JTC1/SC22/WG9). Information on this and on vendor support can be found on the Web at

[ASIS Working Group (ASISWG)
Currie Colket, Chair
SPAWAR 332, Crystal Park #5, 2451 Crystal Drive
Arlington, VA 22245-5200
tel: 703/602-1483
fax: 703/602-6805
e-mail:, or]

Ada Calendar

Call the AdaIC for further information on the following Ada conferences, seminars, and workshops. Let us know if your organization is sponsoring an Ada event!

          Software Methods and Tools for Ada 95

September 16-20, 1996
Brest, France
POC: Yvon Kermarrec
Telecom Bretagne
BP 832
29285 Brest, France

           Ada 95 Seminar for Software Engineering Teaching
                and Research Staff at UK Institutions

September 1996
POC: Helen Byard
P.O. Box 322, York Y01 3GY
Tel: +44 1904 412740
Fax: +44 1904 426702

 Direct Satellite Broadcast: Open Systems for Executives

October 17, 1996
11:30am-3:30pm (ET)
Sponsor: Joint Logistics Commanders Joint Group on Systems Engineering
POC: "JLC Broadcast"
tel: 703/418-4574


October 6-10, 1996
11th Annual ACM Conference on Object-Oriented Programming Systems,
Languages & Applications.
McEnery Conv. Ctr, San Jose, CA
(E-mail encouraged; to get info via faxback service, call
For registration information only:
Tel: 407/628-3602

                             Infotech '96

October 8-10, 1996
Dayton Conv. Ctr, Dayton, OH
POC: AFCEA Dayton Wright Chapter
c/o Spargo & Associates
4400 Fair Lakes Court
Fairfax, VA 22033

                            TRI-Ada '96 *

December 3-7, 1996
Philadelphia Marriott
Philadelphia, PA
POC: Dr. Jorge L. Diaz-Herrera (Conference Chair)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Tel: 412/268-7636
Fax: 412/268-5758

                           Ada's Birthday!

December 10

             Joint Modular Languages Conference (JMLC'97)

March 19-21, 1997
Johannes Kepler University, Linz
POC: JMLC'95 Conference Secretary
Johannes Kepler University-Linz
A-4040 Linz, Austria
Fax: +43-732-2468-9430

          8th International Real-Time Ada Workshop (IRTAW 8)

April 8-11, 1997
Ravenscar, North Yorkshire, England
POC: Andy Wellings
Department of Computer Science
University of York
Heslington, York YO1 5DD

         The 9th Annual Software Technology Conference (STC)

Apr 27-May 2, 1997
Salt Lake City, Utah
POC: Dana Dovenbarger, Conference Manager
Software Technology Support Center
7278 Fourth Street
Hill AFB, UT 84056-5205
Tel: 801/777-7411
Fax: 801/777-8069 (DSN: 458-)

*The AdaIC will have an exhibit. We sometimes have free passes to conference exhibit areas where the AdaIC will have an exhibit. Feel free to call and ask for available passes.

Report of a product, service, or event is for information purposes only and does not constitute endorsement by the Ada Information Clearinghouse or the Ada Joint Program Office.

AdaIC News

The Ada Information Clearinghouse (AdaIC) publishes information on the Ada community's events, working groups, research, publications, and concerns. The AdaIC provides its services free of charge to the governmental, academic, and commercial software communities.

This service is sponsored by the Defense Information Systems Agency's Ada Joint Program Office (DOD/DISA/JIEO/CFOS/AJPO), which facilitates the implementation of the DoD's software initiative (Ada) throughout the Services, and maintains the integrity of the language. IIT Research Institute operates the AdaIC out of the AJPO offices in Falls Church, Virginia.

Ada Information Clearinghouse
P.O. Box 1866
Falls Church, VA 22041
Phone: 703/681-2466
1-800-AdaIC-11 (232-4211)
DSN: 761-2466
Fax: 703/681-2869

Ada Joint Program Office
Defense Information Systems Agency
5600 Columbia Pike
Falls Church, VA 22041
Phone: 703/681-2459
DSN: 761-2459

The views, opinions, and findings contained in this report are those of the author(s) and should not be construed as an official Agency position, policy, or decision, unless so designated by other official documentation.

Copyright 1996. IIT Research Institute.

All rights assigned to the U.S. Government (Ada Joint Program Office). Permission to reprint this newsletter, in whole or in part, is granted, provided the Ada Information Clearinghouse is acknowledged as the source. If this newsletter is reprinted as part of a published document, please send the AdaIC a courtesy copy of the publication. The AdaIC is sponsored by the Ada Joint Program Office.

AdaIC News

Ada Joint Program Office
Defense Information Systems Agency
701 South Courthouse Road
Arlington, VA 22204-2199



To change your address, please mail this panel with the updated information to the AdaIC at P.O. Box 1866, Falls Church, VA 22041 U.S.A. Or send e-mail to