Back Room Front Room 2
Back Room Front Room 2
Back Room Front Room 2
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
2 SOFTWARE HOLONS –<br />
RATIONALE FOR LAYERED<br />
ARCHITECTURES<br />
The complexity of living systems by far exceeds the<br />
complexity of any computer system, and yet living<br />
systems are reliable and adaptive. Therefore, it<br />
seems sensible to study the structure and behaviour<br />
of living organisms in search for paradigms to be<br />
used in the construction of software solutions. An<br />
important way of thinking in behavioural science<br />
(apart from reductionism and holism) is centered on<br />
the notion of holon. To quote Koestler (1980,<br />
p.447):<br />
“A living organism is not an aggregation of<br />
elementary parts, and its activities cannot be<br />
reduced to reeling off a chain of conditioned<br />
responses. In its bodily aspects, the organism is<br />
a whole consisting of “sub-wholes”, such as<br />
the circulatory system, digestive system, etc.,<br />
which in turn branch into sub-wholes of a<br />
lower order, such as organs and tissues - and so<br />
down to individual cells. In other words, the<br />
structure and behaviour of an organism ... is a<br />
multi-levelled, stratified hierarchy of subwholes,<br />
... where the sub-wholes form the<br />
nodes, and the branching lines symbolise<br />
channels of communication and control. ...<br />
The point first to be emphasised is that each<br />
member of this hierarchy, on whatever level, is<br />
a sub-whole or “holon” in its own right - a<br />
stable, integrated structure, equipped with selfregulatory<br />
devices and enjoying a considerable<br />
degree of autonomy or self-government.”<br />
From studies of most complex systems that exist,<br />
such as biological systems, it is known that complex<br />
systems, which work well, have one thing in<br />
common – they are hierarchies of elements; they are<br />
not networks. Such systems exhibit layered<br />
architectures without circular dependencies within<br />
and between layers.<br />
Holons are: “...subordinated as parts to the<br />
higher centres in the hierarchy, but at the same time<br />
function as quasi-autonomous wholes. They are<br />
Janus-faced. The face turned upward, toward the<br />
higher levels, is that of a dependent part; the face<br />
turned downward, towards its own constituents, is<br />
that of a whole of remarkable self-sufficiency.”<br />
(Koestler, 1980, p.447)<br />
Accordingly, in object-oriented system<br />
modeling, the holon abstraction can be simulated by<br />
the notion of composition. This notion has been<br />
documented and offered as a design pattern (Gamma<br />
et al., 1995). The composite pattern represents part-<br />
MANAGING COMPLEXITY OF ENTERPRISE INFORMATION SYSTEMS 31<br />
whole hierarchies of objects and allows treating<br />
parts and wholes in a uniform way (by narrowing the<br />
difference between the components and<br />
compositions of components). Figure 1 is a UML<br />
graphical representation of the composite pattern<br />
(Gamma et al., 1995).<br />
Component<br />
Leaf Composite<br />
Figure 1: The structure of the composite pattern.<br />
As stated in Gamma et al. (1995, p.163):<br />
“The key to the Composite pattern is an abstract<br />
class that represents both primitives and their<br />
containers.” To be precise, the Component class is<br />
a partially implemented abstract class that declares<br />
an interface for objects in the composition. The<br />
behavior of primitive objects is defined<br />
(implemented) in the Leaf class and the behavior of<br />
components having children in the Composite<br />
class. Default implementations of the behaviors<br />
common to all classes in the composition can be<br />
provided in the Component class (hence, this class<br />
is “partially implemented”). Client programs use the<br />
interface of the Component class to communicate<br />
with objects in the composition. If a recipient object<br />
is a Composite, then the client’s message will<br />
usually trigger requests to its child components<br />
before the requested operation can be completed.<br />
Consistently with the holon abstraction, the<br />
composite pattern reflects the “openess” property of<br />
holons and supports “design for change”. In living<br />
organisms, complex systems evolve from simple<br />
systems and there is no absolute “leaf” holon or<br />
“apex” holon. Wholes are composed of parts that<br />
can be either leaves or composites.<br />
The composite pattern matches the holon<br />
hypothesis. Complex software systems consist of<br />
several layers of abstraction. Each one of them is a<br />
quasi-autonomous construction visible as a<br />
dependent part to the higher layer of abstraction and<br />
at the same time exerting some control over lower<br />
layers of abstraction. A layer of abstraction has its<br />
own semantics which is complete according to its<br />
specification and which is independent from the<br />
n