Programming Effort

 The prototype is written in Java. For the integration of the adaptable classes into the core no further meta languages are needed. The description of the implementation profiles and the environment profiles is realized in Java. Therefore R1 is fulfilled up to a certain degree.

Some key concepts are based on reflection. Thus, the concept is only applicable to OO programming languages supporting reflection. Inconvenient in terms of R1 is the interaction with the framework, which does not support other programming languages than the one used for its implementation. If the adaptation concept is used for an application written in a different programming language, the framework must be ported for the new programming language and cannot be reused.

The second requirement concerning the programming effort considers the overhead in terms of lines of code or number of classes (R2). The solution as implemented in the prototype requires programming a functionality interface, which is environment independent, and the development of the implementation classes, one class for each environment.

If it is assumed, that for static customization a separate class for each environment has to be designed, because of modular programming, the number of classes needed for dynamic adaptation is not higher than for static customization.

The explicit description of the environment in every implementation class instead of conditional branches as assumed in static customization, affords more lines of code, but improves the maintainability at the same time.

Requirement R2 is met it terms of number of classes. The lines of code needed for dynamic adaptation are increased, but it also offers the advantage of better maintainability.

Requirement R3 concerns the placement of the profiles in relation to the implementation class. A strong coupling of profile and implementation classes simplifies the maintenance and avoids inconsistencies. As described in section according to the proposed methodology the profiles are specified within a method body of the implementation class. This offers a high level of integration and therefore meets R3

For avoiding a broad spectrum of errors during runtime due to adaptation, R4 requires to detect possible failures during compilation. Since the proposed methodology implements the profiles in a conventional programming language, (s. discussion about R1 above), it is guaranteed that the profiles are implemented correctly concerning the syntax. The profile checker, which is integrated into the repository proves the profiles of an implementation class and delivers information about conflicting profiles. Whether the right profile is specified in the implementation, i.e. the profile describes the right environment, for which the implementation class is suitable, is a potential source of errors, which can be detected at runtime only. Other failures might occur due to unreachable repositories or an environment which is not supported by an implementation class.

Such errors must be handled by the application during runtime and are part of the second set of requirements, which covers the integration of an adaptation mechanism into the application. Whether the proposed methodology fulfills these requirements is discussed in the following section.