In the example the generalization might provide a superclass
Memory and
adaptor classes Memory_AIX_PPC, Memory_WINNT_X86
and Memory_LINUX_X86
(s. figure ![[*]](http://www.nm.informatik.uni-muenchen.de/common/icons/latex2html-97.1/cross_ref_motif.gif){kind=icon}
).
The specific class example refers to the configuration scenario,
introduced in section .
If a superclass is used to realize polymorphism, functionalities which are common for all environments must be implemented only once in the superclass and can be inherited by the implementation classes. This approach however is only possible in OO languages which support multiple inheritance. If the language supports the single inheritance paradigm, e.g. Java, the use of generalization would constrain the programmer to use a single superclass for all implementations of e.g. Memory. For instance, if the application programmer intends to use a class SystemResources_LINUX, which supports access to system information, it is not possible to inherit functionality from SystemResources_LINUX for the implementation class Memory_LINUX_X86, because all implementation classes must inherit the superclass Memory.
The abstraction by interfaces offers
an alternative to the abstraction by superclasses
(s. figure ).
It allows the implementation classes
to be subclasses of other classes
than the one needed for adaptation.
For adaptation it is necessary that all implementation
classes of an implementation group
export the same behaviour to other classes.
If this is realized by an interface,
the implementation classes are not restricted
in the case of a programming language allowing
only single inheritance, e.g. Java.
Figure
shows the same secnario as figure ,
where the implementation class Memory_LINUX_X86
wants to inherit functionality from the class SystemResources_LINUX.
In this case the inheritance is also possible
for single inheritance because
Memory_LINUX_X86 implements an interface
in order to be used as an implementation class
and is not part of an inheritance hierarchy
due to the adaptation mechanism.
The design pattern for the proposed methodology is based on this concept. Before the concept is described in more detail the necessary terminology which is used within the scope of this work will be defined by the example of the classes for the browser configuration agent. The functionality of the Memory class is described in an interface IMemory, called functionality interface . Implementations of IMemory for different environments, called implementation classes , export all the same functionality to other parts of the mobile code, but their implementation is suitable for different environments.
Note that much of this is going on in normal modeling as well. However this approach provides in addition the automatic composition at runtime of particular branches in the inheritance relationship according to environmental conditions. Other branches can be left out, thereby releasing cost benefits.
In the example the three functionality interfaces IMemory,
IHarddisk, IConfiguration are defined.
Table shows the implementation
classes of the functionality interfaces and a description of their
respective environment.
Implementation classes which implement the same functionality interface are called implementation group . The name of an implementation group is by convention the common functionality interface of the implementation classes. The implementation classes Memory_AIX_PPC, Memory_WINNT_X86, Memory_LINUX_X86 all implement the interface IMemory and form an implementation group with the name IMemory .
The names of the implementation classes in the example have suffixes that correlate with their desired execution environment. These suffixes are used to give more meaningful names to the classes of the example. E.g. the implementation class Harddisk_WINNT_X86 could also have the name Foo. It is up to the application programmer to name the implementation classes. There is no compulsive correlation between the name of an implementation class and its respective environment.
Figure shows two hosts with different
configurations. Without changing the interface of
the core mobile agent, different implementations (grey shaded) are used
fitting to the operating system, CPU architecture and the default
browser. The core mobile agent represents the non-adaptable part of
the mobile code which handles e.g. the movement in the network
or controls the general program flow,
e.g. the configBrowserCache(int,int) function.
A constraint of this design pattern is the specification of implementation classes by an interface. Such an interface cannot define any member variables of the implementation classes. A method to add member variables to implementation classes is to wrap the implementation classes.
This wrapper classes as part of the interaction between the core, the functionality interfaces and the implementation classes are described in the following section. The interaction between the functionality interface and the implementation class in particular includes the procedure of replacing an implementation class by another class, e.g. to exchange Memory_AIX_PPC by Memory_WINNT_X86 when the agent moves from a host running AIX on a PorwerPC to another host which is running on a x86 CPU with Windows NT as operating system.
An important aspect of reconfiguration is the dynamic linking of the implementation classes into the core. Dynamic linking is supported by the Java core technology [#!LiBra1998!#], but in the context of this work, it is also important that the impact of the dynamic linking is as low as possible for the non-adaptable parts of the mobile code. In this section three proposals will be presented. The order in which the concepts are described correlates with the degree of transparency of linking to the mobile code. The section will conclude with an evaluation of the proposed concepts. As a result of the evaluation, one proposal will be chosen for the implementation of the prototype.