Afgeronde rechthoek: Top of book Afgeronde rechthoek: Managers track Afgeronde rechthoek: Technical track Afgeronde rechthoek: Previous page Afgeronde rechthoek: Home
 

 

 

 

 


Specification of component based systems

Specification documents

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.

Administrative specification elements

Name

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.

Prefix

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.

Type names and globally unique identifiers

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.

Description

An optional short free-style description accompanies the formal specifications of most design elements.

Documentation

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.

Origin

A formal specification document must contain a URI that points to the location where the corresponding design element was originally specified.

Location

An optional URI may specify the location from which the specification document was retrieved.

Include files

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.

Default values

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.

Initial values

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.

Reference to parent class

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.

Reference to container

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.

References to special services

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.

References to classes of reusable design elements

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.

 

 

Afgeronde rechthoek: Top of page Afgeronde rechthoek: Next page