AO4AADL
Aspect Oriented Extension for AADL
The proposed Approach
In this page, we outline our approach for designing aspect oriented architectures. We propose a complete process, starting with a rigorous specification until the enforcement upon the execution and the generation of aspect code. As shown in Fig.1, our approach consists mainly in three phases:
1) Implementing Functional code: In this phase, the designer should focus on the main functionalities of his application without considering any non-functional properties. First, he specifies, at the architectural level, his applications in terms of AADL elements (components, connectors, threads, ports, etc.). Then, the designer generates the corresponding functional code using a code generator. In fact, many compilers have attempted to translate an AADL specification in several languages such as Ada, C or RTSJ (Real Time Specification for Java).
2) Designing non-functional properties: At this phase, the designer defines the non functional safety properties and states the conditions under which his application operates correctly, such as security, availability, etc. To express these crosscutting concerns at the architectural design level, the designer should use our aspect language called AO4AADL. We proposed a complete grammar of our AADL language as well as its different syntactic and semantic rules. These aspects will be integrated as annexes in the AADL specification to form an aspect oriented architectural description of the software system.
3) Generating non-functional properties code: Since our proposed language is generic, AO4AADL aspects can be translated in different aspect languages such as AspectJ or JAC for Java language, AspectAda for Ada language, AspectC for C language, etc. This generation requires an aspect generator and a well defined transformation rules from A04AADL to the considered aspect language. These transformation rules should take into consideration the transformation rules already existing for generating the functional code. The conformity of the generators ensures the consistency between the functional code and aspects. These aspects will be automatically integrated in the generated functional code, which will lead to a complete prototype.
In our approach, we focus on the generation of RTSJ code from AADL specifications using Ocarina suite tools. Therefore; we implemented a prototype of AspectJ generator based on a set of transformation rules which will be detailed in the following section.
Fig.1: Principle of the proposed approach