1: \section{Concluding Remarks}
2: \label{Sec:conc}
3:
4:
5: Refactoring to aspect-orientation aims at improving the
6: evolvability and reusability of a system. Important issues to be
7: considered in this context are (1) the adequacy of the aspect
8: solutions discussed by a number of authors when applied to a large
9: application, (2) the assessment of the support for and improvements
10: brought by refactoring to aspects, and (3) the challenges of behavior
11: conservation when migrating to aspect-supported
12: implementations.
13:
14: This paper addresses these problems by proposing a refactoring and
15: testing strategy to guide the migration process, and successively by
16: applying it to an open source Java system. The testing strategy aimed
17: at ensuring migration consistency, introduces an aspect-oriented fault
18: model and adequacy criteria. Further, aspect and refactoring designs
19: are analyzed for selected concerns in the system under investigation,
20: which also include new, complex examples of crosscuttings. The
21: analysis consists of a proposed aspect solution, associated validating
22: tests, and a trade-off review of the pre- and post-refactoring
23: implementations. The difficulties in assessing overall improvements
24: due to refactoring are turned into considerations about the
25: suitability of the language features and model for better supporting
26: the types of identified crosscutting concerns. We believe that the
27: development of aspect languages could benefit from catalogs that
28: associate types of crosscutting concerns to language mechanisms, and
29: we provide further input for such catalogs.
30:
31: The paper's main contributions are
32: (1) an aspect-oriented fault model and adequacy criteria;
33: (2) a refactoring strategy that emphasizes testing and the use
34: of aspect-oriented solutions;
35: (3) a detailed discussion of aspect refactorings and their testing implications,
36: as carried out on an existing system; and
37: (4) the initiation of an open source project that can be used
38: to experiment with aspect-oriented testing and refactoring,
39: and that can be used to compare an object with an aspect solution.
40:
41: The work described in this paper can be extended in various ways.
42: First, we will continue to experiment with \ajhd and other case studies,
43: in order to further extend the fault model, adequacy criteria, and refactoring catalogs.
44: Second we will use the proposed models and the experience gained from these
45: case studies to come up with automated tool support for both testing and
46: refactoring of aspect-oriented programs.
47: Last but not least, we will analyze the risks and benefits of the various
48: aspect solutions, and reflect on ways in which some of the limitations of
49: the current solutions can be resolved.
50:
51: In order to put our work in a broader perspective, we would like to refer to
52: Bray~\emph{et al} who state: ``assessment of aspect-oriented software
53: development in general is still arguably in its early
54: days''~\cite{BYCF04}. We argue that one of the prerequisites for such
55: an assessment is the availability of an aspect-oriented and non-aspect
56: oriented version of the same software system. Our work aims to create
57: such versions for a publicly available open source software system and
58: thereby enables experimental comparative software evolution research
59: to asses the benefits of aspect-orientation.
60:
61:
62: \subsubsection{Acknowledgments}
63: We would like to thank Magiel Bruntink (CWI),
64: Hylke van Dijk (TU Delft),
65: Marco Lormans (TU Delft),
66: and Tom Tourw\'{e} (CWI),
67: for reading earlier drafts of this paper.
68:
69: Partial support was received from SENTERNovem,
70: (Delft University of Technology, project MOOSE, ITEA 01002,
71: and CWI, project IDEALS, hosted by the Embedded Systems Institute).
72:
73:
74:
75:
76:
77: %%% Local Variables:
78: %%% mode: latex
79: %%% TeX-master: t
80: %%% End:
81: