Aspect Generation Process 83

In the proposed Aspect model, the generation process of an Aspect can be viewed as the refinement of an AAF into an AF and finally into an AInst. If we define ∋ as refinement, then

AAF ∋ AF ∋ AInst

During this process of refinement, the Aspects are refined from the most abstract form of Aspect, namely AAF, to the less abstract form of Aspect, namely AF, and finally to the concrete and executable form of Aspect, namely AInst. There are different variations such as functional variations, parameterization variations, and platform variations among these three forms of Aspect.

AAF is defined by a set of XML Schemas, which specify the structure of an Aspect. AF is an XML file with the above schemas populated with data. User interaction is needed when refining an AAF to an AF. AInst is the final concrete programming source code of the Aspect. The transformation from an AF to an AInst is done by the Aspect Generator which takes AF and Semantic Interpreter (SI) as input. The process is automatic.

84

Figure 4.3 Product line based Aspect generation

As shown in Figure 4.3, a product family of the adaptation Aspects is designed to achieve high reusability. All Aspects are defined at three abstraction levels: AAF, AF, and AInst. These three abstraction levels of Aspects facilitate the reusability of adaptation Aspects as they realize different variations of these Aspects:

 Functional variations are achieved by a hierarchical classification of Aspects at AAF level. Aspects are classified into different types. With each type, an XML schema is used to define the structure of the selected Aspect.

 Parameter variations reflect the refinement of Aspects in specific adaptation circumstances, which is achieved by the determination of the values of CS and V in AF. Typically, user interaction is required to get parameter values. A software tool was developed to conduct the user interaction.

 Platform variations reflect the implementation of Aspects on particular AOP platforms, which is done by mapping the Aspect in AF format to AInsts in particular AOP platforms. The mapping process is fully automatic by using AOP platform and Aspect related Semantic

85

Interpreters. For each AOP platform, a set of corresponding interpreters need to be developed to deal with various types of Aspects in the specific AOP platform. The adaptation framework is extensible to new AOP platforms by developing appropriate interpreters.

With the basic definition in Figure 4.1, the tuple (CS, V) is refined across the three abstraction layers in both format and contents.

At AAF level, the tuple is an XML schema definition. CS consists of the elements to describe the common structure of an Aspect. V consists of the elements to declare the parameters of variations of the Aspect. All Aspects have the same CS at AAF level.

At AF level, conforming to the structure definition in AAF, the tuple is filled with the XML format data specific to an adaptation circumstance. CS will have the data such as the Aspect name, the signature of the particular component and method(s) on which the Aspect is to be applied. V will be filled with parameter values which determine the specific adaptation circumstances in which the Aspect is applied. Aspects at AF level are bound to specific Aspect types but are still AOP platform independent.

At AInst level, a concrete executable Aspect is generated automatically by the Aspect Generator. The common structure (CS), and variations (V) are finally mapped by a Semantic Interpreter into executable program code. We define T as the transformation process between AAF, AF, and AInst. We

define ST as the three states during the transformation. We define AT as the

actions during the transformation. Then the transformation is defined as follows:

86

T = <ST, AT>, where

ST = {AAF, AF, AInst}

AT = {a1, a2}, where

= {<AAF, AF>}, = _{{<AF, AInst>}}

Hence,

AAF AF AInst

The process of a1 is described in Figure 4.4:

1. GET AAF FROM ASPECT REPOSITORY 2. CHECK WHETHER AAF IS WELL-FORMED 3. VERIFY CS PART OF AAF

4. VERIFY V PART OF AAF 5. IF AAF IS INVALID 6. RETURN Ø 7. END IF

8. READ POINTCUT DEFINITION INFORMATION FROM USER 9. VALIDATE POINTCUT DATA AGAINST ITS AAF DEFINITION 10. IF POINTCUT DATA IS INVALID

11. RETURN Ø 12. END IF

13. READ ADVICE DEFINITION INFORMATION FROM USER 14. VALIDATE ADVICE DATA AGAINST ITS AAF DEFINITION 15. IF ADVICE DATA IS INVALID

16. RETURN Ø 17. END IF

18. READ VARIATIONS DATA FROM USER

19. VALIDATE VARIATIONS DATA AGAINST ITS AAF DEFINITION 20. IF VARIATIONS DATA IS INVALID

21. RETURN Ø 22. END IF

23. CREATE A NEW AF

24. FILL POINTCUT DATA INTO AF 25. FILL ADVICE DATA INTO AF 26. FILL VARIATIONS DATA INTO AF 27. RETURN AF

87 The process of a2 is described in Figure 4.5:

1. GET AF FROM ASPECT REPOSITORY 2. CHECK WHETHER AF IS WELL-FORMED 3. VERIFY AF AGAINST ITS AAF DEFINITION 4. IF AF IS INVALID

5. RETURN Ø 6. END IF

7. READ TARGET AOP PLATFORM FROM USER 8. CHECK SI IN REPOSITORY

9. IF SI IS UNAVAILABLE 10. RETURN Ø

11. END IF

12. GET POINTCUT DATA FROM AF 13. GET ADVICE DATA FROM AF 14. GET VARIATIONS DATA FROM AF

15. FILL POINTCUT DATA INTO PRE-DEFINED TEMPLATE IN SI 16. FILL ADVICE DATA INTO PRE-DEFINED TEMPLATE IN SI 17. FILL VARIATIONS DATA INTO PRE-DEFINED TEMPLATE IN SI 18. GENERATE AInst

19. RETURN AInst

Figure 4.5 The transformation between AF and AInst