J. Software Engineering & Applications, 2010, 3: 303-311
doi:10.4236/jsea.2010.34036 Published Online April 2010 (http://www.SciRP.org/journal/jsea)
303
Separation of Fault Tolerance and Non-Functional
Concerns: Aspect Oriented Patterns and
Evaluation
Kashif Hameed, Rob Williams, Jim Smith
University of the West of England, Bristol Institute of Technology, Bristol, UK.
Received January 1st, 2010; revised January 30th, 2010; accepted February 1st, 2010.
ABSTRACT
Dependable computer based systems employing fault tolerance and robust software development techniques demand
additional error detection and recovery related tasks. This results in tangling of core functionality with these cross cut-
ting non-functional concerns. In this regard current work identifies these dependability related non-functional and
cross-cutting co ncerns and proposes design and implementation solu tions in an aspect oriented framewor k that modu-
larizes and separates them from core function a lity. The degree o f sep aration has been quan tified us ing so ftwa re metrics.
A Lego NXT Robot based case study has been completed to evaluate the proposed design framework.
Keywords: Aspect Oriented Design and Programming, Separation of Concerns, Executable Assertions, Exception
Handling, Fault Tolerance, So ftware Metrics
1. Introduction
Adding fault tolerance (FT) measures and other non-
functional requirements to safety critical and mission
critical applications introduces additional complexity to
the core application. By incorporating handler code, for
error detection, checkpointing, exception handling, and
redundancy/diversity management, the additional com-
plexity may adversely affect the dependability o f a safety
critical or mission critical system.
One of the solutions to reduce this complexity is to
separa te and modular ize the extra , cross-cu tting conce rns
from the true functionality.
Although Rate of Change (ROC) based plausibility
checks for error detection and recovery have been ad-
dressed by [1,2], unfortunately none of the previous stu-
dies propose the separation of these error handling con-
cerns from true functionality to avoid complexity.
At the level of design and programming, several ap-
proaches have been utilized that aim at separating func-
tional and non-functional aspects. Component level ap-
proach like IFTC [3], computational reflection and me-
ta-object protocol based MOP [4] have shown that de-
pendability issues can be implemented independently of
functional requirements.
The evolving area of Aspect-Oriented Programming &
Design (AOP&D) presents the same level of independ-
ence by supporting the modularized implementation of
crosscutting concerns.
Aspect-oriented language extensions, like AspectJ [5]
and AspectC++ [6] pr ovide mechanisms like Advice (be-
havioural and structural changes) that may be applied by
a pre-processor at specific locations in the program
called join point. These are designated by pointcut ex-
pressions. In addition to that, static and dynamic modifi-
cations to a program are incorporated by slices which can
affect the static structure of classes and functions.
The current work thus proposes some generalized as-
pect oriented design patterns representing fault tolerance
error detection and recovery mechanisms like ROC plau-
sibility checks, exception handling, checkpointing and
watchdog. Moreover some additional design patterns for
developing robust mission/safety critical software are also
presented. Software metrics like coupling, cohesion and
size have been applied quite successfully to access and
evaluate the quality attrib utes of OO software systems [7,
8]. However separation of concerns (SOC) especially
cross cutting ones in the light of new abstraction ad-
dressed by AO software development demands some ad-
ditional metrics. The current work reviews these addi-
tional metrics like concern diffusion over the components
(CDC), concern diffusion over the operations (CDO) and
concern diffusion over the lines of code (CDLOC). The

Separation of Fault Tolerance and Non-Functional Concerns: Aspect Oriented Patterns and Evaluation 304
SOC metric suite is later applied on the proposed AO
patterns in an empirical case study. This helps evaluating
the degree to which AOSD modularizes the FT concerns
and its impact on other quality attributes.
The validation and dependability assessment of pro-
posed AOFT patterns has already been done in an earlier
work by the author [9].
2. Aspect Oriented Exception Handling
Patterns
Exception handling has been deployed as a key mecha-
nism in implementing software fault tolerance through
forward and backward error recovery mechanisms. It
provides a convenient means of structuring software that
has to deal with erroneous condition s [10].
In [11], the authors addresses the weaknesses of ex-
ception handling mechanisms provided by mainstream
programming languages like Java, Ada, C++, C#. In their
experience exception handling code is inter-twined with
the normal code. This hinders maintenance and reuse of
both normal and exception handling code.
Moreover as argued by [12], exception handling is
difficult to develop and has not been well understood.
This is due to the fact that it introduces additional com-
plexity and has been misused when applied to a novel
application domain. This has further increased the ratio
of system failures due to poorly designed fault tolerance
strategies.
Thus fault tolerance measures using exception han-
dling should make it possible to produce software where
1) error handling code and normal code are separated
logically and physically; 2) the impact of complexity on
the overall system is minimized; and 3) the fault toler-
ance strategy may be maintainable and evolvable with
increasing demands of dependability.
In this respect, [4] has proposed an architectural pattern
for exception handling. They address the issues like spe-
cification and signaling of exceptions, specification and
invocation of handlers and searching of handlers. These
architectural and design patterns have been influenced by
computati onal refl ect i on and meta-object prot ocol .
However, most meta-programming languages suffer
performance penalties due to the increase in meta-level
computation at run-time. This is because most of the de-
cisions about semantics are made at run-time by the me-
ta-objects, and the overhead to invoke the meta-objects
reduces the system performance [13].
Therefore we propose generalized aspect based pat-
terns for monitoring, error detection, exception raising
and exception handling using a static aspect weaver.
These patterns would lead to integration towards a robust
and dependable aspect based software fault tolerance.
The following design notations have been used to ex-
press aspect-oriented design patterns shown in Figure 1.
2.1 Error Detection and Exception Throwing
Aspect
Error detection and throwing exceptions has been an an-
chor in implementing any fault tolerance strategy. This
aspect detects faults and throws range, input and output
type of exceptions. The overall structure of this aspect is
shown in Figure 2. The GenThrowErrExcept join points
the NormalClass via three pointcut expressions for each
type of fault tolerance case.
RangeErrPc: this jo in points the contexMethod() only.
It initiates a before advice to check the range type errors
before executing the contextMethod(). In case the asser-
tions don’t remain valid or acceptable behavior con-
straints are not met, RaneErrExc exception is raised.
InputErrPc: this join points the contextMethod() fur-
ther scoped down with input arguments of the con-
textMethod(). It initiates a before advice to check the
valid input before the execution of the context method.
Incase the input is not valid it raises InputErrExc.
OutputErrPc: this join points the contextMethod()
Figure 1. Aspect oriented design notations
Figure 2. Error detection, exception throwing

Separation of Fault Tolerance and Non-Functional Concerns: Aspect Oriented Patterns and Evaluation305
further scoped down with results as output of the con-
textMethod(). It initiates an after advice to check the va-
lid output after the execution of the context method. In-
case the output is not valid it raises OutputErrExc.
2.2 Rate of Change Plausibility Check Aspect
This aspect as shown in Figures 3 and 4 is responsible for
checking the erroneous state of the system based on the
rate of change in critical signal/data values. Once an er-
roneous state is detected, the respective exception is
raised. Various exceptions are also defined and initial-
ized in this aspect. The pointcut GetSensorData defines
the location where error checking plausibility checks are
weaved whenever a critical data/sensor reading function
is called. The light weight ROC-based plausibility asser-
tions are executed in the advice part of this aspect.
2.3 Catcher Handler Aspect
The CatcherHandler aspect as shown shown in Figure
5(a) is responsible for identifying and invoking the ap-
propriate handler. This pattern addresses two run-time
handling strategies.
The first strategy is designated by an exit_main point-
Figure 3. Rate of change aspect pattern structure
Figure 4. Rate of change aspect pattern dynamics
cut expression. It checks the run-time main() function for
various fatal error exceptions and finally aborts or exits
the main program upon error detection. This aspect may
be used to implement safe shut-down or restart mecha-
nisms in safety critical systems to ensure safety, if a fatal
error occu rs or safety is breached.
The second strategy returns from the called fu nction as
soon as the error is detected. The raised exception is
caught after giving warning or doing some effective ac-
tion in the catch block. This can help in preventing error
propagation. Using this aspect, every call to critical func-
tions is secured under a try/catch block to ensure effec-
tive fault tolerance ag ainst an erroneous state.
It can be seen in the Figure 5(a) below th at exit_main
pointcut expression join points the main() run-time func-
tion. Whereas caller_return pointcut expression join
points every call to the contextMethod(). Moreover ex-
it_main and caller_return pointcut expressions are asso-
ciated with an around advice to implement error handling.
The tjpproceed() allows the execution run-time main()
and called functions in the try block.
The advice block of the catcher handler identifies the
exception raised as a result of in-appropriate changes in
the rate of signal or data. Once the excep tion is identified,
the recovery mechanism is initiated that assign new val-
ues to signal or data variables based on previous trends
or history of the variable.
2.4 Dynamics of Exception Handling Aspect
This scenario shown in Figure 5(b) represents a typical
error handling case. It simulates two error handling
strategies. In the first case, control is returned from the
caller to stop the propagation of errors along with a sys-
tem warning. In the second case the program exits du e to
a fatal error. This may be used to implement shutdo wn or
restart scenarios. Moreover the extension of a class
member function with a try block is also explained. A
client object invokes the contextMethod() on an instance
of NormalCl ass . The control is transferred to Catcher-
Handler aspect that extends the contextMethod() by
wrapping it in a try block and executes the normal code.
In case an exception is raised by previous aspect, the
exception is caught by the CatcherHandler aspect. This
is shown by the catch message. The condition shows the
type of exception e to be handled by the handler aspect.
CatcherHandler aspect handles the exception e. the call-
er_return strategy warns or signals the client about the
exception and returns from the caller. The client may
invoke the contextMethod2() as appropriate. In exit_main
strategy, the control is retuned to client that exits the
current instances as shown by the life line end status.
3. Watch Dog Aspect
A watchdog is a common concept used in real time sys-
tems for detecting and handling errors in real time sys

Separation of Fault Tolerance and Non-Functional Concerns: Aspect Oriented Patterns and Evaluation 306
(a)
(b)
Figure 5. Catcher handler aspect. (a) Structure; (b) Dy-
namics
tems. It is a component that detects error by receiving a
delayed or null service response. Based on such timing
faults, it initiates a corrective action, such as reset, shut-
down, alarm to notify attending personnel, or signaling
more elaborate error-recovery mechanisms. Sometimes
software watchdogs are more active by performing peri-
odic built-in-tests (BIT). Synchronous tasks are more
prone to such timing based faults resulting in mission
failures.
In this regard we present a watchdog aspect (Figure 6)
to make such tasks fault tolerant by weaving an advice
code. Thus every synchronous mission critical task is
monitored against a deadline that is derived from the
worst case execution time of the overall task. As the d ead
line is expired, the mission is aborted. The watchdog
aspect is presented below. It can be seen that every call
to a contextMethod() of a NormalClass is weaved with
a timing check to see whether time delay between curren t
and previous call exceeds the dead line or not. The
watchdog aspect communicates with an external clock
interface to receive time stamps. Thus the watch dog
aspect separates timing concerns from the true function-
ality. It also localizes the definition and signaling of ex-
ceptions.
4. Save Data and Checkpointing Aspect
Some tasks require context related critical data to be
stored for post analysis and executing recovery mecha-
nisms. Every call to these tasks is weaved with a data
saving advice. SaveData aspect (Figure 7) provides
checkpointed stable recovery data to be used in ROC
based error detection and recovery mechanisms.
Whenever a critical function is called, SaveData as-
pect stores the contextual state information with the help
of MemoryInterface.
5. System Configuration & Initialization Aspect
Most real time systems rely on sensors in-order to attain
Figure 6. Watchdog aspect
Figure 7. Save data & checkpointing aspect

Separation of Fault Tolerance and Non-Functional Concerns: Aspect Oriented Patterns and Evaluation307
physical information from external environment. These
sensors need to be configured and initialized depending
upon the modes of operation. For example a Lego NXT
robot (Tribot) used in our case study uses light, ultra-
sonic and rotation sensors to carry out tasks. These sen-
sors are mapped on respective ports of the NXT brick.
Moreover they must be initialized before starting actual
tasks. It has also been observed that rotation sensors are
reinitialized as the direction of rotation changes (when
Tribot start traversing backward). All such requirements
either cut-across true functional concern or emerges as
additional non-functional requirement. Such require-
ments have been implemented in an aspect thus separat-
ing them from true functional concern. This aspect is
weaved as a startup advice in the control flow of main
program.
6. Mission Pre-Conditions Aspect
Mission critical real time systems require some pre-con-
ditions or constraints to be met before starting the core
task. For example Tribot check the voltage level of bat-
teries and ambient light before staring its mission so that
it could fulfill its tasks reliably. If the above constraints
are not met, mission is aborted. Such constraints are
cross cutting to core functional requirements and thus
implemented as a separate aspect as shown as shown in
Figure 8.
As soon as the software finishes system initialization,
the said aspect acquires environmental data from the
SensorInteface and checks against the pre-conditions or
constraints. If the constraints are not met, an exception is
thrown and mission is ab orted.
7. Case Study
In order to evaluate proposed AO design patterns, a case
study has been carried out using a LEGO NXT Robot
(Tribot). This uses an Atmel 32-bit ARM processor run-
ning at 48 MHz. Our development environment utilizes
AspectC++ 1.0pre3 as aspect weaver [6].
The Tribot has been built consisting of two front
wheels driven by servo motors, a small rear wheel and an
arm holding a hockey stick with the help of some stan-
dard Lego parts. Ultrasonic and light sensors are also
available for navigation and guidance purposes.
An interesting task has been chosen to validate our de-
sign. In this example Tribot hits a red ball with its hock-
ey stick avoiding the blue ball placed on the same ball
stand. It makes use of the ultrasonic and light sensors to
complete this task. This task is mapped on a goal-tree
diagram as shown in Figure 9.
Any deviation in full-filling the OR goals and corre-
sponding AND sub-goals is considered as a mission
failure.
8. Aspects Evaluation via So ftware Metrics
Although software metrics like coupling, cohesion and
size has been used to access the software quality for quite
some time, yet the separation of concerns especially
cross cutting ones with the aid of aspect oriented soft-
ware development demands some additional metrics
suite for its assessment. In this regard [14-16] have pro-
posed additional metric suite for separation of concerns.
This metric suite has been utilized in [17] to access the
quality of some large scale software systems.
These additional metrics measure the degree to which
a single concern in the system maps to the design com-
ponents (classes and aspects), operations (methods and
advice), and lines of code. For all the employed metrics,
a lower value implies a better result. Some of these met-
rics used in our study are explained below.
8.1 Separation of Concerns Metrics
Separation of concern s (SoC) refers to th e ability to id en-
tify, encapsulate and manipulate those parts of software
that are relevant to a particular concern. The metrics for
Figure 8. Mission pre-condition aspect
Leg o NXT
Hockey Player
Hit Red Ball Miss Blue Ball
Move Forward & Stop
25 cm short of ball post
Differentiate Ball
Move Back
OR
A
N
DA
N
D
Figure 9. Lego NXT robot case study: Goal tree diagram

Separation of Fault Tolerance and Non-Functional Concerns: Aspect Oriented Patterns and Evaluation 308
SoC measurement are:
Concern Diffusion over Components (CDC)
This metric measures the degree to which a single
concern in the system maps to the components in the
software design. The more direct a concern maps to the
components, the easier it is to understand. It is also easier
to modify and reuse the existin g components.
Definition: CDC is measured by counting the number
of primary components whose main purpose is to con-
tribute to the implementation of a concern. Furthermore,
it counts the number of components that access the pri-
mary components by using them in attribute declarations,
formal parameters, return types, throws declarations and
local variables, or call their methods.
Concern Diffusion over Operations (CDO)
One way of measuring the code tangling is by count-
ing the number of operations affected by concern code. If
a concern is scattered around more operations, it be-
comes harder to understand, maintain and reuse.
Definition: CDO is measured by counting the number
of primary operations whose main purpose is to contrib-
ute to the implementation of a concern. In addition, it
counts the number of methods and advices that access
any primary component by calling their methods or using
them in formal parameters, return types, throws declara-
tions and local variables. Constructors also are counted
as operations.
Concern Diffusion over LOC (CDLOC)
The intuition behind this metric is to find concern
switching with in the lines of code. For each concern, the
program text is analyzed line by line in order to count
transition points. The higher the CDLOC, the more in-
termingled is the conc ern code within the implementation
of the components; the lower the CDLOC, the more lo-
calized is the concern code.
Definition: CDLOC counts the number of transition
points for each concern through the lines of code. The
use of this metric requires a shadowing process that par-
titions the code into shadowed areas and non-shadowed
areas. The shadowed areas are lines of code that imple-
ment a given concern. Transition points are the points in
the code where there is a transition from a non-shadowed
area to a shadowed area and vice-versa. An extensive set
of guidelines to assist the shadowing process is reported
in [15].
8.2 Coupling Metrics
Coupling is an indication of the strength of interconnec-
tions between the components in a system. Highly cou-
pled systems have strong interconnections, with program
units dependent on each other [14]. The larger the num-
ber of couples, the higher the sensitivity to changes in
other parts of the design and therefore maintenance is
more difficult. Excessive coupling between components
is detrimental to modular design and prevents reuse. The
more independent a component is, the easier it is to reuse
it in another application [14]. The metrics in this cate-
gory are Coupling between Components (CBC) and
Depth of Inheritance Tree (DIT).
Coupling between Components (CBC)
This counts the coupling between classes, classes and
aspects and between other aspects. It counts the classes
used in attribute declarations i.e. C2 and C3 depicted in
figure below. It also counts the number of components
declared in formal parameters, return types, throws dec-
larations and local variables. Moreover classes and as-
pects from which attribute and method selections are
made are also included.
New coupling dimension are also defined in [14] in
order to support aspect oriented software development
(AOSD). For e.g. access to aspect methods and attributes
defined by introduction (couplings C4, C5, C7, C8, C10),
and the relationships between aspects and classes or oth-
er aspects defined in the pointcut (couplings C6, C9) as
depicted in Figure 10. Thus overall this metric encom-
passes nine coupling dimensions (from C2 to C10). If a
component is coupled to another component in an arbi-
trary number of forms, CBC counts only once.
Depth of Inheritance Tree (DIT)
DIT is defined as the maximum length from a node to
the root of the tree. It counts how far down the inheri-
tance hierarchy a class or aspect is declared. This metric
encompasses the coupling dimensions C1 and C11 illus-
trated in Figure 10.
8.3 Lego NXT Software Measures Analysis
Software metrics are attained for the Lego NXT Robot
case study as shown in Figure 11. In this case study, a
C++ based true function ality has been made fau lt tolerant
by weaving various concerns in 30 places using 7 aspects
and 10 independent point cut expressions. These 7 as-
pects represent different concerns that otherwise may be
added to actual true concern making the code more tan-
gled, non maintainable and non reusable.
Separation of Concern Measures
Separation of concerns has been evaluated using CDC,
CDO and CDLOC figures attained in the above case
study.
The Concern Diffusion over the components (CDC)
metrics measures the mapping of a single concern on
various components. It can be inferred from Figure 12
below that there is 64% reduction in mapping of true
concern on the components present in the system due the
introduction of aspects. Moreover the individual aspects
implementing cross cutting concerns don’t present large
CDC figures that means, the aspects are loosely coupled
with the system and thus can be more powerful candi-
dates for reusability.
Same behavior has been observed in CDO measures as
shown in Figure 13. As argued in [15,16], the code tang-

Separation of Fault Tolerance and Non-Functional Concerns: Aspect Oriented Patterns and Evaluation 309
Figure 10. Coupling dimensions on AOSD [14]
Figure 11. Lego NXT software metrics
ling may be visualized by observing the diffusion of a
concern in different operations. Again the true concern
seems more tangled in different operations as compared
to cross cutting concerns implemented as aspects.
Concern diffusion over the lines of code (CDOLC) is a
measure of how much tangled and inter-winded is the
code implemented for a component. The larger the value,
more tangled is the code with other concerns.
CDLOC for the core functionality (TCS) counts to 2
that seems a reasonable reduction as compared to non
aspect oriented implementation. The seven non-fun-
ctional/cross cutting concerns may add to presen t a larger
CDLOC (Figure 14).
It can also be observed from the CDLOC dispersion
that there are some indicators of bit code tangling with
the true functionality especially for the aspects responsi-
ble for error detection and exception handling. Upon
code reviewing it was observed that some critical con-
textual information is required that resulted in concern
switching. Apart from that, overall concern switching for
each component is reasonably small to be considered
better candidates for reusability and maintainability.
There were four concerns implemented with null concern
switching in this study.
Coupling Measures
As observed in the study by [17], the coupling be-
tween components for various concerns has not increased
a lot in our case as well. Coupling between components
seem to be uniformly distributed with an average value
of 2 as shown in Figure 15. Apart from core functional-
ity (TCS), the increased coupling has been observed in
the concerns implementing error detection and recovery

Separation of Fault Tolerance and Non-Functional Concerns: Aspect Oriented Patterns and Evaluation 310
mechanisms. This is due to the fact that aspects imple-
menting these concerns are coupled with the core con-
cern for acquiring contextual information used in error
detection and recovery mechanisms.
Exception Throwing & Handling Measures
It can be seen from Figures 16(a) and 16(b) that ex-
ceptions definition and throwing have been localized in
the components responsible for error detection like ROC
plausibility Checks and Watch Dog. Moreover, ex ception
handling has also been localized in their respective as-
pects without diffusing an y other component.
TCS
36%
EPC
16%
ECI
11%
SD
11%
WD
5%
ROC
5%
EMH
5%
RCH
11%
Figure 12. CDC dispersion
TCS
42%
EPC
7%
ECI
7%
SD
8%
WD
8%
ROC
3%
EMH
8%
RCH
17%
Figure 13. CDO dispersion
TCS, 2
EPC, 0
ECI, 0
SD, 0
WD
,
0
RO C, 2
EMH, 1
RCH, 1
Figure 14. CDLOC dispersion
9. Conclusions & Future Work
The current work proposes AO design patterns for de-
veloping fault tolerant and robust software applications.
The aspect oriented design patterns under this frame-
work bring additional benefits like the localization of
error handling code in terms of definitions, in itializations
and implementation. Thus error handling code is not du-
plicated as the same error detection and handling aspect
is responsible for all the calling contexts of a safety
critical function. Reusability has also been improved
because different error handling strategies can be plugged
in separately. In this way, aspect and functional code
may both be ported more easily to new systems.
Although a detailed analysis of concerns separation
through aspects by refactoring large scale software ap-
TCS, 3
EPC, 3
ECI, 2
SD, 3
WD, 1
RO C , 1
EM H, 1
RCH, 3
Figure 15. Coupling between components
EPC, 2
WD, 1
RO C, 4O T HERS, 0
(a)
EMH, 1
RCH, 2
O T HERS, 0
(b)
Figure 16. (a) Exceptions define & throw; (b) Try/catch
blocks

Separation of Fault Tolerance and Non-Functional Concerns: Aspect Oriented Patterns and Evaluation 311
plication has been provided in [17]. Our case study also
compliments some of the results. It has been observed
that localization of exception management (definition,
initialization and throwing) and exception handling im-
proves modularity. It has been observed that fault toler-
ance concerns when implemented as aspects have re-
sulted in considerable reduction in diffusion of concerns
over the core functionality. The concern diffusion in
terms of LOC does indicate clear separation and localiza-
tion of error management related issues. However some
code tangling has been observed with error detection
based aspects. This is due to the sharing of context in-
formation needed for detecting erroneous states. Apart
from that CDLOC measures too small in the true func-
tionality. Coupling has been increased in the components
responsible for error detection. Thus overall there has
been an improvement in separation of concerns at the
cost of slightly increased coupling.
This further probes the need for incorporating an error
masking strategy like Recovery Blocks and N-Version
Programming. An aspect oriented design version of these
strategies is also under consideration.
REFERENCES
[1] M. Hiller, et al., “Executable Assertions for Detecting
Data Errors in Embedded Control Systems,” Proceedings
of the International Conference on Dependable Systems
& N etwo rks, New York, June 2000, pp. 24-33.
[2] M. Hiller, “Error Recovery Using Forced Validity As-
sisted by Executable Assertions for Error Detection: An
Experimental Evaluation,” Proceedings of the 25th EU-
ROMICRO Conference, Milan, Vol. 2, September 1999,
pp. 105-112.
[3] P. A. C. Guerra, et al., “Structuring Exception Handling
for Dependable Component-Based Software Systems,”
Proceedings of the 30th EUROMICRO Conference (EU-
ROMICRO’04), Rennes, 2004, pp. 575-582.
[4] A. F. Garcia, D. M. Beder and C. M. F. Rubira, “An Ex-
ception Handling Software Architecture for Developing
Fault-Tolerant Software,” Proceedings of the 5th IEEE
HASE, Albuquerque, November 2000, pp. 311-332.
[5] AspectJ Project Homepage. http://eclipse.org/aspectj/
[6] AspectC++ Project Homepage. http://www.aspectc.org
[7] S. Chidamber and C. Kemerer, “A Metrics Suite for Ob-
ject Oriented Design,” IEEE Transactions on Software
Engineering, Vol. 20, No. 6, June 1994, pp. 476-493.
[8] V. Basili, L. Briand and W. Melo, “A Validation of Ob-
ject-Oriented Design Metrics as Quality Indicators,”
IEEE Transactions on Software Engineering, Vol. 22, No.
10, October 1996, pp. 751-761.
[9] K. Hameed, R. Williams and J. Smith, “Aspect Oriented
Software Fault Tolerance,” Proceedings of 4th Interna-
tional Conference on Computer Science & Education
(WCE09), London, Vol. 1, 1-3 July 2009.
[10] L. L. Pullum, “Software Fault Tolerance Techniques and
Implementation,” Artech House Inc., Boston, London, 2001.
[11] F. C. Filho, et al., “Error Handling as an Aspect,” Work-
shop BPAOSD’07, Vancouver, 12-13 March 2007.
[12] A. Romanovsky, “A Looming Fault Tolerance Software
Crisis,” ACM SIGSOFT Software Engineering Notes, Vol.
32, No. 2, March 2007, p. 1.
[13] K. Murata, R. N. Horspool, E. G. Manning, Y. Yokote
and M. Tokoro, “Unification of Compile-Time and
Run-Time Metaobject Protocol,” ECOOP Workshop in
Advances in Meta Object Protocols and Reflection
(Meta’95), August 1995.
[14] C. Sant’Anna, et al., “On the Reuse and Maintenance of
Aspect-Oriented Software: An Assessment Framework,”
Proceedings of the 17th Brazilian Symposium on Soft-
ware Engineering, Salvador, October 2003, pp. 19-34.
[15] A. Garcia, et al., “Agents and Objects: An Empirical
Study on Software Engineering,” Technical Report 06-03,
Computer Science Department, PUC-Rio, February 2003.
ftp://ftp.inf.puc-rio.br/pub/docs/techreports/(file03_06_ga
rcia.pdf)
[16] A. Garcia, et al., “Agents and Objects: An Empirical
Study on the Design and Implementation of Multi-Agent
Systems,” Proceedings of the SELMAS’03 Workshop at
ICSE’03, Portland, May 2003, pp. 11-22.
[17] F. C. Filho, et al., “Exceptions and Aspects: The Devil in
Details,” Proceedings of the 14th ACM SIGSOFT Inter-
national Symposium on Foundations of Software Engi-
neering, Portland, 5 November 2006.