From outside of a module, an interface is an ordered and coherent set of methods. However, as a high-level specification element the interface may contain much more information. When the interface contains get-methods or set-methods, then it is sensible to specify the corresponding attribute together with the interface. This can be taken one step further by including with the interface specification also other attributes and methods that are not part of the exposed part of the interface, but that always appear together with the interface. This will ease the reuse of the interface. On its turn, the reuse will increase the popularity of the interface. Modules that make use of popular interfaces have a greater chance to be reused. When several interfaces of a module share a method or an attribute, then it must be ensured that the method or attribute is implemented only once. Shared attributes must have the same identifier, the same type and the same reference depth or size. Shared methods must have the same signature.
One of the normal interfaces of a module is the prime interface. If the set of normal interfaces is taken as an ordered set, then the first interface is the prime interface. If a reference to an instance of a module is provided by a central service, such as a central relation manager, then the reference will point to the prime interface of that instance. The module must support navigation through its set of interfaces. Each of the normal interfaces must support this navigation service. The navigation is supported by the globally unique identifiers of the interfaces. All interfaces are derived from a common base interface. If the navigation service is queried for the base interface, then the prime interface is returned.
Require-interfaces are the client-side counterpart of normal interfaces. They represent the relation between the caller and the receiver when a client module sends a command or message to another module. In order to point out the distinction, a ‘normal’ interface is sometimes called a provide interface. Require interfaces are the gluing points that are used to connect modules. Gluing can be done statically at system (re)-configuration time or dynamically during run time.
Each system mode corresponds to a connection scheme. Connection schemes are ordered sets of preplanned connections. Part of the scheme consists of connections that can be requested by instances of module classes. The other connections are installed when the system mode is entered. The connections that are specified in a connection scheme define the instances of modules that will be connected statically or dynamically. The specification covers the involved require-interfaces and provide-interfaces. It may include a possible reference to the definition of a connection request.
Normally the infrastructure will install the proper connections before a new system mode is entered. This means that the system mode specifications contain the specification of a required connection scheme. It also means that the infrastructure must keep an administration of existing connections. However, a module may be capable of requesting another or a new connection. This is done via a connection-request. Thus, the specification of a require-interface may contain a list of specifications of connection-requests.
Before establishing a new connection, a previous connection that was using the same require-interface must be released. Releasing a connection may involve the release of a dynamically created instance of a module class. The infrastructure maintains reference counts for each existing instance of a module class. When the reference count of a dynamically created instance decrements to zero, the memory occupied by the instance is offered to the garbage collector.
If a new connection involves a non-existing volatile instance of a module class, then first the new instance is created and initialized. If an existing instance is involved, and its reference count is zero then the instance is reset before it is reused. Even for non-zero reference counts, the specification of the connection may instruct the infrastructure to reset the instance before it is connected.
Hardware interfaces represent the ports between software attributes and hardware registers. A hardware interface consists of a set of hardware registers and a set of attributes that are used to get or set the values of these registers. A macro or a corresponding get-method or set-method is used to realize the communication between the software part and the hardware part. The macro represents the local inline equivalent of the get-method or set-method. Hardware register access can be characterized by special features such as read-reset access, etc.
Streaming-interfaces control the communication of data streams between subjects. Streaming normally occurs in packages. Such a package is a fixed sized set of asset values. In software, these packages form a chain. The size of the packages and the length of the chain are assets.
Notification interfaces are placeholders for relations that must be used when one or more client modules must be notified of a certain event. Subscribed notifications are served by a central notification service. In a module, subscribed notification interfaces are a formed by a combination of a provide interface and one or more require-interfaces.
Late settable assets are placeholders of values that are accessible by system configuration utilities and that influence the appearance or the behavior of the module. As the name says, these assets are set late during system configuration time. Late settable assets cannot be accessed directly by the clients of a module. However, normal interfaces may contain get or set-methods for these attributes. Require-interfaces are examples of late settable assets.
The internals of a module must stay hidden. In this way, a system architect will have difficulty in deciding what connections must be planned. For that reason the specification of the require-interface may contain a list of identifiers of local client methods that use this require-interface. This list also contains the methods that are called by these client methods via the require-interface. This still does not cover indirect access of the require-interface. For that reason, the module specification may contain a list of method disclosures. This list contains the identifiers of methods that locally call other methods. In order to hide methods that must not be exposed, an alias that exposes nothing about the private method can be used instead of its identifier.