A proper encapsulation of a module may effectively hide the intellectual property that is invested in its design. Its also prevents unintended obstructive handling of the module. Only in this way, the behavior of the module can be guaranteed by its supplier. Encapsulation also hides the complexity of the internals of a module from the clients of the module. Modules are excellent vehicles for encapsulation of expert knowledge. In this way, the expert knowledge becomes reusable by non-experts. This feature is effectively applied in integrated circuits. There is no reason why it cannot be applied with the same effectiveness in software components.
Assets can be categorized into equivalence classes, where the instances of these classes are treated by operations in an equal manner. The membership of the class specifies the type of the asset. Classification makes handling of the instances of the class much easier. This fact is so important that in most formal specifications the asset is not only identified with a unique asset identifier, but also with a type identifier. An equivalence class can be derived from another class. Thus, the type of the sub-class is derived from the type of the parent class.
Assets may be structured. This means that they can be seen as assemblies of simpler types. Modules that are part of other modules can be treated as assets. Their classes have a type identifier and a globally unique identifier. The instances have a unique asset identifier. The class related identifier corresponds to the type of the instance.
Often a relation points to an asset. The relation itself is a reference. The type of the relation is the same as the type of the asset at the end-point of the relation. However, the relation becomes a non-zero reference depth. A reference to a reference has a reference depth that is one increment higher than the reference depth of its end-point.
An array of assets has the same type as its members. However, the array has a non-zero size. The size equals the number of elements in the array. A multidimensional array has multiple sizes. If an asset has a non-zero size and a non-zero reference depth then it represents an array of references.
Thus, reference depth and size are not properties of a type. They are properties of an asset, which is an instance of a class that corresponds to the type.
The absence of an asset is often characterized by a special type. The corresponding type identifier is called ‘void’. When the type of a referred asset is not known, then the ‘void’ type identifier is used to characterize the unknown type of the referred asset.
The usage of un-typed assets is a source of potential confusion. It withholds development tools from checking the consistency of a specification.
The activity of a method is controlled by a program block. A method is characterized by a signature. This signature is composed from the identifier of the operation and the types and identifiers of the parameters. The parameters form an ordered set. An inbound, outbound or in-out characteristic tells whether the parameter is a get-only, a set-only or a get-set asset. Often the result of the operation is a communication back to the sender of the trigger. The type of the corresponding result parameter is also part of the signature of the original method. Even when this callback causes a state transition in the original sender, the callback is not seen as a separate method. This is an artificial combination of two independent operations in a single higher-level specification element. Methods and attributes of modules can be private. Private methods are not exposed via interfaces. Private attributes are attributes that have no get-method and no set-method.
The optional method result is an asset. The type of the method result is part of the signature of the method. If the method does not feature a method result, then the type is indicated as ‘void’. It has sense to include the identifier of the method result in the specification of the method. This is not common practice, but it makes implementations more congruent. This eases reuse of the specification.
In a module, all methods and attributes have unique instance identifiers. The instance identifier of a method is coupled to its signature and the instance identifier of an attribute is coupled to its type, its reference depth and its size.