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







A subject can often be considered as a grouping of a series of nearly independent modules. Each of these modules can themselves be formally specified. A proper module hides its assets against direct access from other modules. Thus, the assets of a proper module change only through communication with its environment or through the effects of internal triggers. A module-based subject can itself act as a module of a higher order module-based subject.

During a communication between modules, a method that is part of the receiving module is triggered. The parameters that are transferred control the state transitions that the corresponding operation accomplishes. The appearance changes that follow a communication depend on the state of the module at the instance of the trigger.

A module can be fully specified by the consequences of its internal triggers, by the communication of the module with its environment and by the sequences of appearance changes that are the result of that communication. A module-based subject can be fully specified by the dynamic interrelations of its modules, by the consequences of the internal triggers that occur inside these modules and by the communication of the subject with its environment. The dynamic interrelations of the modules represent the sequence of communications between the modules. A communication to or from a module-based subject is a communication to or from one of its modules.

Usually the methods of modules are grouped in one or more interfaces. A method may appear in more than one interface. Attributes of proper modules cannot be accessed directly. When accessible indirectly, the attributes can be accessed via get-methods and or set-methods that are included in an interface. It is possible that a get-method of an attribute appears in one interface, while its set-method appears in another interface. Often, attributes change because of internal triggers.

Component Model


When modeling systems that appear in real nature, it is always possible to separate the features of that system in two categories; actions and assets. The reason of this possibility is founded in natural law, or better in the logic on which nature is based. David Parnas (1970) understood this and proposed a way of programming that used this fact. The abstract data type that Parnas and consorts proposed, puts the assets in a data structure and the actions are represented in a separate list that contains pointers to the implementations of the actions. The data structure that contains the assets contains a top element that represents the relation between an individual subject and its behavior. This element is a reference to the list that contains the pointers to the implementation of the actions.

If researchers try to understand their environment, they make use of classes of subjects that behave in a similar way. The behavior is class wide. Assets that influence the behavior differ per class instance. In terms of the abstract data type of Parnas, the list of pointers to implementations of actions is a class wide item. The other part of the abstract data type represents the instance of the class. This is still a simplification. There might exist assets that have a class wide nature. If these are included in this data structure, then that structure can no longer be seen as a pure representative of the instance. Further, it makes sense to group the pointers to implementations of actions. These groups represent coherent subsets of the behavior. Each group acts as an interface via which part of the functionality of the module can be accessed. If this is done, then some means of navigation between these groups must be added. Further, the data structure that represents the instance must contain a pointer to each of these interfaces. This leads to the foundation of all modern component models. In languages such as C++, Java and .Net the structure of the underlying component model is hidden. When a COM software component is implemented in C, then the component model appears on the surface. When it is implemented in C++ the component model is hidden by the C++ class instance implementation model. COM guarantees that both implementations are binary similar.



Afgeronde rechthoek: Top of page Afgeronde rechthoek: Next page