As discussed in the previous sections, the application of AOP in projects involving an operating system, frameworks and applications can make use of diverse code generation processes. Additionally, using AOP the project configuration depends on the set of aspects to be woven into the base code, which must be defined prior to code generation. AspectC++ only considers in the weaving process the aspects contained in files with the .ah extension. Thus, the simpler way to disable an aspect is to rename the aspect file with a different extension (e.g. .ah_off). Other option is to copy the selected aspect files from a repository to the project directory.
An important project configuration issue is dealing with two or more versions of a base source code. The following types of base code software versions can coexist in a project:
• The original version. This version may have one or more functionalities that can be introduced by aspects. An example of this situation is the original version of the Semaphore class in BOSS, which uses synchronization features, as described in Section 6.3.3.
• A refactored version for applying AOP functionality. Some refactoring in the source code may be needed to allow the AOP application, as for instance, the creation of new methods to expose joint points to the aspect code, as described for the Semaphore class in Section 6.3.3.
• A modified version without a previous implemented functionality. This consists of a modified version that had some functionality removed from the base code in order to be introduced by aspects.
Therefore, if a project can be configured to implement a given feature with or without AOP, more than one version of the base source code must be maintained, which impacts software maintenance and evolution. Possible related scenarios include projects where AOP is being evaluated as an alternative implementation or projects where AOP is applied just for debugging and is not employed in final versions. In these cases, the management of more than one version of the same source code file may be required.
In the context of this work, project configuration had to be very flexible, in order to evaluate AOP implementations against pure OOP implementations. The configuration was entirely based on bash scripts running from the Linux’s command line. Scripts were used to: (a) define if AOP is applied; (b) define the AOP code generation process; (c) enable or disable individual aspects; and (d) select base source code files to be used in the code generation process. Ideally, aspect-oriented projects should have its configuration supported by special graphic tools used for product line software development, such as pure::variants [95]. An alternative approach might be the adoption of the configuration language used for building the Linux kernel and a buildroot system with graphical support like xconfig and gconfig.
6.5 Summary
This chapter has described how to apply Aspect-Oriented Programming to support the implementation of fault tolerance at various software levels and purposes.
The main target of AOP application is the introduction of fault tolerance at the application level, using the FT framework described in the previous chapter. This approach can be used to convey fault tolerance to an existing application without modifying its source code. Additionally, it modularizes the fault-tolerant code with advantages in flexibility and maintenance. The implementation is based on the definition of general abstract aspects for each FT strategy and application-specific concrete aspects that define the target thread and the required parameters and additional methods for the FT strategy execution. Abstract and concrete aspects have been explained based on an example of FT application using DRB and NVP.
The utilization of AOP to apply fault tolerance at the application level has several benefits: it reduces errors in introducing fault tolerance to legacy systems; it allows the validation of the functional part in advance; and it contributes to product line development and code reuse. The main drawback of AOP application for embedded systems development is the limited support in terms of aspect weavers and tools.
The integration of the FT framework into the operating system has also been discussed. Previously integrated to the operating system, the FT framework has been completely separated from the OS code, allowing its optional integration to be postponed to weaving/compilation time. This modularization reflects in easier software maintenance and reduced memory footprint for non-FT applications.
This chapter has also described the application of AOP to implement fault tolerance in the OS, by adding fault tolerance error detection mechanisms implemented as executable assertions that verify predicates or invariants related to the OS basic functionality. The FT functionality is introduced by aspects that can be optionally selected. The application of AOP for this purpose, as well as the relationship between the fault tolerance and the synchronization concerns has been exemplified using the semaphore functionality in BOSS.
Although AOP aims to simplify software maintenance, there may be projects in which AOP and pure OOP versions must coexist. In this situation several versions of the base code should be maintained, impacting software maintenance and evolution and increasing the complexity of the project configuration process; therefore the utilization of a graphic product line configuration tool is recommended.
Case studies and evaluation
This chapter describes the case studies developed to test the proposed FT framework and compares performance and costs of several configurations and implementations. Two case studies are presented: a sorting application and a radar filtering application. The description of the development and test environment applied in this work is initially presented.