Info-Component-Based Context Awareness - Proposal 2

The info-component approach extends the design pattern of functionality interface and implementation classes by info classes . To every implementation class an info class is assigned and provides the necessary information of the profile values. The reason for the separation of the implementation classes and the profile values is the basic requirement of dynamic adaptation, i.e. only to load code which is really needed. If implementation classes and the profile values are coupled inseparably, the implementation class must be loaded for context awareness purposes from the repository, but are perhaps never needed for the execution of the mobile code.

An example for the implementation info for Harddisk_WINNT_X86 might look like in figure .

 

Figure: Example of info class  

The context awareness loads all info classes and executes their matches() method. The context awareness loads the info classes from the repository specifying the functionality interface. The matches() method of the info classes implements the matching function and also contains the generating function.

In the example (s. figure ) the generating functions are realized by Environment.os() and Environment.arch(). For the matching function simple equality is sufficient in this case.

The improvement of this concept against the rules is the higher flexibility of describing and proving the environment. E.g. if the right implementation class from the implementation group IHarddisk can be resolved, all implementation infos must be loaded from the repository: Harddisk_AIX_PPCInfo, Harddisk_WINNT_X86Info and Harddisk_LINUX_X86Info.

The name of the implementation class can be resolved out of the class name of the implementation info. The application programmer creates for every implementation class an info class. The name of the info class has as root the implementation class name and the suffix Info. E.g. the info class for Harddisk_WINNT_X86 is Harddisk_WINNT_X86Info. This convention must be followed by the programmer, to guarantee that the repository finds the suitable info classes and that the context awareness can resolve the name of the implementation class out of the implementation info class name.

In the info class the environment for the implementation class is defined in the matching function. As shown in figure , the implementation class Harddisk_WINNT_X86 works only on a x86 host running Windows NT. In this concept the matching function also contains the generating function, which describes how these profiles values, i.e. x86 and Windows NT, are retrieved from the system. In the example shown in figure predefined functions from a class Environment are used. For the implementation classes implementing IConfiguration a function would be specified that describes how the default browser can be determined.

The disadvantage of this proposal is the loose coupling between the implementation class and the info class. This extension also roughly doubles the number of classes, which must be implemented by the programmer. The handicap of the big number of classes and the loose coupling between implementation classes and their info classes may be minimized by using a graphical programming editor. The graphical programming editor can supervise the coupling between the implementation classes and the info classes. It can enforce the naming convention and support the programmer by a clear presentation of existing implementation classes and info classes.

Nevertheless this workaround can not match the strength of potential structural linking between implementation classes and profile values. A promising approach is presented in the following section, which represents a refinement of the proposed above component model.