Structure of Profile Values

For the implementation of the Integrated Profile Based Context Awareness of section , the profile values are mapped to a class hierarchy (s. figure ).

The root of the hierarchy is the abstract class ProfileValue which implements only the matching function, in figure the matching function is denoted as matches(). The generating function is only defined, here denoted as getEnvProfileValue(). The other two methods equals() and sameType() are needed two compare implementation profile values in order two check whether two profiles would match for the same environment.

The various types/properties of profile values are direct subclasses of ProfileValue, e.g. the class OperatingSystem in the case of the leading example. The types implement the generating functions of the environment property, i.e. getEnvProfileValue(). The subclasses of the types represent concrete profile values of the environment properties as separate classes, e.g. the class Linux.

The generating functions assumes that the superclasses know all the subclasses. The class OperatingSystem must know that there is a class Linux that must be built if the name of the operating system is ``Linux''. Such a construction works fine as long as the set of subclasses is fixed and not intended to be extended. This would constrain the reuse of profile values or requrie re-writing of the profile values if new types and value are added to the profile values hierarchy.

 

Figure: Extension by profile value BSD  

In figure the profile value UNIX knows the operating systems Linux , AIX and Solaris . The different Unix flavors are implemented as subclasses of the superclass UNIX. If a new Unix operating system, e.g. BSD , would be added, the generating function of class UNIX must be re-written, in order to support the generation of an object of the class BSD. Besides of the re-writing of code, the UNIX profile value would change its semantic for already existing applications using the class UNIX as a representation for Unix flavors.

The solucation is provided by introduction of a new Unix profile value, e.g. Ext UNIX (s. figure ). This new profile value is used as re-presentant of Unix in new applications. It knows how to generate a profile value on a host running BSD. If the context awareness runs in another operating system it requests its superclass, i.e. UNIX, to generate a profile value.

 

Figure: Introduction of superclass for extension  

This approach is not sufficient for the matching function. If an implementation is suitable for UNIX operating systems, including BSD , e.g. Configuration_UNIX_NETSCAPE, its profile contains the profile value Ext UNIX . If the mobile code moves to host running AIX , the context awareness applies the matching function as defined and implemented in the superclass ProfileValue: If the profile value of the environment is the same class or a subclass of the profile value of the implementation class, the implementation class is suitable for the environment

The rule fails, because the class Linux is not a subclass of Ext UNIX, though the implementation class is intended to work also in a Linux environment.

Part of the solution is provided by the Marker Interface design pattern [#!Gr1998!#]:

``The Marker Interface pattern uses interfaces that declare no methods or variables to indicate semantic attributes of a class.''

The interface IExtension, which defines no methods, serves as marker interface. The class Ext UNIX implements the interface IExtension(s. figure ).

 

Figure: Hierarchy of profile value classes in class diagram  

The semantic attribute of IExtension is that classes which implement the interface are not considered to be superclasses in terms of the matching function. Though the class Ext UNIX is a superclass of BSD in the Java class hierarchy, it is not a superclass in the context of the matching function applied on BSD. The class Ext UNIX is ignored and UNIX is taken as superclass. This relation is shown in figure .

 

Figure: Logical hierarchy of profile values due to marker interface  

If Ext UNIX is defined by an implementation class it includes both the own sub profile values, i.e. BSD , and the profile value under the super profile value UNIX

The inspection of the classes, e.g for determining whether a class is marked by IEtension is done by using Java Reflection.