Not all classes of reusable design elements are given their own specification document. Classes of modules and classes of interfaces have their own specification documents, but methods and attributes have no separate specification documents. Complex types have their own specification documents. Simple types are usually specified as a part of the specification of another design element. All specification documents make use of administrative specification elements.
Names are used as instance identifiers. All design elements have names. The name is used both by the specification, by the documentation and by the source code of the software to reference the corresponding design element.
The prefix is an extra but short name. All design elements, for which the class has a private specification document, posses a prefix. The prefix is used to prefix names of instances and of members of these instances. Classes of design elements have a default prefix, but instances may be given a private prefix. In this way, a package-wide consistent namespace can be created. The combination may also be used in source code filenames and class-wide prefixes are often used as extensions of filenames of specification documents.
Every class of reusable design elements has a type name and often it has in addition a globally unique identifier. For example, the system registry works with globally unique identifiers and instance indices rather than with type names and names of instances.
An optional short free-style description accompanies the formal specifications of most design elements.
Complex design elements, such as modules and interfaces may get a more extensive free-style documentation. The formal specification of those design elements contains an optional URI that points to the corresponding free-style document.
A formal specification document must contain a URI that points to the location where the corresponding design element was originally specified.
An optional URI may specify the location from which the specification document was retrieved.
The automatic code generator already generates a hierarchy of include files that reflect the public part of the specification. If the generated source code must refer extra include files, then the filenames of these files must be included in the formal specification.
A class of design elements may specify default values for its assets. Derived classes inherit these default values. Thus, a formal specification of a class of design elements may contain a series of default values. If the instances of the subclasses do not explicitly contain new values, then the default values are used. Usually, the system configuration tool takes care of the initialization of default values. This means that for most assets the default value need not be specified.
Many design elements can take initial values. Attributes and the parameters of task start methods are examples. These values will be specified in text format.
A reference to a parent class is used to inherit members and default values. If a class has a parent then it can be used as if it belongs to that parent. The global unique identifier identifies the class. Since a derived class represents also its parent class, it must also be represented by the global unique identifier of its parent class. Thus, when all members of a hierarchy of classes have their own globally unique identifier, then these identifiers have the same relational hierarchy. This becomes relevant when the implemented system registry is queried by using a globally unique identifier. Any class that is represented by this identifier can be used as a return value. Examples of design elements that feature references to parent classes are modules and interfaces.
If a design element is a member of another design element, then the handling may be eased by keeping a reference to the containing element in the specification of the member. The system configuration tool takes care of this feature. Therefore, there is no need for specifying a reference to the container.
If heap memory must be reserved, or when instances of modules must be approached that can only be found via the central relation manager, then the implementation of the corresponding module must possess a reference to the corresponding services. The system configuration tool takes care of this feature. Therefore, there is no need for specifying references to special services. However, the specification of the module must indicate the requirement for such references.
If a specification document uses instances of a class of reusable design elements that possesses a private specification document, then at that place, the specification must use a reference to the specification document of that class. Further, it must specify initial values for assets and administrative specification elements of that design element. At least the instance must be given a name that is unique in the domain where it will be used.