Specifying key and keyed by properties

You may 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 (here class is used in System Architect terms, distinguishing whether it is a diagram, symbol, or definition)

▪its name (for example, the Reservation_System Use Case diagram versus 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 may be put almost anywhere in the description of a property, but because of its importance, it is customary to place it as the first item within the property’s braces, just before the EDIT keyword.

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” another object(s); 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 statement above 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 object(s) actually being referenced. If the referenced class/type of the property has no key properties, the reference value will just be 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.

Note Heterogeneous reference properties are different in this respect. See HETEROGENEOUS keyword for more information.

You either code this into USRPROPS.TXT so that System Architect automatically gets the values for the end user or you force the end user to type in the fully qualified name, with periods separating the key parts.

▪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 a Use Case Step called Specify email in a Use Case called Order_Product in a package called Order System you type:

Note When a component contains a syntactically significant character (such as a space or a period), it must be enclosed in double quotes so that System Architect can parse the reference properly.