Conclusions and Technique Contributions 155

9.2.1 Conclusions

Despite the success of component-based reuse, the mismatches (section 2.1.4.1) between available pre-qualified components and the specific reuse context in individual applications continue to be a major factor hindering component composition and therefore reusability. From a technical perspective, the reason is largely due to the difficulty of adapting these components to meet the specific needs of the user. The research during the study was based on the observation that existing reuse approaches and tools are weak in providing a mechanism to adapt components at an adequately deep level and meanwhile with sufficient automation.

The Aspect-oriented nature of the approach makes it particularly suitable for the improvement of non-functional features of the target component-based software, such as dependability and performance. However, existing AOP platforms do not support reusable Aspects and advanced weaving process effectively. Therefore, the reuse of Aspects and advanced weaving process support must be considered while applying AOP to component adaptation.

156

The approach applies Aspect-oriented generative adaptation to targeted components to correct the mismatch problem with eliminating the problems associated with current component adaptation and AOP approaches, so that the components can be integrated into the target application easily. The following work has been undertaken during the study:

A generative aspect-oriented component adaptation approach

Based on the successful points of existing technologies, such as generative programming, software product line, component adaptation, and AOP, a new generative aspect-oriented component adaptation approach focusing on non-functional issues to mismatch problems (section 2.1.4.1) has been developed. Meanwhile, the approach has provided the solution to the problems (section 3.1.7 and section 3.3.5) associated with current component adaptation approaches and AOP platforms.

In the approach, from the component view, there are two main parts for each Aspect: Common Structure and Variations. The Common Structure is the mechanism that is reused in several similar Aspects or target aspect oriented systems. On the other hand, Variations reflects the variations among different Aspects. Each Aspect shares the same structure in its Common Structure part and varies in its Variations part. In the abstract view, three levels are used to support the product family: Abstract Aspect Frame (AAF), Aspect Frame (AF), and Aspect Instance (AInst).

A framework to support the approach

As the embodiment of the approach, a generative aspect oriented component adaptation framework has been developed. The framework consists of two phases: Aspect oriented Component Adaptation Design and Aspect oriented Component Adaptation Implementation. The aim of Aspect oriented component adaptation design is to gather the specification for

157

component adaptation and the output of design stage is a PCAS. User intervention is required in the design stage. On the other hand, Aspect oriented component adaptation implementation is the automatic process of performing component adaptation according to the PCAS gathered in the design stage.

A prototype tool

As the implementation of the framework, a prototype tool (Chapter 7) was developed to support the component adaptation in the framework and to demonstrate its scalability. In the design phase, Component Analyzer and PCAS Editor were built to help developers building PCAS. On the other hand, Aspect Generator, Semantic Interpreter, and Aspect Weaver were developed to automate the Aspects generation and weaving process. Also, the Aspect Manager was developed to manage Aspects in three abstract levels.

Case studies

Three case studies (Chapter 8) have been undertaken to illustrate and evaluate the usability and correctness of the approach, in terms of its capability of building highly reusable and platform independent Aspects across various AOP platforms and providing an advanced flow control of weaving process.

In summary, the requirements defined in Section 3.4 have been fulfilled respectively:

 As a source code level adaptation technique, the approach performs deep level component adaptation focusing on non-functional issues. Although the aspect oriented design still needs user intervention, the aspect oriented implementation is a fully automatic process.

158

 With the two dimensional Aspect model, highly reusable Aspects in various AOP platforms have been supported in the approach.

 The advanced weaving process with the support of flexible flow control has been implemented in AspectJ, pure Java, and C#. Depending on different target platform, PCAS based weaving or pre- weaving process is supported.

 As the adaptation knowledge is hidden in the Semantic Interpreters, and in the Aspects, the system users do not need to know too much details of the complex syntax of AOP languages. Therefore, the approach has a short learning curve.

9.2.2 Contributions

The GAIN technology enables application developers to adapt the pre- qualified components to eliminate mismatches to the integration requirement of specific applications. From a component adaptation point of view, the original contribution of this thesis is the automation and deep level adaptation of components, focusing on non-functional issues by introducing extra process, operations and resources. As the feature inherited from AOP, all non-functional issues solved by AOP can also be addressed by GAIN, e.g., Monitoring, Policy enforcement, Persistence, Optimization, Authentication, Authorization, Transaction Management, and implementing business rules. From the AOP point of view, the original contribution is the improved reusability of Aspects and the support of advanced weaving process. The key technical contributions [41][103] are summarised below: 1) Product line based reusable Aspect model [44][103] (section 4.2). In the

approach, a two dimensional Aspect model was developed, e.g. component view and abstraction view of Aspect. Within the two dimensional Aspect model, all Aspects are designed to be reusable in both dimensions. From the component point of view, each Aspect is split into common structures (CS) and variations (V), which support software

159

product line based reuse. On the other hand, from the abstraction point of view, each Aspect has three levels of abstraction: AAF, AF, and AInst. There are different types of variations in these abstractions, including functional variations, parameterisation, and platform variations. During the whole Aspect oriented adaptation process, from the designing of different Aspects in AAF, to the implementation of AOP platform independent Aspects in AFs, to the implementation of concrete AOP platform specific Aspects in AInsts, all Aspects are presented in two parts: CS and V, no matter which abstract level they are, such as AAF, AF, or AInst.

2) Highly reusable and AOP platform independent adaptation Aspects [101][103] (section 5.2). With the support from the product line based Aspect model, the adaptation knowledge is captured in Aspects and is reusable in various adaptation circumstances. Highly reusable Aspects, especially in AAF and AF level are achieved. Different types of Aspect are saved in XML schema as AAF. Platform independent Aspects are implemented in XML as AFs. With the support of AFs, the learning curve of AOP becomes shorter because AOP platform specific syntax is hidden in the related tool, namely the Aspect Generator and Semantic Interpreters. Platform specific Aspects are automatically generated from these AFs by selecting corresponding Semantic Interpreters as required. 3) Aspect Repository for Aspect reuse [42][43][44]. As an embodiment of the

product line based reusable Aspect model, an expandable library of reusable adaptation Aspects at three abstraction levels is used as storage for various levels of Aspects. With the support of three abstract levels of Aspects in Aspect repository, the reusability of the framework is increased incrementally. In addition, the combination of Aspects and control flows are saved in the Aspect repository as Aspect Frameworks and can be reused in the similar adaptation situations.

4) Advanced Aspect weaving process [102][103] (section 6.5). In AOP, it is possible that several Aspects need to be woven at the same join point. In these cases, these Aspects may have problems such as determining the exact execution order and dependencies among the Aspects. The

160

enhanced Aspect weaver supports the advanced weaving processes, e.g. sequence and switch structure in a weaving process. Pre-defined advanced weaving processes may be also added into the Aspect repository as Aspect Framework for further reuse.