A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Reverse Engineering Low-Level Design Patterns From Object-Oriented Code.

The purpose of this research is to develop and automatically extract an abstract representation model of object-oriented (abbreviated as OO) software systems that captures the structure of the system and code dependencies, in order to aid maintenance. The research resulted in the development of two abstract representation models--the low-level design pattern (LLDP) abstract model and the low-level software architecture (LLSA) abstract model. The LLDP model is at a higher level of abstraction than the LLSA model. The LLSA model acts as an intermediate representation between the LLDP model and an OO software system. The design of the LLSA and LLDP representation models and the automatic extraction of these models from an OO software system are significant contributions of this research. An LLDP representation is a textual description of common OO strategies. Three sets of LLDPs--polymorphism, decoupling and messages are defined. LLDPs describe the structure, the benefits and consequences of a strategy. The design of the LLSA model considers the complexities inherent in OO systems, and the requirements of a maintainer from such a model. The LLSA model defines software components, static and dynamic interfaces of components and static and dynamic interactions between components. Software components are defined in terms of OO programming language constructs and interactions between the components are defined in terms of OO relationships that exist between the components. Understanding the relationships is necessary to understand what dependencies occur and why they occur in the code. The LLSA abstract model in conjunction with the LLDPs provides a view of software systems that captures the dependency relationships between code, the nature of the dependencies and the reasons why the dependencies must exist and be preserved. The LLSA model of C++ software systems in particular are defined. The usefulness of LLSA and LLDPs from the maintenance perspective are explored. A prototype CASE tool, pulse was implemented to demonstrate the feasibility of automatic extraction of both models. Reverse engineering and code analysis techniques were developed to extract the LLSA relationships and interfaces and to recognize LLDPs