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.