Together the assets, the atomic sub-states, the operands in a task, the state transitions and the triggers constitute a set of mutually independent atomic descriptors that represent a complete view of the observed dynamic system. All other descriptors are high-level descriptors, derived descriptors, or support the usage of the description. For example, the implementation may restrict the accessibility of asset values or it may prevent the external access to private methods. This adds access characteristics to the set of atomic descriptors.
Inter-task programs and scheduling plans are higher-level constructs that define the behavior of the system. Modules that are part of module-based systems can be interpreted as higher-level specification elements. In addition, types, methods, interfaces, require-interfaces, hardware interfaces, notification interfaces, schedule plans and connection schemes can be interpreted as higher-level specification elements. Local client method descriptors and method disclosures are administrative additions.
According to their usage, higher-level specification elements can be categorized in equivalence classes. The class related identifier corresponds to the type of the instance. The fact that higher-level specification elements can be categorized in equivalence classes renders these elements as reusable design elements.
Modules, normal interfaces, require-interfaces, hardware-interfaces, streaming-interfaces, notification-interfaces, methods and types are reusable design elements. If hiding of intellectual property plays a role then only part of the specification of a module can be published. The other part of the specification is only used to design and build the module. Normal interfaces; require-interfaces; hardware-interfaces; streaming-interfaces; notification-interfaces and type identifiers belong to the publishable part of a module. Most of the private methods and private attributes belong to the hidden part. Only if these methods or attributes always accompany a given interface, then there is no loss of IP in publishing the signature of these private methods or the names and types of these private attributes.
The public part of a module delivers sufficient information to build skeleton instances of the module class. Usually that information is insufficient to be able to build active instances of the module class. The skeleton modules enable the automatic test of the static configuration of a module-based system by using a conventional program development environment. This fact enables the promotion of modules via reference books or even better via publicly accessible repositories. In this way, it is possible to make products from classes of modules.
If a module uses popular interfaces, than the chance that it can be reused is larger then when a new interface is used. In order to promote modules and to make interfaces popular they must be published at publicly accessible places. This fact works for all reusable design elements, including types.
In order to promote and optimize reuse, the specifications of equivalence classes of reusable design elements must be placed in separate specification documents. If another specification document uses an instance of a class of reusable design elements, then it must refer to the corresponding document. The reference may be accompanied by a set of initial values of assets of the instance. In any case, the instance identifier must be specified.
In this way, all specification documents will have a hierarchical structure rather than a network structure. All internal relations will use hyperlinks to other documents. Documents with a pure hierarchical structure can be interpreted much easier than documents that have a network structure. This will also ease the management of the navigation and categorization of the repositories, where the documents will be published.