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
SECTION 3
GENERAL SYNTAX AND SEMANTICS OF THE ABSTRACT SPECIFICATION
The requirements in this section reflect the nature of the PCIS as an
abstract (language-independent) specification and dependent language
bindings. The PCIS definers should take into consideration "The General
Guidelines for Language Bindings" ISO/IEC DTR10182.
3.1 Syntax
3.1A General Syntax. The Syntax of the PCIS shall be expressed using
a well-defined syntactic notation, in both the formal and the informal
abstract specifications. The PCIS shall define the syntax of strings
whenever that structure has associated semantics.
3.1B Uniformity. The PCIS should employ uniform syntactic
conventions and should not provide several notations for the same
concept. PCIS syntax issues (including at least limits on name lengths,
abbreviation styles, other naming conventions, and relative ordering of
input and output parameters) should be resolved in a uniform and
integrated manner for the whole PCIS.
This is good engineering practice. The use of several notations for the
same concept leads to confusion, especially amongst readers for whom
the document is not in their native language. The point is worth
stressing since good style frequently leads to use of synonyms and
alternatives to avoid boring the reader. The use of a uniform approach
to the PCIS syntax issues is essential if the PCIS is to be easy to
learn and use. Non-uniformity is a recipe for errors in use of the PCIS
and difficulty in production of the tools.
3.1C Name Selection. The PCIS should avoid coining new words
(literals or identifiers) and should avoid using words in an
unconventional sense. Identifiers (names) defined by the PCIS should be
composed of natural English language words or industry accepted English
terms. The PCIS should define identifiers which are visually distinct
and not easily confused. The PCIS should use the same name, and not its
possible synonyms, whenever the same meaning is intended.
This, again, is good engineering practice and reflects the
international nature of this specification.
The requirement for visually distinct identifiers covers such things as
identifiers which differ:
- By simple character transposition
- By having the uppercase letter "O" instead of the numeral "0"
- By having the lowercase letter "l" instead of the numeral "1"
- By having the lowercase letter "l" instead of the uppercase
letter "I"
- By having the uppercase letter "I" instead of the numeral "1"
3.1D
Pragmatics. The PCIS should impose only those restrictive rules
or constraints required to achieve interoperability and
transportability. The PCIS shall enumerate those syntactic restrictions
which must be defined by implementors.
This requirement demands that the PCIS specification dictate the
restrictions which affect interoperability and transportability.
Further it demands that the PCIS specification identify any other
constraints and impose a requirement on the PCIS implementor to specify
values for those constraints. Clearly any such limitations are an
impediment to interoperability and transportability, but practical
considerations dictate that some limits will exist in all
implementations. The PCIS designer should consider strategies to deal
with these limits (for example, providing facilities to interrogate the
value of the limits).
A syntactic restriction might be such as is defined in the
Ada Reference Manual,
Section 2.10, which allows, for example, an
implementation to omit the "#" character.
3.2 Semantics
3.2A General Semantics.
a) The PCIS shall be completely and unambiguously defined down to
explicitly identified implementation dependencies. The specification of
semantics should be both precise and understandable. The semantic
specification of each PCIS facility shall include a precise statement
of assumptions (including execution-time preconditions for calls),
effects on global data (including execution-time post-conditions for
calls) and interactions with other facilities.
This is a call for adequate, usable documentation. The requirement for
non-ambiguity, precision and understandability must be interpreted in
the light of the intention that the PCIS will be used by several
nations.
Implementation dependencies may be such things as limits on the sizes
of attributes and length of identifiers.
b) There shall be a formal abstract definition of the semantics of
PCIS.
By "formal" is meant using a rigorous and mathematically based
notation. Well-known examples are VDM-SL and Z; more modern examples
overcoming some of the limitations of those notations are VVSL and RSL.
The notation to be used in the formal abstract definition of PCIS is
not specified, but shall be based upon the most appropriate notation,
among those available.
It is not defined whether the formal abstract definition should be done
before, after, or in parallel with the non-formal abstract definition.
The advantages of a formal specification are:
- Improved information content: it is possible to ensure (by
machine) that there are no ambiguities or gaps in the
definition.
- Sharper criteria for conformance of implementations and
tools.
- Easier checking of the specification against requirements,
for example, by formulating and proving or disproving
conjectures.
- It provides the first stage of development using
refinement, leading to verifiable design and (perhaps)
implementation.
- Overall cost savings from the early identification of
errors and omissions.
The disadvantages are:
- The technology is fairly new and untried in situations such
as this (for example, extensions of VDM-SL were required for
the VIP project to cope with modularity and temporal aspects).
- Production of a formal specification requires special
skills and might be too time-consuming.
- Reading a formal specification needs special knowledge, not
always present in the current tool developer community.
c) There shall be a non-formal abstract definition of the
semantics of PCIS.
3.2B Repeatability. Every time a PCIS facility is invoked under the
same circumstances the outcome should be the same.
Here, circumstances include:
- Parameter values
- The access rights of the subjects and objects involved
- Values of attributes and relationships of all objects involved
Time is not included in the above list since time can never be repeated
and hence time-dependent operations cannot be invoked under the same
circumstances.
Outcome includes:
- Result returned to the subject
- Effects on any objects involved
- Any physical output from the system
Obviously, in the extreme, any hard copy output is non-repeatable since
the output medium is consumed and the system cannot influence the
selection of the replacement.
This is a demand that the behavior of the PCIS be deterministic.
However, it is only a design criterion, not a requirement, so
deviations are acceptable if compromise is necessary to fulfil other
requirements. Indeed, in a distributed system, where an operation
involves users operating in parallel on several processors, or where
the PCIS implementation uses multiple Ada tasks running in parallel to
provide a facility, then it may be impossible to meet this criterion.
3.2C Exceptions. The PCIS shall notify the user in the event of an
exceptional situation. The exceptional situations shall include all
violations of implementation-defined restrictions.
This requirement demands that the PCIS inform the user (a tool)
whenever an operation does not complete normally, hence allowing the
tool to take appropriate action. The interface cannot force the tool to
react to the exception; however, by use of a mechanism such as the use
of the Ada exception, the tool writer can be obliged to specifically
discard the exception notification (if that is the tool writer's
intention).
3.2D Consistency. The description of PCIS semantics should use the
same word or phrase, and not its possible synonyms, whenever the same
meaning is intended.
This, again, is good engineering practice. The use of synonyms can lead
to confusion.
3.2E Cohesiveness. Each PCIS facility should provide singularity of
service.
The requirement should be interpreted as prohibiting design of an
interface with a small number of entry points, each entry point
delivering a range of dissimilar services, with the particular service
being selected dynamically by the value of one or more of the
parameters. Such a design would almost certainly not provide
simple-to-use facilities for performing simple common actions.
The overloading of operation names allowing the selection of different
operations depending on the types of the parameters is acceptable. Such
an approach has the advantage of reducing the number of unique
operation names within the PCIS. When used to extreme, overloading can
lead to a reduction in the clarity of the PCIS and it should be used
with care.
This is a criterion, and it is recognized that there may be some
exceptions. However, the basic principle of one facility providing one
service should guide the designers of the PCIS.
3.2F Pragmatics. The PCIS shall enumerate all aspects of the
meanings of PCIS facilities which must be defined by PCIS implementors.
The PCIS shall require implementors to completely specify these
implementation-defined semantics.
See also
Requirement 3.1D
which has similar requirements relating to
implementation-defined syntax. This requirement relates to semantics.
For example, some of the restrictive rules might be:
- Names used in identification may be up to n1
characters long.
- There may be at most n2 users known to the system
and at most n3 may be logged on simultaneously.
- There may be a maximum of n4 devices known to the
system.
- There may be at most n5 objects known to the
system.
Go forward to
Section 4. Object Management Support.