Estrategias para Alcanzar el Confort de acuerdo con ASHRAE 55-2004

As the approach is the combination of / the improvement to AOP and component adaptation techniques, it is justified in applying the technique requirements of component adaptation approaches and AOP approaches respectively.

In table 9.1, the GAIN approach is compared with other component adaptation approaches. All these approaches are evaluated on how well each technique fulfils the specified component adaptation requirements in section 2.1.6.

150 Adaptation techniques R1 R2 R3 R4 R5 R6 R7 R8 Copy-paste - + - - - - + - Inheritance - + - - - - + - Wrapping + - + - - - - +/- SAGA - + - + - - + - Superimposition + - + + + - - - BCA - + - - - - + - Customizable Components - - + + + + - - Non-Invasive approach to WS + + + + - +/- + +

Wrapper for WS adaptation + - + - - - - +

GAIN - + + + + +? + + R1: Black-box R2: Transparent R3: Composable R4: Reusable R5: Configurable R6: Automatic

R7: Deep level adaptation R8: Language independence +: fulfilled

-: not fulfilled

+/-: fulfilled or not fulfilled depending on the application context +?: Semi-automatic

Table 9.1 The comparison between GAIN and other component adaptation techniques

The comparison outcomes are justified as follows:

R1: Black-box

Since currently GAIN is a source code level adaptation technique, the implementation details of original component must be obtained prior to performing the adaptation. Therefore, the black-box requirement is not fulfilled.

151

R2: Transparent

Since the end-user of the adapted component is unaware of the adaptation between original component and the adapted component, the transparent requirement is fulfilled.

R3: Composable

Since the adaptation process can be composed with other adaptation methods, no matter how many adaptations are applied to the original component, the composable requirement is fulfilled. This process is repeatable.

R4: Reusable

With the support of the two-dimensional Aspect model, Aspect repository and related tool, GAIN is capable of providing platform-independent, highly reusable Aspects to deal with various adaptation circumstances if the required Aspects are available in the repository. Therefore, the reusable requirement is fulfilled.

R5: Configurable

With the support of product line based Aspect model, any abstraction level Aspect has two parts, namely, Common Structure (CS) and Variations (V). In the Variations part, flexible configurations for each type of Aspect are supported by providing various parameters to Aspects and combining different elements within Aspects. Therefore, the configurable requirement is fulfilled.

R6: Automatic

The approach is semi-automatic in performing component adaptation. The Aspect oriented component adaptation design still needs human

152

intervention. However, with the support of the CASE tool, the Aspect oriented component adaptation implementation is fully automatic. As long as the adaptation requirements are described in PCAS, the component adaptation can be performed by simply clicking a button. Benefits from AOP and the automation of the approach, the disadvantages of source code level adaptation such as maintenance and evolution concerns (refer to section 2.1.5.1) have been eliminated as the adaptation concerns are logically separated from the original component(s) and the adaptation process is semi-automatic.

R7: Deep level adaptation

As source code level adaptation is performed in GAIN, the deep level adaptation are supported in the approach by organizing various Aspects in PCAS and performing adaptation by parsing and executing the adaptation process defined in PCAS.

R8: Language independence

With the three abstraction level of Aspects and a set of Semantic Interpreters, language independence is achieved in GAIN. All Aspects can be represented as a language independent form as Aspect frames (AF). On the other hand, considering GAIN as an improvement to Aspect-oriented programming technology, in table 9.2, GAIN approach is evaluated by comparing with other popular AOP technologies.

153

AOP approaches T1 T2 T3 T4 T5 T6 T7

Aspectual Component - + - - -

JAsCo - + - + - - -

Shared Join Points Model - - - - + - -

Framed Aspects - + + + - + +

GAIN + + +/- + + + +

T1: Short learning curve T2: Reusable

T3: Light weight T4: Configurable

T5: Advanced weaving process T6: Language independence T7: Generative Aspects

+: fulfilled -: not fulfilled

+/-: whether fulfil the requirement or not depending on the target AOP platform

Table 9.2 The comparison between GAIN and other AOP techniques The outcomes are justified as follows:

T1: Short learning curve

With support from the associated CASE tool, in the Aspect oriented design stage, end users only need to understand basic concepts in AOP such as pointcut and advice and fill relative parameters for selected AFs. The PCAS is generated automatically by the tool. In the Aspect oriented implementation phase, the job is even easier because the generation of individual Aspects and the adaptation process are fully automatic. Therefore, compared with existing AOP platforms, the GAIN framework is easy to use.

T2: Reusable

All Aspects in GAIN are designed following a software product line based Aspect model. While reflecting different variations in AAF, AF, and AInst, the

154

Aspects are highly reusable. For example, an AF can be reused in various AOP platforms by employing appropriate Semantic Interpreters. Therefore, the reusable requirement is fully fulfilled.

T3: Light weight

The GAIN framework could be heavy or light weight, depending on which target AOP platform is selected and which Semantic Interpreter is selected to generate AInsts. By default, Aspect Generator generates Aspect in the same programming language source code as the component being adapted. In this case, the framework is light weight. On the other hand, when the target AOP platform is an existing heavy weight AOP platform, the Aspect Generator generates heavy weight source code in the selected AOP platform. Therefore, in this case, the GAIN framework is heavy weight.

T4: Configurable

With the support of product line based Aspect models, any abstraction level Aspect has two parts, namely, Common Structure (CS) and Variations (V). In the Variations part, flexible configurations for each type of Aspect are supported by providing various parameters to Aspects and combining different elements within Aspects. Therefore, the configurable requirement is fulfilled.

T5: Advanced weaving process support

To meet the complex adaptation requirements, the advanced weaving process such as switch structure is supported to enhance the weaving in the join points in the GAIN approach.

T6: AOP programming language independence

With the three abstraction level of Aspects and a set of Semantic Interpreters, language independence is achieved in GAIN. All Aspects are

155

represented as a language independent form as Aspect frames (AF), and may be mapped to any AOP language if appropriate Semantic Interpreter is available. Currently, the supported languages in GAIN include AspectJ, Java, and C#.

T7: Generative Aspects

The automatic generation of individual Aspects is supported by the Aspect Generator and Semantic Interpreters in GAIN. Whether the required Aspects in AInst level can be generated by GAIN depends on the availability of the Semantic Interpreters.