Software systems can be seen as a collection of concerns. As they age, they need to be adapted to changing requirements: features may need to be added, algorithms or the underlying operating system might change, parts may become obsolete etc. In general, particular concerns of the system are affected and have to be updated. Such refactoring tasks are especially difficult if the concern in question crosscuts the systems' modularity units (in OO: classes). Tool support can be helpful to identify and visualize the complete extent of such "hidden" concerns.
Joint with Hidehiko Masuhara, Günter Kniesel
Certain software features, such as security, memory management, and logging, are inherently difficult to modularize using traditional program decompositions (such as classes and methods). Implementations of such concerns tend to crosscut the module structure of software systems, and pose a problem for developers who want to understand or maintain them, as they result in scattered and tangled code. Aspect-oriented programming (AOP) is a relatively new programming paradigm that offers explicit program structures, called aspects, for the modularization of such crosscutting concerns (CCCs). Developers who would like to adopt AOP to improve the modularity of their legacy OO systems, face the challenge of identifying non-modularized CCCs in their code (aspect mining) before they can refactor them into aspects.
Our work focuses on using a structural concern model to identify non-modularized CCCs in software systems. In this aspect mining approach, the structural properties of the modeled concerns are compared to those of the target program’s abstract syntax tree. Potential matches can then be used to prompt the suggestion of appropriate refactorings into aspects. In particular, we plan to utilize the mining results in our previously developed semi-automated refactoring tool.
Joint with Gail Murphy, Martin Robillard, William Griswold, and Wesley Leong
A developer evolving a software system experiences first-hand the consequences of modularity decisions made during earlier development. All too often, the developer must expend a significant effort tracking code pertaining to the software change of interest that was not modularized. To help with the activity of elaborating a concern, a software developer may use any of a number of existing tools, including standalone search tools, browsers integrated into a software development environment, or compilers. We believe it is possible to offer more effective support for concern elaboration activity, and have thus introduced three tools: AspectBrowser, AMT and FEAT. A developer using these tools formulates and runs a query over a model of the program and evaluates the query results. The results of the query often cause a developer to refine the query and repeat the process, which ultimately leads to an identification of the code of interest. In this study, we compared the three tools with respect to suitability for concern elaboration tasks.
Joint with Gregor Kiczales
Contemporary modularization techniques such as OOP, although helpful, often fail to encapsulate design decisions that crosscut a software systems' module structure. Code related to one crosscutting concern is often tangled with other code and spread out over a number of different classes. Capturing these concerns in first-order modules (Aspects) can increase the code’s modularity significantly. Consequently, many programmers find the idea of Aspect Oriented Programming (AOP) appealing but don’t know where to start: As the module structure is crosscut by these concerns, many modules have to be considered together to identify and extract Aspects. The Aspect Mining Tool (AMT) provides an visual multi-modal analysis framework for concern identification and system understanding. AMT offers both lexical and type-based analysis techniques.
Last modified: 2007/10/16;
Page Information
|
Wiki Information |
Recent PBwiki Blog Posts |