SECTION 2

GENERAL DESIGN OBJECTIVES

2.1 Scope of the PCIS

2.1A Support for IPSEs. The PCIS shall provide facilities necessary to support the construction of IPSEs. Such IPSEs shall be suitable for supporting the entire life-cycle of a wide variety of civil and military application systems.

The IRAC is concerned with the requirements placed by tools, libraries and other software on their supporting framework in the context of an Integrated Project Support Environment (IPSE). The role of a framework includes the following:

To provide mechanisms to support effective integration.
To provide services which would otherwise have to be provided in many tools (commonality).
To reduce the work which tool builders or environment builders must perform by providing a higher level of service than would be provided by a conventional operating system.
To provide mechanisms to enforce policies for all the tools and users of the environment.

The IPSEs will support projects whose function is to produce software applications. Further, it is expected that the framework requirements of IPSEs for engineering and management disciplines other than software engineering are largely captured. The PCIS will define interfaces to facilities necessary to support the construction and deployment of system engineering environments (SEEs). Of particular interest are SEEs for developing, maintaining and evolving both civil and military application systems throughout their lifetimes.

PCIS should support the incorporation, maintenance, and operation of a wide variety of tools in the SEEs. PCIS is not expected to provide all the services required for the construction of IPSEs, but it will supply those services necessary to satisfy IRAC requirements.

The PCIS will support conventional programming languages, such as Ada and C, and it will also support object-oriented languages.

The PCIS is not concerned with providing facilities to support any particular tool. It is concerned with supporting classes of tools.

2.1B Support for Long-Lifetime Projects. The PCIS shall provide facilities sufficient to support very long-lived development and maintenance projects.

PCIS-based IPSEs will be employed in very large development projects (the larger the project, the greater the need for an IPSE). Very large developments are long termed, and their deployment and maintenance are very lengthy. For example, systems such as the software residing on aircraft can be in development and maintenance twenty to forty years.

One consequence of system longevity is that the IPSE itself will undergo maintenance and change during the project. For example, the PCIS must facilitate tool installation, multiple versions of the same tool, and tool retirement. In general, the IPSE provides essential services in support of the project process; that process may change dramatically ways over the project lifetime. PCIS must facilitate the adaptation of the IPSE to such process changes.

2.1C Interoperability. The PCIS shall provide mechanisms for the integrated functioning of tools (and other environment components) using independently developed PCIS implementations on the same or different types of host.

This requires that the mechanisms for connection of PCIS implementations be sufficiently defined to permit connecting independent implementations. Such mechanisms include facilities to exchange data between independent PCIS implementations, which may reside on independent computer systems. Such mechanisms further permit the services (for example, data manipulation) of one implementation to (appear to) be applied to the resources (for example, objects) managed by another, connected implementation. This recognizes the efforts which IPSEs must serve: large, distributed projects composed of cooperating organizations utilizing diverse hardware and software supplied by multiple vendors.

2.1D Transportability. The PCIS shall support transportability of IPSE components.

This is one of the goals of standardization of the PCIS.

2.1E Tool Cooperation. The PCIS should support the integration of tools and other environment components, and shall include facilities to describe and inspect the specifications of such integration.

Whereas PCIS shall provide mechanisms for communication between tools, it is not required to mandate the form and substance of this communication. That is considered a matter for agreement between tools (or tool vendors). However, a role of PCIS in supporting integration is:

To provide the mechanisms for agreements and conventions between tools.
To minimize the effects of disagreement and difference in the observance of conventions.

There are several kinds of integration to be considered:

Data Integration: concerning the data and description of data passed between tools.
Control Integration: concerning the invocation, synchronization and flow of control between tools.
Presentation Integration: concerning common ways that the user interacts with different tools.
Functional Integration: concerning the sharing of functionality between tools, or the subsuming of the functionality on one tool by another (see Requirement 2.1F, Support for Reuse).
Process Integration: concerning how a number of tools work in concert to achieve project goals, typically in support of the software development process.

Data integration specifications typically include the schema and views describing the data which a given tool accesses. Control integration specifications include the interfaces which a given tool presents to others.

2.1F Support for Reuse. PCIS shall support facilities for software component reuse.

The primary purposes of an IPSE include maximizing software engineering productivity, maximizing software product quality, and minimizing software production costs. One of the potentially most effective services to provide in fulfilling these purposes is the reuse of existing, proven application software components. Reuse of components meeting requirements can minimize software development, and hence its costs and risks. The PCIS support for tool component reuse will allow the evolution of tools (over the lifetime of the application system being developed, maintained or evolved) and assist the sharing of components between tools.

Re-use of PCIS components allows services provided by PCIS implementations to be used in applications.

Such support will include authorization mechanisms for reuse, which can allow different sets of scopes, such as organization wide, division wide, project and temporary.

2.2 Simplicity

The PCIS should provide simple-to-use facilities for achieving common, simple actions.

There are a number of major reasons for the development of the PCIS, including transportability of tools and interoperability of databases. Another major reason is to encourage the production of a wide range of reliable tools. The production of tools is simplified if the PCIS facilities are easy to understand and invoke. The PCIS designers should choose a set of facilities such that the more frequently used ones are simple to use, possibly at the expense of the less frequently used ones being more difficult to invoke. The emphasis here is on providing simple facilities to support a wide range of tools.

The ease of use applies to tool production both for new tools and for existing tools to be ported. The ease of tool porting concerns a requirement to make it easy to migrate a tool from some existing environment or platform to PCIS.

Ease of use also applies to the tool user, inasmuch as simplicity of the PCIS results in simplicity of tools and thence ease of use of the tools. PCIS should be designed to make it easy for tool writers and porters (but particularly the tool writers) to produce tools on PCIS which are easy for the tool-user to use.

2.3 Uniformity

A small number of unifying conceptual models should underlie the PCIS. All PCIS features should uniformly address aspects such as operations, status, exception conditions, parameter types, and options. The PCIS should use a self-referencing approach; in particular, the PCIS should use the data modelling facilities of the OMS (as defined in Section 4) for its model of the logical resources on which it is running and for the object management typing information.

The requirement for a small number of unifying conceptual models underlying the PCIS is a mandate for a well engineered, easily understood specification.

The IRAC requirements are to apply uniformly across the PCIS. The PCIS designers should not split the interface set in order that some part can meet some IRAC requirements and another part can meet other requirements. For example, objects in the database should not be split into those with predefined operations and those with user-defined operations in order to meet requirements for both predefined and user-defined operations.

Another unifying approach to the design of PCIS would be to combine object management with program execution facilities. One aspect of an object is user-defined operations. An object has a set of named operations. The object model may provide mechanisms to define and manage the execution of operations. The model may also provide the means by which the programs and subprograms which implement operations are managed. So long as the requirements of Section 4 and Section 5 are met, a unified solution is more desirable. PCIS designers may also determine that unifying object management and program execution facilities provides better support for software life-cycle activities. The specification and performance of software life-cycle activities, which is known as life-cycle process management, has much in common with object management and program execution facilities.

The use of a uniform approach to aspects such as status and exceptional conditions makes the job of learning to use the PCIS much easier. Once the philosophy has been grasped, a tool writer using a feature for the first time would find such a feature intuitive.

The requirement to use the data modelling facilities of the object management support for the model of logical resources and for the typing information is an important aspect of uniformity. The benefits include: increased confidence in the clarity and completeness of the PCIS, and the ability of generic tools to access a wide variety of different kinds of data using a single set of mechanisms. This latter facility reduces the size of the toolset and increases the integration. The benefits are further elaborated below. In particular:

The requirement that the PCIS use the data modelling facilities for its representations of the architecture on which it is running is a step towards formalization of the architecture model. Generic tools also have the ability to examine the architecture. This also enhances the toolwriters' ability to produce portable tools. It should be noted, PCIS designers must choose how much of the architecture should be a part of the PCIS. However, all of the architecture that is a part of the PCIS should be represented using the OMS. For example, if the physical connections between workstations are not a notion within the PCIS (in particular, if they cannot be examined through the PCIS), then they do not need to be represented in the OMS.
Requiring the PCIS to use the data modelling facilities for its representation of the object management typing information is a step towards formalization of the data model and gives a generic tool the ability to query the schema as well as the data. Thus a standard report generator is automatically a schema print program. A query language allows interrogation of the schema as well as any other data and hence the end user can write ad hoc queries of schema and data.

2.4 Completeness

One of the major goals of PCIS is (tool) transportability. In order to provide this autonomously, a framework must provide a sufficient set of facilities to totally support tools and must be predictably widely used as an incentive for tool builders to base the transportability of their tools on the framework. While it may be desirable that the PCIS be complete and provide all facilities for all tools, a requirement that mandates all facilities for all tools is recognized to be unachievable, and in some cases, unacceptable in practice. The goal in the design of the PCIS should be to optimize the degree of completeness, compromising between all possible facilities and those that can and will be implemented widely and accepted readily.

In light of this trade-off between completeness and acceptability, PCIS must exploit existing and emerging standards (de facto and de jure); it should employ such standards wherever possible, rather than defining its own, new, solutions. In the achievement of this balance, it is essential that the conceptual models supported by PCIS facilities be chosen carefully. Once chosen, these mechanisms must be supported "completely".

The PCIS should provide a complete set of facilities for all elements of its underlying conceptual models.

The conceptual models within the PCIS are local to the PCIS and are not necessarily compatible with the conceptual models of, for example, the underlying operating system (if there is one). The things within the conceptual models of the PCIS can, in all probability, only be manipulated by the PCIS facilities. Hence all desired manipulations must be catered for by the PCIS. Simple examples are:

If there is a facility to create something, then there should also be a facility to delete it.
If there is a facility to set a value, then there should also be a facility to examine it.

2.5 Implementability

2.5A Variety of Architectures. The PCIS shall be implementable on a variety of system architectures, including bare machines, and a variety of operating systems. The system architectures shall include local area networks and wide area networks, which may be homogeneous or heterogeneous.

One of the major goals of the PCIS is tool transportability. A PCIS which could only be implemented on a limited range of architectures could not become generally used, and hence transportability of tools would be constrained.

The specification of facilities should not be bound to any proprietary operating system. The level of abstraction should be high enough to permit an implementation on various and different styles of operating systems.

The current trend in the software industry is towards local computing resources, networked to provide project or company computing capacity. The networking may be via some high speed local area network, or, for geographically separate sites, via a wide area network. Apart from the increased needs for communications, this trend arises from the need to cope with the unacceptability of using resource-hungry tools within a multi-user, single CPU machine. In view of this trend the ability to use a network of workstations to support an IPSE is seen as essential.

2.5B Implementation Independence. The PCIS shall be implementation independent.

This again reflects the basic goal of tool transportability. This can only be achieved where the PCIS itself can be implemented on a wide range of system architectures without revealing any particulars of the underlying system.

2.5C Demonstrated Features. The PCIS shall contain only features which have been demonstrated in existing software systems.

This requirement is introduced to provide stability. In general new and untried features go through several iterations during the initial implementation and commissioning. Where an interface is breaking new ground in this way, it is likely that frequent changes to the specification will be necessary. This introduces unacceptable risks and delays for tool writers. Introducing this requirement ensures that the PCIS designers and implementors have a clear idea of their goals and that the resulting product will be useful. Demonstration in existing software systems is not limited to commercial-off-the-shelf software or deployed systems, however. A demonstration in a reasonably mature research system is also acceptable.

2.5D Effectiveness. The PCIS should be implementable so as to avoid execution costs for unneeded generality, and to ensure that unused features will not add to execution costs of tools which do not require them.

This is a general engineering point. The success of the PCIS depends on its widespread adoption, and anything which mitigates against widespread adoption is to be discouraged. The overheads associated with generality are well known, and this requirement directs the PCIS designers to address this problem.

This also requires a PCIS design that avoids using structures forcing implementation as a monolith.

The requirement for minimization of implementation costs should be passed to the implementation by the PCIS. Note that here execution costs are deemed to include such things as resource consumption, including memory, cpu time and input/output. For example, in the unclassified use of PCIS, it might be feasible to reduce execution costs by bypassing, or not installing, security checking facilities.

2.5E Efficiency.

a) The PCIS should be implementable so as to execute efficiently. In evaluating efficiency, responsiveness is a more important criterion than consumption of resources.

b) The PCIS shall be implementable such that PCIS-based IPSEs can execute as efficiently as equivalent IPSEs based on other specifications.

There are three aspects to this:

The efficiency of a technology is measurable relative to alternative technology available to achieve the same purpose. If a tool takes an appreciable length of time to perform a task, then this may seem unacceptable to the user. If, however, the tool in this time achieves some effect that would require orders of magnitude more time for the user to achieve in any other way, or if, in the time, the tool safeguards against user errors which would otherwise take more time to eradicate at a later stage, then the tool is cost efficient.
The PCIS can only achieve its goal of transportability if it is widely adopted. While the efficiency of any particular implementation is likely to be a contractual matter between supplier and purchaser, it will be necessary to achieve some reasonable level of efficiency before the PCIS can be seriously considered for a significant number of applications. Until the PCIS is considered seriously the tool writers are unlikely to invest in production of tools.
Requirement 2.5E(b) suggests an objective (though dynamically changing and difficult to evaluate) measure of efficiency.

The requirement indicates that, where there is a choice between consumption of hardware resources and the perceived execution time, the execution time should be minimized. This must, of course, be interpreted intelligently, since, in the limit, hardware resources are constrained.

2.5F Compiler Independence.

a) The PCIS shall be implementable such that it can accommodate software tools supplied in object form (for the system underlying a particular implementation) produced by a variety of compilers.

b) Each PCIS language binding should be independent of differences between compilers for that language to the maximum extent possible.

Compilers may use different strategies for calling procedures, memory allocation, etc. Therefore there is the distinct risk that a tool compiled with a compiler different from that used for a PCIS implementation binding will not function correctly on that PCIS implementation.

It would be impractical to require that tools are supplied in source code format for recompilation by the compiler used for the PCIS implementation. This requirement expressly identifies the need to be able to integrate, tools that are compiled by a variety of compilers.

Tools written in languages other than those of the standard language bindings are faced with the same problem of incompatibility with the compiler used to compile the PCIS implementation. Therefore this requirement has important ramifications for the inclusion in PCIS-based IPSEs of tools written in languages other than those of the standard bindings.

If a PCIS implementation is to permit the use of tools without the need for recompilation, the PCIS implementors must provide a mechanism by which a "connection" between a tool and the implementation can be achieved. One possible mechanism is a translator from the tool compiler's calling conventions to those of the compiler used to compile the PCIS implementation.

2.5G Platform Exploitation. The PCIS shall be specified so as to permit effective use of commonly available host system software in its implementation.

Commonly available host system software includes operating systems, network services, database managers and user interface managers. Efficient and cost-effective implementation of PCIS will rely on exploiting production-quality platforms. If PCIS required duplicating existing host functionality, its implementation would be significantly larger, more expensive, and less adaptable.

2.5H Implementation Dependent Features. The PCIS shall be specified so as to permit user visibility into the choices made for any implementation dependent features.

The choices made for implementation dependent features are important ways that one implementation of a standard can be distinguished from another, for a particular environment and situation. The ability to select an appropriate implementation for a given set of circumstances is critically determined by user visibility of these features.

2.6 Subsetting

The PCIS shall allow separation of the interfaces or interface functionalities into coherent and self-consistent subsets. Each such subset shall be clearly identified and shall consist of a set of services obtainable through the PCIS or a subset of the PCIS. There may be subsets of subsets. Tools which work on an implementation of a subset must also be able to work on a full implementation of PCIS or on any defined superset which is itself a subset of PCIS. Conformance shall be defined for each defined subset as for PCIS itself.

These requirements reflect the necessity that the PCIS must not be a monolithic interface set or be supportable only by a monolithic implementation. It is crucial for the success of the PCIS that transitioning IPSEs to become PCIS-based need not "buy into" a complete PCIS implementation from the very beginning, but instead can incrementally absorb the most needed PCIS partitions at a suitable pace. The choice of these partitions will heavily depend on the nature of the tools to be transitioned.

This requirement also correlates to the desire for easy extension in an open architecture (by adding new partitions) and for future standard evolution (by replacing existing partitions). A PCIS architecture that supports separability is more likely to be amenable to such modifications without experiencing a major impact on existing partitions.

The separability requirement is likely to present some conflict with other requirements and is a significant challenge to the PCIS designer and implementer. Particularly, some otherwise desirable tighter integration of services across partitions might not be achievable while maintaining a reasonably high degree of separability. Examples of well-integrated frameworks which would benefit from improved partitioning include the CAIS and PCTE specifications. Hence, services to achieve integration may need to be explicitly provided, which otherwise could be merely implied by the prescribed semantics of certain services and relegated to the internals of the PCIS implementation.

Subsetting of functionality is necessary as well as subsetting of interfaces. This is exemplified by the following:

Security. Some implementations may not provide the security functionality which secure implementations will provide for all operations.
Networking. Some implementations may be confined to single workstations. Then the functionality of replication operations is not needed. Errors from network problems cannot arise so the list of errors for operations is reduced. However most operations are still required, especially if PCIS makes networking generally transparent.

These particular examples are orthogonal so one can have implementations with or without security, and with or without distribution, giving four combinations. The combination without either is a subset of two other subsets, each of which is a subset of a full implementation.

Levels of conformance apply to the subsets.

2.7 Extensibility

2.7A Combining Facilities. The design of the PCIS should facilitate the development and use of higher level interfaces, that is, PCIS facilities should be reusable so that they can be combined to create new interfaces and facilities.

This requirement should not be interpreted to mean that PCIS must have the ability to define new facilities that are equivalent to compositions of existing PCIS facilities where the main difference is that the new facilities are implemented more efficiently. This requirement merely states a demand that a new facility can be constructed on top of the PCIS using the existing facilities of the PCIS. If such new facilities gain widespread usage, it may be that these new facilities could then be accepted in future revisions of the PCIS.

2.7B Open Architecture. The design of the PCIS should facilitate the development and use of new facilities that can be added to implementations of the PCIS. The nature of the open architecture shall not be such as to prejudice the transportability of tools.

This requirement urges an "open architecture" approach. Such extensibility will be a practical approach for dealing with mechanisms to include new device technologies (support for new device types and protocols) and the incorporation of new and existing standards (for instance, GKS, EDIF) in a natural manner.

2.8 Technology Compatibility

2.8A Integration with Standards. The PCIS shall integrate easily with applicable, industry-accepted, international and national standards. The independent evolution of such standards shall be easily accommodated by the PCIS and tracked by its implementations.

The adoption of industry-accepted standards in any software project is sound engineering practice. PCIS should facilitate IPSEs to adopt such standards and respective standard services and interfaces in the construction of IPSE tools.

The portability of tools would make it desirable for PCIS to firmly adopt a limited and non-overlapping set of such standards. However, most standards have a much wider constituency than presented by the IPSE or tool producers. The latter will therefore have a limited influence on the success and evolution of such standards; they need to follow the general market-place. Consequently, the PCIS and its implementations need to easily accommodate shifts in this general market-place both in terms of evolution of existing standards and of replacement of waning standards.

2.8B Usage of Standards. The PCIS shall not develop new alternatives in areas where proven or emerging international and national standards already exist and are functionally adequate for IPSEs. If PCIS services or interfaces depend on an existing standard, such dependence shall be specified and the standard shall be cited by reference.

This again is sound engineering practice. There are already too many "re-inventions of the wheel" in software engineering and too many competing standards of nearly equivalent functionality. This requirement is intended to discourage further diversity.

Furthermore, the PCIS should not become a repository for other standards by incorporating them as part of PCIS, particularly if such standards are likely to evolve independently.

The choice of particular standards is deliberately left to the PCIS designer.

2.8C Integration Into User Organization. PCIS shall be designed in a manner that promotes profitable, low-change adoption. PCIS technology should be usable with minimal change to the methods and systems of a user organization. IPSE users should be able to realize gains with minimal adoption of PCIS technology.

PCIS must take into account the fact that adoption will take place on a variety of equipment and into a variety of business contexts. For example, PCIS should be profitably usable with little change by an organization in which there is already a significant investment in existing IPSE technology (that is unlikely to undergo short term significant change) and associated software engineering methods. An organization should not be required to make major changes to its business practice to beneficially employ PCIS technology.

Integration will be facilitated by the ability of the user to customize the environment. This would normally be expected to be accomplished through the use of tools, implying that the necessary facilities should be available through the PCIS tools interface. There may also be a need to customize an installation from below the interface, for example, at installation time, to set limits, performance tuning, etc.

2.9 Distribution of Resources

A PCIS "instance" is a logical machine which is self-contained and where all the logical resources are under the control of a single system. The PCIS instance, with tools, makes up a single environment, into which a user can log and in which the user can then work. A user can treat the contents of the OMS as a single coherent database.

This logical machine may map onto a single physical machine (workstation or PC), or onto a number of physical machines connected by a Local Area Network (LAN) or even a Wide Area Network (WAN). In the latter cases, the implementation is said to be "distributed". The PCIS should allow implementations where a number of such logical machines share a network and/or single physical machines. Note that during the development of a PCIS implementation one might want to have several prototypes running on the same physical machine, each as a separate PCIS instance.

2.9A Resource Connectivity. PCIS shall include facilities for connecting and disconnecting, or mounting and dismounting, workstations and other information carrying devices.

These facilities are essential for the dynamic reconfiguration of a PCIS network. Reconfiguration requirements arise for many reasons, including failures and maintenance, testing, security, and evolution.

2.9B Implementation Sharing. PCIS shall allow implementations to share PCIS instances between physical workstations and networks.

The PCIS facilities should allow the physical configuration to be varied without restricting the logical machine unnecessarily, and vice versa. It may be, for instance, that a logical machine occasionally requires the special facilities of a particular physical machine type (for example, to run a particular executable).

2.9C Transparency. The PCIS shall provide for the identification of and access to processes and data, irrespective of their physical location.

With the move to a framework based on a database it was fundamental that the database concepts for access to processes and data be adopted. Within a database objects are addressed according to logical relationships with other objects and not via a physical mechanism. (Note that this does not preclude other access methods which do relate to physical location).

This requirement is also needed for process management and for control integration.

2.9D Resilience. The PCIS shall be implementable so that, when physical resources are lost, PCIS facilities which do not depend on these resources may continue to be used.

This requirement is intended to preclude the design of a PCIS such that the operation of an implementation is dependent on availability of the complete set of resources.

2.9E Network Partitions. The PCIS shall be implementable so that partitions of the network of physical resources can usefully work in isolation.

This requirement is primarily concerned with the support for a PCIS which is based on a distributed architecture. A PCIS, based on a distributed network of processors, which could only operate when all processors and interconnections were available, would, in a real production environment, be a severe disadvantage. Indeed, this requirement should be read to demand that if a network fragments, then each segment which has sufficient resources to continue operation should do so. The PCIS must also facilitate subsequent reintegration of the network allowing the partial OMS fragments to be recombined. The PCIS shall not be defined such that the only possible distributed implementation would be one that depended upon a single system-wide resource for its operation.

2.9F Time Management. The PCIS shall provide an interface to a time management system which ensures that the consistence of system-provided time is maintained over a LAN or WAN.

This is necessary for the consistency of distributed time-based tools (for example, a build tool perhaps) and for security (for example, the time recorded in an audit trail).

PCIS shall include a facility for reading time. Time shall be expressed in a manner that avoids ambiguity over time zones. Time accuracy shall be sufficient to distinguish the time of events which need to be thus distinguished. PCIS shall include facilities for adjusting clocks on different machines to maintain synchronicity with one another and with standard time (such as the Greenwich time signal). The provision of the actual time management mechanisms, including any synchronization protocols over networks, is left to PCIS implementors. PCIS merely provides the interface to these mechanisms.

Note that, as processors and networks become ever faster, the required timing accuracy and synchronicity increases. Values of time read from a clock should be expressed with an accuracy of one microsecond or less; though it is difficult to synchronize clocks either over a network or with standard time to this accuracy.

2.10 Logical Resources

Logical resources are computational resources, storage resources and logical devices.

This defines LOGICAL RESOURCES.

2.10A Administration. The PCIS shall provide facilities for resource administration, including the administration of the mapping of logical resources onto physical resources, defining new logical resources, bringing logical resources on-line and taking logical resources off-line. PCIS shall allow the non-use of such facilities for simple systems which cannot justify their overhead.

This requirement was included to mandate support for on-line modification of the hardware supporting the PCIS implementation. This is particularly appropriate in a distributed system where it is envisaged that a single system administrator may be responsible for configuring a variety of devices on a heterogeneous system. In order to facilitate this it is essential that the System Administrator have a single interface to the appropriate facilities; otherwise, the operation becomes too difficult on a large mixed system. It is anticipated that the use of these facilities would be restricted to the system administrator rather than being generally available, although simpler operations such as backup may be carried out by the user. Since a workstation with its peripheral devices is a logical resource, this requirement also addresses the administrative actions necessary to bring a workstation, which contains a fragment of the OMS, on line.

2.10B Identification and Control. The PCIS shall provide a means to identify distinct logical resources and to control (or influence) which logical resources are associated with which processes and data.

In a distributed network, particularly where that network may be non-homogeneous, it is essential to be able to identify and refer to particular processors, discs and other devices. It must be possible to identify which processors can support execution of a particular tool, either because of exploitation of particular characteristics of the processor (the instruction set) or because of licensing restrictions.

The requirement to be able to associate particular resources with data are necessary where the different resources have different characteristics. Examples are access speed (of bulk storage), or proximity (and hence access latency) or even physical location and connectivity to allow for degraded modes of working where some parts of a network are to be able to operate in isolation.

Similarly, the ability to influence the selection of peripheral devices is essential in any distributed system. (It is not much use printing a listing only to find that the system has chosen a geographically remote printer!).

This requirement, in conjunction with the previous requirement, provides appropriate facilities to meet the above. The use of a level of indirection, via logical resources, provides a degree of flexibility that would not be present if this requirement referred directly to physical resources.

This requirement is general and does not distinguish between the resources associated with the requesting process or its children and resources associated with other unrelated processes. It is anticipated that the access control features will limit the latter.

2.10C Queries. The PCIS shall provide facilities to query the existence and availability of logical resources.

To some extent this is a corollary of the previous requirement. This facility is intended to allow a tool to perform some automatic reconfiguration in the event of non-availability of a resource. The response to this request will, of course, be consistent with the access control restrictions. In particular the response must not permit any deductions about the existence of a resource which cannot be accessed because of the access control restrictions.

2.11 Bindings and Binding Language Considerations

2.11A Language Bindings. PCIS shall provide appropriate language bindings, and at least ANSI Standard C and Ada. Other appropriate candidate languages shall be considered when suitable standards are available.

Bindings to C and Ada are required by the SWG on APSE. Other bindings may be required in time and should not be precluded, but there are no clearly appropriate candidates identifiable at the time of writing.

2.11B Bindings Conformance to Language. PCIS bindings shall conform to the current standards for the binding languages, and should be defined according to the best recommended practice of the language.

Conformance to the current language standard is an automatic corollary of using the language. However, standards cannot enforce good practice, although guidelines on "good style", such as in [Nissen84] for Ada, can help to do so. An alternative to using the best recommended practice for each binding language is to use a common strategy for all bindings; this makes production of a new binding simpler, but fails to take advantage of improvements in language design. For example, error reporting in the Ada Binding should use the Ada exception mechanism, even though that mechanism is not available in C, for the following reasons:

The mechanism is efficient. The alternative mechanism, testing some return value for an error status, has an execution overhead even when there is no error.
The inadvertent omission of a test for an error status could result in erroneous operation of a tool. The omission of an exception handler would cause tool failure in the event of an exception.

It is worth noting that use of the exception mechanism does not preclude the utilization of status return values to provide supporting diagnostic information. Thus it would be possible to have a single exception representing a number of different, but related, error conditions, with the identification of the specific error condition via some status parameter.

Similarly, if the alternative strategy were used, a C++ Binding would be identical to a C Binding. Good practice is not necessarily common practice, particularly in a language that has been in use before being standardized.

2.11C Mapping to Language Binding. For each binding there shall be a description of the mapping of the abstract specification to the binding language.

This requirement makes explicit (and hence reviewable) the interpretation of the "good practice" referred to in Requirement 2.11B. This also serves as a primitive PCIS toolwriter's style guide (at little cost, since there must be a binding strategy).

2.11D Conformant Binding. For a PCIS binding to be conformant, it shall provide an interface to all formal operations and shall not add operations affecting the state of the system.

A language binding should neither provide supersets nor subsets of the formal operations that define PCIS; however, it should be possible to add operations which do not affect the state, such as operations to manipulate sets.

2.11E Execution Thread Waiting. For a binding language which provides parallel execution threads (for example, Ada tasks) the PCIS Binding shall specify that, if a PCIS facility is invoked by one execution thread and is defined to result in a delay, the delay is limited to the thread making the call.

This demands that when a PCIS operation cannot be completed directly (that is, completion requires access to some resource that is not immediately available), then the resulting delay shall only extend to the thread enclosing the call and not to the process enclosing that thread.

This requirement is intended to ensure that the PCIS will allow and specify that implementations achieve reasonable concurrency of execution threads in the performance of PCIS services. It would not be in the spirit of this requirement if the PCIS specified that other execution threads could not invoke a PCIS facility during the delay. Nor would it be in the spirit of this requirement if the PCIS implementation could cause execution threads to suspend immediately on calling a PCIS facility while another execution thread is delayed during a PCIS call.

On the other hand there may be no objection for a PCIS implementation to cause other execution threads to wait while the PCIS implementation completes a short service (for example, one unlikely to involve the scheduler) for an execution thread.

2.11F Run-Time System Independence. Any additions to or extensions of the binding language run-time system, required by a PCIS binding, should be minimal.

This requirement constrains the design of the PCIS to be implementable with minimal support from a run-time system. A requirement for complete run-time system independence was felt to be unduly optimistic since some PCIS functionality cannot, in all probability, be implemented efficiently without support from the run-time system.

It is recognized that there is an apparent conflict in the requirements when considering other PCIS requirements that seem to rely on additional run-time system functionality. This conflict can be expected to grow if a single program's execution is distributed on separate computers and the distribution is to remain transparent to the PCIS implementation.

Requirements for support of run-time packages such as the run-time system are discussed in 1.1(c), where these are considered to be important interfaces for standardization, but not part of the toolwriter's interface.

Go forward to Section 3. General Syntax and Semantics of the Abstract Specification.