180 4 Towards Better Product and Process Modelling
4.6.5.1 Components
The object models are abstract in contrast to their modellees, which are usually real
objects. In the case of SCA they have a kind of formal representation (possibly
even several representations). For ideal modelling (pursued by MCA) it is not
enough to have simply representation of the modellee, since it would be passive. In
order to satisfy requirements like R7, R11, R12 and R17, models have to be able to
perform activities. This means that each MCA-model shall contain either an
implementation of the related algorithms or links to their well-known or standard
implementations. On the one hand, the simplest MCA-models (
i.e. those from the
lowest level of the hierarchy) have to be implemented as
components, in the sense
of the components definition of OMG and the additional three requirements,
presented in Section 3.1.3.3.5 (on page 142). On the other hand, requirements such
as 3.1.1 can be satisfied mainly through incorporation of intelligence into the
components above a certain level in the hierarchy.
4.6.5.2 Hierarchy
The next important consideration concerns the correspondence among modellees,
models and components (
cf. also the term similarization in 4.6.7.2 below). Since
numerous components already exist as implementation of different, mainly
computer or computation related objects, it is rational to use them during the
design, composition and implementation of our engineering models in components.
Therefore, even the modelling of the simplest engineering component (
e.g., nut,
bolt, gear,
etc.) will be a model that is a compound software component, relying on
numerous existing (software) components from different component libraries. Due
to some additional requirements for these compound components, they should
implement a number of interfaces (in the sense of OMG) and obey a list of
conventions. We shall call the resulting pieces of software Autonomous Intelligent
Entity (AIE) and classify them as the basic building block of MCA. On the next
level in the hierarchy (
cf. Figure 4.5) comes the composition of interconnected
AIEs, which form an autonomous intelligent unit or module (AIM). AIM is usually
a model of a whole device, aggregate or assembly group. In turn, binding several
AIMs together (possibly also AIEs or other components from the lower levels)
forms an intelligent system. When some of the AIEs are on other computers and
are connected by simply communicating over the network, the resulting system is a
distributed intelligent system (DIS). AIEs and AIMs can be nested and intermixed
arbitrarily, have “loose connections” among the modules and might employ some
redundancy to improve their performance, reliability or fault-tolerance.
It should be stressed that the implementation language or architecture have
secondary meaning as long as models, implemented differently and separately, are
able to interact/interoperate with one another. Otherwise, my practical experience
confirms the ascertainments of other authors like the one of Janocha and Gandyra
(1997) that the Java slogan “
Write once, use everywhere” makes sense, especially
if extended with “(reuse) forever”.
4.6.5.3 Modelling Hierarchy (Holarchy)
On the one hand, according to MCA, almost every model above a certain level of
the modelling hierarchy can be viewed
and used as an autonomous entity (i.e., a
standalone whole). On the other hand, in both real life and the modelled worlds it