Goals: Investigating the impact of verification tools and approaches on the reliability and verification time of AO programs; and proposing tools and approaches to support the verification process.

Problem: The new constructs available in aspect-oriented languages represent new sources of faults, in particular when considering the impact of aspects on the exception flow of programs. Such faults bring new challenges to software testing, static analysis and debugging.
During the verification process of an AspectJ system, the developers usually apply ad hoc approaches to check the reliability of the program, such as: writing and executing functional tests, adding logging statements, or performing smoke testing (i.e., they execute the application and uses it until a failure occurs).
Some tools and approaches have been proposed that aim at detecting and diagnosing specific faults in AO programs, but no empirical study was conducted to asses their effectiveness.

Proposed Approach: Our approach to tackle this problem is twofold: (i) to conduct an experimental study to assess the effectiveness of a set of tools proposed by our group, and (ii) to evaluate the opportunities of tool integration.
The experimental study is going to be our first short/medium-term goal. This study will be conducted in the context of classes at the University of Sao Paulo/Sao Carlos and hopefully at other universities. It will involve a group of Masters and PhD students that will perform a set of verification tasks according to the experiment’s plan.
In parallel we are going to evaluate the possibilities of integrating the three tools. Firstly, Roberta and Guillaume will work on integrating the SAFE tool into Eclipse, potentially reusing the data base structure and some GUI components of TOD - it will avoid a bias caused by the non-user-friendly textual output of SAFE. Secondly, we are going to investigate the use of the set of tools (i.e., TOD, SAFE and JABUTi) through a web interface. A third step would be the integration of the data structures of the three tools, as a way of enabling a synergy between static analysis, structural testing and debugging. For instance, the developer could navigate through the data collected during structural tests and static analysis while debugging.

Detailed report.

This group has the task to investigate testing criteria, techniques and tools adequate to PL testing. At the very end, the aim is to contribute to the establishment of low-cost, efficient testing strategies in the context of PL development, ideally in the scope of a pre-defined PL development process. We would also like to conduct experimental studies with the perspective of evaluating the cost and benefits of developing products based on product lines against the traditional approaches. We consider in the scope of this study developing open educational and training modules to support the use and dissemination of the underlying concepts and tools. This research line is motivated by the fact that there are few initiatives of systematically addressing testing in the scope of product line production. It is also of our interest to explore other VV&T techniques, such as inspection and PL architecture evaluation. We will explore these ideas in the scope of two PL domains: meshing tools and interpreters, as discussed in the detailed report below.

Detailed report.

The main objective of this group is to bring to AO well-known benefits of traditional modularization mechanisms. Particularly, the main purpose of the work is to provide language support to the parallel development of both classes and aspects. In order to address this goal, we have discussed several forms of interfaces already proposed in the literature to decouple the implementation of classes and aspects. After that, we have sketched our first proposal of crosscutting interfaces, that addresses the main drawbacks of the existent proposals.

Basically, our proposal unifies the notions of aspects and classes, removing the differences among such concepts. For example, in our proposal classes can declare pointcuts, advices and intertypes. By relying in our interfaces, developers can work in a independent way, having the right to access interface members implemented by other modules. In a last step, developers can configure an application using the instantiation mechanisms supported by the language.

We have discussed and showed examples of applying our language in the implementation of the Observer design pattern and in automated case tests for software product lines.

Next steps:

1. Definition of the language's syntax and informal semantics.
2. Implementation of more examples using the language.
3. Definition of the language's formal semantics
4. Implementation of a prototype compiler or interpreter.
5. Paper to a major venue (eg. FSE'09, ECOOP'09, OOPSLA'09)

Next meeting: SBLP 2008, August 27-29, Fortaleza

The objective of this group is to investigate the applicability of aspect-oriented techniques and concepts to Model Driven Development. On a first stage we focus on model transformations, and specifically, on enabling the use of aspects for expressing (parts of) model transformations.

A widely known classification of model transformation approaches acknowledges that aspects and reflection mechanisms can be used with model transformation languages. However we found that aspects are explicitly addressed, but not precisely specified, in one transformation language only, which is not rule-based.

The first research question to investigate is what targets of aspects in model transformation languages could be. We considered two alternatives: (a) different concerns present in the source and target models, and (b) different concerns of the model transformation itself. In any case, a second research question we asked ourselves is whether aspects are really present in model transformations. We found that aspects commonly handled in traditional software, such as persistence or security, were not directly applicable to this specific domain. To address this issue we first explored the need of aspctecs by evaluating tangling and scattering within both models and transformations. To that end we started developing a case study of a model transformation operating on a source model including more than one concern. Additionally, we realized that rule-based model transformation languages can be already regarded as aspectual languages, since the left-hand side (LHS) of a rule could be a pointcut expression, while the right-hand side (RHS) of a rule could be an advice. A third research question is whether cunstructs currently found in most model transformation languages are enough for properly define and manage aspects withtin model transformations. We expect that the implementation of our case study would provide some answers. The ultimate goal of the present research stage is to come up with a list of requirements for a Aspect Oriented Model Transformation Language for evaluating if additional constructs in transformation lanaguages are required.

Aspect-orientation concepts extended traditional software development in a useful way. We aim for finding if similar benefits can be introduced in model transformation development. As we found that this issue is not obvious, we plan to summarize the result of the research described above as a challenge to be submitted to the Challenges in Model Driven Engineering (ChaMDE) workshop associated to MoDELS'2008. We plan to further develop these ideas, which would lead to a conference paper where the application of aspect-orientation is shown in terms of current standard constructs, the details of new constructs are presented, or even a hybrid approach based on existing and new constructs is proposed. As a more long term commitment we also plan to integrate the results to each gruop's research and to collaborate in the context of funded projects.

The main goal of this group is to define a model-based aspect-oriented software product line (SPL) development environment, named MaRiPLA (Mapping Requirements to Product Line Architecture), that focus on the mapping from SPL requirements to SPL architecture. MaRiPLA applies (i) aspect-oriented software development (AOSD) to modularize variability and (ii) model-driven development (MDD) to express models of each software activity and to define model transformations between requirements and architecture activities.

Detailed report.