A Unit definition is used for data or information to be included in a PSA database. A Unit can be used for any kind of measurement needed within the system. As with all Objects in PSL, the definition starts with a basic statement:
DEFINE UNIT unit-name(s) ;
Normally, units would be defined one at a time. However, the option to have a list of unit names is used when it is sufficient simply to declare a list of objects as units - this may be necessary to prevent an object being identified as ambiguous with respect to type.
Information about a Unit is then defined using a set of Relations. These Relations are grouped according to a set of system ASPECTS. There is no special significance to these aspects, and a system definer could use any combination of available relations, and does not need to make any declarations about those aspects. Here are the available aspects, and links will take you to the available syntax for each:
CONSUMPTION VALUE [IS][FOR] resource-name [BY] process-name , ... ;
FOR process-name DURATION [IS] [FOR], ... ;
EQUIVALENT [TO]unit-name , ... ;
THERE [IS]PER unit-name, ... ;
PERIOD [IN] [WHICH]HAPPENSTIMES , ... ;
MEASURES;
PROJECT MANAGEMENT
PROJECT-CROSS-REFERENCE [IS];
PROJECT-CROSS-REFERENCED [WITH] name(s) ;
RESPONSIBLE-PROBLEM-DEFINER [IS] string(s) ;
p align="center"><strong>REQUIREMENTS TRACEABILITY</strong></p> <p> </p> <p>TRACE-KEY [IS] string(s) ;</p> <p>[there are no relations for System Boundary & Input/Output Flow, Data Structure, Data Derivation & Flow, System Control, or System Dynamics when defining a Unit].</p>"
A System Parameter definition is used to add a wide range of constraints and parameters to a specification. As with all Objects in PSL, the definition starts with a basic statement:
Normally, system parameters would be defined one at a time. However, the option to have a list of object names is used when it is sufficient simply to declare a list of objects as system parameters.
Information about a system parameter is then defined using a set of Relations. These Relations were grouped according to a set of system ASPECTS. There is no special significant to these aspects, and a process definer could use any combination of available relations, and does not need to make any declarations about those aspects. Here are the available aspects, and links will take you to the available syntax for each:
A Set definition is used for data or information to be included in a PSA database. As with all Objects in PSL, the definition starts with a basic statement:
DEFINE SET set-name(s) ;
Normally, sets would be defined one at a time. However, the option to have a list of set names is used when it is sufficient simply to declare a list of objects as sets - this may be necessary to prevent an object being identified as ambiguous with respect to type.
Information about a Set is then defined using a set of Relations. These Relations are grouped according to a set of system ASPECTS. There is no special significance to these aspects, and a system definer could use any combination of available relations, and does not need to make any declarations about those aspects. Here are the available aspects, and links will take you to the available syntax for each:
A Subtype definition is used for data or information to be included in a PSA database. Typically, a Subtype can be used to rename an object type or to add additional object types. As with all Objects in PSL, the definition starts with a basic statement:
DEFINE SUBTYPE subtype-name(s) ;
Normally, subtypes would be defined one at a time. However, the option to have a list of subtype names is used when it is sufficient simply to declare a list of objects as subtypes - this may be necessary to prevent an object being identified as ambiguous with respect to type.
Information about a Subtype is then defined using a set of Relations. These Relations are grouped according to a set of system ASPECTS. There is no special significance to these aspects, and a system definer could use any combination of available relations, and does not need to make any declarations about those aspects. Here are the available aspects, and links will take you to the available syntax for each:
PROPERTIES & CHARACTERISTICS
SYNONYM [IS] names(s);
DESCRIPTION;
text-entry ;
DOCUMENTATION;
text-entry;
LONG-NAME;
text-entry;
KEYWORD [IS] string(s) ;
LEVEL [IS] string(s) ;
APPLIES [TO] name(s) [ [AS]] ;
SEE-MEMO [] memo-name , ... ;
SECURITY [IS] string(s) ;
SOURCE [IS] string(s) ;
ATTRIBUTE [IS] attribute-name, ... ;
SUBTYPED [AS] subtype-name ;
SYSTEM STRUCTURE
SUBPART [IS] subtype-name(s) ;
PART [OF] subtype-name ;
COMPOSED [OF] [] subtype-name , ... ;
COMPONENT [] IN subtype-name , ... ;
GENERIC STRUCTURE
INCLUDES [] name , ... ;
INCLUDED [] IN name , ... ;
KNOWN [AS] name [ [BY] name] , ... ;
KNOWN-NAME [OF] name [ [FOR] name] , ... ;
KNOWS name [AS] name , ... ;
LINKS name [ [AS]] , ... ;
LINKED [TO] name [ [AS]] , ... ;
PROJECT MANAGEMENT
PROJECT-CROSS-REFERENCE [IS];
PROJECT-CROSS-REFERENCED [WITH] name(s) ;
RESPONSIBLE-PROBLEM-DEFINER [IS] string(s) ;
REQUIREMENTS TRACEABILITY
TRACE-KEY [IS] string(s) ;
[there are no relations for System Boundary & Input/Output Flow, Data Structure, Data Derivation & Flow, Quantification & Resource Usage, System Control, or System Dynamics when defining a Subtype].
A Resource definition is used for data or information to be included in a PSA database. A Reesource can be any kind of resource needed and at some stage consumed by the target processing system. As with all Objects in PSL, the definition starts with a basic statement:
DEFINE RESOURCE resource-name(s) ;
Normally, resources would be defined one at a time. However, the option to have a list of resource names is used when it is sufficient simply to declare a list of objects as resources - this may be necessary to prevent an object being identified as ambiguous with respect to type.
Information about a Resource is then defined using a set of Relations. These Relations are grouped according to a set of system ASPECTS. There is no special significance to these aspects, and a system definer could use any combination of available relations, and does not need to make any declarations about those aspects. Here are the available aspects, and links will take you to the available syntax for each:
[there are no relations for System Boundary & Input/Output Flow, Data Structure, Data Derivation & Flow, System Control, or System Dynamics when defining a Resource].