Final Report Summary - RIVAR (Rich Interfaces for Verifiable Aspect Reuse)
As software systems become increasingly bigger and more important to our daily lives, systematic, formally-grounded software engineering becomes paramount. At least 2 fundamental problems need to be addressed:
1. The increasing size and complexity of software systems requires effective techniques for breaking problems into parts and recombining partial solutions to integrated systems. A variety of dimensions need to be considered in this; these may originate from the structure of the problem and from the set of tasks required to build and maintain the software system. What is a good modularisation from one perspective, may be very problematic from another one.
2. The large scale of the systems to be built implies that they require a large number of developers organised into a substantial hierarchy of teams. Thus no single individual maintains complete oversight of the project, which can cause significant problems with integration and can even lead to errors remaining undetected in the software system. Systematic software engineering needs to provide support for formal verification of partial and integrated software system to give acceptable levels of assurance wrt the reliability of the software produced.
RIVAR has addressed these issues from the more specific perspective of Aspect-oriented programming (AOP), specifically based on AspectJ. AOP aimed to address the need for different modularisation strategies by introducing a new type of module -called an aspect- that may cut across existing modules in a software system. This allows programmers to effectively maintain several modularisation hierarchies in parallel and intermix them to produce a complete, integrated system.
This flexibility is paid for with a number of challenges. For example, reusing aspects in applications different from the one they have originally been designed for is still considered difficult as there are no explicit specifications of the assumptions aspects make on the system environment into which they will be woven nor of the guarantees they provide on how they will change (or leave unchanged) the behaviour of the base system. This is the key problem RIVAR has addressed.
In a first stage, RIVAR analysed the source code of 3 large AspectJ-based systems to identify specific assumptions made by developers of these systems. These were then categorised to produce a comprehensive catalogue of aspect assumption types, published in a paper at the International Conference on Aspect-Oriented Software Development, 2011. This catalogue can already be useful on its own for a variety of purposes. For example, it can be used for assumption elicitation in code walkthroughs: For every aspect inspected, developers can use the catalogue of assumption types to ask questions of the form 'Am I implicitly making an assumption of type XXX here?'
Furthermore, RIVAR has provided templates of formal expressions of the assumption types that can, in principle, be instantiated and used for formally verifying that an aspect's assumptions hold in a concrete base system with which it is to be woven. These templates can be made accessible to aspect developers through dedicated extensions of the AspectJ language. For some of the assumption types, this has been demonstrated through a prototype implemented based on the open-source, extensible AspectJ compiler abc.
These implementations, together with published papers and raw data collected can be obtained from the project website at http://www.steffen-zschaler.de/projects/?project=rivar
The project also aimed to train the fellow Dr Steffen Zschaler enabling him to contribute to the European research community as an independent researcher. This has been fully achieved: The fellow has been offered a position as lecturer in computer science at King's College in London halfway through his fellowship. In this new position, he is already PI for a European Initial Training Network and is working on establishing his own research group.
1. The increasing size and complexity of software systems requires effective techniques for breaking problems into parts and recombining partial solutions to integrated systems. A variety of dimensions need to be considered in this; these may originate from the structure of the problem and from the set of tasks required to build and maintain the software system. What is a good modularisation from one perspective, may be very problematic from another one.
2. The large scale of the systems to be built implies that they require a large number of developers organised into a substantial hierarchy of teams. Thus no single individual maintains complete oversight of the project, which can cause significant problems with integration and can even lead to errors remaining undetected in the software system. Systematic software engineering needs to provide support for formal verification of partial and integrated software system to give acceptable levels of assurance wrt the reliability of the software produced.
RIVAR has addressed these issues from the more specific perspective of Aspect-oriented programming (AOP), specifically based on AspectJ. AOP aimed to address the need for different modularisation strategies by introducing a new type of module -called an aspect- that may cut across existing modules in a software system. This allows programmers to effectively maintain several modularisation hierarchies in parallel and intermix them to produce a complete, integrated system.
This flexibility is paid for with a number of challenges. For example, reusing aspects in applications different from the one they have originally been designed for is still considered difficult as there are no explicit specifications of the assumptions aspects make on the system environment into which they will be woven nor of the guarantees they provide on how they will change (or leave unchanged) the behaviour of the base system. This is the key problem RIVAR has addressed.
In a first stage, RIVAR analysed the source code of 3 large AspectJ-based systems to identify specific assumptions made by developers of these systems. These were then categorised to produce a comprehensive catalogue of aspect assumption types, published in a paper at the International Conference on Aspect-Oriented Software Development, 2011. This catalogue can already be useful on its own for a variety of purposes. For example, it can be used for assumption elicitation in code walkthroughs: For every aspect inspected, developers can use the catalogue of assumption types to ask questions of the form 'Am I implicitly making an assumption of type XXX here?'
Furthermore, RIVAR has provided templates of formal expressions of the assumption types that can, in principle, be instantiated and used for formally verifying that an aspect's assumptions hold in a concrete base system with which it is to be woven. These templates can be made accessible to aspect developers through dedicated extensions of the AspectJ language. For some of the assumption types, this has been demonstrated through a prototype implemented based on the open-source, extensible AspectJ compiler abc.
These implementations, together with published papers and raw data collected can be obtained from the project website at http://www.steffen-zschaler.de/projects/?project=rivar
The project also aimed to train the fellow Dr Steffen Zschaler enabling him to contribute to the European research community as an independent researcher. This has been fully achieved: The fellow has been offered a position as lecturer in computer science at King's College in London halfway through his fellowship. In this new position, he is already PI for a European Initial Training Network and is working on establishing his own research group.