Nyberg@ADA20.ISI.EDU.UUCP (03/31/87)
[Ed - forwarded mail - the copy I received was slightly truncated.
This is followup to the message posted to INFO-ADA on 25 March.]
Date: 30 Mar 1987 15:43-PST
Subject: IEEE Ada PDL Standards...
From: ADA20.ISI.EDU!CDONALDSON
The IEEE Recommended Practice on Ada as a Program Design
Language will become an ANSI standard if no negative comments
are received by April 14. Like many of us in the Ada community
you were probably unaware of the call for comments. I have
gotten the document (approx. 3 1/2 pages) typed in and am
distributing for widest possible review. Please take the time
to review it or have someone in your organization review
it and submit your comments to:
Louise Germani
IEEE
345 E. 47th St.
New York, NY 10017
and
ATTN: Board of STDS Review
BSR Dept.
ANSI
1430 Broadway
New York, NY 10018
NO LATER THAN APRIL 14.
Thank you for your time.
Cammie Donaldson
(305) 773-6510
IEEE Recommended Practice for
Ada as a Program Design Language
IEEE Std 990-1987
1. Introduction.
1.1 Scope. This document provides recommendations reflecting
the state of the art and alternate approaches to good practice
for characteristics of Program Design Languages (PDLs) based on
the syntax and semantics of the Ada Programming Language. In
this recommended practice, these are referred to as Ada PDLs.
1.2 Scope Restrictions. This recommended practice addresses the
characteristics of an Ada PDL and not the use of an Ada PDL.
Although certain capabilities are recommended to be provided by
an Ada PDL, this document does not state how a designer will
design, nor how the design is to be documented, using an Ada PDL.
While certain capabilities are recommended for an Ada PDL,
specification of the ways to use those capabilities is beyond the
scope of this document.
While it is widely recognized that graphic representations
may enhance the design activity, there is no clear consensus
concerning graphic representations at this time. As such, this
document is principally concerned with the aspects of textual
representations.
This recommended practice does not specify:
(1) A single PDL syntax
(2) The programming languages in which a design may be
implemented
(3) A specific methodology to be used in conjunctions
with an Ada PDL
(4) The method by which a PDL text is represented,
stored or processed
This recommended practice does not provide:
(1) A tutorial on the use of:
(a) The Ada Programming Language, to include an
exhaustive list of Ada constructs
(b) An ADL PDL
(2) A survey of PDLs or a history of their use
(3) A means for quantitatively determining the cost
effectiveness of using an Ada PDL
1.3 Terminology. Where recommendations are made that represent
the position of the IEEE, the verb "should" is used. Where
alternate approaches are provided and no firm recommendations are
made, the verb "may" is used.
1.4 Cautions. These are as follows:
(1) This document focuses on Ada PDLs. The use of a design
language that is consistent with this recommended practice for
other areas--for example, system requirements or hardware
requirements--is not prohibited by this document. However, the
reader is warned that there may very well be other substantial
considerations in these uses, and that these considerations are
beyond the scope of this recommended practice.
(2) An Ada PDL may be used to document a design when the
implementation is projected to be in a Programming Language other
than Ada. Users should be aware that an Ada PDL may not have the
ability to represent such a design.
(3) Personnel associated with the use of a PDL should take
special care to ensure that the designers do not become
preoccupied with the details of the implementation when they
should be designing. This may require special training,
additional informal reviews, etc.
1.5 Examples. Examples are incorporated into the text of this
recommended practice to enhance clarity and to promote
understanding. All examples are explicitly identified. Examples
should not be construed as recommended implementations.
2. Definitions and References.
2.1 Definitions. The definitions listed in this section
establish meaning in the context of this recommended practice.
Other definitions can be found in: ANSI/IEEE Std. 729-1983
[1](1) and ANSI/MIL-STD-1815A-1983 [2].
design element - a basic component or building block in a design
design unit - a logically related collection of design elements.
In an Ada PDL, a design unit is represented by an Ada compilation
unit.
2.2 References. This standard shall be used in conjunction with
the following publications:
[1] ANSI/IEEE Std 729-1983, IEEE Standard Glossary of Software
Engineering Terminology (2,3).
[2] ANSI/MIL-STD-1815A-1983 Reference Manual for the Ada
Programming Language (4).
3. Characteristics.
3.1 General Methodology Support. A specific Ada PDL may support
more than one design methodology. For example, both rapid
prototyping and object-oriented design may be supported by the
same Ada PDL. This is because no single development methodology
is known to be superior for all applications and for all
development organizations.
3.1.1 Abstraction. An Ada PDL should support the extraction of
essential concepts while supporting the suppression of
nonessential details.
3.1.2 Decomposition. An Ada PDL should support the division of
a large software system into smaller, more manageable pieces
while maintaining a fixed level of detail.
3.1.3 Information Hiding. An Ada PDL should support isolating
and making inaccessible certain details that ought not to affect
other parts of the software system.
3.1.4 Stepwise Refinement. An Ada PDL should support the
progressive addition of detail to a software design.
3.1.5 Modularity. An Ada PDL should support the development of
a design from standardized units.
3.2 Specific Design Support.
3.2.1 Algorithm Design. An Ada PDL should support algorithm
design. For example, depending on the intended usage, the PDL
may support the use of structured control flow, computations,
finite state machines, and Petri nets.
3.2.2 Data Structure Design. An Ada PDL should support data
structure design. Specifically, an Ada PDL should support:
(1) Data structure definition
(2) Formalization of data structures
(3) Identification of constraints on acceptable values
(4) Identification of allowable operations on objects
(5) Location of points of access to data objects
(6) Modification of data objects
(7) Specification of data structure scope, duration, and
storage methodology (for example, stored in shared
memory, files, stack, etc.) and constraints (for
example, size limitations).
3.2.3 Connectivity. An Ada PDL should support the
identification of explicit connections, including dependencies.
(1) The following should be formally described by the PDL:
(a) Ordering of component execution. As a part of this,
the PDL should support the expression of:
(i) Sequential invocation of computational processes
(ii) Initiation and termination of parallel processes
(iii) Synchronization of parallel processes
(b) Data definition dependencies
(c) Data flow
(d) Possible error conditions and their associated
consequences
(e) Interfaces between design units and between design
elements
(f) Asynchronous interrupts
(2) The following may be formally describable by the Ada
PDL:
(a) How the hardware works
(b) How interacting systems are expecting to behave.
3.2.4 Adaptability. The Ada PDL may have the capability to:
(1) Be adjusted under controlled forms to allow for
national characters in a language other than English
(2) Implement restriction of certain syntax and semantics
for particular applications (see 3.4.1)
(3) Support graphic representations of the design being
described.
3.3 Other Support. The PDL may support the expression of
Product and Management Information.
3.3.1 Product Information. Examples include:
(1) Performance. This may include critical timing,
frequency, capacity, and other constraints.
(2) Fault Tolerance. This may include error detection/
diagnosis and error handling, backup and recovery,
reliability, and redundancy.
(3) Security. This may include multilevel security
constraints, set/use access restrictions, breach
detection and handling, and the identification of the
security classification(s) of the material itself.
(4) Distribution. This may include geographic distribution
of processing, data storage, and access.
(5) Adaptation. This may include accommodations to be made
to support differing levels of user expertise.
(6) Assumptions. Description of a context within which an
algorithm exists. For example, a function that does
division may be built on the assumption that the
denominator is not zero.
(7) History. This may include design decisions and
alternate, rejected solutions to the chosen design,
together with a rationale for the choice.
(8) Traceability. This may include traceability of:
(a) Detailed Design to Preliminary or Top-Level Design,
and further to the Software Requirements
specifications
(b) Preliminary, or Top-Level Design to Detailed Design
(c) Applicable standards.
3.3.2 Management Information. Examples include:
(1) Organizational information, such as division of work and
assignment of tasks to team members
(2) Planning information, such as milestone definitions,
resource estimation, dependencies that affect the
development process itself, and scheduling
(3) Status information, such as milestone completion
(4) Configuration Management information, to include
Configuration Identification and Change Control
restrictions
3.4 Ada Relationships. The PDL should be related to the Ada
Programming Language in the following respects:
3.4.1 Conformance. An Ada PDL should conform syntactically and
semantically to ANSI/MIL-STD-1815A-1983 [2]. Specifically, an
Ada PDL should be processible by a validate Ada compiler without
error.
(1) An Ada PDL may be processible by other tools: for
example, a PDL Preprocessor. Preprocessing should not
be required prior to error-free processing by a
validated Ada compiler.
(2) There is no requirement that an Ada PDL provide the full
capabilities of the Ada Programming Language. A
conforming subset should be adequate for the application
and is allowable, for example, to prevent the use of:
(a) Untranslatable Ada constructs when designing for a
target language other than Ada
(b) Inefficient control structures when developing
embedded computer systems software
(c) Excessively detailed design constructs during high-
level design, for example, use of representation
specifications.
3.4.2 Extensions. Commentary text may be used to extend the
expressive capability of an Ada PDL beyond the semantics of Ada.
Two forms of comments are available:
(1) Unstructured comments
(2) Structured comments
3.4.2.1 Unstructured Comments. Unstructured comments may be
used for:
(1) Natural language explanation of statements made in Ada
(2) Any information required in the design process where
formal structures are not required: for example, for
humanto-human communication
The user of unstructured comments should be aware that tools
can process unstructured comments only in very primitive ways
(for example, storage, retrieval and crossreferencing).
3.4.2.2 Structured Comments. Structured comments (also known as
annotations):
(1) May be used to provide design information in additional
design-oriented semantics
(2) Should be consistent with the Ada language. For
example, in compound constructs, the end of the construct
should mirror the beginning:
--*High Level Design
--*
--*
--*End High Level Design
(3) Are identified by a sentinel character, word, or phrase
immediately following the double dash that indicates a
comment to an Ada compiler, for example, "--keyword" or
"--*".
(a) The sentinel has two functions:
(i) To highlight the comment as belonging to the
formal structure of the PDL, alerting any reader
that the information is of special significance
(ii) To direct PDL processing tools toward
information upon which the tools may be required to
act
(b) Associated with the sentinel are semantic rules that
indicate:
(i) Whether the comment applies to the preceding or
the following Ada construct
(ii) What constructs are allowed after the sentinel,
based on the context in which the sentinel appears
3.4.2.3 Replication Constraints. All concepts that can be
reasonably expressed in non-commentary Ada should be so
expressed. Information that can be provided in the Ada portion
of the PDL should not be replicated within the commentary text by
Ada constructs or by any other means.
-------