|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - download
Length: 198750 (0x3085e)
Types: TextFile
Notes: R1k Text-file segment
└─⟦8527c1e9b⟧ Bits:30000544 8mm tape, Rational 1000, Arrival backup of disks in PAM's R1000
└─ ⟦5a81ac88f⟧ »Space Info Vol 1«
└─⟦0c1f7938b⟧
└─⟦this⟧
@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
...