DataMuseum.dk

Presents historical artifacts from the history of:

Rational R1000/400 Tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about Rational R1000/400 Tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download
Index: ┃ D T

⟦a8c03e99d⟧ TextFile

    Length: 198751 (0x3085f)
    Types: TextFile
    Names: »DF_2167_HELP«

Derivation

└─⟦5f3412b64⟧ Bits:30000745 8mm tape, Rational 1000, ENVIRONMENT 12_6_5 TOOLS 
    └─ ⟦91c658230⟧ »DATA« 
        └─⟦f6fec0485⟧ 
            └─⟦this⟧ 
└─⟦d10a02448⟧ Bits:30000409 8mm tape, Rational 1000, ENVIRONMENT, D_12_7_3
    └─ ⟦fc9b38f02⟧ »DATA« 
        └─⟦f95d63c89⟧ 
            └─⟦this⟧ 

TextFile

    
  @node !Tools.Design_Implementation.Complete

  procedure Complete (Include_Optional_Annotations : Boolean := False);

  Description

  Inserts annotations for the current design phase into the design component
  image on which the cursor is currently located.

  As a design component progresses forward through design phases, additional
  annotations may be required; these can be added with the Complete procedure.

  Parameters

  Include_Optional_Annotations : Boolean := False;

  Specifies, when false (the default), that only required annotations be added
  to the design component. When true, this parameter specifies that optional
  annotations also be added.

  Restrictions

  The design component must be in source state and open for editing.

  Errors

  When this command is executed in a CSCI for which no design target is
  registered, an error results and an error message is displayed in the Message
  window.

  Examples

  The following Unit has been created in a CSCI that is at the Detailed_Design
  phase:

   procedure The_Unit (Inputs : in Integer; Outputs: out Integer);

  The user then executes the Design_Implementation.Complete command, which adds
  the @COMPONENT_KIND annotation to the design component, as shown below:

   --| @COMPONENT_KIND [2167 Component]
   procedure The_Unit (Inputs : in Integer; Outputs: out Integer);

  When the @COMPONENT_KIND annotation has been completed by the user with Unit
  to specify a Unit design component, the user executes the
  Design_Implementation.Complete command a second time.  The rest of the
  annotations required in a Unit in the Detailed_Design phase are added, as
  shown below:

   --| @COMPONENT_KIND UNIT
   --| @PURPOSE [TEXT]
   --| @MEMORY [Memory Allocation]
   --| @TIME [Time Allocation]
   --| @LIMITATIONS [TEXT]
   --| @SEQUENCING [TEXT]
   --| @ALGORITHM [TEXT]
   --| @PROCESSING [TEXT]
   --| @UTILIZATION [TEXT]
   procedure The_Unit (Inputs : in Integer; Outputs: out Integer);

  References

  procedure Format

  procedure Common.Complete, EST, Rational Environment Reference Manual

  procedure Common.Format, EST, Rational Environment Reference Manual

  @node !Tools.Design_Implementation.Definition

  procedure Definition (In_Place : Boolean := False;
                        Visible  : Boolean := True);

  Description

  Displays in a window the design component, file, or document in which the
  information is defined, when executed in a document.

  Parameters

  In_Place : Boolean := False;

  Specifies whether the current frame should be used to bring up the image.
  The default, false, specifies that the least recently used frame should be
  replaced.

  Visible : Boolean := True;

  Specifies, for requirements, whether to display the specification in the PDL
  (in the @FUNCTION_DEFINED or @INTERFACES_DEFINED annotation) or in the
  defining paragraph in the SRS or IRS document. A value of true, the default,
  specifies the annotation; false specifies the document.

  Restrictions

  When this command is executed in a CSCI for which no design target is
  registered, an error results and an error message is displayed in the Message
  window.

  Errors

  When this command is entered in PDL or in a document that is not within a
  Rational System or Subsystem with the Rational Design Facility specified as
  its design target, an error results and an error message is displayed.

  References

  procedure Ada.Show_Usage, EST, Rational Environment Reference Manual

  procedure Common.Definition, EST, Rational Environment Reference Manual

  @node !Tools.Design_Implementation.Enclosing

  procedure Enclosing (In_Place : Boolean := False);

  Description

  Traverses to and displays the enclosing 2167 DF design component (note that
  this is not the enclosing library structure).

  Parameters

  In_Place : Boolean := False;

  Specifies whether the current frame should be used to bring up the image.
  The default, false, specifies that the least recently used frame should be
  used.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  The following table illustrates the relationships of the enclosing design
  component:

         ------------------------------------------------------------- 
        |                    |                                        |
        |  Cursor Location   |       Enclosing Design Component       |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |There is no enclosing design component, |
        |System design       |so the following message is displayed:  |
        |component           |This is the root of the 2167 system     |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the package specification for  |
        |Segment design      |the System design component from which  |
        |component           |it was allocated                        |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the package specification for  |
        |CSCI design         |the Segment (or System if there is no   |
        |component           |Segment) design component from which it |
        |                    |was allocated                           |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the package specification for  |
        |HWCI design         |the Segment (or System if there is no   |
        |component           |Segment) design component from which it |
        |                    |was allocated                           |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the specification for the CSCI |
        |TLCSC design        |or TLCSC design component from which it |
        |component           |was allocated                           |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the specification for the TLCSC|
        |LLCSC design        |or LLCSC design component from which it |
        |component           |was allocated                           |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the specification for the TLCSC|
        |Unit design         |or LLCSC design component from which it |
        |component           |was allocated                           |
         ------------------------------------------------------------- 

  @node !Tools.Design_Implementation.Explain

  procedure Explain;

  Description

  Displays, in a preview document, information for the document structure on
  which the cursor is located.

  In PDL, this command displays information for the annotation and its argument
  on which the cursor is currently located.

  Restrictions

  When no information is available, the message No information available is
  displayed in the Message window.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  References

  procedure Common.Explain, EST, Rational Environment Reference Manual

  @node !Tools.Design_Implementation.Format

  procedure Format;

  Description

  Performs syntactic checking of annotations in the image of a design
  component.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  References

  procedure Common.Format, EST, Rational Environment Reference Manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design

  Package Design provides the operations required by 2167 DF users and project
  administrators. More specifically, it provides commands required to:

  *  Enter PDL

  *  Generate document databases

  *  View preview documents

  *  Print documents

  *  View and change design targets

  *  View and change design phases

  *  View, create, and change the DOD-STD-2167 static hierarchy

  ERROR RESPONSE

  Some commands in this package have a Response parameter that specifies how
  the command should respond to errors, how to generate logs, and what
  activities to use. The Response profile special name "<PROFILE>", which many
  commands use by default, specifies the job response profile. If there is no
  job response profile, the session response profile "<SESSION_PROFILE>" is
  used. If there is no session response profile, the system's default profile
  "<DEFAULT>" is used. For further information on profiles, see SJM, package
  Profile, in the Rational Environment Reference Manual.

  PARAMETER PLACEHOLDERS

  Some commands in this package have a parameter placeholder as a default
  value. Parameter placeholders take the form ">>name<<", where name is the
  type of object that should replace the parameter placeholder. Executing a
  command without replacing a parameter placeholder produces an error.

  OPTIONS PARAMETER

  Like many other packages found in the Rational Environment, some of the
  procedures (specifically, Build, Generate_Markup, Preview, and Print) in
  package Design have an Options parameter. For detailed information on the
  syntax for specifying options, see the discussion of the Options parameter in
  the Key Concepts of the Library Management (LM) book in the Rational
  Environment Reference Manual.

  The following table shows the procedures that can take options and which
  options they can take. To have any effect, the asterisked options require
  that the Build_Db option also be true.

               ------------------------------------------------- 
              |                 |       |       |       |       |
              |                 |       |Generat|       |       |
              |     Option      | Build |  e-   |Preview|  Print|
              |                 |       |_Markup|       |       |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Analyze_Private_T|  #    |  #*   |  #*   |   #*  |
              |ypes             |       |       |       |       |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Build_Db         |       |  #    |  #    |   #   |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Csc_Numbering    |  #    |  #*   |  #*   |   #*  |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Data_Tables      |  #    |  #*   |  #*   |   #*  |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Device           |       |       |       |   #   |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Formatter_Options|       |       |       |   #   |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Input_Output_Tabl|  #    |  #*   |  #*   |   #*  |
              |es               |       |       |       |       |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Interpretation   |  #    |  #*   |  #*   |   #*  |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Paragraph_Header_|       |  #    |       |   #   |
              |Style            |       |       |       |       |
               ------------------------------------------------- 
              |                 |       |       |       |       |
              |Queue_Options    |       |       |       |   #   |
               ------------------------------------------------- 

  LIBRARY SWITCHES

  The Rational Environment provides a number of library switches that control
  certain functions on a library basis. These library switches and their
  associated commands are documented in the LM book of the Rational Environment
  Reference Manual.

  Worlds that have the 2167 DF registered as their design target have two
  special switches that pertain to the 2167 DF only. These two library
  switches, Design.Options and Design.Phase, are described below.

  Options Switch

  This library switch specifies nondefault options normally specified through
  the Options parameter of many procedures in package Design.  The Options
  that can be specified are documented in detail with each procedure to which
  they pertain. Available options include:

  *  Analyze_Private_Types

  *  Build_Db

  *  Csc_Numbering

  *  Data_Tables

  *  Device

  *  Formatter_Options

  *  Input_Output_Tables

  *  Interpretation

  *  Paragraph_Header_Style

  *  Queue_Options

  The precedence of option specification is shown below. The precedence is from
  highest (1) to lowest (3).

  1. An option specified in a command in a Command window overrides the library
     switch setting and package Design defaults.

  2. An option specified in a switch file overrides package Design defaults.

  3. The default value of an option, as specified in package Design, is used
     when an option has not been specified in a Command window or in the
     library switch file.

  The full switch name is Design.Options. The default is the null string (""),
  which specifies no options.

  Phase Switch

  This library switch specifies the current design phase of a development path.
  The design phase controls:

  *  Which documents are created or printed by default

  *  Which annotations are required, allowed, or prohibited in PDL

  *  Which design standards are enforced

  The legal range of values is a property of the design target. For further
  information on the design targets, see the Key Concepts book of this manual.
  When the switch is modified, the value is checked to ensure that it is legal
  for that design target. The legal design phase values for the
  RATIONAL_2167_R1000 design target and other 2167 DF-based design targets are:

  *  Requirements_Analysis

  *  Preliminary_Design

  *  Detailed_Design

  *  Coding

  *  CSC_Integration

  *  CSCI_Test

  The full switch name is Design.Phase. The default value is Nil, which
  specifies no design phase. The value of this switch must be changed with
  Design.Set_Phase rather than with the switch editor.

  NAMING RESOLUTION AND THE DESIGN FACILITY

  Many of the commands in package Design take parameter values that refer to
  CSCIs and documents. The resolution of CSCI naming expressions and document
  names in the 2167 DF follows the conventions described below.

  Naming in CSCI-Related Parameters

  Many of the commands in package Design have a CSCI-related
  parameter-specifically, the In_Csci_View parameter. The default value for
  these parameters is always the special value "<CURSOR>". This value specifies
  that the current cursor location is used as the context in which to perform
  CSCI naming resolution.

  Although you supply a single value to a CSCI-related parameter, CSCI name
  resolution for these parameters actually is performed based on two pieces of
  information: a subsystem and a view. The subsystem defines the name and kind
  of CSCI (either single subsystem or multisubsystem). The view selects the
  versions of CSCs and Units that represent the decomposition of the CSCI.

  Depending on the cursor location when the command is executed, there are
  three possible scenarios for name resolution of these CSCI-related parameter
  naming expressions, as described below:

  *  The name resolves to an object in a view: The resolved view and subsystem
     are those that enclose the object. For example, when a document is
     generated and the value of the In_Csci_View parameter resolves to a
     library package specification for a TLCSC, the document will be generated
     for the view of the subsystem in which that TLCSC is located.

  *  The name resolves to a view: The resolved view is that view and its
     enclosing subsystem. For example, when a document is generated and the
     value of the In_Csci_View parameter resolves to the view Pdr1_Working,
     the document will be generated for the Pdr1_Working view for the subsystem
     in which it is located.

  *  The name resolves to a subsystem: The resolution is that subsystem and the
     load view of that subsystem as specified by the default activity for the
     session, or by the activity as specified by the Activity.Set command for
     that job, or by the activity specified as part of the response profile for
     that command. You can specify another activity as part of the response
     profile. For example, for the activity !Users.Tom.Activity_For_Tom, you
     would specify the following argument to the Response parameter:

     "Activity=>(!Users.Tom.Activity_For_Tom), <PROFILE>"

  Document Naming in Document Parameters

  Because document names for the IRS and the IDD can be ambiguous when used as
  values in commands with the Document parameter, the following naming
  convention makes the names unambiguous.  A document name alone can be
  specified as a parameter value-for example, IDD.  However, because more than
  one IDD can be generated for a given CSCI, that name is ambiguous.  To make
  the name unambiguous, a document number, enclosed in parentheses, must follow
  the document name. For example, the unambiguous specification of an IRS docu-
  ment with the document number AD-423-997 can be specified to the
  Document_Name parameter as IRS(AD-423-997). The following rules apply when
  the 2167 DF resolves ambiguous document names:

  *  When reference is made to a document without specification of a document
     number, all documents of the given name are specified.

  *  When reference is made to a document or documents using a document name
     and document numbers, all documents matching the document name and numbers
     are specified.

  *  A document name and number specification that do not match are invalid and
     will produce a message to that effect.

  When an ambiguous document name is specified to the Build, Generate_Markup,
  and Print commands in package Design (which would be desirable in many
  instances), the ambiguous reference is resolved to the specified documents
  and then each document is processed. In the Preview command, however, the
  ambiguous reference is resolved to the appropriate list of documents, and a
  menu appears from which the user can make a single selection. To display the
  document, the user can execute the Common.Definition procedure.

  Wildcards cannot be used in Document parameters.

  CONVENTIONS OF IRS/IDD DOCUMENT FILENAMING

  When multiple IRS or IDD documents are generated, the document name is Irs_
  followed by the document number-for example, Irs_Dcr974. If the document
  number includes a character that is not legal in an Ada simple name, each is
  converted to a legal character.  Thus, the name of the IRS document whose
  number is I9-426 would be Irs_I9_426. These filenames cannot be used in the
  Document parameter as described above. Rather they are used to name files in
  the Documentation directory containing the document database for each
  document.

  COMMANDS FROM PACKAGE COMMON

  The following commands from package !Commands.Common can be used on preview
  documents. For documentation on the use of Common commands on the Ada
  constituent of PDL, see the Rational Environment Reference Manual, EST, Ada
  Images. For documentation on the use of Common commands on text files used by
  the 2167 DF, see the Rational Environment Reference Manual, EST, Text Images.

  procedure Common.Abandon

  Ends the display of the preview document. The window is removed from the
  screen and from the Window Directory. The Window parameter specifies which
  window should be removed from the screen. The default, "<IMAGE>", removes the
  current image.

  procedure Common.Create_Command

  Creates a Command window below the preview window if one does not already
  exist; otherwise, the procedure puts the cursor in the existing Command
  window below the preview document window. This Command window initially has
  a use clause:

    use Editor, Common;

  This use clause provides direct visibility to the declarations in packages
  !Commands.Editor and !Commands.Common for names resolved in the command.

  procedure Common.Definition

  Traverses, in a preview document, to the defining occurrence in PDL or
  another document. In PDL, the command traverses to the document in which the
  requirement was defined.

  procedure Common.Edit

  Displays the file and opens it for editing, when executed on a prompt for an
  included file. If other users or jobs have write locks on the file, the
  operation will fail.

  The Name parameter specifies the name of the file to be made editable.  The
  default special name, "<IMAGE>", specifies the file referred to in the
  current cursor location. The In_Place parameter specifies whether the
  current frame should be used. The default, false, specifies that the current
  frame should not be used.

  procedure Common.Enclosing

  Brings up a window that contains an image of the library containing the file
  corresponding to the preview document. The In_Place parameter specifies
  whether the current frame should be used. The default is false.

  procedure Common.Explain

  Displays information in the Message window about the structure on which the
  cursor is located.

  procedure Common.Release

  Ends the display of the preview document and removes the image from the
  Window Directory.

  The Window parameter specifies which window should be released. The default
  is the current image.

  procedure Common.Revert

  Refreshes the image in the current window with the current value of the
  underlying document database. Note that, if a job is writing to the file and
  the file is concurrently being viewed with the Rational Editor, the Revert
  command can be used to update the image to show any new output that has
  occurred since the last time Revert was executed.

  procedure Common.Object.Child

  Selects the next lower-level item in the hierarchical structure of the
  preview document. The item selected will be the one in which the cursor is
  located if such an item exists. If no items are selected, the item closest
  to the cursor is selected.

  The Repeat parameter specifies the number of levels to move down in selecting
  the image. The default, 1, specifies the next lower level.

  procedure Common.Object.First_Child

  Selects the first child of the current selection. The first child is the
  first one at the next lower level in the hierarchy of the current selection.

  The Repeat parameter specifies the number of levels to move down in selecting
  the image. The default, 1, specifies the next lower level.

  procedure Common.Object.Last_Child

  Selects the last child of the current selection. The last child is the last
  one at the next lower level in the hierarchy of the current selection.

  The Repeat parameter specifies the number of levels to move down in selecting
  the image. The default, 1, specifies the next lower level.

  procedure Common.Object.Next

  Selects the next item after the current selection at the same level in the
  preview document hierarchy. If there is no current selection, the item
  after the current cursor position is selected.

  The Repeat parameter specifies the number of the selection to be selected
  after the current cursor position. The default, 1, specifies the next
  selection.

  procedure Common.Object.Parent

  Selects the next higher-level item in the hierarchical structure of the
  preview document. The item selected will be the one in which the cursor is
  located if such an item exists. If no items are selected, the item closest to
  the cursor is selected.

  The Repeat parameter specifies the number of levels to move up in selecting
  the image. The default, 1, specifies the next higher level.

  procedure Common.Object.Previous

  Selects the item before the current selection at the same level in the
  preview document hierarchy. If there is no current selection, the item
  before the current cursor position is selected.

  The Repeat parameter specifies the number of the selection to be selected
  before the current cursor position. The default, 1, specifies the previous
  selection.

  ADA SPECIFICATION FOR PACKAGE DESIGN

  The following is the specification for package !Commands.Design. Note that
  the Ada specification is ordered logically, whereas the reference entries
  in this book are arranged alphabetically.

   package Design is

       subtype Document_Name is String;

       Srs : constant Document_Name := "SRS";
       Irs : constant Document_Name := "IRS";
       Stldd : constant Document_Name := "STLDD";
       Sddd : constant Document_Name := "SDDD";
       Idd : constant Document_Name := "IDD";

       Unknown : constant Document_Name := "<UNKNOWN>";

       Default : constant Document_Name := "<DEFAULT>";

       function Current_Document
                   (In_Csci_View : String := "<CURSOR>") return Document_Name;

       procedure Build (Document : Document_Name := "<DEFAULT>";
                        In_Csci_View : String := "<CURSOR>";
                        Options : String := "";
                        Response : String := "<PROFILE>");

       procedure Generate_Markup (Of_Document : Document_Name := "<DEFAULT>";
                                  In_Csci_View : String := "<CURSOR>";
                                  Options : String := "";
                                  Response : String := "<PROFILE>");

       procedure Preview (Document : Document_Name := "<DEFAULT>";
                          In_Csci_View : String := "<CURSOR>";
                          Options : String := "";
                          In_Place : Boolean := False;
                          Response : String := "<PROFILE>");

       procedure Print (Document : Document_Name := "<DEFAULT>";
                        In_Csci_View : String := "<CURSOR>";
                        Options : String := "";
                        Response : String := "<PROFILE>");

       procedure Complete (Include_Optional_Annotations : Boolean := False);
       procedure Definition (In_Place : Boolean := False;
                             Visible : Boolean := True);
       procedure Enclosing (In_Place : Boolean := False);
       procedure Explain;
       procedure Format;
       procedure Show_Usage (In_Csci_View : String := "<CURSOR>");

       procedure Display_All_Targets;
       procedure Display_Target (In_Csci_View : String := "<CURSOR>");
       procedure Set_Target (To_Value : String := ">>DESIGN TARGET<<";
                             In_Csci_View : String := "<CURSOR>");
       procedure Display_All_Phases (In_Csci_View : String := "<CURSOR>");
       procedure Display_Phase (In_Csci_View : String := "<CURSOR>");
       procedure Set_Phase (To_Value : String := ">>DESIGN PHASE<<";
                            In_Csci_View : String := "<CURSOR>");

       function Current_Target_Image
                   (In_Csci_View : String := "<CURSOR>") return String;
       function Current_Phase_Image
                   (In_Csci_View : String := "<CURSOR>") return String;

       procedure Create_Model (Compiler_Model : String := ">>MODEL NAME<<";
                               Design_Facility_Model : String :=
                                    ">>MODEL NAME<<";
                               New_Model_Name : String := "");

       type Component_Kinds is (System,
                                Segment,
                                Multi_Subsystem_Csci, Csci_Child_Subsystem,
                                Single_Subsystem_Csci,
                                Hwci);

       procedure Initial (Component : String := ">>COMPONENT_NAME<<";
                          Kind : Component_Kinds :=
                                Design.Single_Subsystem_Csci;
                          Parent : String := "";
                          Working_View_Base_Name : String := "Ssr1";
                          View_To_Import : String := "";
                          Create_Load_View : Boolean := True;
                          Model : String := "RATIONAL_2167_R1000";
                          Comments : String := "";
                          Work_Order : String := "<DEFAULT>";
                          Volume : Natural := 0;
                          Response : String := "<PROFILE>");

       procedure Set_Parent (Of_Component : String := "<CURSOR>";
                             To : String := "";
                             Response : String := "<PROFILE>");

       procedure Check_Consistency (Of_Component : String := "<CURSOR>";
                                    Attempt_Repair : Boolean := True;
                                    Response : String := "<PROFILE>");

       procedure Display_Hierarchy (Of_Component : String := "<CURSOR>";
                                    Decompose_Cscis : Boolean := True;
                                    Transitive : Boolean := True);

       function Children (Of_Component : String := "<CURSOR>";
                          Decompose_Cscis : Boolean := True;
                          Transitive : Boolean := True) return String;

       function Parent (Of_Component : String := "<CURSOR>";
                        Recursive : Boolean := False) return String;

   end Design;

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Build

  procedure Build (Document     : Document_Name := "<DEFAULT>";
                   In_Csci_View : String        := "<CURSOR>";
                   Options      : String        := "";
                   Response     : String        := "<PROFILE>");

  Description

  Generates a document database for a CSCI using the specified options.

  Once a document database has been generated with the Build command, various
  online and hard-copy forms of the document can be viewed or printed: the
  preview document, markup for the document, a draft hard copy of a document
  (printed on a line printer), or a camera-ready hard copy of the document
  (printed on a laser printer).

  Parameters

  Document : Document_Name := "<DEFAULT>";

  Specifies which document database to generate: IRS, SRS, STLDD, IDD or SDDD.
  The default value, "<DEFAULT>", specifies that the kind of document database
  will be determined from the current design phase for the CSCI specified in
  the In_Csci_View parameter. Thus, if the design phase is
  Requirements_Analysis, a document database for the SRS will be generated. If
  the design phase is Preliminary_Design, an STLDD document database will be
  generated. Finally, if the design phase is Detailed_Design or later, an SDDD
  document database will be generated.  For information on the resolution of
  ambiguous document names, see "Document Naming in Document Parameters," in
  the introduction to this package.

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI for which the document database is to be
  generated. The default, "<CURSOR>", specifies the current CSCI.  For further
  details, see "Naming in CSCI-Related Parameters," in the introduction to this
  package.

  Options : String := "";

  Specifies the options for document generation. This parameter allows the
  tailoring of document format to meet specific requirements and to specify
  nondefault contents of the document database. For further information on
  specifying options, see the Key Concepts in the LM book of the Rational
  Environment Reference Manual.

  The following options are available:

  *  Analyze_Private_Types=True|False

     Specifies, when true, that data format tables will include size and limits
     information for objects declared from or composed of private types. When
     false, these table entries show PRIVATE for such objects. The default is
     false.

  *  Csc_Numbering=Compressed|Dotted|None

     Specifies the format of automatically generated CSC numbers from the 2167
     static structure. The CSC number is composed from the CSC number for the
     parent and the ordinal number of the given child.  The Dotted option
     places a period (.) between the parent and child numbers. The Compressed
     option inserts no intervening character. For example, CSCI 5, TLCSC 2 is
     numbered as 52 when the Compressed option is specified.  When the Dotted
     option is specified, the TLCSC is numbered as 5.2. None specifies that
     CSCs will not be numbered. The default is Csc_Numbering=Dotted.

  *  Data_Tables=(Constants, Objects, Types)

     Specifies which declarations will be included in tables that describe data
     formats. The default is Data_Tables=(Objects).

  *  Input_Output_Tables=(Functional, Interface,Non_Requirement)

     Specifies which subprograms will be included in tables that describe
     component inputs and outputs. The default is
     Input_Output_Tables=(Functional,Interface). The Non_Requirement option
     specifies nonrequirement subprograms.

  *  Interpretation=Rational|Strict

     Specifies the interpretation of DOD-STD-2167 to be used when generating
     documents. This option primarily affects table formats. The default is
     Interpretation=Rational. When Interpretation=Strict, the table formats
     used will match those found in the DIDs for DOD-STD-2167.

  Response : String := "<PROFILE>";

  Specifies how to respond to errors, how to generate logs, and which activity
  to use during execution of this command. The default is the job response
  profile.

  Restrictions

  This command cannot be used on CSCIs that do not have a design target
  registered for them.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error will result and an error message
  will be displayed.

  If the specified document name is invalid, an error will result and an error
  message will be displayed.

  Examples

  The Design.Build command can be executed as shown below with default values.
  If the design phase for the current CSCI is set to Preliminary_Design, the
  STLDD will be generated. The tables in the STLDD will contain only objects
  (the default). Input/output tables will contain only functions and interfaces
  (the default). Finally, analysis of private types will not be included in
  data format tables; their entries will show PRIVATE.

   Design.Build;

  The design phase for the current CSCI is set to Preliminary_Design. The SRS
  must be regenerated, using default options, as shown below:

   Design.Build (Document => "srs";
                 In_Csci_View => "<CURSOR>";
                 Options => "";
                 Response => "<PROFILE>");

  If the design phase for the current CSCI is set to Preliminary_Design, the
  following example will generate an STLDD by default. Tables in the STLDD will
  contain constants, objects, and types. Input/output tables will contain
  functions, interfaces, and nonrequirement subprograms.  Finally, private
  types will be included in data format tables.

   Design.Build (Document => "<DEFAULT>";
                 In_Csci_View => "<CURSOR>";
                 Options =>
                    "analyze_private_types," &
                     data_tables=(constants,objects,types)," &
                     input_output_tables=" &
                     (Functional,Interface,Non_Requirement)";
                 Response => "<PROFILE>");

  The following example illustrates how all of the IRSs can be generated. The
  IRS tables will contain constants, objects, and types.  Input/output tables
  will contain functions, interfaces, and nonrequirement subprograms. Finally,
  analysis of private types will not be included in data format tables; their
  entries will show PRIVATE.

   Design.Build (Document => "irs";
                 In_Csci_View =>
                    "!Projects.Cruise_Control.Pdr1_Working";
                 Options =>
                    "data_tables=(constants,objects,types)," &
                    "input_output_tables=" &
                    "(Functional,Interface,Non_Requirement)";
                 Response => "<PROFILE>");

  References

  procedure Generate_Markup

  constant Idd

  constant Irs

  procedure Preview

  procedure Print

  constant Sddd

  constant Srs

  constant Stldd

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Check_Consistency

  procedure Check_Consistency (Of_Component   : String  := "<CURSOR>";
                               Attempt_Repair : Boolean := True;
                               Response       : String  := "<PROFILE>");

  Description

  Verifies that the specified design component is structurally and
  hierarchically consistent with the 2167 DF requirements.

  This command checks the consistency of System, Segment, HWCI, and CSCI design
  components.

  For further information on the structure and hierarchy required by the 2167
  DF, see the Key Concepts book in this manual.

  Parameters

  Of_Component : String := "<CURSOR>";

  Specifies the name of the design component to check.  The default,
  "<CURSOR>", specifies the current design component.  See "Naming in
  CSCI-Related Parameters," in the introduction to this package.

  Attempt_Repair : Boolean := True;

  Specifies, when true (the default), that any inconsistencies detected be made
  consistent or, when that is not possible, the user be notified that they
  should be made consistent manually. The consistency required is described in
  "A Consistent Design Hierarchy for High-Level Design Components," in Chapter
  2 of the Key Concepts book in this manual. When false, this parameter
  specifies that only diagnostic information should be generated.

  Response : String := "<PROFILE>";

  Specifies how to respond to errors, how to generate logs, and which activity
  to use during execution of this command. The default is the job response
  profile.

  Restrictions

  This command can be used only for System, Segment, HWCI, and CSCI design
  components.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error will result and an error message
  will be generated.

  Examples

  When executed in a Command window, the following command will check the
  consistency of the current CSCI, but it will not try to repair any errors
  that it finds. The command will simply report errors.

   Design.Check_Consistency (Of_Component => "<CURSOR>";
                             Attempt_Repair => False);

  References

  function Children

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Children

  function Children (Of_Component    : String  := "<CURSOR>";
                     Decompose_Cscis : Boolean := True;
                     Transitive      : Boolean := True) return String;

  Description

  Returns a naming expression for the children of the specified design
  component.

  Parameters

  Of_Component : String := "<CURSOR>";

  Specifies the name of the design component for which the children should be
  returned. The default, "<CURSOR>", specifies the current design component.

  Decompose_Cscis : Boolean := True;

  Specifies, when true, that the static hierarchy defined in the @DECOMPOSITION
  annotation in the design component should be included in the naming
  expression. When false, the naming expression includes components only down
  to the HWCI and CSCI levels. The default is true.

  Transitive : Boolean := True;

  Specifies, when true, that the transitive closure of the specified design
  component is included in the naming expression. When false, only the
  immediate children of the specified design component are included. The
  default is true.

  return String;

  Returns the naming expression for the children of the specified design
  component.

  Errors

  If this function is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, the value "[ ]" will be returned.

  Examples

  The following program segment will return a naming expression for all of the
  children of the specified CSCI and print it in the Message window:

   with Design;
   with Library;
   procedure Display_Children (The_Csci : in String := "<CURSOR>");
      ...
   declare
        The_Children: constant String :=
            Design.Children (Of_Component => The_Csci);
   begin
      ...
      Library.Resolve (The_Children);
      ...
   end Display_Children;

  References

  procedure Display_Hierarchy

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Complete

  procedure Complete (Include_Optional_Annotations : Boolean := False);

  Description

  Inserts annotations for the current design phase into the design component
  image on which the cursor is currently located.

  As a design component progresses forward through design phases, additional
  annotations may be required; these can be added with the Complete procedure.

  Parameters

  Include_Optional_Annotations : Boolean := False;

  Specifies, when false (the default), that only required annotations be added
  to the design component. When true, this parameter specifies that optional
  annotations also be added.

  Restrictions

  The design component must be in source state and open for editing.

  Errors

  When this command is executed in a CSCI for which no design target is
  registered, an error results and an error message is displayed in the Message
  window.

  Examples

  The following Unit has been created in a CSCI that is at the Detailed_Design
  phase:

   procedure The_Unit (Inputs : in Integer; Outputs: out Integer);

  The user then executes the Design.Complete command, which adds the
  @COMPONENT_KIND annotation to the design component, as shown below:

   --| @COMPONENT_KIND [2167 Component]
   procedure The_Unit (Inputs : in Integer; Outputs: out Integer);

  When the @COMPONENT_KIND annotation has been completed by the user with Unit
  to specify a Unit design component, the user executes the Design.Complete
  command a second time.  The rest of the annotations required in a Unit in the
  Detailed_Design phase are added, as shown below:

   --| @COMPONENT_KIND UNIT
   --| @PURPOSE [TEXT]
   --| @MEMORY [Memory Allocation]
   --| @TIME [Time Allocation]
   --| @LIMITATIONS [TEXT]
   --| @SEQUENCING [TEXT]
   --| @ALGORITHM [TEXT]
   --| @PROCESSING [TEXT]
   --| @UTILIZATION [TEXT]
   procedure The_Unit (Inputs : in Integer; Outputs: out Integer);

  References

  procedure Format

  procedure Common.Complete, EST, Rational Environment Reference Manual

  procedure Common.Format, EST, Rational Environment Reference Manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Component_Kinds

  type Component_Kinds is (System, Segment, Multi_Subsystem_Csci,
                           Csci_Child_Subsystem, Single_Subsystem_Csci,
                           Hwci);

  Description

  Defines the various kinds of design components that can be created using the
  2167 DF.

  Enumerations

  System

  Indicates a System design component.

  Segment

  Indicates a Segment design component.

  Multi_Subsystem_Csci

  Indicates a CSCI design component that consists of more than one subsystem.

  Csci_Child_Subsystem

  Indicates a subsystem that is a child of a multisubsystem CSCI.

  Single_Subsystem_Csci

  Indicates a CSCI design component that is contained in a single subsystem.

  Hwci

  Indicates a HWCI design component.

  References

  Chapters 2 and 3, Key Concepts book of this manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Create_Model

  procedure Create_Model
                    (Compiler_Model        : String := ">>MODEL NAME<<";
                     Design_Facility_Model : String := "RATIONAL_2167";
                     New_Model_Name        : String := "");

  Description

  Creates a model world, to be used by the Design.Initial command, specifying
  the requisite components of the design target: the Design Facility PDL name
  and the compiler name.

  The command performs the following steps in creating the model (the user
  should not perform any of them):

  *  Copies the model specified in the Compiler_Model parameter into the model
     specified in the New_Model_Name parameter, including the contents of the
     switch file associated with that model world.

  *  Creates Design.Options and Design.Phase library switches in the library
     switch file for the model specified in the New_Model_Name parameter.

  *  Copies the nondefault switch values from the switch file associated with
     the model specified in the Design_Facility_Model parameter into the
     corresponding switch file in the model specified in the New_Model_Name
     parameter. If the switch values in both switch files have nondefault
     values, the Design_Facility_Model value is not copied and an error message
     is displayed in the log.

  *  Composes the name associated with the New_Model_Name parameter from the
     target key names associated with the two source models, unless a name
     other than the null string is specified as a value for the New_Model_Name
     parameter.

  *  Copies the library structure from the model specified in the
     Design_Facility_Model parameter into the model specified in the
     New_Model_Name parameter.

  Parameters

  Compiler_Model : String := ">>MODEL NAME<<";

  Specifies the name of the model for the compiler to be used in the design
  target.  The default parameter placeholder >>MODEL NAME<< must be replaced.

  Design_Facility_Model : String := "RATIONAL_2167";

  Specifies the name of the model for the Design Facility PDL to be used.  The
  default specifies RATIONAL_2167.

  New_Model_Name : String := "";

  Specifies the name of the model to be created.  The null string specifies
  that the name will be a composite of the Design Facility model name and the
  compiler model name.  For example, the composite name for the RATIONAL_2167
  model and the M1750A_BARE model is, by default, RATIONAL_2167_M1750A_BARE.

  Restrictions

  If the models are incompatible, error messages are generated, warning the
  user that editing of the model may be required.

  Both the compiler and the Design Facility models must already exist.  If they
  do not, no attempt will be made to create a new model.

  Examples

  To create a model world for a RATIONAL_2167_M1750A_BARE model, the
  Create_Model command would be used as shown below. Using the model for the
  compiler and the Design Facility model, the command creates a new model
  called RATIONAL_2167_M1750A_BARE.

   Design.Create_Model (Compiler_Model => "m1750a_bare",
                        Design_Facility_Model => "rational_2167",
                        New_Model_Name => "rational_2167_m1750a_bare");

  References

  procedure Initial

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Current_Document

  function Current_Document
             (In_Csci_View : String := "<CURSOR>") return Document_Name;

  Description

  Returns the document kind to be generated by default during the current
  design phase for the specified CSCI.

  If the design phase is Requirements_Analysis, the SRS is the default
  document. If the design phase is Preliminary_Design, the STLDD is the default
  document.  Finally, if the design phase is Detailed_Design or later, the SDDD
  is the default document.

  Parameters

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI.  The default, "<CURSOR>", specifies the
  current CSCI. See "Naming in CSCI-Related Parameters," in the introduction to
  package Design, for further details.

  return Document_Name;

  Returns the document kind: SRS, STLDD, SDDD, or "<UNKNOWN>".

  Restrictions

  If the design phase of the specified CSCI is not set to one of those provided
  by the 2167 DF or if the CSCI has no design target registered for it, the
  document name "<UNKNOWN>" is returned.

  Errors

  If this function is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, "<UNKNOWN>" will be returned.

  Examples

  The following example shows how the Current_Document function might be used:

   with Design;
   procedure The_Current_Document (The_CSCI : in String) is
       Document : constant Design.Document_Name :=
           Design.Current_Document (In_Csci_View => The_CSCI);
   begin
       if Document = Design.Srs then
           ...
       elsif Document = Design.Stldd then
           ...
       elsif Document = Design.Sddd then
           ...
       else
           raise Document_Name_Error;
       end if;
   end The_Current_Document;

  References

  constant Default

  subtype Document_Name

  constant Idd

  constant Irs

  constant Sddd

  constant Srs

  constant Stldd

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Current_Phase_Image

  function Current_Phase_Image
                    (In_Csci_View : String := "<CURSOR>") return String;

  Description

  Returns the string representation of the current design phase for the
  specified CSCI.

  The design phase value is stored in the Design.Phase library switch. The
  Set_Phase command should be used to edit the Design.Phase switch.

  Parameters

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI. The default, "<CURSOR>", specifies the
  current CSCI. See "Naming in CSCI-Related Parameters," in the introduction to
  package Design, for further details.

  return String;

  Returns one of the following design phases:

  *  Requirements_Analysis

  *  Preliminary_Design

  *  Detailed_Design

  *  Coding

  *  Csc_Integration

  *  Csci_Test

  Errors

  If this function is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, Nil will be returned.

  If no design phase is set for the current CSCI, Nil will be returned.

  Examples

  The following example shows how the Current_Phase_Image function might be
  used to check the current design phase and perform some action based on the
  phase:

   with Design;
   . . .
   declare
       Project: constant String := Projects (The_Project);
       Phase : constant String :=
           Design.Current_Phase_Image (Project);
   begin
       if Phase = "REQUIREMENTS_ANALYSIS" then
           ...
       elsif Phase = "PRELIMINARY_DESIGN" then
           ...
       elsif Phase = "DETAILED_DESIGN" then
           ...
       elsif Phase = "Nil" then
           ...
       end if;
   end;

  References

  procedure Display_All_Phases

  procedure Display_Phase

  procedure Set_Phase

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Current_Target_Image

  function Current_Target_Image
                    (In_Csci_View : String := "<CURSOR>") return String;

  Description

  Returns the string representation of the design target for the specified
  CSCI.

  Parameters

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI.  The default, "<CURSOR>", specifies the
  current CSCI. See "Naming in CSCI-Related Parameters," in the introduction to
  package Design, for further details.

  return String;

  Returns the string representation of the design target for the specified
  CSCI.

  Errors

  If this function is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, "<NONE>" will be returned.

  Examples

  The following sample procedure shows how the Current_Target_Image function
  can be used to display the name of the current design target in the current
  log file:

   with Design, Log;
   procedure The_Current_Target_Image
       (The_Csci : in String := "<CURSOR>") is
   begin
       Log.Put_Line ("The current design target is " &
                     Design.Current_Target_Image (The_Csci));
         ...
   end The_Current_Target_Image;

  References

  procedure Display_All_Targets

  procedure Display_Target

  procedure Set_Target

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Default

  Default : constant Document_Name := "<DEFAULT>";

  Description

  Defines a constant that represents the default document for the current
  design phase.

  For the Requirements_Analysis phase, the document is the SRS; for the
  Preliminary_Design phase, the document is the STLDD; and for Detailed_Design
  and later phases, the document is the SDDD.

  References

  subtype Document_Name

  constant Idd

  constant Irs

  constant Sddd

  constant Srs

  constant Stldd

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Definition

  procedure Definition (In_Place : Boolean := False;
                        Visible  : Boolean := True);

  Description

  Displays in a window the design component, file, or document in which the
  information is defined, when executed in a document.

  Parameters

  In_Place : Boolean := False;

  Specifies whether the current frame should be used to bring up the image.
  The default, false, specifies that the least recently used frame should be
  replaced.

  Visible : Boolean := True;

  Specifies, for requirements, whether to display the specification in the PDL
  (in the @FUNCTION_DEFINED or @INTERFACES_DEFINED annotation) or in the
  defining paragraph in the SRS or IRS document. A value of true, the default,
  specifies the annotation; false specifies the document.

  Restrictions

  When this command is executed in a CSCI for which no design target is
  registered, an error results and an error message is displayed in the Message
  window.

  Errors

  When this command is entered in PDL or in a document that is not within a
  Rational System or Subsystem with the Rational Design Facility specified as
  its design target, an error results and an error message is displayed.

  References

  procedure Show_Usage

  procedure Ada.Show_Usage, EST, Rational Environment Reference Manual

  procedure Common.Definition, EST, Rational Environment Reference Manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Display_All_Phases

  procedure Display_All_Phases (In_Csci_View : String := "<CURSOR>");

  Description

  Displays in the Message window all of the design phases for the design target
  registered with the specified CSCI.

  The design phases for 2167 DF-based design targets are:

  *  Requirements_Analysis

  *  Preliminary_Design

  *  Detailed_Design

  *  Coding

  *  Csc_Integration

  *  Csci_Test

  Parameters

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI.  The default,  "<CURSOR>", specifies the
  current CSCI.  See "Naming in CSCI-Related Parameters," in the introduction
  to package Design, for further details.

  Errors

  If no design target has been registered with the specified CSCI, an error
  results and an error message is displayed.

  Examples

  Executing the command:

   Design.Display_All_Phases;

  in a Command window in a CSCI that has RATIONAL_2167_R1000 registered for it
  will result in the following display in the Message window:

   Available Design Phases:  REQUIREMENTS_ANALYSIS, PRELIMINARY_DESIGN,
   DETAILED_DESIGN, CODING, CSC_INTEGRATION, CSCI_TEST

  References

  function Current_Phase_Image

  procedure Display_Phase

  procedure Set_Phase

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Display_All_Targets

  procedure Display_All_Targets;

  Description

  Displays in the Message window all of the targets registered on the machine
  on which the command is executed.

  The name of the design target for the 2167 DF with the R1000 compiler is
  RATIONAL_2167_R1000.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  If the only design target registered on a machine is RATIONAL_2167_R1000, the
  command:

   Design.Display_All_Targets;

  executed in a Command window results in the following display in the Message
  window:

   Available Design Targets:  RATIONAL_2167_R1000

  References

  procedure Create_Model

  function Current_Target_Image

  procedure Display_Target

  procedure Set_Target

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Display_Hierarchy

  procedure Display_Hierarchy (Of_Component    : String  := "<CURSOR>";
                               Decompose_Cscis : Boolean := True;
                               Transitive      : Boolean := True);

  Description

  Displays the 2167 static hierarchy in current output.

  If the Decompose_Cscis parameter is false, the static structure through the
  CSCI level is shown. If this parameter is true, any design components
  specified in the @DECOMPOSITION annotation of any CSCIs in the specified
  hierarchy also are included in the display. If the Transitive parameter is
  true, the transitive closure is shown.

  Parameters

  Of_Component : String := "<CURSOR>";

  Specifies the design component for which the static hierarchy should be
  displayed. The default, "<CURSOR>", specifies the current design component.

  Decompose_Cscis : Boolean := True;

  Specifies, when false, that the static structure through the CSCI level is
  shown. When true (the default), this parameter specifies that any design
  components specified in the @DECOMPOSITION annotation of any CSCI in the
  specified hierarchy also are included in the display.

  Transitive : Boolean := True;

  Specifies, when true (the default), that the transitive closure of the
  Of_Component parameter is displayed. When false, only the immediate children
  of the given component are displayed.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  When executed in the context of the CSCI, the command:

   Design.Display_Hierarchy (Of_Component => "<CURSOR>";
                             Decompose_Cscis => True;
                             Transitive => True);

  shows the static structure of the CSCI, including all design components
  included in the @DECOMPOSITION annotation of the CSCI.  The transitive
  closure of the CSCI also will be displayed.

  References

  procedure Initial

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Display_Phase

  procedure Display_Phase (In_Csci_View : String := "<CURSOR>");

  Description

  Displays in the Message window the current design phase for the design target
  registered with the specified CSCI.

  Parameters

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI. The default, "<CURSOR>", specifies the
  current CSCI. See "Naming in CSCI-Related Parameters," in the introduction to
  package Design, for further details.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  The command:

   Design.Display_Phase;

  executed from a Command window below a CSCI, displays the following in the
  Message window for a CSCI that is currently set to the Preliminary_Design
  phase:

   Current Design Phase is PRELIMINARY_DESIGN

  References

  procedure Display_All_Phases

  procedure Set_Phase

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Display_Target

  procedure Display_Target (In_Csci_View : String := "<CURSOR>");

  Description

  Displays the name of the design target registered with the specified CSCI.

  Design target names consist of two parts, connected by the underscore
  character.  The first part is the 2167 DF PDL name; the second is the name of
  the target compiler. For example, the default design target is
  RATIONAL_2167_R1000. Design target names are determined on system boot as a
  composite of the PDL names and the compilers registered on the machine.

  Parameters

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI for which the registered design target name
  will be displayed.  The default, "<CURSOR>", specifies the current CSCI.  See
  "Naming in CSCI-Related Parameters," in the introduction to package Design,
  for further details.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  Executing the command:

   Design.Display_Target;

  in a Command window below a CSCI that has RATIONAL_2167_R1000 registered with
  it results in the following display:

   Current Design Target is RATIONAL_2167_R1000

  References

  procedure Create_Model

  procedure Display_All_Targets

  procedure Set_Target

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Document_Name

  subtype Document_Name is String;

  Description

  Defines the form of document names.

  References

  constant Default

  constant Idd

  constant Irs

  constant Sddd

  constant Srs

  constant Stldd

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Enclosing

  procedure Enclosing (In_Place : Boolean := False);

  Description

  Traverses to and displays the enclosing 2167 DF design component (note that
  this is not the enclosing library structure).

  Parameters

  In_Place : Boolean := False;

  Specifies whether the current frame should be used to bring up the image.
  The default, false, specifies that the least recently used frame should be
  used.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  The following table illustrates the relationships of the enclosing design
  component:

         ------------------------------------------------------------- 
        |                    |                                        |
        |  Cursor Location   |       Enclosing Design Component       |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |There is no enclosing design component, |
        |System design       |so the following message is displayed:  |
        |component           |This is the root of the 2167 system     |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the package specification for  |
        |Segment design      |the System design component from which  |
        |component           |it was allocated                        |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the package specification for  |
        |CSCI design         |the Segment (or System if there is no   |
        |component           |Segment) design component from which it |
        |                    |was allocated                           |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the package specification for  |
        |HWCI design         |the Segment (or System if there is no   |
        |component           |Segment) design component from which it |
        |                    |was allocated                           |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the specification for the CSCI |
        |TLCSC design        |or TLCSC design component from which it |
        |component           |was allocated                           |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the specification for the TLCSC|
        |LLCSC design        |or LLCSC design component from which it |
        |component           |was allocated                           |
         ------------------------------------------------------------- 
        |                    |                                        |
        |On the image of the |Image of the specification for the TLCSC|
        |Unit design         |or LLCSC design component from which it |
        |component           |was allocated                           |
         ------------------------------------------------------------- 

  References

  procedure Display_Hierarchy

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Explain

  procedure Explain;

  Description

  Displays, in a preview document, information for the document structure on
  which the cursor is located.

  In PDL, this command displays information for the annotation and its argument
  on which the cursor is currently located.

  Restrictions

  When no information is available, the message No information available is
  displayed in the Message window.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  References

  procedure Common.Explain, EST, Rational Environment Reference Manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Format

  procedure Format;

  Description

  Performs syntactic checking of annotations in the image of a design
  component.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  References

  procedure Common.Format, EST, Rational Environment Reference Manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Generate_Markup

  procedure Generate_Markup
                          (Of_Document  : Document_Name := "<DEFAULT>";
                           In_Csci_View : String        := "<CURSOR>";
                           Options      : String        := "";
                           Response     : String        := "<PROFILE>");

  Description

  Generates markup for the specified document in the specified CSCI.

  The markup language generated can be used by the Rational Document Formatter
  to produce either PostScript output to be printed on a laser printer or ASCII
  output to be printed on a line printer.

  The file containing the markup is located in the Documents directory of the
  CSCI in a file called >>DOCUMENT NAME<<_Mss, where >>DOCUMENT NAME<< is SRS,
  STLDD, SDD, IRS_>>DOCUMENT_NUMBER<<, or IDD_>>DOCUMENT_NUMBER<<.

  If the Rational Document Formatter is run on the markup file, two additional
  files are generated in the Documents directory. When the Device parameter of
  the command that invokes the Rational Document Formatter is set to
  PostScript, two files, called >>DOCUMENT NAME<<_Mss_Ps and >>DOCUMENT
  NAME<<_Mss_Aux, are generated. The >>DOCUMENT NAME<<_Mss_Ps file contains
  the PostScript, and it can be printed on a laser printer.

  When the Device parameter of the command that invokes the Rational Document
  Formatter is set to Lineprinter, two files, called >>DOCUMENT_NAME<<_Mss_Lpt
  and >>DOCUMENT NAME<<_Mss_Aux, are generated. The >>DOCUMENT NAME<<_Mss_Lpt
  file contains ASCII, and it can be printed on a line printer. If the Device
  parameter of the command that invokes the Rational Document Formatter is set
  to Lineprinter, and PostScript graphics are included in the document, an
  error will result and an error messages will be generated because the
  pictures cannot be interpolated into the document.

  Parameters

  Of_Document : Document_Name := "<DEFAULT>";

  Specifies the name of the document. The default, "<DEFAULT>", specifies that
  markup will be generated for the default document for the current design
  phase. Thus, if the current design phase is Requirements_Analysis, markup for
  the existing SRS will be generated. Similarly, in the Preliminary_Design
  phase, markup for the existing STLDD will be generated, and in
  Detailed_Design and later phases, markup for the existing SDDD will be
  generated. For information on the resolution of ambiguous document names,
  see "Document Naming in Document Parameters," in the introduction to this
  package.

  The available options are:

  *  In_Csci_View : String := "<CURSOR>";

     Specifies the CSCI containing the document for which markup will be
     generated. The default, "<CURSOR>", specifies the CSCI on which the cursor
     is located. For further details, see "Naming in CSCI-Related Parameters,"
     for in the introduction to this package.

  *  Options : String := "";

     Specifies options that will be used in generating markup. Through the
     Options parameter, you can specify nondefault contents of the document
     database. For further information on specifying options, see the Key
     Concepts in the LM book of the Rational Environment Reference Manual.

  *  Analyze_Private_Types=True|False

     Specifies, when true, and when the Build_Db option is true, that data
     format tables will include size and limits information for objects
     declared from or composed of private types. When false, these table
     entries show PRIVATE for such objects. The default is false.

  *  Build_Db=True|False

     Specifies, when true, that the document database for the document will be
     regenerated before the markup is generated. Thus, the resulting markup
     will be for the most recent version of the PDL and included text and
     document files. When false, the document database will not be regenerated.
     Thus, it may not reflect recent changes to PDL and included files. The
     default is false.

  *  Csc_Numbering=Compressed|Dotted|None

     Specifies the format of automatically generated CSC numbers from the 2167
     static structure. In both cases, the CSC number is composed from the CSC
     number for the parent and the ordinal number of the given child.  The
     Dotted option places a period (.) between the parent and child numbers.
     The Compressed option inserts no intervening character. For example, CSCI
     5, TLCSC 2 is numbered as 52 when the Compressed option is specified.
     When the Dotted option is specified, the TLCSC is numbered as 5.2. None
     specifies that CSCs will not be numbered. The default is
     Csc_Numbering=Dotted. This option is valid only when the Build_Db option
     is true.

  *  Data_Tables=(Constants, Objects, Types)

     Specifies which declarations will be included in tables that describe data
     formats. The default is Data_Tables=(Objects). This option is valid only
     when the Build_Db option is true.

  *  Input_Output_Tables=(Functional, Interface, Non_Requirement)

     Specifies which subprograms will be included in tables that describe
     component inputs and outputs. The default is
     Input_Output_Tables=(Functional,Interface). The Non_Requirement option
     specifies nonrequirement subprograms. This option is valid only when the
     Build_Db option is true.

  *  Interpretation=Rational|Strict

     Specifies the interpretation of DOD-STD-2167 to be used when generating
     documents. This option primarily affects table formats. The default is
     Interpretation=Rational. When Interpretation=Strict, the table formats
     used will match those found in the DIDs for DOD-STD-2167. This option is
     valid only when the Build_Db option is true.

  *  Paragraph_Header_Style=Rational|Italicize_Subparagraphs|
                                                     Underline_All

     Specifies the style of paragraph headings in the printed document. The
     meaning of each choice for this option is described below:

     -  Rational:  Paragraph headers will be produced in bold typeface with no
        special processing.

     -  Italicize_Subparagraphs:  All paragraph headers with more than two
        digits (for example, 1.2.5 or 6.2.7 or 2.1.3.9) will be italicized.
        This option conforms to MIL-STD-490A, paragraph 3.2.5, for typeset
        documents.

     -  Underline_All:  All paragraph headers, regardless of level, will be
        underlined.  This option conforms to MIL-STD-490A, paragraph 3.2.5, for
        nontypeset documents.

     The default is Paragraph_Header_Style=Rational. Only one of these options
     can be specified.

  Response : String := "<PROFILE>";

  Specifies how to respond to errors, how to generate logs, and which activity
  to use during execution of this command.  The default is the job response
  profile.

  Restrictions

  The document database for the specified document must exist before the
  execution of this command, unless the Build_Db option is set to true.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  Assume that a user wants to regenerate markup for the SRS but not print it
  until after reviewing the marked-up version. The current design phase is
  Preliminary_Design; thus, the SRS is not the default document. The user also
  wants to regenerate the document database for the SRS while generating
  markup. To accomplish this, the user enters the following command in a
  Command window and executes it:

   Design.Generate_Markup (Of_Document => "SRS";
                           In_Csci_View => "<CURSOR>";
                           Options => "build_db";
                           Response => "<PROFILE>");

  References

  procedure Build

  procedure Preview

  procedure Print

  Rational Document Formatter documentation

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Idd

  Idd : constant Document_Name := "IDD";

  Description

  Defines a constant for the Interface Description Document (IDD).

  References

  constant Default

  subtype Document_Name

  constant Irs

  constant Sddd

  constant Srs

  constant Stldd

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Initial

  procedure Initial
     (Component              : String          := ">>COMPONENT_NAME<<";
      Kind                   : Component_Kinds :=
                                           Design.Single_Subsystem_Csci;
      Parent                 : String          := "";
      Working_View_Base_Name : String          := "Ssr1";
      View_To_Import         : String          := "";
      Create_Load_View       : Boolean         := True;
      Model                  : String          := "RATIONAL_2167_R1000";
      Comments               : String          := "";
      Work_Order             : String          := "<DEFAULT>";
      Volume                 : Natural         := 0;
      Response               : String          := "<PROFILE>");

  Description

  Creates and initializes the specified design component of the specified type.

  The following operations are performed during creation and initialization:

  *  Creation of the CMVC system object types as described in the following
     table

  *  Building of the appropriate library structure for the design target

  *  Possible creation of an empty design component (see the following table)

  *  Setting of the design target for the subsystem to the design target
     specified in the model

  *  Setting of the design phase to Requirements_Analysis

  *  Setting of the appropriate parental relationship as specified in the
     Parent parameter

  *  Passing of the information supplied to the parameters following the Parent
     parameter to the Cmvc.Initial command

  When subsystems are created, the default model, RATIONAL_2167_R1000, is used.
  It has a set of links identical to model R1000_PORTABLE, so that the code can
  be ported more easily to other machines.  Further information about the model
  appears below in the description of the Model parameter.

  The following table shows what objects are created when each type of design
  component is initialized:

                ----------------------------------------------- 
               |               |               |               |
               |2167 Design    |               |2167 Design    |
               |Component      |CMVC Object    |Component      |
               |               |Created        |Created        |
                ----------------------------------------------- 
               |               |               |               |
               |System         |Rational System|System package |
               |               |               |specification  |
                ----------------------------------------------- 
               |               |               |               |
               |Segment        |Rational System|Segment package|
               |               |               |specification  |
                ----------------------------------------------- 
               |               |               |               |
               |Multisubsystem |Rational System|None           |
               |CSCI           |               |               |
                ----------------------------------------------- 
               |          1    |               |               |
               |CSCI Child     |Rational       |CSCI package 2 |
               |               |Subsystem      |specification  |
                ----------------------------------------------- 
               |               |               |               |
               |Single-Subsyste|Rational       |CSCI package   |
               |m CSCI         |Subsystem      |specification  |
                ----------------------------------------------- 
               |               |               |               |
               |HWCI           |Rational       |HWCI package   |
               |               |Subsystem      |specification  |
                ----------------------------------------------- 

  1
    The parent of a CSCI child must be a multisubsystem CSCI.
  2
    This is created only if the CSCI package specification does not already
  exist in another sibling CSCI child subsystem.

  Parameters

  Component : String := ">>COMPONENT_NAME<<";

  Specifies the name of the design component to be created. The default
  parameter placeholder, >>COMPONENT_NAME<<, must be replaced with the name of
  the design component to be created. The name specified must be an Ada simple
  name.

  Kind : Component_Kinds := Design.Single_Subsystem_Csci;

  Specifies the kind of design component to initialize. The default,
  Single_Subsystem_Csci, specifies that a CSCI consisting of a single subsystem
  will be initialized.

  Parent : String := "";

  Specifies the name of a previously initialized parent design component to be
  linked. The default, the null string (""), specifies that the design
  component has no parent. It should be noted that the parent can be added or
  changed at a later time with the Set_Parent procedure.

  Working_View_Base_Name : String := "Ssr1";

  Specifies the base name for the working view of the subsystem created for the
  CSCI. CSCIs are created in subsystems. Each view of a subsystem has a base
  name that is the part of the name shared by the working and released views of
  that view. For example, Ssr1_Working might be the name of the working view
  and Ssr1_0_1 and Ssr1_0_2 might be the names of released views. The
  Working_View_Base_Name parameter allows you to specify a base name other than
  Ssr1, which is the default. For example, you may want to give a view in which
  you are writing PDL and generating documents for the Preliminary Design
  Review the name Pdr1_Working. Thus, you would specify Pdrl as the value for
  this parameter. The default, Ssr1, specifies the Software Specification
  Review.

  View_To_Import : String := "";

  Specifies the name of views to import. The default, the null string (""),
  specifies that no views will be imported. To use interfaces or functions
  defined in the views that contain other CSCIs (they are specified in the
  @INTERFACES_USED and @FUNCTIONS_DEFINED annotations), they must be imported.

  Create_Load_View : Boolean := True;

  Specifies whether a load view using the base name specified in the
  Working_View_Base_Name parameter will be created. The default, true,
  specifies that the load view will be created. False specifies that a combined
  view will be created.

  Model : String := "RATIONAL_2167_R1000";

  Specifies which model to use when the CSCI subsystem is created. The default
  model, RATIONAL_2167_R1000, has a set of links identical to model
  R1000_PORTABLE, so that the code can be run on machines other than R1000s.
  The CSCI has RATIONAL_2167_R1000 registered with it and the design phase
  library switch is set to Requirements_Analysis. Finally, the model contains
  the library structure required by the 2167 DF-namely, the addition of the
  Documentation, Graphics, and Files directories at the same level as the Units
  directory of a subsystem.

  Comments : String := "";

  Specifies any comments to be put into the CMVC configuration database on
  creation of the CSCI subsystem.

  Work_Order : String := "<DEFAULT>";

  Specifies the name of the work order to use when creating the CSCI subsystem.
  The default, "<DEFAULT>", specifies the default work order for that session.

  Volume : Natural := 0;

  Specifies the disk volume on which to create the CSCI subsystem. The default,
  0, specifies the volume with the greatest amount of available space.

  Response : String := "<PROFILE>";

  Specifies how to respond to errors, how to generate logs, and which activity
  to use during execution of this command. The default is the job response
  profile.

  Restrictions

  All of the design components in a System must use the same design target.

  Examples

  The following example illustrates how a multisubsystem CSCI called
  Cruise_Control might be initialized. Its parent is a Segment called
  Vehicle_System. It also requires the use of some interfaces specified in
  !Projects.Steering. A Spec_Load subsystem should be created. Finally, the
  model world to be used is called RATIONAL_2167_R1000 because that is the
  design target to be used for the CSCI.

   Design.Initial (Component => "cruise_control";
                   Parent => "vehicle_system";
                   Kind => Design.Multi_Subsystem_Csci;
                   Working_View_Base_Name => "PDR1";
                   View_To_Import => "!projects.steering.pdr1_0_spec";
                   Create_Load_View => True;
                   Model => "RATIONAL_2167_R1000";
                   Comments => "";
                   Work_Order => "<DEFAULT>";
                   Volume => 0;
                   Response => "<PROFILE>");

  Next, its child CSCI subsystems would be initialized. A sample of their
  initialization is shown below. This child CSCI is called Child_1, and its
  parent is the multisubsystem CSCI called Cruise_Control.

   Design.Initial (Component => "child_1";
                   Parent => "cruise_control";
                   Kind=> Design.Csci_Child_Subsystem;
                   Working_View_Base_Name => "PDR1";
                   View_To_Import => "!projects.steering.pdr1_0_spec";
                   Create_Load_View => True;
                   Model => "RATIONAL_2167_R1000";
                   Comments => "";
                   Work_Order => "<DEFAULT>";
                   Volume => 0;
                   Response => "<PROFILE>");

  References

  type Component_Kinds

  package Cmvc, PM, Rational Environment Reference Manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Irs

  Irs : constant Document_Name := "IRS";

  Description

  Defines a constant for the Interface Requirements Specification (IRS)
  document.

  References

  constant Default

  subtype Document_Name

  constant Idd

  constant Sddd

  constant Srs

  constant Stldd

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Parent

  function Parent (Of_Component : String  := "<CURSOR>";
                   Recursive    : Boolean := False) return String;

  Description

  Returns a naming expression for the parent of the specified design component.

  When the Recursive parameter is true, the complete parentage of the specified
  design component is included in the naming expression. When it is false, only
  the immediate parent of the specified component is returned.

  Parameters

  Of_Component : String := "<CURSOR>";

  Specifies the design component for which the parentage should be returned.
  The default, "<CURSOR>", specifies the design component on which the cursor
  is currently located.

  Recursive : Boolean := False;

  Specifies, when true, that the complete parentage of the specified design
  component is included in the naming expression. When false, this parameter
  specifies that only the immediate parent of the specified component is to be
  returned. The default is false.

  return String;

  Returns a naming expression specifying the parentage of the specified design
  component.

  Errors

  If this function is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, the value "[ ]" will be returned.

  References

  procedure Display_Hierarchy

  procedure Set_Parent

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Preview

  procedure Preview (Document     : Document_Name := "<DEFAULT>";
                     In_Csci_View : String        := "<CURSOR>";
                     Options      : String        := "";
                     In_Place     : Boolean       := False;
                     Response     : String        := "<PROFILE>");

  Description

  Displays the specified preview document located in the view specified in the
  In_Csci_View parameter.

  If the Document parameter resolves to more than one document, a menu of
  documents is displayed. For further details concerning resolution of
  ambiguous document names, see the introduction to this package.  If the
  Build_Db option is specified, the document database is rebuilt before the
  preview document is displayed.

  Parameters

  Document : Document_Name := "<DEFAULT>";

  Specifies the preview document to be previewed. The default, "<DEFAULT>",
  specifies the default document for the current design phase of the specified
  CSCI. Thus, if the design phase is Requirements_Analysis, the SRS document
  will be displayed. If the design phase is Preliminary_Design, the STLDD
  will be displayed. Finally, if the design phase is Detailed Design or later,
  the SDDD will be displayed.  For information on the resolution of ambiguous
  document names, see "Document Naming in Document Parameters," in the
  introduction to this package.

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI for which the document is to be displayed. The
  default, "<CURSOR>", specifies the current CSCI. For further information, see
  "Naming in CSCI-Related Parameters," in the introduction to this package.

  Options : String := "";

  Specifies options for generating and displaying documents. Through the
  Options parameter, you can specify nondefault contents of the document
  database. For further information on specifying options, see the Key Concepts
  in the LM book of the Rational Environment Reference Manual.

  The available options are:

  *  Analyze_Private_Types=True|False

     Specifies, when this option is true and when the Build_Db option is true,
     that data format tables will include size and limits information for
     objects declared from or composed of private types. When false, these
     table entries show PRIVATE for such objects. The default is false.

  *  Build_Db=True|False

     Specifies, when true, that the document database for the document will be
     regenerated before the preview document is displayed. Thus, the resulting
     preview document will reflect the most recent versions of the PDL and
     included text and document files. When false, the document database will
     not be regenerated. Thus, the preview document may not reflect recent
     changes to PDL and included files. The default is false.

  *  Csc_Numbering=Compressed|Dotted|None

     Specifies the format of automatically generated CSC numbers from the 2167
     static structure. In both cases, the CSC number is composed from the CSC
     number for the parent and the ordinal number of the given child.  The
     Dotted option places a period (.) between the parent and child numbers.
     The Compressed option inserts no intervening character. For example, CSCI
     5, TLCSC 2 is numbered as 52 when the Compressed option is specified.
     When the Dotted option is specified, the TLCSC is numbered as 5.2. None
     specifies that CSCs will not be numbered. The default is
     Csc_Numbering=Dotted. This option is valid only when the Build_Db option
     is true.

  *  Data_Tables=(Constants, Objects, Types)

     Specifies which declarations will be included in tables that describe data
     formats. The default is Data_Tables=(Objects).  This option is valid only
     when the Build_Db option is true.

  *  Input_Output_Tables=(Functional, Interface, Non_Requirement)

     Specifies which subprograms will be included in tables that describe
     component inputs and outputs. The default is
     Input_Output_Tables=(Functional,Interface). The Non_Requirement option
     specifies nonrequirement subprograms. This option is valid only when the
     Build_Db option is true.

  *  Interpretation=Rational|Strict

     Specifies the interpretation of DOD-STD-2167 to be used when generating
     documents. This option primarily affects table formats. The default is
     Interpretation=Rational. When Interpretation=Strict, the table formats
     used will match those found in the DIDs for DOD-STD-2167. This option is
     valid only when the Build_Db option is true.

  In_Place : Boolean := False;

  Specifies whether the frame displaying the document will replace the frame
  from which the Preview command was executed. The default, false, specifies
  that the frame will not be replaced. A value of true specifies that the frame
  will be replaced.

  Response : String := "<PROFILE>";

  Specifies how to respond to errors, how to generate logs, and which activity
  to use during execution of this command. The default is the job response
  profile.

  Restrictions

  The document database for the specified document must exist before the
  execution of this command, unless the Build_Db option is true.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  The following command generates the default document database and displays
  the corresponding preview document for the current CSCI.  Included files
  are displayed in the preview document:

   Design.Preview (Document => "<DEFAULT>";
                   In_Csci_View => "<CURSOR>";
                   Options => "build_db,expand_included_files";
                   In_Place => False;
                   Response => "<PROFILE>");

  References

  procedure Build

  procedure Generate_Markup

  procedure Print

  Rational Document Formatter documentation

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Print

  procedure Print (Document     : Document_Name := "<DEFAULT>";
                   In_Csci_View : String        := "<CURSOR>";
                   Options      : String        := "";
                   Response     : String        := "<PROFILE>");

  Description

  Prints the specified document located in the specified CSCI.

  The Print procedure is actually a combination of three other procedures.
  First, the Print procedure calls the Generate_Markup procedure.  This command
  generates markup for the specified document database and stores it in a file
  called >>DOCUMENT NAME<<_Mss in the appropriate document directory in the
  CSCI subsystem structure. Next, the >>DOCUMENT NAME<<_Mss file, containing
  text and markup, is submitted to the Rational Document Formatter to produce
  either PostScript output to be printed on a laser printer or ASCII output to
  be printed on a line printer.  When the Rational Document Formatter is run on
  the >>DOCUMENT NAME<<_Mss file, two additional files are generated in the
  same directory.

  When the Device option of the Print command is set to PostScript, two files,
  called >>DOCUMENT NAME<<_Mss_Ps and >>DOCUMENT NAME<<_Mss_Aux, are generated.
  The >>DOCUMENT NAME<<_Mss_Ps file contains the PostScript and can be printed
  on a laser printer.

  When the Device option of the Print command is set to Lineprinter, two files,
  called >>DOCUMENT NAME<<_Mss_Lpt and >>DOCUMENT NAME<<_Mss_Aux, are
  generated. The >>DOCUMENT NAME<<_Mss_Lpt file contains ASCII and can be
  printed on a line printer. If the Device parameter of the command that
  invokes the Rational Document Formatter is set to Lineprinter, and PostScript
  graphics are included in the document, errors will result and error messages
  will be generated because graphics cannot be interpolated into the document.

  Finally, the Print command submits the resulting >>DOCUMENT NAME<<_Mss_Ps or
  >>DOCUMENT NAME<<_Mss_Lpt file to the appropriate print queue with the
  Queue.Print command.

  Parameters

  Document : Document_Name := "<DEFAULT>";

  Specifies the document to be printed. The default, "<DEFAULT>", specifies the
  default document for the current design phase of the specified CSCI. Thus, if
  the design phase is Requirements_Analysis, the SRS will be printed. If the
  design phase is Preliminary_Design, the STLDD will be printed. Finally, if
  the design phase is Detailed_Design or later, the SDDD will be printed.  For
  information on the resolution of ambiguous document names, see "Document
  Naming in Document Parameters," in the introduction to this package.

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI for which the document is to be printed. The
  default, "<CURSOR>", specifies the CSCI on which the cursor is currently
  located. For further details, see "Naming in CSCI-Related Parameters," in the
  introduction to this package.

  Options : String := "";

  Specifies options for generating and printing documents. Through the Options
  parameter, you can specify nondefault contents of the document database and
  printing options. For further information on specifying options, see the Key
  Concepts in the LM book of the Rational Environment Reference Manual.

  The available options are:

  *  Analyze_Private_Types=True|False

     Specifies, when true and when the Build_Db option is true, that data
     format tables will include size and limits information for objects
     declared from or composed of private types. When false, these table
     entries show PRIVATE for such objects. The default is false.

  *  Build_Db=True|False

     Specifies, when true, that the document database for the document will be
     regenerated before the document is printed. Thus, the resulting printed
     document will reflect the most recent versions of the PDL and included
     text and document files. When false, the document database will not be
     regenerated. Thus, the printed document may not reflect recent changes to
     PDL and included files. The default is false.

  *  Csc_Numbering=Compressed|Dotted|None

     Specifies the format of automatically generated CSC numbers from the 2167
     static structure. In both cases, the CSC number is composed from the CSC
     number for the parent and the ordinal number of the given child.  The
     Dotted option places a period (.) between the parent and child numbers.
     The Compressed option inserts no intervening character. For example, CSCI
     5, TLCSC 2 is numbered as 52 when the Compressed option is specified.
     When the Dotted option is specified, the TLCSC is numbered as 5.2. None
     specifies that CSCs will not be numbered. The default is
     Csc_Numbering=Dotted. This option is valid only when the Build_Db option
     is true.

  *  Data_Tables=(Constants, Objects, Types)

     Specifies which declarations will be included in tables that describe data
     formats. The default is Data_Tables=(Objects). This option is valid only
     when the Build_Db option is true.

  *  Formatter_Options=(Rational Document Formatter options)

     Changes overall document characteristics, such as font or point size. The
     value of this argument is passed to the Options parameter of the Rational
     Document Formatter when the markup file is processed. See the
     documentation for the Rational Document Formatter for further details on
     the use of this parameter. The default, (), specifies no options.

  *  Device=Lineprinter|Postscript

     Specifies the form of output to the printer and is passed through to the
     Device parameter of the command that invokes the Rational Document
     Formatter when the markup file is processed. It should be noted that some
     camera-ready features are not supported in Lineprinter devices. It also
     should be noted that graphics cannot be printed with Lineprinter as the
     specified device. The default is Device=Postscript. Only one of these
     options can be specified.

  *  Input_Output_Tables=(Functional, Interface, Non_Requirement)

     Specifies which subprograms will be included in tables that describe
     component inputs and outputs. The default is
     Input_Output_Tables=(Functional,Interface). The Non_Requirement option
     specifies nonrequirement subprograms. This option is valid only when the
     Build_Db option is true.

  *  Interpretation=Rational|Strict

     Specifies the interpretation of DOD-STD-2167 to be used when generating
     documents. This option primarily affects table formats. The default is
     Interpretation=Rational. When Interpretation=Strict, the table formats
     used will match those found in the DIDs for DOD-STD-2167. This option is
     valid only when the Build_Db option is true.

  *  Paragraph_Header_Style=Rational|Italicize_Subparagraphs|
                                                     Underline_All

     Specifies the style of paragraph headings in the printed document. This
     option is valid only when the Device option specifies Postscript. The
     meaning of each choice for this option is described below:

     -  Rational: Paragraph headers will be produced in bold typeface with no
        special processing.

     -  Italicize_Subparagraphs: All paragraph headers with more than two
        digits (for example, 1.2.5 or 6.2.7 or 2.1.3.9) will be italicized.
        This option conforms to MIL-STD-490A, paragraph 3.2.5, for typeset
        documents.

     -  Underline_All: All paragraph headers, regardless of level, will be
        underlined. This option conforms to MIL-STD-490A, paragraph 3.2.5, for
        nontypeset documents.

  The default is Paragraph_Header_Style=Rational.

  Queue_Options=(Queue.Print options)

  Alters the characteristics of the printed document. The value of this option
  is passed to the Options parameter of Queue.Print when the document is
  printed. The default queues the document, as a PostScript document, to the
  laser printer specified in !Machine.Laser_Class or, if that class does not
  exist, to class LASER.

  To print the document on a line printer, you must change the Class option to
  specify the line printer. For example, if the name of the line printer is LP,
  you would specify Class=LP.

  For further information on Queue options, see package Queue, in the SMU book
  of the Rational Environment Reference Manual.

  Response : String := "<PROFILE>";

  Specifies how to respond to errors, how to generate logs, and which activity
  to use during execution of this command. The default is the job response
  profile.

  Restrictions

  The document database for the specified document must exist before the
  execution of this command, unless the Build_Db option is true.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  Executing the following command in a Command window prints the default
  document for the current CSCI. The document database is not regenerated.
  Thus, the document will be printed as it existed the last time the document
  database was generated:

   Design.Print (Document => "<DEFAULT>";
                 In_Csci_View => "<CURSOR>";
                 Options => "";
                 Response => "<PROFILE>");

  To regenerate the current CSCI's document database for the SRS (whether or
  not the design phase was currently Software_Requirements) and print it, you
  would execute the following command in a Command window:

   Design.Print (Document => "SRS";
                 In_Csci_View => "<CURSOR>";
                 Options => "build_db";
                 Response => "<PROFILE>");

  Assume that you are currently in the CSCI called Vehicle_Dynamics. You want
  to regenerate and print the STLDD on a line printer, whose class is LP, for
  the CSCI Cruise_Control. You do not know the design phase of Cruise_Control.
  To accomplish this, you enter:

   Design.Print (Document => "STLDD";
                 In_Csci_View =>
                            "!projects.vehicle_system.cruise_control";
                 Options => "build_db, queue_options=> (class=lp)";
                 Response => "<PROFILE>");

  If you want to print the current document for the current CSCI and regenerate
  the document database using other than default formats for data tables and
  CSC numbering, you would enter:

   Design.Print (Document => "<DEFAULT>";
                 In_Csci_View => "<CURSOR>";
                 Options => "build_db,csc_numbering=(compressed)," &
                                      "data_tables=(constants,types)";
                 Response => "<PROFILE>");

  References

  procedure Build

  procedure Generate_Markup

  procedure Preview

  Rational Document Formatter documentation

  procedure Queue.Print, SMU, Rational Environment Reference Manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Sddd

  Sddd : constant Document_Name := "SDDD";

  Description

  Defines a constant for the Software Detailed Design Document (SDDD).

  References

  constant Default

  subtype Document_Name

  constant Sddd

  constant Stldd

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Set_Parent

  procedure Set_Parent (Of_Component : String := "<CURSOR>";
                        To           : String := "";
                        Response     : String := "<PROFILE>");

  Description

  Sets or changes the parent relationship of the previously initialized
  specified design component.

  Parameters

  Of_Component : String := "<CURSOR>";

  Specifies the design component for which the parentage should be returned.
  The default, "<CURSOR>", specifies the design component on which the cursor
  is currently located.

  To : String := "";

  Specifies the name of the design component that is to be the parent of the
  specified design component. The default, the null string (""), specifies that
  the design component has no parent.

  Response : String := "<PROFILE>";

  Specifies how to respond to errors, how to generate logs, and which activity
  to use during execution of this command. The default is the job response
  profile.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  A CSCI called Cruise_Control is created, and its parent, Vehicle_System, is
  inadvertently unspecified. Assuming that Cruise_Control is defined in the
  current context, the Design.Set_Parent command can be executed to specify
  the necessary hierarchy, as shown below:

   Design.Set_Parent (Of_Component => "Cruise_Control";
                      To => "!projects.vehicle_system";
                      Response => "<PROFILE>");

  References

  procedure Display_Hierarchy

  procedure Initial

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Set_Phase

  procedure Set_Phase (To_Value     : String := ">>DESIGN PHASE<<";
                       In_Csci_View : String := "<CURSOR>");

  Description

  Changes or sets the design phase for the specified CSCI to the one specified
  in the To_Value parameter.

  This value is stored in the CSCI view's library switch file in the
  Design.Phase switch.

  Parameters

  To_Value : String := ">>DESIGN PHASE<<";

  Specifies the design phase to which the current CSCI will be set.  The
  possible values for this parameter are:

  *  Requirements_Analysis

  *  Preliminary_Design

  *  Detailed_Design

  *  Coding

  *  CSC_Integration

  *  CSCI_Test

  The default parameter placeholder, ">>DESIGN PHASE<<", must be replaced.

  In_Csci_View : String := "<CURSOR>";

  Specifies the CSCI for which the design target will be set.  The default,
  "<CURSOR>", specifies the current CSCI.  For further details, see "Naming in
  CSCI-Related Parameters," in the introduction to this package.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  If the user attempts to set the phase to a name that does not correspond to
  one of those in the 2167 DF, an error will result and an error message will
  be displayed.

  Examples

  The following example shows how the design target for the current CSCI (as
  determined by the current cursor location) can be set to Preliminary_Design:

   Design.Set_Phase (To_Value => "preliminary_design");

  The following display will appear in the Message window, confirming that the
  design phase has been changed:

   Design Phase set to PRELIMINARY_DESIGN

  References

  procedure Display_All_Phases

  procedure Display_Phase

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Set_Target

  procedure Set_Target (To_Value     : String := ">>DESIGN TARGET<<";
                        In_Csci_View : String := "<CURSOR>");

  Description

  Sets or resets the registered design target for the specified CSCI to that
  specified in the To_Value parameter.

  Parameters

  To_Value : String := ">>DESIGN TARGET<<";

  Specifies the name of the design target reistered with a CSCI. The name of
  the design target for 2167 DF is RATIONAL_2167_R1000. The default parameter
  placeholder, ">>DESIGN TARGET<<", must be replaced.

  In_Csci_View : String := "<CURSOR>";

  Specifies the CSCI for which the design target will be set. The default,
  "<CURSOR>", specifies the current CSCI.  For further details, see "Naming in
  CSCI-Related Parameters," in the introduction to this package.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  Examples

  The following example shows how the design target for the current CSCI can be
  set to RATIONAL_2167_R1000:

   Design.Set_Target (To_Value => "RATIONAL_2167_R1000",
                      In_Csci_View => "<CURSOR>");

  The following display appears in the Message window to confirm that the
  design target has been set:

   Design Target set to RATIONAL_2167_R1000

  To set the design target to RATIONAL_2167_M1750A_BARE, you would enter:

   Design.Set_Target (To_Value => "RATIONAL_2167_M1750A_BARE",
                      In_Csci_View => "<CURSOR>");

  The following display appears in the Message window to confirm that the
  design target has been set:

   Design Target set to RATIONAL_2167_M1750A_BARE

  References

  procedure Create_Model

  procedure Display_All_Targets

  procedure Display_Target

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Show_Usage

  procedure Show_Usage (In_Csci_View : String := "<CURSOR>");

  Description

  Traverses to all using occurrences, when executed on a requirement-related
  annotation in PDL; in documents, the command traverses between the document
  and PDL or other documents related to a given requirement.

  Requirement-related annotations are:

  *  @FUNCTIONS_DEFINED

  *  @INTERFACES_DEFINED

  *  @REQUIREMENT FUNCTION

  *  @REQUIREMENT SUBFUNCTION

  *  @REQUIREMENT INTERFACE

  Parameters

  In_Csci_View : String := "<CURSOR>";

  Specifies the name of the CSCI. The default, "<CURSOR>", specifies the
  current CSCI.  For further details, see "Naming in CSCI-Related Parameters,"
  in the introduction to this package.

  Restrictions

  When this command is executed in a CSCI for which no design target is
  registered, an error results and an error message is displayed in the Message
  window.

  Errors

  If this command is executed in a Rational System or Subsystem for which no
  2167 DF design target is specified, an error results and an error message is
  displayed.

  References

  procedure Ada.Show_Usage, EST, Rational Environment Reference Manual

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Srs

  Srs : constant Document_Name := "SRS";

  Description

  Defines a constant for the System Requirements Specification (SRS) document.

  References

  constant Default

  subtype Document_Name

  constant Idd

  constant Irs

  constant Srs

  constant Stldd

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Stldd

  Stldd : constant Document_Name := "STLDD";

  Description

  Defines a constant for the Software Top-Level Design Document (STLDD).

  References

  constant Default

  subtype Document_Name

  constant Idd

  constant Irs

  constant Sddd

  constant Srs

  constant Unknown

  @node !Tools.Design.Release.Rational_2167.Pdl_Commands.Revn.Units.Design.Unknown

  Unknown : constant Document_Name := "<UNKNOWN>";

  Description

  Specifies a constant for an unknown document type.

  This document type results when the design phase for a CSCI registered with
  the 2167 DF is not one of the following:

  *  Requirements_Analysis

  *  Preliminary_Design

  *  Detailed_Design

  *  Coding

  *  CSC_Integration

  *  CSCI_Test

  References

  constant Default

  subtype Document_Name

  constant Idd

  constant Irs

  constant Sddd

  constant Srs

  constant Stldd

  @node PDL

  This section of the Reference Entries book contains reference materials for
  Rational's PDL, including design phases, design rules, and 2167 DF
  annotations.

  DESIGN PHASES

  The 2167 DF supports the design phases described in DOD-STD-2167. The names
  for the design phases, abbreviated for entry as arguments to commands, are:

  *  Requirements_Analysis

  *  Preliminary_Design

  *  Detailed_Design

  *  Coding

  *  Csc_Integration

  *  Csci_Test

  For information on the activities to be performed in each of these phases,
  see DOD-STD-2167, Appendix B.

  DESIGN RULES

  To enforce project standards, the 2167 DF provides the following design
  rules:

  *  The following declarations and statements are not allowed at any design
     phase:

     -  Goto statements

     -  Anonymous type declarations

     -  Use clauses

  *  The following PDL elements are permitted only after the
     Requirements_Analysis phase:

     -  Ada library unit bodies

     -  Private types completed with anything except (TBD)

     -  Representation clauses

     -  Task declarations

  *  The following PDL element is permitted only after the Preliminary_Design
     phase:

     -  Bodies with nonempty statement lists

  *  The following are permitted only after the Detailed_Design phase:

     -  Promotion of design components to the coded state (if the capability
        for prototyping is required, a subpath can be created off the current
        design path and the design phase for the subpath can be set to the
        Coding or later phase, without affecting the main design path)

     -  Pragma Elaborate

  Most of these design rules are straightforward; however, some may be made
  clearer in the following examples.

  Anonymous Type Declarations

  The following Object declaration references a full type declaration of the
  type Integer.

   X : Integer;

  In contrast, the Object declaration below is a constrained type declaration
  that causes the creation of an anonymous subtype.  As stated in paragraph
  3.3.1[5] of ANSI/MIL-STD-1851A: "A type is said to be anonymous if it has no
  simple name." Thus, this declaration is an anonymous type and is not
  permitted by the 2167 DF.

   X : Integer range 1 .. 10;

  To correctly create this Object declaration, the following would be used:

   subtype Small_Integer is Integer range 1 .. 10;
   X : Small_Integer;

  Private Type Completion

  In the Requirements_Analysis phase, completing private types with anything
  except (TBD) is prohibited. TBD specifies that the completion of the private
  type has yet to be determined.  For example, the private part shown in the
  following example is not legal in the Requirements_Analysis phase because
  the type has been completed-in this case as a new Integer:

       ...
   private
       type The_Integer is new Integer;
       ...

  Similarly, the private part in the following example is not legal because the
  [expression] prompt is not a legal Ada construct:

       ...
   private
       type The_Integer is new [expression];
       ...

  The private part shown below is legal because the private part has been
  specified as "to be determined" (Tbd) at a later time:

       ...
   private
       type The_Integer is (Tbd);
       ...

  ANNOTATIONS

  This section describes the keyword annotations available for the 2167 DF.
  The reference entries for annotations show first the keyword and then the
  prompt for the argument(s) required for the annotation.  For example, in the
  reference entry for the @ABBREVIATION annotation, the entry

   @ABBREVIATION [Abbreviated Component Name]

  is shown. The notation [Abbreviated Component Name] is the prompt that
  appears for the annotation when it is added to a PDL element by the
  Design.Complete command or when you enter the keyword and execute the
  Design.Format command.

  Annotations are provided by the 2167 DF for two reasons. The first is that
  their appearance in a design component causes some information to be included
  in the documents generated by the 2167 DF. The annotations that perform this
  function are used in conjunction with PDL elements (design components,
  requirements, data, and interrupts). The annotations required depend on the
  PDL element being annotated and the current design phase.  Additionally,
  certain annotations are permitted, but not required, on PDL elements at
  each design phase.

  Alternatively, certain annotations are provided to allow commenting of PDL in
  the same format as the other annotations provided by the 2167 DF.  These
  annotations do not provide input to the documents generated by the 2167 DF,
  and they are grouped into the Miscellaneous category, discussed later.

  For a conceptual overview of annotations, see the Key Concepts book in this
  manual.

  Design Components

  All DOD-STD-2167 design components require annotations. The following tables
  show the required annotations and the phases in which they are required.
                             
                             System Design Component

                        ------------------------------- 
                       |               |               |
                       |  Annotation   |    Phases     |
                        ------------------------------- 
                       |               |               |
                       |@ABBREVIATION  |Required all   |
                       |               |phases         |
                        ------------------------------- 
                       |               |               |
                       |@COMPONENT_KIND|Required all   |
                       |               |phases         |
                        ------------------------------- 
                       |               |               |
                       |@ID            |Required all   |
                       |               |phases         |
                        ------------------------------- 
                       |               |               |
                       |@PURPOSE       |Required all   |
                       |               |phases         |
                        ------------------------------- 

                            Segment Design Component

                        ------------------------------- 
                       |               |               |
                       |  Annotation   |    Phases     |
                        ------------------------------- 
                       |               |               |
                       |@ABBREVIATION  |Required all   |
                       |               |phases         |
                        ------------------------------- 
                       |               |               |
                       |@COMPONENT_KIND|Required all   |
                       |               |phases         |
                        ------------------------------- 
                       |               |               |
                       |@ID            |Required all   |
                       |               |phases         |
                        ------------------------------- 
                       |               |               |
                       |@PURPOSE       |Required all   |
                       |               |phases         |
                        ------------------------------- 

                              CSCI Design Component

              -------------------------------------------------- 
             |                 |                                |
             |   Annotation    |             Phases             |
              -------------------------------------------------- 
             |                 |                                |
             |@ABBREVIATION    |Required all phases             |
              -------------------------------------------------- 
             |                 |                                |
             |@CDRL            |Required all phases             |
              -------------------------------------------------- 
             |                 |                                |
             |@COMPONENT_KIND  |Required all phases             |
              -------------------------------------------------- 
             |                 |                                |
             |@DECOMPOSITION   |Required all phases after       |
             |                 |Requirements_Analysis           |
              -------------------------------------------------- 
             |                 |                                |
             |@DOCUMENT_NUMBERS|Required all phases             |
              -------------------------------------------------- 
             |                 |                                |
             |@FUNCTIONS_DEFINE|Required all phases             |
             |D                |                                |
              -------------------------------------------------- 
             |                 |                                |
             |@ID              |Required all phases             |
              -------------------------------------------------- 
             |                 |                                |
             |@INTERFACES_DEFIN|Required all phases             |
             |ED               |                                |
              -------------------------------------------------- 
             |                 |                                |
             |@INTERFACES_USED |Required all phases             |
              -------------------------------------------------- 
             |                 |                                |
             |@PURPOSE         |Required all phases             |
              -------------------------------------------------- 

                              HWCI Design Component

                        ------------------------------- 
                       |                 |             |
                       |   Annotation    |   Phases    |
                        ------------------------------- 
                       |                 |             |
                       |@ABBREVIATION    |Required all |
                       |                 |phases       |
                        ------------------------------- 
                       |                 |             |
                       |@COMPONENT_KIND  |Required all |
                       |                 |phases       |
                        ------------------------------- 
                       |                 |             |
                       |@ID              |Required all |
                       |                 |phases       |
                        ------------------------------- 
                       |                 |             |
                       |@INTERFACES_DEFIN|Required all |
                       |ED               |phases       |
                        ------------------------------- 
                       |                 |             |
                       |@PURPOSE         |Required all |
                       |                 |phases       |
                        ------------------------------- 

                             TLCSC Design Component

                  ------------------------------------------- 
                 |            |                              |
                 | Annotation |            Phases            |
                  ------------------------------------------- 
                 |            |                              |
                 |@ALGORITHM  |Required all phases after     |
                 |            |Requirements_Analysis         |
                  ------------------------------------------- 
                 |            |                              |
                 |@COMPONENT_K|Required all phases           |
                 |IND         |                              |
                  ------------------------------------------- 
                 |            |                              |
                 |@DECOMPOSITI|Required all phases after     |
                 |ON          |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@MEMORY     |Required all phases           |
                  ------------------------------------------- 
                 |            |                              |
                 |@PROCESSING |Required all phases after     |
                 |            |Requirements_Analysis         |
                  ------------------------------------------- 
                 |            |                              |
                 |@PURPOSE    |Required all phases           |
                  ------------------------------------------- 
                 |            |                              |
                 |@SEQUENCING |Required all phases after     |
                 |            |Requirements_Analysis         |
                  ------------------------------------------- 
                 |            |                              |
                 |@TIME       |Required all phases           |
                  ------------------------------------------- 

                             LLCSC Design Component

                  ------------------------------------------- 
                 |            |                              |
                 | Annotation |            Phases            |
                  ------------------------------------------- 
                 |            |                              |
                 |@ALGORITHM  |Required all phases after     |
                 |            |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@COMPONENT_K|Required all phases           |
                 |IND         |                              |
                  ------------------------------------------- 
                 |            |                              |
                 |@DECOMPOSITI|Required all phases after     |
                 |ON          |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@LIMITATIONS|Required all phases after     |
                 |            |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@MEMORY     |Required all phases           |
                  ------------------------------------------- 
                 |            |                              |
                 |@PROCESSING |Required all phases after     |
                 |            |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@PURPOSE    |Required all phases           |
                  ------------------------------------------- 
                 |            |                              |
                 |@TIME       |Required all phases           |
                  ------------------------------------------- 
                 |            |                              |
                 |@UTILIZATION|Required all phases after     |
                 |            |Detailed_Design               |
                  ------------------------------------------- 

                              Unit Design Component

                  ------------------------------------------- 
                 |            |                              |
                 | Annotation |            Phases            |
                  ------------------------------------------- 
                 |            |                              |
                 |@ALGORITHM  |Required all phases after     |
                 |            |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@COMPONENT_K|Required all phases           |
                 |IND         |                              |
                  ------------------------------------------- 
                 |            |                              |
                 |@LIMITATIONS|Required all phases after     |
                 |            |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@MEMORY     |Required all phases           |
                  ------------------------------------------- 
                 |            |                              |
                 |@PROCESSING |Required all phases after     |
                 |            |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@PURPOSE    |Required all phases           |
                  ------------------------------------------- 
                 |            |                              |
                 |@TIME       |Required all phases           |
                  ------------------------------------------- 
                 |            |                              |
                 |@UTILIZATION|Required all phases after     |
                 |            |Detailed_Design               |
                  ------------------------------------------- 

                              TBD Design Component

                           ------------------------- 
                          |            |            |
                          | Annotation |   Phases   |
                           ------------------------- 
                          |            |            |
                          |@COMPONENT_K|Required all|
                          |IND         |phases      |
                           ------------------------- 

  REQUIREMENTS

  DOD-STD-2167 specifies that there are three kinds of requirements: Interface,
  Functional and Subfunctional.  The annotations required for each are
  specified below.

  Functional and Subfunctional Requirements

  Functional and subfunctional requirements are mapped to subprogram
  declarations and task entries.  When the annotation @REQUIREMENT is used, the
  rest of the annotations shown in the following table are required.
  
                    Functional and Subfunctional Requirements

                   ----------------------------------------- 
                  |          |                              |
                  |Annotation|            Phases            |
                   ----------------------------------------- 
                  |          |                              |
                  |@DESCRIPTI|Required all phases on        |
                  |ON        |subprogram or task entry      |
                   ----------------------------------------- 
                  |          |                              |
                  |@DESTINATI|Required all phases           |
                  |ON        |                              |
                   ----------------------------------------- 
                  |          |                              |
                  |@PROCESSIN|Required all phases           |
                  |G         |                              |
                   ----------------------------------------- 
                  |          |                              |
                  |@PURPOSE  |Required all phases           |
                   ----------------------------------------- 
                  |          |                              |
                  |@REQUIREME|Required all phases           |
                  |NT        |                              |
                   ----------------------------------------- 
                  |          |                              |
                  |@SOURCE   |Required all phases           |
                   ----------------------------------------- 

  Interface Requirements

  Interface requirements are mapped to subprogram declarations and task
  entries. When the annotation @REQUIREMENT is used, the rest of the
  annotations shown in the following table are required.
                              
                              Interface Requirement

                            ----------------------- 
                           |          |            |
                           |Annotation|   Phases   |
                            ----------------------- 
                           |          |            |
                           |@INITIATIO|Required all|
                           |N         |phases      |
                            ----------------------- 
                           |          |            |
                           |@PURPOSE  |Required all|
                           |          |phases      |
                            ----------------------- 
                           |          |            |
                           |@REQUIREME|Required all|
                           |NT        |phases      |
                            ----------------------- 
                           |          |            |
                           |@RESPONSE |Required all|
                           |          |phases      |
                            ----------------------- 

  GLOBAL AND LOCAL DATA

  Data-related information is first mentioned in the DIDs for DOD-STD-2167
  during the Preliminary_Design phases (STLDD). Annotations for global and
  local data are not required. However, the @DATABASE_STRUCTURE and
  @FILE_STRUCTURE annotations are required to indicate that a data element is a
  database object or a file object.
                                      Files

                  ------------------------------------------- 
                 |            |                              |
                 | Annotation |            Phases            |
                  ------------------------------------------- 
                 |            |                              |
                 |@FILE_STRUCT|Required all phases after     |
                 |URE         |Preliminary_Design            |
                  ------------------------------------------- 
                 |            |                              |
                 |@PURPOSE    |Required all phases after     |
                 |            |Preliminary_Design            |
                  ------------------------------------------- 

                                    Databases

                ----------------------------------------------- 
               |                |                              |
               |   Annotation   |            Phases            |
                ----------------------------------------------- 
               |                |                              |
               |@DATABASE_STRUCT|Required all phases after     |
               |URE             |Preliminary_Design            |
                ----------------------------------------------- 
               |                |                              |
               |@PURPOSE        |Required all phases after     |
               |                |Preliminary_Design            |
                ----------------------------------------------- 

  INTERRUPTS

  Interrupts are first discussed in the DOD-STD-2167 DIDs during
  Preliminary_Design (STLDD).  Interrupts are not required; if they are used,
  the documented interrupts must contain the following annotations:
                                   
                                   Interrupts

                   ----------------------------------------- 
                  |          |                              |
                  |Annotation|            Phases            |
                   ----------------------------------------- 
                  |          |                              |
                  |@FREQUENCY|Required all phases after     |
                  |          |Requirements_Analysis         |
                   ----------------------------------------- 
                  |          |                              |
                  |@PRIORITY |Required all phases after     |
                  |          |Requirements_Analysis         |
                   ----------------------------------------- 
                  |          |                              |
                  |@PURPOSE  |Required all phases after     |
                  |          |Requirements_Analysis         |
                   ----------------------------------------- 
                  |          |                              |
                  |@RESPONSE |Required all phases after     |
                  |          |Requirements_Analysis         |
                   ----------------------------------------- 
                  |          |                              |
                  |@SOURCE   |Required all phases after     |
                  |          |Requirements_Analysis         |
                   ----------------------------------------- 

  MISCELLANEOUS ANNOTATIONS

  Finally, there set of annotations that are not required in any design
  component at any design phase. The information supplied as arguments to these
  annotations, if any, does not appear in documents.  The annotations are used
  for commenting the PDL or code, in the same annotation form as the other
  annotations provided by the 2167 DF, for others who may be looking at the
  design or code.  The miscellaneous annotations include:

  *  @ASSERT

  *  @CONCURRENCY

  *  @CRITICAL

  *  @ERRORS

  *  @NOTE

  *  @SIDE_EFFECT

  @node @ABBREVIATION

  @ABBREVIATION [Abbreviated Name]

  Description

  Specifies the abbreviation for the PDL element to which it is attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [Abbreviated Name]

  Requires a simple name argument.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on System, Segment, CSCI, HWCI

  *  Preliminary Design - Required on System, Segment, CSCI, HWCI

  *  Detailed Design and later phases - Required on System, Segment, CSCI, HWCI

  Examples

  The following example illustrates how the @ABBREVIATION annotation is used in
  the Cruise_Control CSCI to indicate that its abbreviation is CC. The ellipsis
  (...) between an annotation and a PDL element indicates annotations, also
  required for the PDL elements to which they are attached, that are not shown.
  The ellipsis after a PDL element indicates that additional PDL has been
  omitted.

   --| @COMPONENT_KIND CSCI
       ...
   --| @ABBREVIATION CC
       ...
   package Cruise_Control is
       ...

  @node @ALGORITHM

  @ALGORITHM [TEXT]

  Description

  Describes the algorithm used in a design component.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Preliminary Design - Required on TLCSC

  *  Detailed Design and later phases - Required on TLCSC, LLCSC, Unit

  Examples

  The following annotation in a Unit design component describes the algorithm
  used. The ellipsis (...) between an annotation and a PDL element indicates
  annotations, also required for the PDL elements to which they are attached,
  that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

   --| @COMPONENT_KIND UNIT
       ...
      --| @ALGORITHM The Feynman half step method is used on
      --| initialization so that on subsequent iterations we are
      --| using velocities half way through the proposed step instead
      --| of the velocities at the beginning of the step.  This greatly
      --| improves the accuracy of the approximation.
          ...

  @node @APPLICABLE_INTERFACES

  @APPLICABLE_INTERFACES ([Interface Name List])

  Description

  Indicates the interfaces that are applicable to (associated with) the PDL
  element to which this annotation is attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([Interface Name List])

  Requires a list argument. Each list element must specify the name of an
  interface defined in the current CSCI.

  Examples

  The following example illustrates how the @APPLICABLE_INTERFACES annotation
  is used on a functional requirement to indicate the interfaces associated
  with it:

   --| @REQUIREMENT FUNCTION Process_Packets
   --| @APPLICABLE_INTERFACES (Get_Packet, Put_Packet)
       ...
   procedure Packet_Processing ...

  The following example illustrates how the @APPLICABLE_INTERFACES annotation
  is used on a subfunctional requirement:

   --| @REQUIREMENT SUBFUNCTION Process_Packets.Queue
   --| @APPLICABLE_INTERFACES (Get_Packet)
       ...
   procedure Packet_Queue ...

  @node @ASSERT

  @ASSERT [TEXT]

  Description

  Makes an assertion about the PDL element to which it is attached that must be
  true in all cases in which the PDL element is used.

  This annotation is not required on any PDL element at any design phase.
  Typically, this annotation is used during Coding and later phases.

  Arguments

  [TEXT]

  Requires a text argument.

  Examples

  The following shows the use of the @ASSERT annotation in a loop.  The
  ellipsis (...) between an annotation and a PDL element indicates annotations,
  also required for the PDL elements to which they are attached, that are not
  shown. The ellipsis after a PDL element indicates that additional PDL has
  been omitted.

       ...
   --| @ASSERT This loop is executed at least once.
   loop
       ...
   exit when Done;
   end loop;
       ...

  @node @CDRL

  @CDRL ([Document Name] => ([Data Item List]))

  Description

  Specifies the Contracts Data Requirement List (CDRL) number for each
  document.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([Document Name] => ([Data Item List]))

  Requires a list argument. Each list element specifies a document name: SRS,
  STLDD, SDDD, IDD, or IRS.  The document name is to be followed by the =>
  symbol and the CDRL number for the document. List elements are separated by
  commas or new lines. The argument NONE can be used to specify that no CDRL
  numbers are specified.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on CSCI

  *  Preliminary Design - Required on CSCI

  *  Detailed Design and later phases - Required on CSCI

  Examples

  The following example illustrates the use of the @CDRL annotation in a CSCI
  design component. The ellipsis (...) between an annotation and a PDL element
  indicates annotations, also required for the PDL elements to which they are
  attached, that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

   --| @COMPONENT_KIND CSCI
       ...
   --| @CDRL (SRS   => DN4,
   --|        STLDD => DN5,
   --|        SDDD  => DN6)
       ...

  The following example shows the @CDRL annotation used when the IRS and IDD
  are generated separately from the SRS and SDDD:

   --| @COMPONENT_KIND CSCI
       ...
   --| @CDRL (SRS   => DN4,
   --|        IRS   => (AN3,AN4,AN5),
   --|        STLDD => DN5,
   --|        SDDD  => DN6,
   --|        IDD   => (AN6,AN7,AN8))
       ...

  @node @COMPONENT_KIND

  @COMPONENT_KIND [2167 Component]

  Description

  Specifies the design component kind of the current design component in the
  DOD-STD-2167 static structure.

  This information is important in documentation generation and analysis.  The
  design components are System, Segment, CSCI, HWCI, TLCSC, LLCSC, Unit, and
  TBD (to be determined).  The TBD annotation is used when a design component
  is being added that typically would not be designed at the current design
  phase.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [2167 Component]

  Requires one of the following arguments:

  *  System

  *  Segment

  *  CSCI

  *  HWCI

  *  TLCSC

  *  LLCSC

  *  Unit

  *  TBD

  Phase Name - Element(s)

  *  Requirements Analysis - Required on System, Segment, CSCI, HWCI

  *  Preliminary Design - Required on System, Segment, CSCI, HWCI, TLCSC

  *  Detailed Design and later phases - Required on System, Segment, CSCI,
     HWCI, TLCSC, LLCSC, Unit

  Examples

  The following example illustrates how the @COMPONENT_KIND annotation can be
  used to specify that the design component in which it appears is a TLCSC. The
  ellipsis (...) between an annotation and a PDL element indicates annotations,
  also required for the PDL elements to which they are attached, that are not
  shown. The ellipsis after a PDL element indicates that additional PDL has
  been omitted.

   --| @COMPONENT_KIND TLCSC
       ...
   package Throttle_Data is
       ...

  @node @CONCURRENCY

  @CONCURRENCY [TEXT]

  Description

  Describes concurrency relationships of the PDL element to which it is
  attached.

  This annotation is not required on any PDL element during any design phase.
  Typically, it is used in the Coding phase to describe the concurrency
  characteristics of the PDL element to which it is attached.

  Arguments

  [TEXT]

  Requires a text argument.

  Examples

  The following example illustrates how concurrency issues might need to be
  described for a stack package. The ellipsis (...) between an annotation and a
  PDL element indicates annotations, also required for the PDL elements to
  which they are attached, that are not shown. The ellipsis after a PDL element
  indicates that additional PDL has been omitted.

       ...
   --| @CONCURRENCY This package is not protected against concurrent
   --| access.  Calls to Push and Pop must be done serially.
   --| Concurrent calls to Push and Pop cause undefined results.
   package Stack is
       type Element is ...
       procedure Push (Item : in Element);
       procedure Pop (Item : out Element);
       function Is_Empty return Boolean;
   end Stack;

  @node @CRITICAL

  @CRITICAL

  Description

  Specifies that the PDL element to which it is attached is critical, as
  defined by DOD-STD-480A, Appendix E, paragraph 110.15.

  This annotation is not required for any PDL element at any design phase.  It
  typically is used in early design phases to identify CSCs that may be
  designed in greater detail than might be expected for that design phase.
  Use of this annotation does not affect enforcement of design rules.

  Arguments

  This annotation has no argument.

  Examples

  Assume that the design phase is Software Requirements Analysis, in which an
  LLCSC normally has not been designed. The following example illustrates the
  use of the @CRITICAL annotation to specify that a design component, normally
  not designed until a later phase, is being designed at the current phase
  because it is critical to the design.  The ellipsis (...) between an
  annotation and a PDL element indicates annotations, also required for the PDL
  elements to which they are attached, that are not shown. The ellipsis after a
  PDL element indicates that additional PDL has been omitted.

   --| @COMPONENT_KIND TBD
       ...
   --| @CRITICAL
       ...
   package Emergency is
   ...

  @node @DATABASE_STRUCTURE

  @DATABASE_STRUCTURE [TEXT]
                                                                                                                         
  Description

  Specifies that the item to which it is attached is a database structure.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on database objects

  *  Preliminary Design - Required on database objects

  *  Detailed Design and later phases - Required on database objects

  Examples

  The following example illustrates the use of the @DATABASE_STRUCTURE
  annotation on data. The ellipsis (...) between an annotation and a PDL
  element indicates annotations, also required for the PDL elements to which
  they are attached, that are not shown. The ellipsis after a PDL element
  indicates that additional PDL has been omitted.

       ...
   --| @DATABASE_STRUCTURE
   --|     This database is organized in 1024 byte blocks of 8 records
   --|     each.  Each record is a fixed size of 128 bytes and may be
   --|     accessed sequentially or randomly accessed using the
   --|     Employee_Id key.
   --|
   --| @PURPOSE
   --|     This database maintains the employee data collected for the
   --|     current payroll period.  This database is updated on a
   --|     weekly basis as new payroll information is made available
   --|     to the accounting department.
   --|
   Employee_Records : Employee_Database_File;
       ...

  @node @DECOMPOSITION

  @DECOMPOSITION ([Component Name List])

  Description

  Specifies the design components contained by the design component to which
  the annotation is attached.

  For example, TLCSCs may contain LLCSCs and Units.  The @DECOMPOSITION
  annotation defines the static hierarchy of the design.  The order in which
  the design components are specified in the argument is the order in which
  they will appear in the documents generated by the 2167 DF.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([Component Name List])

  Requires a list of simple names, where the names correspond to the list of
  PDL components contained by the current design component.  Names must be
  separated by commas or new lines.  Naming will be resolved as described in
  package Design.

  *  Preliminary Design - Required on CSCI

  *  Detailed Design and later phases - Required on CSCI, TLCSC, LLCSC

  Examples

  The following example illustrates the use of the @DECOMPOSITION annotation in
  a TLCSC. The ellipsis (...) between an annotation and a PDL element indicates
  annotations, also required for the PDL elements to which they are attached,
  that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

   --| @COMPONENT_KIND TLCSC
       ...
   --| @DECOMPOSITION (Computation_Procedures, Math_Library)
       ...
   package Orbit is
       ...

  This annotation, located in the Orbit TLCSC, indicates that the TLCSC
  contains the two library unit-level LLCSCs: Computation_Procedures and
  Math_Library.

  The following shows an example of a nested TLCSC and LLCSC:

   --| @COMPONENT_KIND CSCI
       ...
   --| @DECOMPOSITION (Object_Operations)
   package Nested_Example is
       --| @COMPONENT_KIND TLCSC
           ...
       --| @DECOMPOSITION
       --|  (Robot_Operations)
       package Object_Operations is
           --| @COMPONENT_KIND LLCSC
               ...
           package Robot_Operations is
           ...
           end Robot_Operations;
      end Object_Operations;
   end Nested_Example;

  @node @DESCRIPTION

  @DESCRIPTION [TEXT]

  Description

  Adds descriptive information to the PDL element to which it is attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Requirements

  *  Preliminary Design - Required on Requirements

  *  Detailed Design and later phases - Required on Requirements

  Examples

  The following example illustrates the use of the @DESCRIPTION annotation on a
  requirement to provide additional information about that requirement.  The
  ellipsis (...) between an annotation and a PDL element indicates annotations,
  also required for the PDL elements to which they are attached, that are not
  shown. The ellipsis after a PDL element indicates that additional PDL has
  been omitted.

   --| @REQUIREMENT INTERFACE Communicate
       ...
   --| @DESCRIPTION
   --|     This interface provides the primary mechanism of
   --|     communication between the Master and Slave CSCIs.
       ...
   procedure Communicate;
       ...

  @node @DESTINATION

  @DESTINATION [TEXT]

  Description

  Describes the receiver of output data; pertinent to in out and out parameters
  for functional and subfunctional requirements.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required for Functional and Subfunctional
     Requirements

  *  Preliminary Design - Required for Functional and Subfunctional
     Requirements

  *  Detailed Design and later phases - Required for Functional and
     Subfunctional
     Requirements

  Examples

  The following example shows how the @DESTINATION annotation can be used. The
  ellipsis (...) between an annotation and a PDL element indicates annotations,
  also required for the PDL elements to which they are attached, that are not
  shown. The ellipsis after a PDL element indicates that additional PDL has
  been omitted.

       ...
   --| @DESTINATION Querying client
       ...
   procedure Locate (The_Item  : in String;
                     In_String : in String;
                     The_Value : out Integer);
       ...

  @node @DOCUMENT_NUMBERS

  @DOCUMENT_NUMBERS ([Document Name] =>
                                       ([Document Control Number List]))

  Description

  Specifies the mapping between documents and their document control numbers.

  Arguments

  ([Document Name] => ([Document Control Number List]))

  Requires a list argument.  Each list element must specify a document name:
  SRS, STLDD, SDDD, IRS, or IDD.  Each document name must be followed by the =>
  symbol and the document control number(s) for that document name.  List
  elements must be separated by commas or new lines.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on CSCI

  *  Preliminary Design - Required on CSCI

  *  Detailed Design and later phases - Required on CSCI

  Examples

  The following example illustrates the use of the @DOCUMENT_NUMBERS annotation
  in the Computation CSCI to specify the relationship between documents and
  their related document control numbers. The ellipsis (...) between an
  annotation and a PDL element indicates annotations, also required for the PDL
  elements to which they are attached, that are not shown. The ellipsis after a
  PDL element indicates that additional PDL has been omitted.

   --| @COMPONENT_KIND CSCI
       ...
   --| @DOCUMENT_NUMBERS (SRS =>   (GJD-091-43B),
   --|                    STLDD => (GJD-092-43B),
   --|                    SDDD =>  (GJD-094-43B))
       ...
   package Computation is
    ...

  The following example shows how the IRS and the IDD are specified to be
  separate documents using the @DOCUMENT_NUMBERS annotation.  The number of
  IRSs and IDDs specified must be the same.  For further information on the
  separation of the IRS and the IDD, see the Key Concepts book in this manual.

   --| @COMPONENT_KIND CSCI
       ...
   --| @DOCUMENT_NUMBERS (IRS   => (GJD-091-44B,
   --|                              GJD-091-45B,
   --|                              GJD-091-46B),
   --|                    SRS   => (GJD-091-43B),
   --|                    STLDD => (GJD-092-43B),
   --|                    IDD   => (GJD-092-44B,
   --|                              GJD-092-45B,
   --|                              GJD-092-46B),
   --|                    SDDD  => (GJD-094-43B))
       ...
   package Computation is
       ...

  @node @ERRORS

  @ERRORS [TEXT]

  Description

  Specifies expected error conditions for the PDL element to which this
  annotation is attached.

  This annotation is not required on any PDL element. Typically, it is used as
  a communication mechanism between developers to describe any known error
  conditions.

  Arguments

  [TEXT]

  Requires a text argument.

  Examples

  The following example illustrates the @ERRORS annotation. The ellipsis (...)
  between an annotation and a PDL element indicates annotations, also required
  for the PDL elements to which they are attached, that are not shown. The
  ellipsis after a PDL element indicates that additional PDL has been omitted.

   type Device is ...
   type Device_Contents is ...
   ...
   --| @ERRORS The null string is returned when the Object
   --| name cannot be resolved.  This may have undesired results.
   ...
   procedure Resolve (The_Name : in Name;
                      The_Resolution : out Full_Name);
   ...

  @node @FILE_STRUCTURE

  @FILE_STRUCTURE [TEXT]

  Description

  Specifies that the item to which it is attached is a file structure and
  supplies details about the structure of the file.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument. The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on File objects

  *  Preliminary Design - Required on File objects

  *  Detailed Design and later phases - Required on File objects

  Examples

  The following example illustrates the use of the @FILE_STRUCTURE annotation
  on some data. The ellipsis (...) between an annotation and a PDL element
  indicates annotations, also required for the PDL elements to which they are
  attached, that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

       ...
   --| @FILE_STRUCTURE
   --|     This file is organized in 1024 byte blocks of 8 records
   --|     each.  Each record is a fixed size of 128 bytes and
   --|     may be accessed sequentially or randomly accessed using
   --|     (Block_Id, Record_Offset) pairs.
   --|
   --| @PURPOSE
   --|     This file maintains the employee data collected for
   --|     the current payroll period.  This file is updated on
   --|     a weekly basis as new payroll information is made
   --|     available to the accounting department.
   Employee_Records : Employee_Record_File;
       ...

  @node @FREQUENCY

  @FREQUENCY [TEXT]

  Description

  Describes the frequency with which the PDL element, to which this annotation
  is attached, is accessed or called.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  This argument is usually specified in hertz (Hz).
  The text that appears as the argument for this annotation will appear,
  exactly as it does here, in the documents generated by the 2167 DF.

  Phase Name - Element(s)

  *  Preliminary Design - Required on Interrupts

  *  Detailed Design and later phases - Required on Interrupts

  Examples

  The following annotation is attached to an interrupt to specify that its
  frequency is 4 hertz:

       ...
   --| @FREQUENCY 4 Hz
       ...
   procedure Database_Update (New_Data : Db_Record);

  @node @FUNCTIONS_DEFINED

  @FUNCTIONS_DEFINED ([Function Name] => ([Subfunction Name List]))

  Description

  Specifies functions or subfunctions defined in the CSCI that will be
  allocated to lower-level design components.

  The order in which the functions appear in the annotation is the order in
  which they will appear in the documents.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([Function Name] => ([Subfunction Name List]))

  Requires a list argument.  Each list element must specify a function name,
  followed by the => symbol and the names of the subfunctions into which it has
  been decomposed.  Decomposition into subfunctions is optional.  Each list
  element must be separated by commas or new lines.  Alternatively, the word
  NONE can be specified to indicate that no functions or subfunctions are
  defined in the CSCI.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on CSCI

  *  Preliminary Design - Required on CSCI

  *  Detailed Design and later phases - Required on CSCI

  Examples

  The following annotation in a CSCI design component specifies that six
  functions are defined in that design component. The last function defined has
  been decomposed into subfunctions. The ellipsis (...) between an annotation
  and a PDL element indicates annotations, also required for the PDL elements
  to which they are attached, that are not shown. The ellipsis after a PDL
  element indicates that additional PDL has been omitted.

   --| @COMPONENT_KIND CSCI
       ...
   --| @FUNCTIONS_DEFINED (CURRENT_SPEED, CURRENT_DIRECTION,
   --|                     CURRENT_THROTTLE, CURRENT_RANGE,
   --|                     CURRENT_LOCATION,
   --|                     CURRENT_DESTINATION => (COORDINATES,
                           ESTIMATED_TIME_OF_ARRIVAL))
       ...
   package Current_Readings is
       ...

  @node @FUNCTIONS_USED

  @FUNCTIONS_USED ([CI Name].[Function Name] => [Text])

  Description

  Specifies that functions, defined in another CSCI, are to be used in the CSCI
  in which this annotation appears.

  To use a function defined in another CSCI, the Cmvc.Import command must be
  used to import the function.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([CI Name].[Function Name] => [Text])

  Requires a list argument.  Each list element must specify the name of the
  CSCI from which the function comes, followed by the period symbol (.) and the
  name of the function being used.  Optionally, a textual description of the
  function use can follow the previous information.  The text that appears as
  the argument for this annotation will appear, exactly as it does here, in the
  documents generated by the 2167 DF.

  If no functions are used, the argument NONE should be specified. 

  Examples

  The following example illustrates the use of functions, called
  Current_Location and Current_Speed, defined in another CSCI, named
  Current_Readings, that are used by the current CSCI.  The ellipsis (...)
  between an annotation and a PDL element indicates annotations, also required
  for the PDL elements to which they are attached, that are not shown. The
  ellipsis after a PDL element indicates that additional PDL has been omitted.

   --| @COMPONENT_KIND CSCI
       ...
   --| @FUNCTIONS_USED (Current_Readings.Current_Location=>Used to get
   --|                  locator information,
   --|                  Current_Readings.Current_Speed);
   package Display_Readings is
       ...

  @node @ID

  @ID [NUMBER]

  Description

  Specifies the identification number for a System, Segment, CSCI, or HWCI.

  This number is used as the basis for numbering lower-level design components.
  Within the closed scope of the DOD-STD-2167 System, the argument for this
  annotation should be unique.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [NUMBER]

  Requires a positive integer.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on System, Segment, CSCI, HWCI

  *  Preliminary Design - Required on System, Segment, CSCI, HWCI

  *  Detailed Design and later phases - Required on System, Segment, CSCI, HWCI

  Examples

  The following example illustrates the use of the @ID annotation. The ellipsis
  (...) between an annotation and a PDL element indicates annotations, also
  required for the PDL elements to which they are attached, that are not shown.
  The ellipsis after a PDL element indicates that additional PDL has been
  omitted.

   --| @COMPONENT_KIND CSCI
       ...
   --| @ID 5
       ...

  @node @INFORMATION_KIND
                                                                                                                         
  @INFORMATION_KIND [Kind of Data]

  Description

  Specifies the data classification for the PDL element to which this
  annotation is attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [Kind of Data]

  Requires a simple name argument.  The value must be Control, Data, or
  Message.

  Examples

  The following example illustrates the use of the @INFORMATION_KIND annotation
  to specify the type of information for parameters.  Note the spacing used to
  ensure appropriate attachment to the parameters.  The ellipsis (...)
  between an annotation and a PDL element indicates annotations, also required
  for the PDL elements to which they are attached, that are not shown. The
  ellipsis after a PDL element indicates that additional PDL has been omitted.

       ...
   procedure State_Transition (

                               --| @INFORMATION_KIND Data
                                   State_Info : in out State_Record;

                               --| @INFORMATION_KIND Control
                                   New_State  : out State_Id);
       ...

  @node @INITIATION

  @INITIATION [TEXT]

  Description

  Specifies the conditions for initiating each data transfer for the interface
  requirement to which it is attached.

  If this interface is used in a cyclic manner, the argument for this
  annotation also should also describe how often the cycle occurs.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Interface Requirements

  *  Preliminary Design - Required on Interface Requirements

  *  Detailed Design and later phases - Required on Interface Requirements

  Examples

  The following example shows how the @INITIATION annotation is used on an
  interface requirement.  The ellipsis (...) between an annotation and a PDL
  element indicates annotations, also required for the PDL elements to which
  they are attached, that are not shown. The ellipsis after a PDL element
  indicates that additional PDL has been omitted.

       ...
   --| @REQUIREMENT INTERFACE
   --| @INITIATION A string must be composed that will be written to
   --|             the device, by passing it through this interface.
       ...
   --| @RESPONSE The string is written to the device.
   procedure Put_Line (The_String : String; The_Device : Devices);
       ...

  @node @INTERFACES_DEFINED

  @INTERFACES_DEFINED ([Interface Name] => [Document Name]
                                                    ([Document Number]))

  Description

  Specifies the name of an interface defined in a CSCI or HWCI.

  Other CSCIs or HWCIs can use the interfaces specified in this annotation with
  the @INTERFACES_USED annotation.  The order in which the interfaces are
  specified in the argument is the order in which they will appear in the
  documents.  The document name and number are optional.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([Interface Name] => [Document Name] ([Document Number]))

  Requires a list argument.  Each list element specifies the name of an
  interface, which must be an Ada simple name.  This name is followed by the =>
  symbol and the name of the document and document numbers in which the
  interface is defined.  List elements are separated by commas or new lines.
  The word NONE can be specified to indicate the no interfaces are defined.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on CSCI, HWCI

  *  Preliminary Design - Required on CSCI, HWCI

  *  Detailed Design and later phases - Required on CSCI, HWCI

  Examples

  The following example illustrates the use of the @INTERFACES_DEFINED
  annotation in the Computation CSCI.  This annotation specifies that two
  interfaces, State_Update and Startup, are defined in this CSCI and that they
  can be used by other CSCIs with the @INTERFACES_USED annotation.  The
  ellipsis (...) between an annotation and a PDL element indicates annotations,
  also required for the PDL elements to which they are attached, that are not
  shown. The ellipsis after a PDL element indicates that additional PDL has
  been omitted.

   --| @COMPONENT_KIND CSCI
       ...
   --| @INTERFACES_DEFINED (State_Update => SRS,
   --|                      Startup => SRS)
       ...
   package Computation is
       ...

  The following example illustrates the PDL for IRS and IDD separation.  The
  @DOCUMENT_NUMBERS annotation shown below would appear in the CSCI,
  indicating the document numbers for each of the documents to be generated.
  There can be only one each of the SRS, STLDD, and SDDD specified. Note that
  there are three IRSs and three IDDS to be generated. The number of IRSs and
  IDDs must always be the same, and ordering of the IDD documents must
  correspond to that for the IRS documents.

   --| @DOCUMENT_NUMBERS (IRS   => (GJD-091-44B,
   --|                              GJD-091-45B,
   --|                              GJD-091-46B),
   --|                    SRS   => (GJD-091-43B),
   --|                    STLDD => (GJD-092-43B),
   --|                    IDD   => (GJD-092-44B,
   --|                              GJD-092-45B,
   --|                              GJD-092-46B),
   --|                    SDDD  => (GJD-094-43B))

  In that same CSCI, the @INTERFACES_DEFINED annotation appears, indicating
  which requirements are to be documented in which documents.  INTERFACE_A
  will be documented by itself in an IRS; INTERFACE_B, INTERFACE_C, and
  INTERFACE_D will be documented together in another IRS.  Finally, INTERFACE_E
  will be documented by itself in yet a third IRS.

   --| @INTERFACES_DEFINED (INTERFACE_A => IRS(GJD-091-44B),
   --|                      INTERFACE_B => IRS(GJD-091-45B),
   --|                      INTERFACE_C => IRS(GJD-091-45B),
   --|                      INTERFACE_D => IRS(GJD-091-45B),
   --|                      INTERFACE_E => IRS(GJD-091-46B))

  The 2167 DF performs document number checking.  If inappropriate duplicates
  occur (for example, an SRS and SDDD with the same number), these will be
  flagged as errors during semantic checking.  Until the error is corrected,
  the design component will not be semantically correct and thus cannot be
  promoted to the installed state.

  @node @INTERFACES_USED

  @INTERFACES_USED ([Ci Name].[Interface Name] => [Text])

  Description

  Specifies the name of an interface, defined in another CSCI or HWCI with the
  @INTERFACES_DEFINED annotation, that is used by the CSCI or HWCI in which
  the @INTERFACES_USED annotation appears.

  The order in which the interfaces appear in the annotation is the order in
  which they will appear in documents.  The Cmvc.Import command must be used to
  import interfaces from other CSCIs.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([Ci Name].[Interface Name] => [Text])

  Requires a list argument.  Each list element specifies the name of the
  defining CSCI or HWCI, followed by a period and the name of the interface,
  optionally followed by the => symbol and text that describes its use.  List
  elements are separated by commas or new lines.

  If no interfaces are used in a CSCI, the argument NONE should be specified.

  The optional text that appears as the argument for this annotation will
  appear, exactly as it does here, in the documents generated by the 2167 DF.

  Examples

  The following example illustrates the use of the @INTERFACES_USED annotation
  in a CSCI called Computation.  The ellipsis (...) between an annotation and a
  PDL element indicates annotations, also required for the PDL elements to
  which they are attached, that are not shown. The ellipsis after a PDL element
  indicates that additional PDL has been omitted.

   --| @COMPONENT_KIND CSCI
       ...
   --| @INTERFACES_USED (Cruise_Control.Computation_Interface)
       ...
   package Computation is
       ...

  @node @LEGALITY_CHECK

  @LEGALITY_CHECK [Is Checking Performed?]

  Description

  Indicates whether validity checking is performed on the PDL element to which
  this annotation is attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [Is Checking Performed?]

  Requires the argument Yes, No, or N/A.  The text that appears as the argument
  for this annotation will appear, exactly as it does here, in the documents
  generated by the 2167 DF.

  Examples

  The following example illustrates the use of the @LEGALITY_CHECK annotation
  on a parameter to specify that legality checking is performed on its values.

      ...
   procedure Receive (

                      --| @LEGALITY_CHECK Yes
                      Data : in Network_Buffer);
      ...

  @node @LIMITATIONS

  @LIMITATIONS [TEXT]

  Description

  Describes any special limitations or unusual features that restrict the
  performance or usability of the design component.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Examples

  The following example illustrates the use of the @LIMITATIONS annotation in
  an LLCSC.  The ellipsis (...) between an annotation and a PDL element
  indicates annotations, also required for the PDL elements to which they are
  attached, that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

   --| @COMPONENT_KIND LLCSC
       ...
   --| @LIMITATIONS The accuracy of these operations is machine
   --|              dependent.
       ...
   package Orbit is
       ...

  @node @MEMORY

  @MEMORY [Memory Allocation]

  Description

  Describes the memory requirements for a design component.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [Memory Allocation]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on TLCSC, LLCSC, Unit

  *  Preliminary Design - Required on TLCSC, LLCSC, Unit

  *  Detailed Design and later phases - Required on TLCSC, LLCSC, Unit

  Examples

  The following example illustrates the use of the @MEMORY annotation to
  specify that a design component requires 10 kilobytes of memory. The ellipsis
  (...) between an annotation and a PDL element indicates annotations, also
  required for the PDL elements to which they are attached, that are not shown.
  The ellipsis after a PDL element indicates that additional PDL has been
  omitted.

   --| @MEMORY 10KB

  @node @NOTE

  @NOTE [TEXT]

  Description

  Specifies additional information not captured in other annotations.

  This annotation is not required on any PDL element at any design phase.

  Arguments

  [TEXT]

  Requires a text argument.

  Examples

  The following example shows how the @NOTE annotation can be used to provide
  the name of the designer of a Unit.  The ellipsis (...) between an annotation
  and a PDL element indicates annotations, also required for the PDL elements
  to which they are attached, that are not shown. The ellipsis after a PDL
  element indicates that additional PDL has been omitted.

   --| @COMPONENT_KIND UNIT
       ...
   --| @NOTE The designer of this Unit was John Smith.
       ...

  @node @PRIORITY

  @PRIORITY [TEXT]

  Description

  Specifies the priority at which the PDL element to which it is attached runs.

  The value can reflect Ada priorities, if desired.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Interface Requirements in HWCIs

  *  Preliminary Design - Required on Interrupts, Interface Requirements in
     HWCIs

  *  Detailed Design and later phases - Required on Interrupts, Interface
     Requirements
     in HWCIs

  Examples

  The ellipsis (...) between an annotation and a PDL element indicates
  annotations, also required for the PDL elements to which they are attached,
  that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

   --| @PRIORITY Level 8
       ...
   procedure Emergency_Shutdown;
       ...

  @node @PROCESSING

  @PROCESSING [TEXT]

  Description

  Specifies the processing performed by the PDL element to which it is
  attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Functional and Subfunctional
     Requirements

  *  Preliminary Design - Required on Functional and Subfunctional Requirements

  *  Detailed Design and later phases - Required on Functional and
     Subfunctional
     Requirements

  Examples

  The following example illustrates the use of the @PROCESSING annotation.  The
  ellipsis (...) between an annotation and a PDL element indicates annotations,
  also required for the PDL elements to which they are attached, that are not
  shown. The ellipsis after a PDL element indicates that additional PDL has
  been omitted.

  --| @COMPONENT_KIND UNIT
      ...
  --| @REQUIREMENT FUNCTION acceleration
      ...
  --| @PROCESSING Computes acceleration from position vector.
      ...
  procedure Compute_Acceleration (X, Y : in State_Variable.Value;
                                  Ax, Ay : in out State_Variable.Value);
      ...

  @node @PROTOCOL

  @PROTOCOL [TEXT]

  Description

  Describes the protocol related to the interface requirement to which it is
  attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Interface Requirements

  *  Preliminary Design - Required on Interface Requirements

  *  Detailed Design and later phases - Required on Interface Requirements

  Examples

  The following example illustrates the use of the @PROTOCOL annotation.  The
  ellipsis (...) between an annotation and a PDL element indicates annotations,
  also required for the PDL elements to which they are attached, that are not
  shown. The ellipsis after a PDL element indicates that additional PDL has
  been omitted.

       ...
   --| @PROTOCOL  EtherNet
   procedure Network_Transfer;
       ...

  @node @PURPOSE

  @PURPOSE [TEXT]

  Description

  Describes the purpose of the design component to which it is attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on System, Segment, CSCI, HWCI, TLCSC,
     LLCSC, Unit, Requirements

  *  Preliminary Design - Required on System, Segment, CSCI, HWCI, TLCSC,
     LLCSC, Unit, Requirements, Interrupts

  *  Detailed Design and later phases - Required on System, Segment, CSCI,
     HWCI, TLCSC, LLCSC, Unit, Requirements, File Objects, Database Objects,
     Interrupts

  Examples

  The following example illustrates the use of the @PURPOSE annotation in a
  Unit design component.  The ellipsis (...) between an annotation and a PDL
  element indicates annotations, also required for the PDL elements to which
  they are attached, that are not shown. The ellipsis after a PDL element
                                                                                                                         
  indicates that additional PDL has been omitted.

  --| @COMPONENT_KIND UNIT
      ...
  --| @PURPOSE
  --| Given a position (X,Y), this Unit calculates the acceleration
  --| (AX,AY).
      ...
  procedure Compute_Acceleration (X, Y : in State_Variable.Value;
                                  Ax, Ay : in out State_Variable.Value);
      ...

  @node @RAISES

  @RAISES ([Exception Name] => [Reason])

  Description

  Describes any exceptions propagated out of the design component and the
  conditions under which they are propagated.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([Exception Name] => [Reason])

  Requires a list argument.  Each list element specifies an exception name,
  followed by the => symbol and a text description of the conditions under
  which the exception is raised.  List elements are separated by commas or new
  lines. When no exceptions are propagated, the argument NONE can be specified.

  The text that appears as the argument for this annotation will appear,
  exactly as it does here, in the documents generated by the 2167 DF.

  Examples

  The following example illustrates the use of the @RAISES annotation in a
  design component.  The ellipsis (...) between an annotation and a PDL element
  indicates annotations, also required for the PDL elements to which they are
  attached, that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

       ...
   --| @RAISES (Unexpected_Value => Operator input unexpected value,
   --|          Unexpected_Range => Operator input unexpected range,
   --|          Unexpected_Data  => Operator input alphabetical or
   --|          punctuation characters instead of numeric values or
   --|          ranges)
       ...

  @node @REQUIREMENT FUNCTION

  @REQUIREMENT FUNCTION [Name]

  Description

  Specifies allocation of a functional requirement.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  FUNCTION [Name]

  Specifies the name of the requirement, when it is not the same as the Ada
  element to which it is attached. If specified, the argument for this
  annotation is a simple name. If omitted, the name defaults to the name of the
  function or procedure or task entry, with spaces replacing underscore
  characters.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Functional and Subfunctional
     Requirements

  *  Preliminary Design - Required on Functional and Subfunctional Requirements

  *  Detailed Design and later phases - Required on Functional and
     Subfunctional
     Requirements

  Examples

  The following example shows the use of the @REQUIREMENT FUNCTION annotation.
  The ellipsis (...) between an annotation and a PDL element indicates
  annotations, also required for the PDL elements to which they are attached,
  that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

       ...
   --| @REQUIREMENT FUNCTION Results
       ...
   function The_Result;
       ...

  @node @REQUIREMENT INTERFACE

  @REQUIREMENT INTERFACE [Name]

  Description

  Specifies allocation of an interface requirement.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  INTERFACE [Name]

  Specifies the name of the requirement, when it is not the same as the Ada
  element to which it is attached. If specified, the argument for this
  annotation is a simple name. If omitted, the name defaults to the name of the
  function or procedure or task entry, with spaces replacing underscore
  characters.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Interface Requirements

  *  Preliminary Design - Required on Interface Requirements

  *  Detailed Design and later phases - Required on Interface Requirements

  Examples

  The following example illustrates the use of the @REQUIREMENT INTERFACE
  annotation.  The ellipsis (...) between an annotation and a PDL element
  indicates annotations, also required for the PDL elements to which they are
  attached, that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

       ...
   --| @REQUIREMENT INTERFACE
       ...
   procedure Throttle_Control;
       ...

  @node @REQUIREMENT SUBFUNCTION

  @REQUIREMENT SUBFUNCTION [Name]

  Description

  Specifies the allocation of a subfunctional requirement.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  SUBFUNCTION [Name]

  Specifies the name of the requirement, when it is not the same as the Ada
  element to which it is attached. If specified, the argument for this
  annotation is a simple name. If omitted, the name defaults to the name of the
  function or procedure or task entry, with spaces replacing underscore
  characters. A complex name is used to specify the name of the function from
  which the subfunction was decomposed.  The function name is optional.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Subfunctional Requirements

  *  Preliminary Design - Required on Subfunctional Requirements

  *  Detailed Design and later phases - Required on Subfunctional Requirements

  Examples

  The following example illustrates the use of the @REQUIREMENT SUBFUNCTION
  annotation.  The subfunction Current was decomposed from Functional
  Requirement Speed. The name of the subfunction is specified because its name
  differs from the requirement name. The ellipsis (...) between an annotation
  and a PDL element indicates annotations, also required for the PDL elements
  to which they are attached, that are not shown. The ellipsis after a PDL
  element indicates that additional PDL has been omitted.

       ...
   --| @REQUIREMENT SUBFUNCTION Speed.Current
       ...
   procedure Current_Speed;
       ...

  @node @RESPONSE

  @RESPONSE [TEXT]

  Description

  Describes the expected response to each data transfer associated with the PDL
  element to which it is attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Preliminary Design - Required on Interrupts and Interface Requirements

  *  Detailed Design and later phases - Required on Interrupts and Interface
     Requirements

  Examples

  The following example shows how the @RESPONSE annotation is used on an
  Interface Requirement.  The ellipsis (...) between an annotation and a PDL
  element indicates annotations, also required for the PDL elements to which
  they are attached, that are not shown. The ellipsis after a PDL element
  indicates that additional PDL has been omitted.

       ...
   --| @REQUIREMENT INTERFACE
   --| @INITIATION A string must be composed that will be written to
   --|             the device, by passing it through this interface.
   --| @RESPONSE The string is written to the device.
   procedure Put_Line;
       ...

  @node @SEQUENCING

  @SEQUENCING [TEXT]

  Description

  Describes the sequencing, logic, and input conditions related to the
  invocation of the design component.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Preliminary Design - Required on TLCSC

  *  Detailed Design and later phases - Required on TLCSC, LLCSC, Unit

  Examples

  The following example illustrates the use of the @SEQUENCING annotation in a
  design component.  The ellipsis (...) between an annotation and a PDL
  element indicates annotations, also required for the PDL elements to which
  they are attached, that are not shown. The ellipsis after a PDL element
  indicates that additional PDL has been omitted.

   --| @SEQUENCING The Device must be opened.  The data is then
   --| written to it.  The Device is then closed.
       ...
   procedure Device_Update;

  @node @SIDE_EFFECT

  @SIDE_EFFECT [TEXT]

  Description

  Describes any side effects related to the use of the PDL element to which it
  is attached.

  This annotation is not required on any PDL element at any design phase.  It
  typically is used as a communication mechanism between developers on the same
  project.

  Arguments

  [TEXT]

  Requires a text argument.

  Examples

  The following example illustrates use of the @SIDE_EFFECT annotation.  The
  ellipsis (...) between an annotation and a PDL element indicates annotations,
  also required for the PDL elements to which they are attached, that are not
  shown. The ellipsis after a PDL element indicates that additional PDL has
  been omitted.

   --| @SIDE_EFFECT When this procedure is called, it updates a
   --|              global variable, The_Current.
       ...
   procedure Update;

  @node @SOURCE

  @SOURCE [TEXT]

  Description

  Describes the source of input data.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [TEXT]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on Functional and Subfunctional
     Requirements,
     Interrupts

  *  Preliminary Design - Required on Functional and Subfunctional
     Requirements, Interrupts

  *  Detailed Design and later phases - Required on Functional and
     Subfunctional
     Requirements, Interrupts

  Examples

  The following example shows how the @SOURCE annotation can be used on an in
  parameter.  The ellipsis (...) between an annotation and a PDL element
  indicates annotations, also required for the PDL elements to which they are
  attached, that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

       ...
   --| @SOURCE Client making the query, the Image_Processor
       ...
   procedure Locate (The_Item : in String;
                     In_String : in String;
                     The_Value : out Integer);
       ...

  @node @STATES

  @STATES ([State Name List])

  Description

  Lists the states in which a design component executes.

  The order in which the names of the states appear in the annotation is the
  order in which they will appear in the documents.

  On a CSCI, this annotation specifies all of the states in which the CSCI is
  operational. On a low-level design component, it specifies the state or
  states in which the design component is operational.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  ([State Name List])

  Requires a list of simple names.  Simple names are separated by commas or new
  lines.

  Examples

  The following example illustrates the use of the @STATES annotation in a Unit
  design component.  The ellipsis (...) between an annotation and a PDL
  element indicates annotations, also required for the PDL elements to which
  they are attached, that are not shown. The ellipsis after a PDL element
  indicates that additional PDL has been omitted.

   --| @COMPONENT_KIND UNIT
       ...
   --| @STATES (Displaying,
   --|          Stopped)
       ...
   package Screen_Utilities is
       ...

  @node @TIME

  @TIME [Time Allocation]

  Description

  Describes the processing time requirement for the design component.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [Text Allocation]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Requirements Analysis - Required on TLCSC, LLCSC, Unit

  *  Preliminary Design - Required on TLCSC, LLCSC, Unit

  *  Detailed Design and later phases - Required on TLCSC, LLCSC, Unit

  Examples

  The following example illustrates the use of the @TIME annotation in a Unit
  design component. The ellipsis (...) between an annotation and a PDL element
  indicates annotations, also required for the PDL elements to which they are
  attached, that are not shown. The ellipsis after a PDL element indicates that
  additional PDL has been omitted.

   --| @COMPONENT_KIND UNIT
       ...
   --| @TIME 4MS
       ...
   package Screen_Utilities is
       ...

  @node @UTILIZATION

  @UTILIZATION [Text]

  Description

  Describes the utilization of other elements by the PDL element to which this
  annotation is attached.

  For information on where this annotation is used in the documents generated
  by the 2167 DF, see the Appendix in this manual.

  Arguments

  [Text]

  Requires a text argument.  The text that appears as the argument for this
  annotation will appear, exactly as it does here, in the documents generated
  by the 2167 DF.

  Phase Name - Element(s)

  *  Detailed Design and later phases - Required on LLCSC, Unit

  Examples

  The following example illustrates the use of the @UTILIZATION annotation in a
  Unit design component. The ellipsis (...) between an annotation and a PDL
  element indicates annotations, also required for the PDL elements to which
  they are attached, that are not shown. The ellipsis after a PDL element
  indicates that additional PDL has been omitted.

   --| @COMPONENT_KIND LLCSC
       ...
   --| @UTILIZATION This design component uses the Robot_Control
   --|              unit to maintain the appropriate orientation
   --|              of the robot assembly to the satellite control
   --|              platform.
       ...
   package Satellite_Control is
       ...