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:

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:

The disadvantages are:

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: 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:

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:
  1. Names used in identification may be up to n1 characters long.
  2. There may be at most n2 users known to the system and at most n3 may be logged on simultaneously.
  3. There may be a maximum of n4 devices known to the system.
  4. There may be at most n5 objects known to the system.
Go forward to Section 4. Object Management Support.