Aspect mining is a reverse engineering process that aims at finding crosscutting concerns in existing systems. This paper proposes an aspect mining approach based on determining methods that are called from many different places, and hence have a high fan-in, which can be seen as a symptom of crosscutting functionality. The approach is semi-automatic, and consists of three steps: metric calculation, method filtering, and call site analysis. Carrying out these steps is an interactive process supported by an Eclipse plug-in called FINT. Fan-in analysis has been applied to three open source Java systems, totaling around 200,000 lines of code. The most interesting concerns identified are discussed in detail, which includes several concerns not previously discussed in the aspect-oriented literature. The results show that a significant number of crosscutting concerns can be recognized using fan-in analysis, and each of the three steps can be supported by tools.

Architecture and design patterns, as demonstrated solutions to recurring problems, have proved practically important and useful in the process of software development. They have been extensively applied in industry. Discovering the instances of architecture and design patterns from the source code of software systems can assist the understanding of the systems and the process of re-engineering. More importantly, it also helps to trace back to the original architecture and design decisions, which are typically missing for legacy systems. This paper presents a review on current techniques and tools for discovering architecture and design patterns from object-oriented systems. We classify different approaches and analyze their results. We also discuss the disparity of the discovery results from different approaches and analyze possible reasons with some insight. 1.

Many articles and tools have been proposed over the years for mining design patterns from source code. These tools differ in several aspects, thus their fair comparison is hard. Besides the basic methodology, the main differences are that the tools operate on different representations of the subject system and that the pattern definitions differ as well. In this paper we first provide a common measurement platform for three well-known pattern mining systems, Columbus, Maisa and CrocoPat. Then we compare these tools on four C++ open-source systems: DC++, WinMerge, Jikes and Mozilla. Columbus can discover patterns from the C++ source code itself, while Maisa and CrocoPat require the representation of a software system in a special textual format, so we extended Columbus to provide the common input for the two other tools. We compared these tools in terms of speed, memory consumption and the differences between the hits. While the first two aspects showed comparable results, the recognition capabilities were quite diverse. This is probably due to the significant difference in how the patterns to be recognized and formalized by the tools. Therefore we conclude that a more precise and formal description of design patterns would be desirable.

Frameworks are a valuable way to share designs and implementations on a large scale. Client programmers, however, have difficulty using frameworks. They find it difficult to understand non-local client-framework interactions, design solutions when they do not own the architectural skeleton, gain confidence that they have engaged with the framework correctly, represent their successful engagement with the framework in a way that can be shared with others, ensure their design intent is expressed in their source code, and connect with external files. A design fragment is a specification of how a client program can use framework resources to accomplish a goal. From the framework, it identifies the minimal set of classes, interfaces, and methods that should be employed. For the client program, it specifies the client-framework interactions that must be implemented. The structure of the client program is specified as roles, where the roles can be filled by an actual client program’s classes, fields, and methods. A design fragment exists separately from client programs, and can be bound to the client program via annotations in