SECTION 1

INTRODUCTION

1.1 Scope

This document is the International Requirements and Design Criteria for the Portable Common Interface Set. Both the IRAC and the PCIS will be recommended for adoption and use by NATO and its member nations when completed.

A general Project Support Environment provides a total capability for developing software in a range of programming languages. This capability includes not only software engineering, but also project management and documentation, etc. These capabilities are made available to the user through a comprehensive set of transportable tools. The ability to extend the tool set by adding new tools, combining existing tools, and reusing tool components should lead to cost-effective automation of life-cycle support for software.

The IRAC forms the basis for the design of PCIS. An implementation of the PCIS framework can take one of many forms and may typically conform to a subset of the requirements (particularly in the short-term). The PCIS Programme does not intend to define new standards or a new public tool interface. Rather, it prefers the use of existing standards to fulfill requirements wherever possible. This approach is adopted in order to:

Capitalize on the considerable investment already made in standards, interfaces and frameworks.
Guide industry in a way which will enhance the capability of tools and frameworks to intercommunicate, without restricting freedom to create enhanced or specialized systems.
Provide a basis for the future evolution and incorporation of framework and other technologies.

The requirements in the IRAC have been formulated to capture the characteristics of the PCIS in the foreseeable future.

Requirements are distinguished from Design Criteria in this document by their being mandatory, whereas the latter provide options which may not be fully implemented in a given design.

This document defines the requirements and design criteria for the framework and recognizes also the need to incorporate existing and emerging standards from areas such as:

a) Communication protocols, so that implementations running on a network of computers form an integrated whole.

The standardization of communication protocols is essential if PCIS implementations are to communicate without the explicit intervention of tools. In a network of PCIS installations, the communication necessary to support the integrated Object Management System (OMS) should be invisible to the tools, and hence communication is not part of the tool support interface. The facilities for communications in Section 6 address tool-specific communications.

b) Presentation and functionality of the man-machine interface to human users.

This means the end-user-interaction style for those operations provided by the tool interface. For example, the support for moving of windows or choosing from a menu. The PCIS framework will define the form of user interaction, preferably by incorporating an existing widely used standard, such as the X Window System.

c) The interfaces to binding language run-time systems.

The implementation of run-time systems (RTSs) may use the PCIS. The PCIS should include facilities enabling both the integration of, and communication between, PCIS and the RTS. The definition of the RTS facilities (e.g., Ada tasking model, C run-time library, or embedded SQL) may not form a part of the PCIS. The definition of the PCIS will take due note of ongoing relevant standardization activities in this area. Typical of such relevant standards is the IRDS family [IRDS90], [IRDS91a], [IRDS91b].

d) Procedure calling conventions and other compiler-dependent aspects.

The trend towards dynamic linking of code for run-time binding will necessitate standards in this area. These will be required to ensure portability of executable code between implementations of PCIS. Implementations may be based upon different compilers, and should enable new tools to be added without re-linking the whole environment. The standard for remote procedure call (RPC) may prove relevant. It is expected that PCIS will take into account such standards.

e) Inter-tool interfaces.

Inter-tool interfaces define the syntax and semantics of the data passed between tools. This may range from the format of object code modules passed between a compiler and a linker, to the contents of the Ada program library. The definition of inter-tool interfaces is already the subject of existing standardization, for example, the CASE Design Interchange Format (CDIF). However, the facilities of the PCIS, particularly those of the OMS (see Section 4), will assist in the process of defining such interfaces.

1.2 Approach

This document intentionally leaves as many degrees of design freedom to the PCIS definers as is consistent with the achievement of interoperability and transportability. Likewise, the PCIS definers should also leave as many degrees of implementation freedom to PCIS implementors as is consistent with the achievement of interoperability and transportability.

1.3 Terminology

Precise and consistent use of terms has been attempted throughout the document.

A definition of terms is provided in Section 10.

Additionally, the following verbs and verb phrases are used throughout the document to indicate where, and to what degree, individual constraints apply. Any sentence not containing one of the following verbs or verb phrases is a definition, explanation or comment.

"SHALL"
indicates a requirement on the definition of the PCIS. Sometimes "shall" is followed by "provide", "support" or "be implementable", in which cases the following definitions supersede this one.
"SHALL PROVIDE"
indicates a requirement for the PCIS to define facilities which, when implemented, will provide the prescribed semantics.
"SHALL SUPPORT"
indicates a requirement for the PCIS to define facilities which, when implemented, will provide the prescribed semantics or for the PCIS definers to demonstrate that the functionality can be constructed from PCIS facilities.
"SHALL BE IMPLEMENTABLE"
indicates a constraint on the design of the PCIS. A requirement of this form does not imply that implementations must be so implemented.
"SHOULD"
indicates a design criterion. For some design criteria there may be no objective tests. The degree to which the PCIS complies with design criteria may be used as a measure of the quality of the PCIS.
The IRAC requirements are often expressed in the form "The PCIS shall provide (support) facilities to...". This, strictly, should be written "The PCIS shall provide (support) facilities for a process to...", but, since only processes can call subprograms, the shortened form is preferred.

1.4 Relationship to Specifications and Implementations

There are three elements essential to the realization of a PCIS implementation:

The document that specifies requirements for facilities which are to be defined in the PCIS and are therefore to be provided by conforming PCIS implementations,
The specification of facilities (and decisions about whether or not to include certain facilities, as suggested by the "shall support" definition in the previous section) which is written by the PCIS definers, and
The implementation decisions about how certain facilities are provided (for example, if a PCIS implementor determines that it is feasible, the implementation may provide a particular specified PCIS facility by reusing other PCIS facilities, thereby achieving a "layered implementation" of the PCIS).

Therefore, the realization of a specific PCIS implementation is the result of intentionally divided decision-making authority among this requirements document, the PCIS definers, and the PCIS implementors.

1.5 Reference Documents

MILITARY STANDARDS

[Ada83]: Reference Manual for the Ada Language, ANSI/MIL-STD-1815A, January 1983.
[CAIS89]: Military Standard Common Ada Programming Support Environment (APSE) Interface Set (CAIS), Revision A, MIL-STD-1838A, 6 April 1989.

1.6 List of Acronyms

ACEC	Ada Compiler Evaluation Capability (USA DoD)
ACVC	Ada Compiler Validation Capability
AES	Ada Evaluation System (UK MoD)
APSE	Ada Programming Support Environment
BS	British Standard
CAIS-A	Common APSE Interface Set - Revision A
CASE	Computer Aided Software Engineering
CDIF	CASE Design Interchange Format
CEC	Commission of the European Communities
CG-VDI	Computer Graphics - Video Display Interface
CIVC	CAIS-A Implementation Validation Capability
CLI	Command Language Interpreter
DBMS	Database Management System
DIS	Draft International Standard
DoD	Department of Defense (USA)
ECMA	European Computer Manufacturers Association
EDIF	Electronic Data Interchange Format (Standard)
ER	Entity Relationship
ESPRIT	European Strategic Programme for Research of Information Technology
EURAC	European Requirements and Design Criteria (document)
GKS	Graphics Kernel System (Standard)
IEPG	Independent European Programme Group
IPC	Inter-Process Communication
IPSE	Integrated Project Support Environment
IRAC	International Requirements and Design Criteria (document)
IRDS	Information Resource Dictionary Services (Standard)
ISO	International Standards Organization
ITSEC	Information Technology Security Evaluation Criteria (document)
KAPSE	Kernel APSE
LAN	Local Area Network
MIL-STD	Military Standard (USA)
MIT	Massachusetts Institute of Technology
MoD	Ministry of Defence (UK)
MSDOS	Microsoft Disk Operating System (Trademark of Microsoft, Inc.)
MVS	Multiple Virtual Storage (Trademark of IBM, Inc.)
NIST	National Institute for Standards and Technology (USA)
NATO	North Atlantic Treaty Organization
NRAC	NATO Requirements and Design Criteria (document)
OMS	Object Management System
OSCRL	Operating System Command and Response Language (Standard)
OSF	Open Systems Foundation
OSI	Open Systems Interconnect (Standard)
PC	Personal Computer
PCIS	Portable Common Interface Set
PCTE	Portable Common Tool Environment
PHIGS	The Programmer's Hierarchical Interactive Graphics Standard
PSE	Project Support Environment
PVS	Pascal Validation Suite
RAC	Requirements and Design Criteria
RAISE	Rigorous Approach to Industrial Software Engineering (project)
RPC	Remote Procedure Call (Standard)
RSL	RAISE Specification Language
RTS	Run-Time System
SEE	Software Engineering Environment
SQL	Structured Query Language
SWG	Special Working Group on APSE
TCB	Trusted Computing Base
TCS	Trusted Computer System
TSGCE	Tri-Service Group on Communications and Electronics
VDM-SL	Vienna Development Method - Specification Language (Standard)
VIP	VDM Interfaces of PCTE (project)
VVSL	VIP VDM Specification Language
WAN	Wide Area Network
X-Windows	The X Window System (Trademark of MIT)

Go forward to Section 2, General Design Objectives.