You can specify that a particular definition is ‘keyed’ to one or more other definitions. A key determines the name space of a definition in the encyclopedia. For example, a class attribute definition type is keyed by its containing class definition, and that class’s containing package definition. So you could have two attributes called “name”, one belonging to the class Customer in the package Reservation_System, and the other belonging to the class Product in the Order_System package. The two attributes, although having the same name, are distinctly different definitions.
By default, every modeling element in an encyclopedia is already secretly keyed to three things:
•its class (distinguishing whether it is a diagram, symbol, or definition)
•its type (whether it is a UML Use Case diagram, a BPMN Process diagram, and so on)
•its name (for example, the Reservation_System Use Case diagram or the Human_Resource_System Use Case diagram).
Add key properties to a definition by using the KEY command. Specify the KEY command within the property that you want to be a key of a definition. The KEY command can be put almost anywhere in the description of a property, but because of its importance, it is usually put as the first item in the property’s braces, before the EDIT keyword.
Note It is not possible to add a KEY EDIT ONEOF to a diagram.
Note Key properties of a definition are not shown in a grid formed by an ASGRID command. For example, in a Use Case definition, Use Case Steps are depicted in a grid formed by an ASGRID command, however, the key properties of Use Case Steps (owning package and Use Case) are not shown in the grid of Use Case Steps.
For a property that is a key and that “points at” other objects; for example, a LISTOF or ONEOF property, not a simple TEXT or NUMERIC property: the end user must specify the class and the class type of the referenced objects when entering a value for the property while working in System Architect.
The following example indicates that the property “Use Case Name” refers to a definition of type “Use Case”. “Definition” is the default when no class is specified (class in the System Architect sense: diagram, symbol, or definition).
The property value itself often contains all the necessary remaining material needed to identify the objects being referenced. If the referenced class/type of the property has no key properties, the reference value is just the object's Name (because the class and type are known), but if the referenced class/type has key properties (such as “Use Case” in the above example, which has key property “package”), System Architect must know the values of these key properties in order to properly identify the reference object. (Heterogeneous reference properties are different in this respect: for more information, see HETEROGENEOUS (ONEOF, LISTOF).)
You can either code this into USRPROPS.TXT so that System Architect automatically gets the values for the end user, or force the end user to type in the fully qualified name, with periods separating the key parts.
•To have System Architect get the value for users, use the KEYED (BY) command.
•If a KEYED BY clause is not given for the property, System Architect expects these additional key values to be given in the reference itself; in other words, you type the fully qualified name of the reference object, with periods separating key values. For example, for a Use Case Step called “Specify email” in a Use Case called “Order_Product” in a package called “Order System”, type:
"Order System".Order_Product."Specify email"
Note When a component contains a syntactically significant character, for example, a space or a period, it must be enclosed in double quotation marks.
Examples
Here are two examples of references to a “Use Case Step”:
Order_System.Order_Product."Specify email"
where CorrectInvoice is the name of the Use Case that belongs to the Accounts_Payable package.
Description of above example does not match the example, -- where is “CorrectInvoice”?. Also wrong in the IBM DITA source
"Order System"."Order Product"."Specify email"
where Order Product is the name of the Use Case that belongs to the Order System package.
