home *** CD-ROM | disk | FTP | other *** search
/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / point / ieeepdl.txt < prev    next >
Encoding:
Internet Message Format  |  1988-05-03  |  14.0 KB
  1. Date: 30 Mar 1987 15:43-PST
  2. Subject: IEEE Ada PDL Standards...
  3. From: ADA20.ISI.EDU!CDONALDSON
  4.  
  5. The IEEE Recommended Practice on Ada as a Program Design
  6. Language will become an ANSI standard if no negative comments
  7. are received by April 14.  Like many of us in the Ada community
  8. you were probably unaware of the call for comments.  I have
  9. gotten the document (approx. 3 1/2 pages) typed in and am 
  10. distributing for widest possible review.  Please take the time
  11. to review it or have someone in your organization review
  12. it and submit your comments to:
  13.  
  14. Louise Germani
  15. IEEE
  16. 345 E. 47th St.
  17. New York, NY  10017
  18.  
  19. and 
  20.  
  21. ATTN: Board of STDS Review
  22. BSR Dept.
  23. ANSI
  24. 1430 Broadway
  25. New York, NY  10018
  26.  
  27. NO LATER THAN APRIL 14.
  28.  
  29. Thank you for your time.
  30.  
  31. Cammie Donaldson
  32. (305) 773-6510
  33.  
  34.                   IEEE Recommended Practice for 
  35.                 Ada as a Program Design Language
  36.  
  37.                         IEEE Std 990-1987
  38.  
  39. 1.  Introduction.
  40.  
  41. 1.1  Scope.  This document provides recommendations reflecting 
  42. the state of the art and alternate approaches to good practice 
  43. for characteristics of Program Design Languages (PDLs) based on 
  44. the syntax and semantics of the Ada Programming Language.  In 
  45. this recommended practice, these are referred to as Ada PDLs.
  46.  
  47. 1.2  Scope Restrictions.  This recommended practice addresses the 
  48. characteristics of an Ada PDL and not the use of an Ada PDL.  
  49. Although certain capabilities are recommended to be provided by 
  50. an Ada PDL, this document does not state how a designer will 
  51. design, nor how the design is to be documented, using an Ada PDL. 
  52. While certain capabilities are recommended for an Ada PDL, 
  53. specification of the ways to use those capabilities is beyond the 
  54. scope of this document.
  55.  
  56.      While it is widely recognized that graphic representations 
  57. may enhance the design activity, there is no clear consensus 
  58. concerning graphic representations at this time.  As such, this 
  59. document is principally concerned with the aspects of textual 
  60. representations.
  61.  
  62.      This recommended practice does not specify:
  63.  
  64.           (1) A single PDL syntax
  65.           (2) The programming languages in which a design may be 
  66.               implemented
  67.           (3) A specific methodology to be used in conjunctions 
  68.               with an Ada PDL
  69.           (4) The method by which a PDL text is represented, 
  70.               stored or processed
  71.  
  72.      This recommended practice does not provide:
  73.           
  74.           (1) A tutorial on the use of:
  75.               (a) The Ada Programming Language, to include an 
  76.                   exhaustive list of Ada constructs
  77.               (b) An ADL PDL
  78.           (2) A survey of PDLs or a history of their use
  79.           (3) A means for quantitatively determining the cost 
  80.               effectiveness of using an Ada PDL
  81.  
  82. 1.3  Terminology.  Where recommendations are made that represent 
  83. the position of the IEEE, the verb "should" is used.  Where 
  84. alternate approaches are provided and no firm recommendations are 
  85. made, the verb "may" is used.
  86.  
  87. 1.4  Cautions.  These are as follows:
  88.  
  89.      (1) This document focuses on Ada PDLs.  The use of a design 
  90. language that is consistent with this recommended practice for 
  91. other areas--for example, system requirements or hardware 
  92. requirements--is not prohibited by this document.  However, the 
  93. reader is warned that there may very well be other substantial 
  94. considerations in these uses, and that these considerations are 
  95. beyond the scope of this recommended practice.
  96.  
  97.      (2) An Ada PDL may be used to document a design when the 
  98. implementation is projected to be in a Programming Language other 
  99. than Ada.  Users should be aware that an Ada PDL may not have the 
  100. ability to represent such a design.
  101.  
  102.      (3) Personnel associated with the use of a PDL should take 
  103. special care to ensure that the designers do not become 
  104. preoccupied with the details of the implementation when they 
  105. should be designing.  This may require special training, 
  106. additional informal reviews, etc.
  107.  
  108. 1.5  Examples.  Examples are incorporated into the text of this 
  109. recommended practice to enhance clarity and to promote 
  110. understanding.  All examples are explicitly identified.  Examples 
  111. should not be construed as recommended implementations.
  112.  
  113. 2.  Definitions and References.
  114.  
  115. 2.1  Definitions.  The definitions listed in this section 
  116. establish meaning in the context of this recommended practice.  
  117. Other definitions can be found in:  ANSI/IEEE Std. 729-1983 
  118. [1](1) and ANSI/MIL-STD-1815A-1983 [2].
  119.  
  120. design element - a basic component or building block in a design
  121.  
  122. design unit - a logically related collection of design elements.  
  123. In an Ada PDL, a design unit is represented by an Ada compilation 
  124. unit.
  125.  
  126. 2.2  References.  This standard shall be used in conjunction with 
  127. the following publications:
  128.  
  129. [1]  ANSI/IEEE Std 729-1983, IEEE Standard Glossary of Software 
  130. Engineering Terminology (2,3).
  131.  
  132. [2]  ANSI/MIL-STD-1815A-1983 Reference Manual for the Ada 
  133. Programming Language (4).
  134.  
  135. 3.  Characteristics.
  136.  
  137. 3.1  General Methodology Support.  A specific Ada PDL may support 
  138. more than one design methodology.  For example, both rapid 
  139. prototyping and object-oriented design may be supported by the 
  140. same Ada PDL.  This is because no single development methodology 
  141. is known to be superior for all applications and for all 
  142. development organizations.
  143.  
  144. 3.1.1  Abstraction.  An Ada PDL should support the extraction of 
  145. essential concepts while supporting the suppression of 
  146. nonessential details.
  147.  
  148. 3.1.2  Decomposition.  An Ada PDL should support the division of 
  149. a large software system into smaller, more manageable pieces 
  150. while maintaining a fixed level of detail.
  151.  
  152. 3.1.3  Information Hiding.  An Ada PDL should support isolating 
  153. and making inaccessible certain details that ought not to affect 
  154. other parts of the software system.
  155.  
  156. 3.1.4  Stepwise Refinement.  An Ada PDL should support the 
  157. progressive addition of detail to a software design.
  158.  
  159. 3.1.5  Modularity.  An Ada PDL should support the development of 
  160. a design from standardized units.
  161.  
  162. 3.2  Specific Design Support.
  163.  
  164. 3.2.1  Algorithm Design.  An Ada PDL should support algorithm 
  165. design.  For example, depending on the intended usage, the PDL 
  166. may support the use of structured control flow, computations, 
  167. finite state machines, and Petri nets.
  168.  
  169. 3.2.2  Data Structure Design.  An Ada PDL should support data 
  170. structure design.  Specifically, an Ada PDL should support:
  171.  
  172.      (1) Data structure definition
  173.      (2) Formalization of data structures
  174.      (3) Identification of constraints on acceptable values
  175.      (4) Identification of allowable operations on objects
  176.      (5) Location of points of access to data objects
  177.      (6) Modification of data objects
  178.      (7) Specification of data structure scope, duration, and 
  179.          storage methodology (for example, stored in shared 
  180.          memory, files, stack, etc.) and constraints (for 
  181.          example, size limitations).
  182.  
  183. 3.2.3  Connectivity.  An Ada PDL should support the 
  184. identification of explicit connections, including dependencies.
  185.  
  186.      (1) The following should be formally described by the PDL:
  187.  
  188.          (a) Ordering of component execution.  As a part of this, 
  189.              the PDL should support the expression of:
  190.            (i) Sequential invocation of computational processes
  191.            (ii) Initiation and termination of parallel processes 
  192.            (iii) Synchronization of parallel processes
  193.  
  194.          (b) Data definition dependencies
  195.          (c) Data flow
  196.          (d) Possible error conditions and their associated 
  197.              consequences
  198.          (e) Interfaces between design units and between design 
  199.              elements
  200.          (f) Asynchronous interrupts
  201.  
  202.      (2) The following may be formally describable by the Ada 
  203.          PDL:
  204.  
  205.          (a) How the hardware works
  206.          (b) How interacting systems are expecting to behave.
  207.  
  208. 3.2.4  Adaptability.  The Ada PDL may have the capability to:
  209.  
  210.      (1) Be adjusted under controlled forms to allow for 
  211.          national characters in a language other than English
  212.      (2) Implement restriction of certain syntax and semantics 
  213.          for particular applications (see 3.4.1)
  214.      (3) Support graphic representations of the design being 
  215.          described.
  216.  
  217. 3.3  Other Support.  The PDL may support the expression of 
  218. Product and Management Information.
  219.  
  220. 3.3.1  Product Information.  Examples include:
  221.  
  222.      (1) Performance.  This may include critical timing, 
  223.          frequency, capacity, and other constraints.
  224.      (2) Fault Tolerance.  This may include error detection/
  225.          diagnosis and error handling, backup and recovery, 
  226.          reliability, and redundancy.
  227.      (3) Security.  This may include multilevel security 
  228.          constraints, set/use access restrictions, breach 
  229.          detection and handling, and the identification of the 
  230.          security classification(s) of the material itself.
  231.      (4) Distribution.  This may include geographic distribution 
  232.          of processing, data storage, and access.
  233.      (5) Adaptation.  This may include accommodations to be made 
  234.          to support differing levels of user expertise.
  235.      (6) Assumptions.  Description of a context within which an 
  236.          algorithm exists.  For example, a function that does 
  237.          division may be built on the assumption that the 
  238.          denominator is not zero.
  239.      (7) History.  This may include design decisions and 
  240.          alternate, rejected solutions to the chosen design, 
  241.          together with a rationale for the choice.
  242.      (8) Traceability.  This may include traceability of:
  243.          (a) Detailed Design to Preliminary or Top-Level Design, 
  244.              and further to the Software Requirements 
  245.              specifications
  246.          (b) Preliminary, or Top-Level Design to Detailed Design
  247.          (c) Applicable standards.
  248.  
  249. 3.3.2   Management Information.  Examples include:
  250.  
  251.      (1) Organizational information, such as division of work and 
  252.          assignment of tasks to team members
  253.      (2) Planning information, such as milestone definitions, 
  254.          resource estimation, dependencies that affect the 
  255.          development process itself, and scheduling
  256.      (3) Status information, such as milestone completion
  257.      (4) Configuration Management information, to include 
  258.          Configuration Identification and Change Control 
  259.          restrictions
  260.  
  261. 3.4  Ada Relationships.  The PDL should be related to the Ada 
  262. Programming Language in the following respects:
  263.  
  264. 3.4.1  Conformance.  An Ada PDL should conform syntactically and 
  265. semantically to ANSI/MIL-STD-1815A-1983 [2].  Specifically, an 
  266. Ada PDL should be processible by a validate Ada compiler without 
  267. error.
  268.  
  269.      (1) An Ada PDL may be processible by other tools: for 
  270.          example, a PDL Preprocessor.  Preprocessing should not 
  271.          be required prior to error-free processing by a 
  272.          validated Ada compiler.
  273.      (2) There is no requirement that an Ada PDL provide the full 
  274.          capabilities of the Ada Programming Language.  A 
  275.          conforming subset should be adequate for the application 
  276.          and is allowable, for example, to prevent the use of:
  277.          (a) Untranslatable Ada constructs when designing for a 
  278.              target language other than Ada
  279.          (b) Inefficient control structures when developing 
  280.              embedded computer systems software
  281.          (c) Excessively detailed design constructs during high-
  282.              level design, for example, use of representation 
  283.              specifications.
  284.  
  285. 3.4.2  Extensions.  Commentary text may be used to extend the 
  286. expressive capability of an Ada PDL beyond the semantics of Ada.
  287.      
  288.      Two forms of comments are available:
  289.  
  290.           (1) Unstructured comments
  291.           (2) Structured comments
  292.  
  293. 3.4.2.1  Unstructured Comments.  Unstructured comments may be 
  294. used for:
  295.      
  296.      (1) Natural language explanation of statements made in Ada
  297.      (2) Any information required in the design process where 
  298.          formal structures are not required:  for example, for 
  299.          humanto-human communication
  300.  
  301.      The user of unstructured comments should be aware that tools 
  302. can process unstructured comments only in very primitive ways 
  303. (for example, storage, retrieval and crossreferencing).
  304.  
  305. 3.4.2.2  Structured Comments.  Structured comments (also known as 
  306. annotations):
  307.  
  308.      (1) May be used to provide design information in additional 
  309.          design-oriented semantics
  310.      (2) Should be consistent with the Ada language.  For 
  311.          example, in compound constructs, the end of the construct 
  312.          should mirror the beginning:
  313.  
  314.           --*High Level Design
  315.           --*
  316.           --*
  317.           --*End High Level Design
  318.  
  319.      (3) Are identified by a sentinel character, word, or phrase 
  320.          immediately following the double dash that indicates a 
  321.          comment to an Ada compiler, for example, "--keyword" or 
  322.          "--*".
  323.          (a) The sentinel has two functions:
  324.              (i)  To highlight the comment as belonging to the 
  325.                   formal structure of the PDL, alerting any reader 
  326.                   that the information is of special significance
  327.              (ii) To direct PDL processing tools toward 
  328.                   information upon which the tools may be required to 
  329.                   act
  330.          (b) Associated with the sentinel are semantic rules that 
  331.              indicate: 
  332.              (i)  Whether the comment applies to the preceding or 
  333.                   the following Ada construct
  334.              (ii) What constructs are allowed after the sentinel, 
  335.                   based on the context in which the sentinel appears
  336.       
  337. 3.4.2.3  Replication Constraints.  All concepts that can be 
  338. reasonably expressed in non-commentary Ada should be so 
  339. expressed.  Information that can be provided in the Ada portion 
  340. of the PDL should not be replicated within the commentary text by 
  341. Ada constructs or by any other means.
  342.  
  343.  
  344.