Back Room Front Room 2

32
ENTERPRISE INFORMATION SYSTEMS VI
semantics of the other layers. The composite pattern
determines all transitions between different layers of
abstractions that make sense in such a system. The
Component objects conform to the following
observation by Koestler (1967) with regard to
holons:
they “...should operate as an autonomous, selfreliant
unit which, though subject to control
from above, must have a degree of
independence and take routine contingencies in
its stride, without asking higher authority for
instructions. Otherwise the communication
channels would become overloaded, the whole
system clogged up, the higher echelons would
be kept occupied with petty detail and unable
to concentrate on more important factors”
(Koestler, 1967, p.55)
However, there are two important differences
between our view of a complex software system and
the holon view of the real world. Firstly, the holon
hypothesis explains the structure and behavior of an
“implemented” system (e.g. living organism), but it
does not explain the abstractions needed for the
development of a system. Short of further analysing
the evolution of living organisms, we suggest that a
large system that works is always a result of an
evolution of a small system that was built using a
supportable hierarchical structure reminiscent of
holon structures. Therefore, the development process
must start with a simple architectural design that
proposes a hierarchy of layers of abstractions. It is
crucial then that this architectural design is obeyed
in the implemented system.
Secondly, hierarchical structures found in nature
tend to be relatively static. Their structure does not
change much over time but behavior can moderatly
change. On the contrary, hierarchical structures in
software must support change much more readily.
Enterprise information systems and business
applications change in structures and in behavior
(after all company structures, product and employee
classifications, plant operation specifications, and
many other aspects of business are in a constant state
of flux). The design for change demands a special
attention to dependency management, which is
discussed next. It also explains the principle (that
undeprins the composite pattern) to „Favor object
composition over class inheritance” (Gamma et al.,
1995, p.20). Inheritance model works poorly on
dynamic structures.
3 DEPENDENCY MANAGEMENT
A dependency between two system objects exist if a
change to the object that supplies a service may
necessitate a change in client objects that demand
that service.
If all dependencies in a system are identified and
understood, the system is said to be supportable, i.e.
the system is understandable, maintainable and
scalable. A necessary condition for supportability is
that a sheer number of dependencies is tractable.
Consequently, a task of software engineer is to
minimize dependencies (Maciaszek and Liong,
2004).
In software systems, dependencies can be
identified for objects of varying granularity –
components, packages, classes, methods. The
dependencies between more specific objects at lower
levels of granularity propagate up to create
dependencies at higher level of granularity.
Accordingly, dependency management necessitates
a detailed study of the program code to identify all
relationships between data structures and code
invocation between software objects.
Figure 2 shows an example of quite troublesome
dependencies in a simple program. The example
refers to three Java classes AAA, XXX, and YYY. YYY
is a subclass of XXX. AAA obtains a reference
varA1 to YYY when instantiating it, but it keeps
this reference as XXX type.
When operA1() is called, it invokes
operX1() on the superclass XXX. However,
operX1() calls operXY1(). The operation
operXY1() exists in the superclass, but it is
overridden in the subclass (as shown in the Class
Specification window). Accordingly, the overridden
method is called in a down-call to YYY (because
varA1 refers to YYY).
The operation operA1() executes also
operXY2() on the superclass XXX. Again, because
operXY2() is overridden in YYY, the execution
involves a down-call to YYY. However, the
overridden method is an extension of the parent
method. The parent method is invoked in an up-call
to XXX.
This simple example illustrates difficulties faced
by developers and maintainers when trying to
understand and maintain dependencies in the code.
Interestingly, the example is not demonstrating any
bad programming practice. It only illustrates how
one of the dominant reuse techniques, namely
implementation inheritance, “naturally” results in
unduly complex, perhaps even unsupportable, code.