An Integrated Crosscutting Concern Migration Strategy and its Application to JHotDraw

Despite significant research efforts on various parts of the refactoring of crosscutting concerns from existing systems, to date there exists no compelling show-case for such a complete migration. One of the main causes for this void is the fact that there is no clearly defined, coherent migration strategy detailing the steps to be taken to perform this process.

Successful migration requires a strategy comprising steps like identification of the concerns (i.e., aspect mining), description of the concerns to be refactored, and consistent refactoring solutions to be applied. Moreover, such a strategy requires integrated migration steps, so that aspect mining results, for example, can be consistently mapped onto concerns in code, and further refactored by general aspect solutions. The present state of the art prevents developers and practitioners from experimenting with a complete migration process and assessing the benefits of migrating to AOP.

In this paper, we propose such an integrated strategy for migrating crosscutting concerns to aspects, which consists of four main steps: (1) idiom-driven identification of crosscutting concerns in an existing system (aspect mining); (2) exploration of (the context of) the concerns identified in the previous step; (3) query-based modeling and documentation of crosscutting concerns in the system; (4) template-based refactoring of the object-oriented idioms into AOP solutions.

Our strategy builds upon the classification and decomposition of crosscutting concerns in so-called crosscutting concern sorts that we proposed earlier [11,13]. Each sort describes the typical implementation idiom and relation of crosscutting concerns. Sorts act as glue between the successive steps of the migration: The mining step in our strategy uses the sort-specific idioms to define search-goals for identifying crosscutting concerns that belong to a specific sort (i.e., sort instances). To support the exploration and documentation steps, we have formalized the concern sorts using queries over source code and implemented these in a tool for browsing and modeling crosscutting concerns [14].

While the first three steps of our approach have been covered in our earlier work, this paper focuses on the fourth step and its connection with the three preceding steps. In particular, we define template solutions for the aspect refactoring of our sorts (to AspectJ). Furthermore, we describe a case study in which we apply the whole migration strategy to JHOT-DRAW, 1 an object-oriented application used in other aspect mining and refactoring studies as well [10,2,12,1]. The results of our migration are available under version control as an open-source project on sourceforge called AJHOTDRAW, which is also the largest aspect refactoring publicly available to date that we are aware of.

The remainder of the paper is organized as follows. In next section, we recall the notion of crosscutting concerns sorts. We describe the migration strategy and elaborate on the first three steps in Section 3. The sort-based aspect refactoring approach that we introduce for the fourth step is presented in Section 4. Section 5 covers our experiences with migrating crosscutting concerns in JHOTDRAW to aspect solutions. Section 6 discusses the results and outlines a number of lessons learned. We conclude with an overview of related work and recommendations for future research.

A systematic migration strategy requires a consistent way to address crosscutting concerns in source code. To this end, we distinguish a number of atomic crosscutting concerns (i.e., concerns that cannot be split into smaller, still meaningful concerns) that share properties like their implementation idioms and relations. We group concerns that share such properties in categories called crosscutting concern sorts [11]. These sorts can be used on their own, but can also be composed to construct more complex crosscutting designs, for example, the Observer pattern, often used as a typical example of crosscuttingness.

The first two columns of Table 1 describe the identified sorts and show several examples of instances (the other columns will be introduced in later sections). Consistent behavior, for instance, groups concerns whose implementation consists of scattered calls to a specific method implementing the crosscutting functionality. Instances of this sort include, for example, a logging concern, a simple authentication or authorization concern implemented as a call to a method checking credentials, or a mechanism for updating observers using calls to

…(Full text truncated)…