Defense Information Systems Agency Center for Software Tools and Libraries Report DASW01-94-C-0054 Task Order T-S5-306 August 1995 Approved For Open Publication TABLES Table 1. Tools and Libraries Reference Model 3 Table 2. Examples of Current AJPO Work 9 Table 3. Tools/Components Requirements 16 Table 4. Long-Term Tool and Integration Strategies 19 Table A-1. Third-Party Software Suppliers A-1 Table A-2. Compiler Vendors A-5 TABLE OF CONTENTS 1. INTRODUCTION 1 2. REFERENCE MODEL 3 2.1 BASIC TOOLS FRAMEWORK 3 2.1.1 Components - Foundation 4 2.1.2 External Interfaces 5 2.2 DOMAIN SPECIFIC 5 2.2.1 Components - Stand-alone 5 2.2.2 Component Interfaces 6 2.3 TASK SPECIFIC 6 2.3.1 Components - Connected Tools 6 2.3.2 Tool Interfaces 7 3. CURRENT STATUS OF AJPO SUPPORT FOR Ada TOOLS 9 4. NEAR-TERM REQUIREMENTS 11 4.1 MINIMAL TOOL SUITE 11 4.2 STANDARDS 14 4.3 NEAR TERM (1-2 YEAR) TOOLS REQUIRMENTS 15 5. LONG-TERM REQUIREMENTS 19 5.1 THREE TO FIVE YEAR TARGETS 19 5.2 METHODS 20 5.2.1 Visual Workspace 21 5.2.2 Class Libraries and Browser 21 5.2.3 Application Architecture and Generator 21 5.3 ENVIRONMENT CHARACTERISTICS 21 5.3.1 Small 22 5.3.2 Portable 22 5.3.3 Extensible 22 5.3.4 Examples to Emulate 22 6. CONCLUSIONS 25 APPENDIX A. EXAMPLES OF AVAILABLE Ada 83 TOOLS AND LIBRARIES A-1 1. INTRODUCTION This report describes the Ada tools and libraries that are required for the Ada programming language to compete with commercial programming environments currently available for other languages. Information presented in this report was gathered and consolidated by the Institute for Defense Analyses, under the sponsorship of the Ada Joint Program Office (AJPO), and was derived from an analysis of commonly available environments for C++, C, and Basic (Microsoft Visual C++, Microsoft Visual Basic, and Centerline C). These environments were analyzed to determine the tools offered and the integration approach taken by the offerors. In addition, special requirements of the Department of Defense (DoD), such as embedded and real-time systems, were incorporated. The objectives of this report are to: 1. Identify the tools and techniques used by the most successful commercial environments; this enables identifying a model to which Ada-specific capabilities can be added - creating a product superior to the current commercial alternatives. 2. Establish a reference model for tools and libraries that provides a single vision for the construction of tools and libraries. 3. Capture the qualities of the successful commercial environments, so that appropriate characteristics can be introduced into Ada programming environments. The intended audience of this report includes: -Ada compiler and tool implementors, -experienced Ada software engineers and applications developers, and -other software practitioners interested in the development of tools and libraries that will improve Ada's competitiveness in the general software marketplace. The report is organized in the following five sections: -Section One is an introduction. -Section Two presents a reference model as the context for relating subsequent discussions of near-term and long-term requirements for tools and libraries that will enable the Ada 95 language to be integrated with current and emerging visual software technology. -Section Three summarizes the current status of AJPO-supported tools available for use with Ada compilers. -Section Four presents applicable standards and the minimal set of tools necessary to produce the desired environment. -Section Five discusses the requirements for tool and library evolution during the future three- to five-year period. The target programming environment is one in which tools facilitate the use of Ada 95's object-oriented programming features. To move quickly to the target environment, it must be recognized that the expressive power of the programming environment is not in the particular tools provided, but rather in the integration techniques used for the tools. The integration techniques envisioned in this report center around a single visual and graphical presentation, class libraries with tools to support their use, and an understanding of the application architecture within the environment itself. Lastly, in order that the desired environment maintains the overall purpose of competing with commercial environments, the general characteristics of the environment are discussed. 2. REFERENCE MODEL Table 1 shows a reference model for tools and libraries. As shown, it breaks down the environment into three layers: Framework, Domain- Specific, and Task-Specific. Using these three layers, a developer should be able to integrate libraries of packages that fulfill a given end purpose (i.e., an application or tool in a specific domain), and should have a means to use them together to accomplish a goal. The framework layer provides the parts necessary to construct tools easily. The domain-specific layer provides users individual tools that perform particular actions. The task-specific layer provides a collection of tools bound together to accomplish a goal. Table 1. Tools and Libraries Reference Model\x11 Layer Component and Interface Types Examples Framework Basic layer composed of parts used to create tools Components - Foundation Classes Libraries, Class Hierarchies, Bindings External Interfaces Multimedia, Communications, Databases, Buses, Reuse Libraries Domain Specific Applications and tools particular for a domain Components - Stand-alone Tools Program Management Tools, Rate Monotonic Analysis Tools, Filters Component Interfaces OMG CORBA IDL, Microsoft OLE Task Specific Collection of applications to accomplish a particular goal Components - Connected Tools Aggregates of domain-specific tools and components Tool Interfaces TCL, Pipes, Object Brokers 2.1 BASIC TOOLS FRAMEWORK This section identifies the general functions that every programming environment should have. The C libraries provided with every C compiler, or the Microsoft Foundation Classes, are representative of such functions. 2.1.1 Components - Foundation Foundation classes are the fundamental component of this layer. Included in a foundation set of classes are the core classes that can affect the entire environment. These foundation classes enable the type of reuse gained by an object-oriented environment (e.g., Smalltalk). The classes should include libraries to interface to basic operating- system services, extensive sets of programming primitives (e.g., Booch components), and bindings to common products (e.g., windowing systems), project engineering functions, and project management functions. The decision as to whether to create a binding or library has to do with the possible success of the binding method. A library or binding needs to be created if the software being bound to makes heavy use of the resources of C++ and does not lend itself to implementation in an environment such as the Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) or Microsoft's Object Linking and Embedding (OLE). In such a case, a library must be a complete or partial rewrite of the system in question. Following are four approaches, in order of preference: 1. Generate a thin binding using a bindings generator. A thin binding - containing pointers to, for instance, some governing standard - requires the least effort and provides an immediate solution. If the software system is popular or prone to misuse by programmers, a thick - self-contained - binding should be constructed. 2. Encapsulate the software system using the Interface Definition Language (IDL) Tool Kit (TK) or OLE. This is the second most effective method for interfacing; it will allow the original software to be used and maintained by the authors, while allowing Ada to access the functionality. (However, not all software has the capability to be encapsulated using IDL or OLE.) 3. Write a thin binding by hand. This approach requires some effort. Moreover, if the software system is popular or prone to misuse by programmers, a thick binding should be constructed. 4. Reimplement the interface portion of the software system and bind to the underlying layers. This approach can be successful for most of the C++ class libraries that a binding cannot be written to, but which are written on top of a layer of C code that can be bound to. Libraries provided by Unix or Microsoft Foundation classes provide examples of basic capabilities such as: -memory management (e.g., malloc) -input/output (e.g., aio, sockets, volume management) -execution control (e.g., thread, dynamic linking, elf) -security (e.g., nis, auth) -natural-language independence (e.g., nls) -platform interfaces (e.g., X-Window System, Microsoft Windows) 2.1.2 External Interfaces The components themselves need to interface with external environments, i.e., hardware buses, databases, persistent-object stores, and other external devices that need to be accessed via a software interface. Tools that support the framework layer need to interface with a network of reuse libraries that provide a virtual library for the selection and understanding of existing components. The Reuse Library Interoperability Group (RIG), a working group of the Institute for Electrical and Electronics Engineers (IEEE), is preparing a draft standard for this activity. Also applicable is work by the Reuse Technical Working Group (RTWG) Interoperability Vision Working Group (IVWG), which has produced a concept of operations and a technical reference model. Groupware interfaces (e.g., Lotus Notes) should be considered for tools that will be used by more than one individual. Also important are interfaces to the integrated tool suite of the environment itself, and interfaces to any general environment - e.g., the Portable Common Tool Environment (PCTE), or the Integrated Computer Aided Software Engineering (I-CASE) Environment. 2.2 DOMAIN SPECIFIC These are functions that are specific to the domain area for which applications are being developed. They can be horizontal domains (e.g., program management) or vertical domains (e.g., rate-monotonic scheduling). 2.2.1 Components - Stand-alone The components of this layer are tools in their own right. They provide a particular service that is usually part of the tasks that an engineer or manager performs during their normal activities. They should be constructed based on components and libraries provided by the framework layer. 2.2.2 Component Interfaces Interfaces that are important for this suite of tools should be interacting with the components of the framework layer. Also of interest are interfaces that allow tools to be treated as components, such as Object Management Group's (OMG's) CORBA and Microsoft's OLE. 2.3 TASK SPECIFIC These are functions to perform a specific task or duty. Tools in this layer are composed of the framework and domain-specific layers linked via some communication means. A good example is Unix filters bound together via a byte-stream pipe. 2.3.1 Components - Connected Tools The components necessary at the task-specific layer are combinations of the tools integrated into the environment in the domain-specific layer. The means of integration should support a large number of combinations of tools, and present the set of integrated tools as a single tool. This allows the combination of tools to be hierarchical and therefore scalable. For example, Unix pipes have been a successful means of integration for more than 25 years. Pipes are still used because there they make no assumptions about the data being transferred between filters - except that such data is represented as a byte-stream, where the output of one tool can be used as input to another tool. However, pipes are limited in power and complexity for the same reasons they are successful. New approaches of combining more substantial tools than filters have emerged in recent years. A good example of this is the Tool Command Language (TCL). TCL is a scripting language that allows a programmer to make procedural-like calls to a tool in order to exchange data. TCL combines this feature with a script language that allows a programmer to combine the inputs and outputs of tools in complex and algorithmic ways. With the advent of visual scripting languages, Ada can provide a substantial contribution. Ada's strong typing, when combined with a tool-scripting language or a visual-based language, can identify and help prevent incorrect combinations of complex tools. Special consideration should be given to embedded systems, to develop the capabilities that are emerging for commercial environments with respect to tool command languages. 2.3.2 Tool Interfaces Interfaces that concern the task-specific layer are interprocess communication (IPC) mechanisms, such as pipes and sockets, and commercial, off-the-shelf (COTS) interfaces that can be bound to or used via a tool command language. In addition, the Internet's World Wide Web (WWW) offers the capability to combine tools into an application that is geographically disperse. Graphical interfaces, such as Motif or Microsoft Windows, should be used to support any visual components. 3. CURRENT STATUS OF AJPO SUPPORT FOR Ada TOOLS The current set of tools provided by Ada compiler vendors is minimal when compared with visual user interfaces provided by some of the commercial alternatives to Ada - e.g., Visual Basic, Visual C++. Most Ada vendors do not provide a comprehensive suite of tools with their compiler. The compiler and symbolic debugger are usually provided, but testing and profiling tools are not. (See Appendix A for currently available tools.) Many Ada compilers offer some of the features of commercial alternatives to Ada; usually, however, a visual integrated environment is not provided. Responding to the needs of DoD Ada users, the AJPO has complemented the offerings of compiler vendors and third-party vendors by funding efforts to produce other components and tools. Table 2 provides examples. Table 2. Examples of Current AJPO Work\x11 Name Function ASIS/PVL Semantic Components used to view characteristics of Ada programs ASIS/Execution Time Prediction Generates execution time and bounds CAPS Computer Aided Prototyping System for Real-Time software ADAR Decimal Arithmetic library tools GNAT Compiler based on GCC with links for other FSF tools AdaSAGE PC- and Unix-based application builder 9X Conversion Conversion and Reengineering for Ada 83 to Ada 95 migration Textbook & Compiler Introductory environments for Ada programmers GUI generator Windows GUI generator Bindings Generator C to Ada Bindings Generator Multi-Language Debugger Debugger interfaces for to allow for a multi-language environment In summary, the concentration to date has been on components for creating tools, on providing semantic information to tools, and on creating tools for writing visually oriented programs. To date, little work has been performed in the gathering of the tools into a visual programming environment or in the integration methods of existing tools. 4. NEAR-TERM REQUIREMENTS 4.1 MINIMAL TOOL SUITE The tools described in this section are required for Ada to compete with the Visual C++ and similar commercial environments. These tools are a minimum set, and must be integrated to provide the basic functionality of the environment. The means chosen for integration of these tools with others is more important than individual tools that provide stand-alone capabilities. The tools described below are an example set of tools that are provided with the basic environment purchased off-the-shelf for C++. Some of the value-added features that Ada can contribute to these tools are also discussed. -Compiler and Source-Level Debugger Central to every programming environment is the compiler and source-level debugger. Most Ada programming environments provide these tools already. For Ada 95 tools and libraries, the concentration of effort should be on the ability of these tools to be integrated into a programming environment that is dynamic and interactive. -Visual Workspace The visual workspace, while not normally thought of as a tool, is a tool integral to the visual aspect of visual C++. The visual workspace provides a single user interface to the environment through which users interact with the environment. The basics of the interface are simple, and use common visual cues and patterns shared by other environments on the same platform. The visual element of the environment is critical. Some business analysts predict that the commercial visual market will be over 3 billion dollars by 1999. (See, for instance, IEEE Computer magazine, March 1995, p. 8.) Also, many of the participants at the 1995 Ada Dual Use Workshop cited a lack of visualization tools similar to Visual Basic and Visual C++ as a reason for not using Ada. -Embedded Workspace For embedded systems, the analogous workspace concentrates on simulation of the target environments, so that testing and prototyping can be done independent of the target hardware. Appropriate libraries provide the keys to this workspace, allowing applications to be compiled in the development environment and linked to the target environment. This approach is not unique for embedded systems and it is critical in a visual environment. -Browser A source-code browser is necessary to manage the modularity of the source code. The browser should allow for examining uses and references of names in the source code, as well as for examining the structure of the source code. There are many examples of browsers in C++ environments. In fact, many environments use the browser as a means to integrate class libraries into an application. -Inheritance Manager For the creation of inheritance trees, a tool to manage possible interaction of the inheritance is necessary. The manager needs to be able to relate different choices of inheritance and the possible effects on the application environment. -Configuration Manager While general reuse is difficult to introduce into an environment, a recurring tool on any successful reuse project is a configuration manager. Having the configuration manager as a central part of the environment (i.e., not as an after- thought) is critical to its success. The configuration manager contains a notion of the versions of packages and subprograms used to create an application. The configuration manager is closely related to an Ada library manager that understands different versions of compilation units. -Metrics Manager A set of tools and components is necessary to collect and analyze various metrics. The metrics should be simple and directly relate to programming tasks, such as memory allocation and de-allocation, lines of code, and number of packages, among others. The object-oriented nature of Ada presents a challenge for collecting metrics, since object-oriented metrics are a heavily debated research topic. Ada's semantics allows for some advancement in this field, because of the separation of the inheritance mechanism (e.g., tagged types) from the encapsulation mechanism (e.g., packages). Besides the minimal tool suite described in the preceding text, examples of tools that are needed for the types of domains of interest to the DoD are: -Testing In large software environments typical for DoD, test tools can produce significant improvements in the quality of the code produced, and can significantly reduce maintenance costs. Only one Ada environment identified contained a test tool. Types of test tools that can excel in an Ada environment are semantic- based testing tools, pre- and post-condition management tools, and test-plan generators -Support for Re-engineering Legacy Systems Incorporating legacy code into new systems is of growing concern to both government and commercial sectors. While several tools exist in the public domain to analyze code, none are currently integrated into an Ada programming environment. Tools of interest are reverse-engineering tools and software- and hardware- dependency analyzers. When taking Ada code as input and processing the code's semantic properties, these tools should use the Ada Static-Semantics Interface Specification (ASIS) interface. To perform an analysis, many tools on the market today need to parse and semantically check the Ada code; such tools become less useful as the size of the legacy system they analyze increases. ASIS-compliant tools avoid this problem. The ASIS standard is the only interface that is supported by many vendors and provides detailed information about the semantics of Ada programs. In particular, the Descriptive Intermediate Annotated Notation for Ada (DIANA) interface should not be used, because of the lack of standardization of DIANA between Ada compiler vendors. -Support for Embedded Applications Embedded systems are of great importance for the DOD. With the current focus on visual systems and individual programmer productivity, embedded systems should be taken into account. Examples of tools that can be integrated into an embedded programming development environment are checkpoint and restart tools, remote-execution and control shells, and simulators for hardware or software components. In addition, links or protocols to allow remote execution of visual tools would also be beneficial. -Code Generators Code generators are an often little used software engineering technique. Including these tools in a programming environment will encourage use of generation techniques and increase productivity. Examples are finite state machine generators, GUI- builders, and fourth-generation languages. -Visualization In order to compete with commercial environments, increased visualization techniques are necessary. Besides a visual workspace, other visual tools can provide increased understanding of the data and code being produced by a programmer. Examples are code- execution animators, data-structure animators, and 2d/3d-display tools. An important factor in the success of these tools should be the ability of the Ada language to improve their capabilities and usefulness. Semantic-based test tools will have much more information available and at their disposal when processing Ada code over C or C++ code. These advantages (e.g., ranges on discrete types) should be exploited and appropriate test cases developed. Each example tool can be improved by accessing Ada's extra semantic information, thus increasing the overall quality of the tool. Tools that are necessary to support the framework layer include: bindings generators, IDL generators, and software-composition analyzers, among others. The bindings and IDL generators are necessary to quicken Ada developers' time-to-use of emerging COTS technologies whose underlying code was not written in Ada. The software-composition analyzers are necessary to understand the most important properties for a given application when combining different software components to create a tool or application. 4.2 STANDARDS Improved portability of software is the most immediate benefit of an adherence to commonly accepted standards. In turn, reuse is easier to achieve. Economics and user demand, as well as DoD policy, indicate the necessity for commercial standards compliance. The following standards support various types of tool interfaces and methods of integration. They should be incorporated into any design of a programming environment. -ANSI X3H6 Tool Integration Models specification -OMG Common Object Request Broker Architecture (CORBA) -ECMA Portable Common Tool Environment (PCTE) -CASE Data Interchange Format (CDIF) -IEEE-1175 Semantic Transfer Language -IEEE-1420.2 RIG Basic Interoperability Data Model (BIDM) (Draft) -ISO Ada Static-Semantics Interface Specification (ASIS) (Draft) -Microsoft Object Linking and Embedding 2.0 (OLE) (Product Standard) -Microsoft Component Object Model (COM) (Product Standard) For the creation of components and objects for reuse, the OLE, COM, or CORBA specifications should be followed. For an environment's exchange of data and integration with other environments, the CDIF and PCTE specifications should be followed. For exchange of reuse data and for descriptions of reuse assets, the BIDM standard should be followed. For the gathering of semantic information about Ada programs, the ASIS standard should be used. For operation and architecture guidance with respect to reuse, two relevant documents are the Virtual Library Concept of Operations, and the Virtual Library Technical Reference Model - both produced by the Interoperability Vision Working Group (IVWG) of the IEEE Reuse Technical Working Group (RTWG). 4.3 NEAR TERM (1-2 YEAR) TOOLS REQUIRMENTS While concentrating on the creation of tools that support the Task- Specific layer of the reference model, developers should consider the tools or components shown in Table\x113. These tools were selected because of their contribution to a visual environment and to embedding semantic capabilities into tools. The libraries were chosen because of the need to create an environment that is equal to or greater than the commercially available environments. This set of libraries is the basic set provided by Unix or Microsoft with their respective environments. Table 3. Tools/Components Requirements\x11 Category Function(s) Visual Tools Data Animator Process Animator Message Animator Visual Memory Management Visual Workbench Graphical Profiling Graphical Metrics Program Views Program-Document System Icon-Program Construction ASIS Graphical Interface Ada Scripting Tools Object-Oriented Browser Graphical-Tasking Analysis Analysis Tools Hardware-Dependency Analyzer Checkpoint and Restart Tools Pre- and Post-Condition Test Tool Finite-State-Machine Generators Tool-Building Tools (Components and Task-Specific tools) ASIS interface in Perl ASIS program standards ASIS World Wide Web interfaces ASIS TCL interfaces ASIS-based code generator Improved Ada TCL Toolkit ASIS Browser Toolkit Libraries Platform-Specific Library Natural-Language Independence Library Software-Licensing Library Dynamic-Linking Library Input-Output Library Memory-Management Library Ada-Browser Library World Wide Web Library Terminal-Independence Library Fonts-Management Library Math Library Business/Spreadsheet Library Data-Plotting Library Container-Class Library Animating parts of a programmer's task or materials is a powerful means to communicate information and to understand complex information. A data animator will allow a programmer to visualize data structures that are in use in a program, and to enter data into persistent files for test or demonstration capabilities. A process animator will enable a visual representation of communication objects used to construct a system. A message animator will assist in lessening the complexity of message passing in an object-oriented environment. Sun Microsystems uses these techniques in its current network management tools; because of the visual representation, Sun has been able to scale their tools to support management of thousands of nodes. Memory management is one of the more difficult tasks in a large programming environment. As Ada programs use more bindings and external objects to construct a program, the natural ability of Ada to handle memory management is compromised. A visual tool for memory management would counterbalance this difficulty. Graphical representation of profiling information, metrics, and tasking properties would enable programmers to make greater use of the information provided and improve the quality of the programs produced. One of Visual Basic's strengths is in the icon-based construction of programs. An icon program constructor allows a programmer to create a system for aggregating a collection of visual representations of components. The visual workbench would aid in composing a program from icons, and then in analyzing and generating missing connections. A scripting tool to enable recording and playing of common tasks in the environment is also necessary. Ada programming environments would benefit from the addition of the visual presentation of programs. Knuth, in his literate-programming methodology, likens the creating of programs to the writing of essays to communicate a program's meaning to others as well as it is communicated to the computer. In creating a visual environment, most vendor effort to date has been focused on supporting the initial programmer/developer. Program maintainers, on the other hand, would benefit from the important visual tools to produce program views (a large number of views), coupled with a program-documentation system that would enable program text to be included into a document in an easy and straight-forward manner. Also important is for the environment to be tailorable to meet user needs. An aid in this would be a graphical front-end to the ASIS interface. This would enable programmers to quickly construct and browse ASIS queries, and have the information presented visually. Coupled with this would be an object-oriented browser that would enable programmers to understand the inheritance and encapsulation used in an Ada 95 program. Other ASIS components are suggested to enable tools and environments to quickly take advantage of the semantics information available in Ada program libraries. ASIS interfaces built into the scripting language Perl, TCL, and the WWW would allow users to quickly build graphical and textual tools as easily as they write command-language scripts today. The tools and components discussed in this section are only examples of what would help integrate and visualize tasks of importance to Ada programmers. The specific tools are not as important as the integration means. As demonstrated by analyzing commercial environments, the number of tools necessary for a productive environment is small. 5. LONG-TERM REQUIREMENTS 5.1 THREE TO FIVE YEAR TARGETS Table 4 lists examples of tools and integration strategies for the long-term. The concentration of the tools should be on methods that will enable the Ada environment to be expanded with COTS tools from other languages and other environments. Table 4. Long-Term Tool and Integration Strategies\x11 Tool Components IDL/OLE Encapsulation of Tools ASIS Interfaces Hardware/Software-Simulator Interfaces Visual Workbench Embedded Workbench Debuggers Animators Interface Generators Embedded Systems Additional Simulators Remote Execution Runtime-Property Prediction Assertion Analyzer Application-Specific Code Generators IDL Generator Distributed Reuse Library Tools Interoperation Components Reuse-Task Support Tools Reuse Library Objects Architecture-Task Support Tools Architecture-Specification Maintenance Tools Product-Line Support Tools Product-Line Manager Currently, the expected means for inter-language integration is through OMG CORBA's IDL or OLE. The existing tools developed during years 1-2 should be already CORBA or OLE compliant, or should be made compliant. The integration efforts in years 3-5 should take advantage of this to produce a larger more integrated environment. For example: -CORBA/OLE interfaces for ASIS to allow for Ada semantics to be used by more non-Ada and distributed tools. -Compliance of the visual and embedded workbenches with CORBA/OLE would allow a distributed visual environment for use on large, geographically disperse programming environments. -CORBA/OLE compliant debuggers and animators would facilitate a geographically separate development. -More simulators and remote execution capabilities would enhance Ada's position in the distributed simulation market. The task specific layer of the reference model is also important in the long-term. Examples of a mature task specific layer are: -Reuse tasks and programming activities should be supported by the integration of multiple tools and interfaces. Distributed reuse libraries should seamlessly fit into the programming environment as if the code were developed locally. The visual component should feel and look just like code developed by the programmers themselves. -Architecture management and design should also be supported by the tools and interfaces. Information about the architecture should be visually presented to a programmer, as well as enforced by the tools. -Product-line release should reflect a balance among the configuration-management system, architecture development activities, and customer needs. The suite of tools to support this should be able to execute and perform tasks at the developer's or customer's site independent of the hardware or software platform. 5.2 METHODS The power of commercial environments is not derived from the number of tools provided, but rather from the quality and integration means presented to the users. Ada developers need tools that can be combined in similar ways. The following sections detail three areas where the commercial environments excel with respect to Ada environments, and should be of consideration when planning future tool development. 5.2.1 Visual Workspace Visual Basic and Visual C++ are integrated environments because they use a single graphical presentation that operates all tools and libraries. The workspace allows each tool to present its unique features, and allows common features to be presented in a common way. Access to the tools is via a menu or icon. The tools of the environment share information and data, so that no tool tries to perform tasks that are better performed by another. 5.2.2 Class Libraries and Browser Integration of the libraries with the visual workspace and the programming environment is through a browser. The libraries should be usable by the environment in a method that is easier than using custom code. This makes reuse a more natural option. The integration of an Ada "class", or tagged type and package browser with support for distributed reuse libraries can support the notion of a virtual reuse library described in the IEEE IVWG documents. 5.2.3 Application Architecture and Generator Arguably, the successful commercial environments are not general programming environments. A particular viewpoint or domain is chosen, and the programming environment structures the actions of a programmer to create applications in that domain. The environment, understanding the application's domain, can generate parts of the application, such as message handlers for object hierarchies. This aids dramatically in the constructing of an application from existing parts. The Visual Basic environment allows an application to be created with very little new code written. This is accomplished by selecting existing "classes" of code and pulling them into the new application. Tools help in coordinating messages and the appropriate hierarchy of the new application. New code is necessary only in cases where detailed algorithms are used, or very domain-specific terminology is justified. The messaging code and other "glue" are automatically generated by the environment. 5.3 ENVIRONMENT CHARACTERISTICS While a narrow focus must be taken when developing a tool or component, the effectiveness of commercial environments is largely controlled by the integration strategy and other overall characteristics.The following sections detail overall qualities that all tools and functions should support. 5.3.1 Small The environment needs to be small and efficient. It needs to be designed as a single system and not as parts that when combined require large amounts of computing resources (beyond a normal PC). Scalablity of the environment is judged by the initial computing-resource demand. As the size of the system being developed increases, the computing resources should increase in no more than a linear relationship. 5.3.2 Portable The environment needs to be portable to the major compiler vendors, such that the same look-and-feel is presented. This is necessary in order to have no particular compiler vendor at an advantage with this environment. In the development plans for the tools, two different compilers should be used to demonstrate the portability. The initial compiler and hardware platform used should not be on a computing engine that is larger or more powerful than the second planned platform. 5.3.3 Extensible The environment needs to be extensible - so that individual programmers can customize the environment with additional tools and libraries, as they are created. The customization by individual programmers is critical to their productivity. The methods used for extensibility should allow for tools to execute in a remote environment, such as encapsulated via a CORBA IDL interface, or using another standard communication means. 5.3.4 Examples to Emulate Visual C++, Visual Basic, and Centerline C provide the most popular commercial environments available. The trend of these environments is toward more distribution and visualization. The particular implementation means of these trends is still in question, but the trend is unmistakable. The Visual Basic environment takes very little start-up time for users. This type of environment should be emulated in order to make the Ada language more popular. A more complicated product than Visual Basic, Visual C++, contains features and techniques that support more advanced and sophisticated programmers than Visual Basic. In fact, many organizations use Visual Basic to prototype systems, and Visual C++ to create a more stable product. An interpretive environment that aids the quality attributes of the systems being developed is supported by Centerline C. This environment has built-in knowledge of programming techniques used with the C language, and has features to prevent the misuse of C language. 6. CONCLUSIONS While many of the tools that are mentioned in this report exist, there is not yet a means to integrate them into a single cohesive environment. The minimal tool sets provided by Visual C++, Visual Basic, and Centerline C show that the number of tools provided is not important, but the ability for the tools to work together to accomplish a programming task is critical. At this time, the task-specific layer of the reference model has the greatest priority. Work in the domain-specific and framework layers should be considered only when the product is important for the goals of the task specific layer - for example, basic libraries that are necessary to create usable programs. Specific tools in the domain-specific layer should be considered if they support the creation or management of the framework layer, or have a clearly defined purpose for the task- specific layer. A holistic approach to the development of task-specific tools should increase tool vendors' participation due to the cost savings provided by the components reused, and the well-defined integration strategy. Compiler vendors should also find the approach attractive, because it allows addition of the visualization and other characteristics currently missing in their Ada environments at a reduced cost and in accord with de facto standards.