The U.S. Department of Defense Common High Order Language program was initiated in 1975 with the goal of establishing a single high order language for new DoD embedded computer systems. We are now approaching that goal. A significant reduction in the number of languages approved for new systems was achieved through the issuance of DoD Instruction 5000.31 in November 1976, the technical requirements for the common language were finalized in the Steelman report of June 1978, the preliminary language design was completed and named Ada in June 1979, and extensive test and evaluation of the design has just been completed. The effort thus far has been coordinated through the High Order Language Working Group (HOLWG) of the DoD Management Steering Committee for Embedded Computer Resources.
In the next few months Ada will be added to the DoD list of approved languages, the HOLWG will be replaced by a permanent Ada Language Control Board (ALCB), and national and international standards are planned. The final phase of refinement of the language design will be completed and issued in July 1980. Development of an Ada Compiler Validation Capability (ACVC) was begun in September 1979, and multiply targeted production compilers are planned by the Army and Air Force with work to begin in March and July 1980 respectively.
It was recognized from the beginning that the major benefits to DoD from a common language would be economic and would derive from Ada's appropriateness to military applications, from the portability that comes with a machine independent language, from the availability of software resulting from acceptance of the language for nonmilitary applications, and most importantly from the use of Ada as a mechanism for introducing and distributing effective software development and support environments to those developing and evolving military systems.
The Ada effort is now at a major transition point as the emphasis shifts from the language design to its introduction and use. The Stoneman is the first major accomplishment of this new phase. The Stoneman paints a broad picture of the needs and identifies the relationships of the parts of an integrated Ada Program Support Environment (APSE). It develops a model which reflects an understanding of both the realities of current practice and a realistic appraisal of the possibilities for more effective software development and support environments. It calls for the integration of conventional software tools into a framework that is sufficiently open ended to accommodate a wide variety of programming methodologies and automated software tools currently unavailable or unused in military systems.
The Air Force will act as the lead Service in the development of an integrated software environment for Ada. Their draft: RFP has been issued and the responses reviewed. The final RFP will be issued in April 1980 and will call for several parallel efforts for detailed designs of APSEs in compliance with the Stoneman. Widespread review is planned at major milestones in the designs. After a six month initial design effort one or more of the designs will be continued into implementation. The Stoneman will not be superseded until evaluation of the initial designs has been completed. Products are planned for two years from the start of the designs.
At the same time, the Army will be developing a few critical software tools to enable more effective use of Ada in the context of existing software environments. Bids on the Army efforts have been reviewed and the contractor will be announced in February 1980. The Army also will take the lead in Ada related education and training efforts. The latter activities are coordinated through the Ada Education and Training Committee chaired by DARPA.
The Stoneman will also play a major role in the Ada Joint Project Office (AJPO) now being established. This will be a funded office with full time personnel and will be the principal DoD agent for development, support and distribution of generic tools, common libraries, and environments for Ada. The AJPO will continue the coordination of all generic Ada efforts within DoD, including ongoing efforts in the Army, Air Force, DCA, and DARPA, to ensure their compatibility with other Service and DoD Agency requirements, to avoid duplicative efforts and to maximize sharing of resources. The HOLWG will remain the point of contact for Ada activities until the ALCB and AJPO are established.
We are extremely grateful for the laudatory effort of John Buxton in developing. the Stoneman. It represents the state-of-the-art in programming environments in the context of Ada and has been developed in as much depth as can be expected without more intensive detailed studies. Initial reviews by some 50 people have been very positive. We are also indebted to Vic Stenning for his able assistance, to the many individuals who have contributed to the various iterations in the Pebbleman/Stoneman process, and to DARPA and the British Ministry of Defense for sponsoring John and Vic's work.
Although this brings the Stoneman series to an end, it is only a beginning for the extensive work that lies ahead. The Ada language provides a mechanism for considerable cost savings and for introducing modern software technology into operational use in military systems. That potential, however, can be achieved only through continual effort and dedication to the task. The Stoneman provides guidance for an important facet of that effort.
David A. Fisher
Staff Specialist for Computers, Communications, and Command and Control
It is with great pleasure that I acknowledge the very significant part Vic Stenning has played in the preparation of this document by working with me as co-author during the major redraftings.
The work embodied in the Stoneman would not have been possible without the generous cooperation and enthusiastic help 9f the very many people who have provided substantial criticisms and/or alternative versions for sections of the text at various stages in the project. Particularly substantial contributions have been made by R.F. Brender, T.E. Cheatham. R.A. Converse, L.E. Druffel, R. Firth, H. Fischer, D.A. Fisher, R.L. Glass, H. Hart, D.S. Johnson, N.M. Lehman, L. MacLaren, D. Notkin, I.C. Pyle, D.F. Roberts, P. Santoni, E. Satterthwaite, T.A. Standish, S.L. Squires, J.A. Townley and P. Wegner.
Professor John N. Buxton
AIKEN COMPUTATION LABORATORY
Cambridge; Mass. 02138
1.B The purpose of an APSE is to support the development and maintenance of Ada applications software throughout its life cycle, with particular emphasis on software for embedded computer applications.
1.C The three principal features of an APSE are the data base, the (user and system) interface and the toolset. The data base acts as the central repository for information associated with each project throughout the project life cycle. The interface includes the control language which presents an interface to the user as well as system interfaces to the data base and toolset. The toolset includes tools for-program development, maintenance and configuration control supported by an APSE.
1.D A further goal of great importance in some areas of Ada usage, such as within the DoD, is that of portability both of user programs and of the software tools within the APSE. The Stoneman, therefore, goes on to indicate an approach to portability by giving requirements for two lower levels within the APSE; the Kernel (KAPSE) and the minimal toolset (MAPSE)
1.E It is convenient to represent an APSE which addresses theme problems as a structure with a number of layers or levels:
1.G Section 2 of this document provides some perspective concerning current practice and the mechanism for making the transition from current systems to the Ada environment. Section 3 presents general principles for the overall design of an APSE system. Section 4 presents requirements for the main individual components of an APSE. Sections 5 and 6 respectively present the requirements for a kernel interface (KAPSE) and minimal toolset (MAPSE). Section 7 presents proposals for further components which are candidates for inclusion in an APSE.
1.H Where appropriate, requirements are supplemented by notes which motivate and explain the requirements. In particular, sections 4, 5 and 6 include sections of notes which respectively supplement the requirements on APSEs, KAPSEs and MAPSEs.
1.J It is possible to take a broader and more general view of programming environments as embodying and supporting the complete integrated process of program design and evolution. This generality is regarded as beyond the present scope of the Stoneman; however, the aim is that the present document should not exclude a more general view being developed and so it is intended to be "upwards compatible" in all critical areas.
2.A.2 In order to establish the background, we give here a brief summary of typical current practice in many establishments engaged in developing embedded computer systems for military and industrial purposes.
2.A.3 REQUIREMENTS: Particularly in the military field there are formal steps and documentation required at each stage in the system development. However, especially with advanced systems, the initial requirements specification may be imprecise and generalized.
2.A.4 DESIGN: The design stage often involves considerable interaction with the customer and may also be dependent on experimental results from simulation and prototype studies. This can lead to experimental or iterative design techniques.
2.A.5 IMPLEMENTATION: In many cases this is carried out on a host computer, of reasonable size, batch or interactive about equally probable, with mainframe vendor's software support. Much of the programming is done in a high level language, but some is done directly in assembly code. The compiler is viewed primarily as a means to generate and document assembly code and is therefore expected to produce efficient but understandable assembly code. The link-edit phase generates target configuration load tapes.
For some projects there is no host computer and implementation is directly on the target machine with minimal support facilities.
Data preparation and checking may itself be a substantial task.
2.A.8 ERROR REPORTS: A necessary and continuing task is administering error reports and fixes, together with configuration, version and release control throughout the lifetime of the released system. This is regarded as a data processing task and may be carried out manually or, with larger applications, by a computer data processing system.
2.A.9 CYCLE TIME: A full recompile cycle, with optimising, reconfiguring, etc., can vary-in length from 2 days to 2 weeks, depending on size of project, quality of software tools, etc.
2.A.10 MAINTENANCE: This is normally performed by personnel who were not associated with the original software development, often at the customer site. The practice is developing whereby the hardware/software system used during development is contracted as a deliverable and shipped with the product, enabling fault correcting and system upgrading to continue much as described under TESTING above. The system typically continues to undergo change throughout the lifecycle and the annual extent of changes may well be of the same order of magnitude as that of the original system.
2.A.11 CONCLUSIONS: The main features which have a major influence on the activity of developing real time embedded computing systems would seem to be:
2.A.13 An environment simulator is of particular importance as a project- specific tool which is always required and may well require as much effort to design and build as a major component of the system.
2.A.14 In past and in much of current practice, the concept of a support system is not much in evidence. The tools available are not well integrated, nor do they form a complete set.
2.A.15 In particular, the crucial problem of long term configuration control is normally addressed by a combination of ad-hoc manual and data processing techniques, and successful configuration control is there- fore critically dependent upon management skills.
2.B.2 An APSE adopts a host/target approach to software construction. That is, a program which will execute in an embedded target computer is developed on a host computer which offers extensive support facilities. Except where explicitly stated otherwise, this document refers to an APSE system running on a host machine and supporting development of a program-for an embedded target machine.
2.B.3 An APSE offers a coordinated and complete set of tools which is applicable at all stages of the system life cycle, from initial requirements specification to long-term maintenance and adaptation to changing requirements.
2.B.4 The tools communicate mainly via the database, which stores all relevant information concerning a project throughout its life cycle. The database is structured so than relationships between objects in the database can be maintained, in order that configuration control problems can be resolved.
2.B.5 Individual functions supported by the tools in an APSE include:
2.B.7 At all stages of the development of a program-design, coding, testing, maintenance--an APSE encourages the programmer to work in Ada source terms, rather than in terms of the assembly language of the particular host or target machine.
2.B.8 Extension of an APSE toolset requires knowledge only of the particular APSE and of the Ada language. A new tool-for example, an environment simulator-is written within the APSE. This tool can then be installed as part of the APSE and subsequently invoked.
2.B.9 An APSE supports the use of libraries of standard routines for incorporation in programs written for both host and target machines.
2.B.10 The above paragraphs outline the facilities offered by an APSE to its users in support of Ada programming. However, a further requirement is for portability both of APSE tools between, for example, APSEs hosted on different machines and of complete APSE toolsets. To address this aim and to indicate a means of implementation of an APSE designed to provide portability, this document gives requirements for a low level portability interface and support function set (the KAPSE) together with a minimal toolset (the MAPSE).
2.B.11 The purpose of the KAPSE is to allow portable tools to be produced and to support a basic machine-independent user interface to an APSE. Essentially, the KAPSE is a virtual support environment (or a "virtual machine") for Ada programs, including tools written in Ada.
2.B.12 The declarations which are made visible by the KAPSE are given in one or more Ada package specifications. These specifications will include declarations of the primitive operations that are available to any tool in an APSE. They will also include declarations of abstract data types which will be common to all APSEs, including the data types which feature in the interface specifications for the various stages of compilation and execution of a program.
2.B.13 While the external specifications for the KAPSE will be fixed, the associated bodies may vary from one implementation to another. In general all software above the level of the KAPSE will be written in Ada, but the KAPSE itself will be implemented in Ada or by other techniques, making use of local operating systems, filing systems or database systems as appropriate.
2.B.14 The minimal APSE (MAPSE) is one which provides a minimal but useful Ada programming environment and supports its own extension with new tools written in Ada. Hence, the MAPSE is an APSE and must meet the general requirements set down for APSEs.
2.B.15 For many important activities during a project life cycle as listed below, the only support offered by the MAPSE consists of general text manipulation facilities. A more comprehensive APSE will offer specialized tools to support a wide range of these activities, possibly including:
2.C.2 In cases where there is a large current investment in software projects, written originally in other languages and for which long term maintenance must be continued and improved, a viable policy may be to implant APSE-built tools into the existing environment or toolset with-a view to improving the existing environment for maintenance. This could provide valuable technology transfer at the environment level rather than the language level.
2.C.3 In other cases, Ada support environments will be constructed offering the use of the language together with a range of facilities which differ markedly in content and/or structure from those proposed here. For example, highly-integrated top-down development systems may be produced in some programming research establishments, meeting the APSE requirements but not reflecting the KAPSE/MAPSE structure.
2.C.4 All such systems, of course, represent entirely valid approaches to use of the Ada language. A further intent of the Stoneman, however, is to propose a way forward towards the goal-of portability. APSEs will address this requirement where relevant by making explicit a KAPSE portability level.
2.C.5 In order to achieve the long-term goal of portability of software tools and application systems dependent on them, it is intended that conventions and, eventually, standards be developed at the KAPSE interface level. This level will then serve as specifying a portability interface and separate tools or integrated sets of tools which meet the KAPSE interface requirements will be readily portable between hosts.
2.C.6 At this time, no attempt is made to specify in the Stoneman a long-term standard set of KAPSE interfaces, on the grounds that such standardization would be premature. The document gives requirements for APSEs in general and for KAPSEs and MAPSEs in particular. In later Appendices, provisional examples will be given of specifications for some KAPSE interfaces in the form of Ada package definitions. It is intended that such Appendices be separately distributed as available.
2.C.7 Progress towards the long-term goal of a wide measure of portability is expected to be achieved by a process of competitive design and evaluation of APSEs and their associated KAPSEs.
2.C.8 It is expected that in response to Stoneman and other initiatives designs for MAPSEs will be put forward in the immediate future for consideration by DOD components and others. These alternative designs will be considered and evaluated and may lead to iterative changes in the requirements.
2.C.9 Furthermore, it is expected that. one such MAPSE, and more particularly its basic kernel or KAPSE, will achieve a sufficiently wide measure of acceptance for it to become a de facto convention and, eventually, for the KAPSE specifications to be considered for standardization within the DOD.
2.C.10 Individual cools or sets of mutually dependent tools implemented on the DOD-KAPSE would then become fully portable within the DOD and other applications areas with DOD-compatible systems.
3.A SCOPE: An APSE shall provide a program development and maintenance environment for embedded computer system projects involving Ada programs, with the intent of improving long-term cost effective software reliability.
3.B QUALITY: An APSE shall reflect the priorities for software quality in military embedded computer applications; that is, reliability, performance, evolution, maintenance and responsiveness to changing requirements.
3.C SIMPLICITY: The structure of an APSE shall be based on simple overall concepts which are straightforward to understand and use and few in number. Wherever possible, the concepts of the Ada language will be used in the APSE.
3.D LIFE CYCLE SUPPORT: Support shall be provided to projects throughout the software life cycle from requirements and design through implementation to long term maintenance and modifications.
3.E PROJECT TEAM SUPPORT: An APSE shall support all functions required by a project team. These functions include project management control, documentation and recording, and long-term configuration and release control.
3.F USER HELPFULNESS: High priority will be given to human engineering requirements in the design. The system shall provide a helpful user interface that is easy to learn and use, with adequate response times for interactive users and turn-round times for batch users.
3.G UNIFORMITY OF PROTOCOL: Communications between users and tools shall be according to uniform protocol conventions.
3.H SYSTEM PORTABILITY: An APSE shall be portable so far as practicable. This will normally be achieved by writing the system in Ada, and by following the KAPSE design model as required in this document.
3.J PROJECT PORTABILITY: An APSE shall be designed to facilitate the easy movement of project support from one host machine to another.
3.K HARDWARE: An APSE will be designed to exploit, but not demand, modern high capacity and high performance host system hardware.
3.L ROBUSTNESS: An APSE will be a highly robust system that can protect itself from user and system errors, that can recover from unforseen situations and that can provide meaningful diagnostic information to its users.
3.M INTEGRATED: An APSE shall provide a well-coordinated set of useful tools, with uniform inter-tool interfaces and with communication through a common database which acts as the information source and product repository for all tools.
3.N GRANULARITY: Tools will be designed where appropriate to have separable limited function components that are composable, user selectable and communicate through the common data base.
3.P OPEN-ENDED: An APSE shall facilitate the development and integration of new tools. It shall permit improvements, updates and replacement of tools.
4.A.2 The database shall offer flexible storage facilities to all APSE tools.
4.A.3 A separately identifiable collection of information in the database in known in this document as an "object". Every object stored in the database is accessed by the use of its distinct name. The database shall permit relationships to be maintained between objects.
4.A.4 The database shall permit the user to designate several distinct database objects as forming a "version group". The user shall be permitted to designate one object within the group as being the preferred (or default) version. A method of access shall be offered in which an incomplete object name is provided, sufficient to identify explicitly a version group but net one object within that group; with such access, the preferred version is selected. Every object within a version group shall always be accessible by providing the complete object name.
4.A.5 The database shall support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name.
4.A.6 Mechanisms shall be provided in the database whereby all database objects needed to recreate a specified object will continue to be maintained in the database as long as the specified object itself remains in the database.
4.A.7 It shall be possible to establish partitions of the information in the database such that, for example, all objects connected with a specific project area can be grouped in a partition. It shall be possible to associate general access controls with partitions.
4.A.8 The database shall support the storage of Ada libraries in source form, and may also support a form where the library object has been pre-compiled for the host or a particular target machine. Facilities for determining the availability and functional specification of library objects shall be provided.
4.A.9 It shall be possible to associate access controls with any object in-the database, Such access controls shall be appropriate for the environment in which the particular APSE system is deployed, and shall be commensurate with the requirement that an APSE supports all roles in a project team throughout the lifetime of a project.
4.A.10 The database shall store information which allows management reports to be generated, as required at the particular APSE system.
4.A.11 The capabilities of the APSE database system shall be such that the users may work within the APSE to achieve reliable storage of objects, including long-term storage of archived objects.
4.A.12 The database shall preserve the consistency of the information and relationships it contains.
4.B.2 VERSIONS: All objects in the database are uniquely identifiable; however, a group of objects may exist as related versions which all may meet the same or closely related external specifications and may therefore be regarded as different versions of the same "abstract object". Within such a group, the user may specify that one object is the normal, default or preferred version which is to be used whenever the user does not indicate a specific one. Typically, in many current systems the concept of the most recent version of a "module" plays an important role and it may be that this methodological choice will be made in many APSEs; however, the requirements do not prescribe this approach.
4.B.3 CONFIGURATIONS: Different collections of objects in a project may be brought together to form different groupings or "software configurations." The differences arise in response to, for example, differing categories of user requirement or differences between peripheral devices on various target systems. Some configurations are long-lived, such as major system releases, and others may be temporary test-beds for development purposes. The relationships between objects in different configurations are in general complex, partially overlapping and not well-structured. Some .configurations are related in time, such as consecutive "releases;" others co-exist in time as separate "models". Note that configurations are themselves objects and may therefore exist in version groups.
The system must contain tools to enable the generation, release and subsequent control of a project which exists in multiple configurations. It is generally necessary to be able to determine for any configuration exactly what are the components of that configuration and to be able to reconstruct in detail the history and antecedents of each component.
The automatic rederivation of configurations as a result of constituent object changes may be a methodological choice in some APSEs.
4.B.4 HISTORY PRESERVATION: It is a requirement of an APSE that configuration control be provided. In general this necessitates recording and preserving sufficient information to establish, for any extant configuration, its precise constituents and all relevant information to support their repair or modification.
It is therefore a requirement at the KAPSE level that history attributes be maintained for all objects (see 5.A.5 below) as a basis for a configuration control system. At the MAPSE level a configuration control system is required but not specified in detail.
The detailed requirements on configuration control systems are left to some extent open to design choice. One- position to take is that no object whatever can be deleted from the database if it is referenced in the history attribute of any other object. This maximises reliability and maintainability and in many application areas, if combined with an effective archiving system, would be the preferable approach.
However, in other areas the requirements may differ and may indicate that indefinite preservation should be the privilege of specified objects only (see 4.A.6) and objects not so specified, under managerial control, may be purged from the database.
4.B.5 PARTITIONS: The partition level is the highest level grouping in the database. It exists primarily for managerial purposes as a means of applying broad access and budgetary control to large collections of information associated with projects. It can also play a part in implementation strategies designed to improve access to specifically important partitions in large data bases.
4.B.6 ACCESS CONTROLS: The access control requirements on APSEs are expected to be highly specific to the applications area and methodology of each APSE. Some areas will require very detailed controls whereas others will require only a few broad classes of protection.
The key requirement for a KAPSE is therefore that the primitive protection facilities it offers shall be sufficiently general purpose so that it can provide the basis for any required access control system in the APSEs built on that KAPSE.
In order to meet these requirements, the KAPSE must have knowledge of individual user identifications. These may well be handled by the local underlying operating system.
4.B.7 MANAGEMENT REPORTS: The style and content of project management reporting is specific to the project environment and methodology. In general, however, the database should contain information enabling at least two classes of reports to be produced:
4.C.2 The virtual interface shall be based on simple overall concepts which are straightforward to understand and use and which are few in number.
4.C.3 The virtual interface shall permit the invocation of individual tools from the APSE toolset.
4.C.4 The user may access the virtual interface from a variety of physical terminal devices.
4.C.5 The virtual interface shall permit the user to interact with the invoked tool and to exercise control over the tool.
4.C.6 APSE tools may access the virtual interface; e.g., to invoke other tools.
4.C.7 An APSE. must prevent access from the user which might affect the integrity of the KAPSE and its facilities.
4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set.
4.C.9 Initial user connection to the APSE may require use of the host operating system. A mechanism for returning to the underlying operating system shall be provided in the APSE.
4.D.2 USER INTERACTION WITH TOOLS: The degree of interaction possible between a user and a tool depends on the "granularity" of that style of device; for example, interaction from a batch terminal is limited to initiation of a job, provision of data and parameters and notification of the completion of the job together with its results.
4.D.3 ACHIEVABILITY OF COMMAND FUNCTIONS FROM WITHIN PROGRAMS: The requirement of 4.C.6 is fundamental to the composition of tools.
4.D.4 COMMAND LANGUAGES: The requirements of 4.C.3 and 4.C.4 may well be implemented by a command language (or job control language).
Regardless of the choice of command language, the environment must provide a primitive operation which enables the initiation of a program to be carried out. More precisely, this operation permits a data structure (such as a compiler output) to be executed as a program on the host.
Given this primitive, one possible approach to the implementation of a command language is to use a basic Ada-like language whose facilities, offered by a simple interpreter tool, provide little more than the ability to perform simple editing of command lines and to initiate programs.
The requirement in 4.C.6 indicates that the primitive initiation facility used by the command language will be made available as a library procedure to Ada programs. This will enable the user to construct job control sequences as Ada program texts which initiate other programs. This use may well be subject to some restrictions; for example, to prevent recursive initiation in unsuitable cases.
A more general approach is to regard the user interaction as being expressed entirely within Ada program segments which are executed or interpreted as necessary in the context of relevant points in the APSE database, thus providing a total Ada environment similar, for example, to an Interlisp environment.
In view of this range of possibilities, the detailed choice of command language is left as a design decision for specific APSEs.
4.E.2 Tools in an APSE shall be designed to meet clear functional needs and shall be composable with other tools in order to carry out more complex functions where appropriate.
4.E.3 Tools shall be written in Ada and where possible shall conform to standard interface specifications.
4.E.4 The set of tools in an APSE shall remain open-ended; it shall always be possible to add new tools.
4.E.5 The communications between tools shall be simple and uniform throughout an APSE toolset. Inter-tool communication shall be via the virtual interface.
4.E.6 The principles for communication between tools and the user shall be simple and uniform throughout an APSE toolset. The uniform principles shall apply to error handling as well as to normal operation of a tool.
4.E.7 An APSE toolset shall offer comprehensive help facilities to APSE users.
4.E.8 An APSE toolset shall support its own extension with new tools written in Ada.
4.E.9 An APSE toolset shall permit testing and debugging of any Ada program which does not use machine-dependent features of the language. It shall be possible to perform such testing and debugging purely in terms of the Ada source text and Ada language concepts (i.e., without reference to the instruction set or architecture of any machine).
4.E.10 An APSE shall permit testing and debugging of an Ada program executing in any target machine supported by the APSE. It shall be permitted for such a program to use the machine-dependent features of the language. The facilities for testing and debugging of target-resident programs should be based upon the equivalent facilities for host-resident programs.
4.E.11 APSE tools shall provide appropriate summary data for management reports and control. Such summary data shall be stored in the APSE database and will be project-dependent in nature.
4.F.2 TARGET ENVIRONMENTS. As stated in various sections above, the model of program development expressed in the APSE approach is that of a host-target system where the- host offers the vast majority of the support facilities. The whole purpose of the APSE, however, is to develop and support target machine programs and, in embedded computer systems in particular, final testing on the target machine is normally essential. The intention is for that testing to be carried out in Ada terms so far as practicable.
Four general styles of target resident testing are envisaged:
5.A.2 The database shall not impose restrictions on the format of information stored in an object.
5.A.3 The database shall permit relationships between objects to be recorded.
5.A.4 Objects in the database shall have attributes.
5.A.5 Every abject shall have a history attribute. The history attribute records the manner in which the object was produced and all information which was relevant in the production of the object. The history attributes shall contain sufficient information to provide a basis for comprehensive configuration control. Any necessary constraints shall be imposed on database operations so that the validity and consistency of history attributes is ensured.
5.A.6 Every object shall have a categorization attribute which indicates the category of information contained in the object. It shall be possible for the categorization attribute to be used in such a way that APSE tools are offered protection against accessing an object in a way that is not meaningful (i.e., incompatible with the format and/or content of the object) but are not prevented from accessing an object in any way that is meaningful.
5.A.7 Every object shall have an attribute which indicates access rights to the object.
5.A.8 The database interface shall permit provision of an archiving facility whereby files may be relegated to backing storage media while nevertheless retaining the integrity, consistency, and eventual availability of all information in the database.
5.A.9 The database shall allow APSE tools to access both the information content of objects and the attributes of objects, and to traverse the networks formed by relationships between objects. Access protection shall be applied to attributes so that attribute consistency is maintained.
5.A.10 It shall be possible for the actual reading and writing of database objects to be performed from within an Ada tool using the standard input/output facilities of the language, as defined in package INPUT OUTPUT.
The attributes which record history, categorization and access rights are mandatory. The list of possible attributes is open-ended and some APSEs may provide further attributes.
5.B.2 CATEGORIZATIONS: Every object has a category attribute. In general, a tool will only access objects of an appropriate category. Other tools, however, may need to access objects regardless of their category; one such tool is a general copying tool. The requirement on the KAPSE encompasses both of these styles of access. However, the requirement; does not dictate the manner in which protection is offered, nor that the protection mechanism must actually be implemented within the KAPSE.
5.C.2 The KAPSE shall offer the input/output support facilities that are required by Ada programs within the APSE which use the standard input/ output facilities of the language, as defined by package INPUT_OUTPUT.
5.C.3 The KAPSE shall provide the database access functions that are required by Ada programs within the APSE. This shall include the provision of the primitive functions necessary to permit the implementation of access control and security mechanisms as appropriate.
5.C.4 The KAPSE shall provide a mechanism whereby it shall be possible for one APSE tool to invoke another APSE tool and supply the invoked tool with parameters.
5.C.5 Input/Output support offered by the KAPSE shall be such that package INPUT_OUTPUT can be used by an Ada tool for communication with the control device from which the tool was invoked.
5.C.6 The KAPSE shall provide mechanisms where appropriate whereby asynchronous commands issued by a user at an interactive terminal can be applied to the executing tool.
5.D.2 CONTROL FUNCTION LIST
The KAPSE shall define a fixed set of terminal interface control functions. The list should be short, functionally adequate and human engineered to fit the needs of the terminal user. The following list is proposed:
5.D.4 PROVISION OF FUNCTIONS: In general, the KAPSE will be specified as a series of Ada package definitions making extensive use of the concept of abstract data types. This technique can be used both to provide KAPSE functions as listed in 5.C. above and to provide data structure descriptions of interfaces as in 5.E. below.
5.E.2 Interface definitions provided by the KAPSE shall encompass
5.E.3 The source representation of a compilation unit shall be as defined in the Ada reference manual.
5.E.4 An abstract syntax definition of a compilation unit shall be specified.
5.E.5 A post syntactic/semantic analysis intermediate language definition of a compilation unit shall be specified.
5.E.6 An abstract data type definition of an executing Ada program shall be specified. The abstract data type shall offer read/write access to both the code segments and the data spaces of the executing program. When used in conjunction with the full symbol tables (see 5.E.7 below), this abstract data type shall allow the production of source- level debugging tools.
5.E.7 An abstract data type definition of a comprehensive symbol table for a compilation unit shall be specified. In addition to the basic symbol declaration entries, the abstract data type shall encompass source line locations, symbol usage, program topology, and any other information required by basic analysis, testing, or debugging tools.
5.E.8 An abstract data type definition of a "library filed" (Ada Reference Manual, section 10.4) shall be specified. This abstract data type shall allow new compilation units to be added to the library file, and shall allow the relationship between compilation units in the library file to be determined.
5.E.9 When used in combination, the symbol table and library file abstract data types shall permit construction of comprehensive symbol table(s) for the (possibly incomplete) program(s) represented by the contents of the library file.
In some translation systems there is a clearly defined intermediate language representation level between the syntactic and semantic analysis phases and the code generation phase. This separation is the basis of the retargetable compiler approach whereby several code generators are provided for different targets. It is expected that retargetable Ada translators will be produced and therefore there is a requirement for agreement on this level of representation.
Currently one candidate for an Ada-oriented intermediate representation is available for comment. This is TCOL-Ada and it is described in
The existence of retargetable and separable-phase translator systems does not of course preclude the existence of more traditional compiler designs in which an intermediate code level may well not be distinguishable.
5.F.2 LIBRARY FILES
A library file as defined in Ada groups together all those compilation units (represented as objects in the database) which are inter-related and which eventually will be linked into one or more complete programs.
The technique of implementation of the library file, and hence of separate translation as defined in Ada, is of course a design decision. An example of such a design, funded by the U.K. Ministry of Defense is given in; "Ada Support System Study: Phase 2 and Phase 3 Reports."
In addition to the examples referenced in 5.F.1 and 5.F.2 work is proceeding on preparing initial examples of Ada package specifications in response to requirements 5.E.6, 5.E.7, and 5.E.8. It is intended that the examples be circulated when available as Appendices to this document.
A candidate for the abstract syntax specification required in 5.E.4 is expected to emerge from current work in the Ada design group.
6.A.2 PRETTYPRINTER: A display tool is required to format and output textual material ranging from documentation to source programs. More specifically, it shall print database objects in legible formats which depend on the object categorization.
6.A.3 TRANSLATOR: A MAPSE will include at least one Ada translator, which translates source Ada programs into target code for the host and at least one target. The detailed requirements on the translator are that it should interface to the KAPSE as specified in section 5E above and thereby be cooperative with the other tools.
6.A.4 LINKERS: Linkers are required in a MAPSE for both the host and target machines. The facilities needed are:
6.A.6 SET-USE STATIC ANALYSER: A tool is required to provide a cross-reference map indicating where each data item is changed in value and where it is merely referenced.
6.A.7 CONTROL FLOW STATIC ANALYZER: This tool produces a chart of the program control topology. This will indicate which routines are called from where in the program and may indicate exception scopes and inter-task communication calls.
6.A.8 DYNAMIC ANALYSIS TOOL: On systems with an interactive capability this tool shall provide the following functions:
6.A.9 TERMINAL INTERFACE ROUTINES: Corresponding device handlers shall be provided for each variety of terminal device available on a specific configuration. These interface between the terminal and the relevant functions and data structures in the KAPSE.
6.A.10 FILE ADMINISTRATOR: A file transfer and compare facility shall be provided. A standard transfer format shall be adopted and the following facilities provided:
6.A.12 CONFIGURATION MANAGER: A tool is required to assist in long term configuration control of projects. As minimal functions this tool will enable interrogation of history attributes and will offer managerial control over the persistence of objects in the database.
6.B.2 Many of the objects stored in the database are not structured in ways that are immediately legible. The information in these objects (as well as their attributes), however, must often be studied by users; hence the need for a prettyprinting tool (or set of tools) that transforms database objects into legible and understandable formats. The prettyprinter may perform transformations that include:
6.B.4 Debugging and testing Ada programs at a low level representation (machine or assembly language level, for instance) defeats much of the purpose of programming in Ada in the first place. Therefore, these facilities must be provided at the Ada source level in a MAPSE. This may require KAPSE level support.
6.C.2 A high-level 1/0 package is required for each target machine.
6.C.3 A physical file handling package is required for each target, if appropriate.
6.C.4 A file directory system is required for each target.
6.D.2 Clearly these proposals for MAPSE libraries represent a minimal subset only.
7.A.2 ADA PROGRAM EDITOR: An APSE may provide an editor specifically for Ada source programs. This will assist in the preparation of syntactically correct programs by providing templates for language constructs and by checking input for consistency as appropriate.
7.A.3 DOCUMENTATION SYSTEM: A substantial part of the effort of developing a system is devoted to its associated documentation; for example in specifications, design documents, user manuals and educational material, and so on. An APSE may provide a tool to support the production and control of documentation for a project. This may interface with the editor and with a word processing system, if one is available, together with display tools (such as the prettyprinter required in a MAPSE). It may control graphic displays, figures and text in a unified system. It may be necessary for this tool to be sensitive to the security classification of materials and to implement military documentation standards where required.
7.A.4 PROJECT CONTROL SYSTEM: An APSE may provide a tool for keeping track of progress of a project against review dates and budgets. This may include productivity measurements and programmer usage logging.
7.A.5 CONFIGURATION CONTROL SYSTEM: The history attributes provided at the KAPSE level record a variety of software configuration relationships. Tools to help structure these relationships, modify them, indicate the ramifications of (potential) modifications, etc., are appropriate in an APSE. In many systems the facility will be provided, subject to suitable controls, to archive or delete superceded material in the database or to rederive material subsequent to and affected by changes.
7.A.6 MEASUREMENT: Instrumentation and performance measurement tools may be provided by an APSE. These are for use both in determining the efficiency of. other. tools and in the study of user programs.
7.A.7 FAULT REPORT SYSTEM: As part of the continuing responsibility during maintenance, an APSE may provide a tool to handle error and change reports, to progress them and to relate them to source code documentation and configuration changes. This tool may offer further support for the testing process, for example in automatic retesting after changes.
7.A.8 REQUIREMENT SPECIFICATIONS: An APSE may provide tools for manipulating requirement specifications and for tracing requirement specifications through to design and coding stages.
7.A.9 DESIGN: Tools to aid both system and program design may be part of an APSE.
7.A.10 VERIFICATION: As automatic program verification systems become available, they may be provided in an APSE.
7.A.11 TRANSLATORS: Complex translators may be appropriate in an APSE.
These complex tools may consist of several discrete components that may be interchanged and used by other tools in the APSE. These components may include:
7.B.2 As one initial example, there will be a requirement for a numeric applications library.
You may return to the introduction to STONEMAN on-line.
STONEMAN was converted to HTML and other electronic formats by Clyde Roby.