Building systems from modules has its greatest advantage when the modules can be picked from an existing resource. Thus, if an open market of reusable modules exist, then building systems from modules will be far more efficient than building systems from libraries of non-encapsulated elements. As a rule, reusable modules will not be delivered separately but in packages that contain a coherent set of binary implementations of classes of modules. The packages are the products of component suppliers.
In order to promote their products and to enable the usage of the modules that are contained in the package, the package must be published in a publicly accessible way. Classically, (hardware) modules are published via reference manuals and user manuals. A more modern way, that is far better suitable for software modules, is to publish the package on a web-based repository.
Modules have a greater chance to be reused when they make use of popular interfaces and well-known types. This can be achieved by not only publishing and promoting packages of modules, but also publishing other reusable design elements on publicly accessible repositories.
A component supplier may decide to offer packages that contain a coherent set of classes of software components. He may also decide to publish separate classes of software components and offer dedicated packages that contain a set of classes of software components that was selected by a customer. In that case, the customer that acts as a system integrator must use one of the available tools to generate a public version of the wanted package. This public version can then be used by the system configuration tool to produce a testable prototype of the package. After the prototype proves useful, the customer may decide to order the corresponding binary package from the component supplier.
The software components are delivered in binary packages that contain the encapsulated implementation of the classes of software components. This effectively hides the IP invested in the design of the components.
Since the internals of modules must be hidden, it is not obvious to a software architect how modules must be linked when only the provide-interfaces and the require-interfaces of the modules are published. For that reason the public specification of require interfaces contain specifications of local client methods and the specification of modules contain specifications of method disclosures. The method disclosure specification contains information on what local methods are called by a given method. If a method is a private method, an alias that does not disclose its purpose can replace its name. The method disclosure can also tell whether the method will never return.
For local design purposes of modules, it must be possible to specify the internals of the module. Thus, when specifications are created, tools may support two modes. The first mode specifies for local use. The second specifies for publication on a publicly accessible repository. Designers may want to put the internals of a module open to the public. This can be accomplished by introducing a descriptor that states that the corresponding design element must not be hidden.
On itself, the binary representations of module classes that are contained in the packages are useless. Instances of the modules that will exist from the start of the system must be generated, initialized and glued together. This is the task of a dedicated package manager. Further will each class be served by an instance manager. Both the package manager and the instance managers implement the application specific aspects for the package. Before the final system configuration takes place, the system configuration tool generates the package managers and the instance managers that belong to the selected packages.
Instances that will be generated dynamically during the runtime of the system are served by a class-specific instance manager. This facility generates and initializes the instances. The instance manager may also fill some late settable assets that determine part of the appearance of the modules. The class-specific instance manager is often called ‘class factory’. The package manager registers the instance managers with a central relation manager.
The package manager is specific to the package and the instance managers are specific to the corresponding classes. However, they are not part of the package. The data that are required for their generation and operation are taken from the public part of the package and from the configuration plan of the system. The package manager and the instance managers are generated by the system configuration tool and are is added as modules to the target system. During initialization of the target-system, the package manager realizes the tasks of the system configuration tool. That tool is not a part of the target system. The addition of classes to an existing system may be done in a version controlled way. Classes that are not used or that are replaced by a newer version may be removed by the configuration tool or by the relation manager. The relation manager is part of the target system. If the relation manager removes non-used module classes, then it does that during runtime. However, it will usually occur in a low-activity mode of the system.
An appropriate configuration tool can generate binary packages as well as component based systems. The system-configuration tools cannot handle loose classes of software components. It is not sensible to create the equivalent of a package manager for each loose component class. It is also inefficient to use very small packages. This may lead to the fact that component suppliers must offer many different reusable components or the component suppliers must stick together and offer package services that combine component classes of different component suppliers in a single package.
Registration of modules offers the opportunity for services or for other modules to find module classes via a globally unique identifier. Instances of classes may be found by the combination of a globally unique identifier and an index. A central relation manager manages the system registry. New classes registered by a package manager. Instances will be registered by the class specific instance manager. For each module instance a reference counter is maintained. This counter is increased when a client wants a reference that is guarded against unwanted deletion. When its reference counter decreases to zero, then a dynamic instance will be deleted. A fixed instance with a zeroed reference counter will be reset before it is reused.