ConcernMapper - An extensible plug-in for Eclipse

A brief introduction of ConcernMapper:


A concern is a set of related methods and code-fragments of a large project that are related to a certain feature of the software but are scattered in multiple classes. These concerns can be monitored in a user-friendly view provided by the ConcernMapper plug-in where you can easily see the tree structure of the concern elements as they are found in your software code while also being able to keep together all elements that are part of one concern in the software design.
The ConcernMapper is an Eclipse plug-in for experimenting with techniques for advanced separation of Concerns. It supports software development involving scattered concerns and also paves way for new research methods in software investigation by observations of concern creation and usage during development of large software projects. (Official ConcernMapper site)

The Extension project:

Although ConcernMapper provided a very good feature, there was a restriction to this useful plug-in that it only supported Java Elements such as methods and fields in the Concern Model. This means that a concern could only contain fields and methods defined in a Java Class. However many people in the industry and academia use languages other than Java and would like to have a similar tool for the language of their choice.
The problem with encoding other types of elements directly into the plug-in is that there are an unlimited number of useful types that one could want to add to a Concern Model, each with its own special features and properties and it would be infeasible to continuously hack into the code of an independently complete plug-in.
The extensible platform of Eclipse provides a plug-in architecture which suggested the solution to this problem. The existing ConcernMapper could be changed into a generic plug-in implementing the ConcernMapper with support for a generic element node in its model. We could then write, plug-ins extending this generic ConcernMapper plug-in to specify the exact type for some new element that the Concern Model would then support. This would also allow further customization on the elements supported in the ConcernMapper depending upon the level of abstraction provided by the ConcernMapper. For the purpose of this project, this abstraction has been limited to the level where the existing functionality of the ConcernMapper can be reproduced for the existing supported types (i.e. Java Methods and Java Fields) as well as the addition of a new type unrelated to the Java Elements having complete and independent functionality of its own.
This required that the ConcernMapper host plug-in make no reference to any specific type of element throughout its code. Due to the extensive use of Java specific helper methods to provide special functionality for elements in the ConcernMapper caused by the assumption that the elements stored in the concern model are always one of two types of Java Elements, the ConcernMapper plug-in had to be re-visited throughout the code to replace the Java specific code with a general processing of all element types for each functionality at the locations found. Doing so required varying strategies depending upon the specific task being re-designed. This transformation of the existing ConcernMapper into an extensible version was the objective of this project.

A complete report of how the project makes use of the plug-in extension architecture of Eclipse, can be found here.
Presentation slides for this project are also available.

A few screenshots that capture the modified plug-in's functionality are provided below.

The workings of concernmapper.

The extensible concernMapper with an extension running for detecting and allowing additions for regular files, e.g. an xml file.

Sample code that performs the extension processing throught the eclipse platform.

The original ConcernMapper currently being maintained by Professor Martin Robillard is available here.



Back to HOME