IRAC Preface |
1 Introduction |
2 General Design Objectives |
3 General Syntax and Semantics of the Abstract Specification |
4 Object Management System |
5 Program Execution Facilities |
6 Input and Output |
7 Protection and Security |
8 Requirements for Tool Management and Services for Tools |
9 Ancillary Requirements |
10 Definitions |
Submission of Comments
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:
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.
- 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.
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
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
2.1D Transportability. The PCIS shall support transportability of
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
There are several kinds of integration to be considered:
- To provide the mechanisms for agreements and conventions
- To minimize the effects of disagreement and difference in
the observance of conventions.
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
- 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.
Support for Reuse. PCIS shall support facilities for software
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.
The PCIS should provide simple-to-use facilities for achieving common,
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.
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
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
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
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
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.
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
Section 2.7 on Extensibility.
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.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
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
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
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
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
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.
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
There are three aspects to this:
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
- 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
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
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
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
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.
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
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
Subsetting of functionality is necessary as well as subsetting of
interfaces. This is exemplified by the following:
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
- Security. Some implementations may not provide the security
functionality which secure implementations will provide for all
- 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.
Levels of conformance apply to the subsets.
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
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.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
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.
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
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
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
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
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.
Logical resources are computational resources, storage resources and
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.
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
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
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
Other appropriate candidate languages shall be considered when suitable
standards are available.
Bindings to C and
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.
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
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
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.
- 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
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
2.11C Mapping to Language Binding. For each binding there shall be a
description of the mapping of the abstract specification to the binding
This requirement makes explicit (and hence reviewable) the
interpretation of the "good practice" referred to in
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
2.11E Execution Thread Waiting. For a binding language which provides
parallel execution threads (for example,
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
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
Requirements for support of run-time packages such as the run-time
system are discussed in
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.