Radu Marinescu

Detection strategies: metrics-based rules for detecting design flaws

In order to support the maintenance of an object-oriented software system, the quality of its design must be evaluated using adequate quantification means. In spite of the current extensive use of metrics, if used in isolation metrics are oftentimes too fine grained to quantify comprehensively an investigated design aspect (e.g., distribution of systems intelligence among classes). To help developers and maintainers detect and localize design problems in a system, we propose a novel mechanism - called detection strategy - for formulating metrics-based rules that capture deviations from good design principles and heuristics. Using detection strategies an engineer can directly localize classes or methods affected by a particular design flaw (e.g., God Class), rather than having to infer the real design problem from a large set of abnormal metric values. We have defined such detection strategies for capturing around ten important flaws of object-oriented design found in the literature and validated the approach experimentally on multiple large-scale case-studies.

Measurement and quality in object-oriented design

In order to support the maintenance of object-oriented software systems, the quality of their design must be evaluated using adequate quantification means. In spite of the current extensive use of metrics, if used in isolation, metrics are oftentimes too fine grained to quantify comprehensively an investigated aspect of the design. To help the software engineer detect and localize design problems, the novel detection strategy mechanism is defined so that deviations from good-design principles and heuristics are quantised inform of metrics-based rules. Using detection strategies an engineer can directly localize classes or methods affected by a particular design flaw (e.g. God Class), rather than having to infer the real design problem from a large set of abnormal metric values. In order to reach the ultimate goal of bridging the gap between qualitative and quantitative statements about design, the dissertation proposes a novel type of quality model, called factor-strategy. In contrast to traditional quality models that express the goodness of design in terms of a set of metrics, this novel model relates explicitly the quality of a design to its conformance with a set of essential principles, rules and heuristics, which are quantified using detection strategies.

Using history information to improve design flaws detection

As systems evolve and their structure decays, maintainers need accurate and automatic identification of the design problems. Current approaches for automatic detection of design problems are not accurate enough because they analyze only a single version of a system and consequently they miss essential information as design problems appear and evolve over time. Our approach is to use the historical information of the suspected flawed structure to increase the accuracy of the automatic problem detection. Our means is to define measurements which summarize how persistent the problem was and how much maintenance effort was spent on the suspected structure. We apply our approach on a large scale case study and show how it improves the accuracy of the detection of god classes and data classes, and additionally how it adds valuable semantical information about the evolution of flawed design structures.

Detecting design flaws via metrics in object-oriented systems

The industry is nowadays confronted with large-scale monolithic and inflexible object-oriented software. Because of their high business value, these legacy systems must be re-engineered. One of the important issues in re-engineering is the detection and location of design flaws, which prevent the efficient maintenance and further development of the system. In this paper, we present a metrics-based approach for detecting design problems, and we describe two concrete techniques for the detection of two well-known design flaws found in the literature. We apply our technique to an industrial case study and discuss the findings. The proposed technique indeed found real flaws in the system and the experiment suggests that, based on the same approach, further detection techniques for other common design flaws could be defined.

Using concept analysis to detect co-change patterns

Software systems need to change over time to cope with new requirements, and due to design decisions, the changes happen to crosscut the systems structure. Understanding how changes appear in the system can reveal hidden dependencies between different entities of the system. We propose the usage of concept analysis to identify groups of entities that change in the same way and in the same time. We apply our approach at different levels of abstraction (i.e., method, class, package) and we detect fine grained changes (i.e., statements were added in a class, but no method was added there). Concept analysis is a technique that identifies entities that have the same properties, but it requires manual inspection due to the large number of candidates it detects. We propose a heuristic that dramatically eliminate the false positives. We apply our approach on two case studies and we show how we can identify hidden dependencies and detect bad smells.

How Developers Copy

Copy-paste programming is dangerous as it may lead to hidden dependencies between different parts of the system. Modifying clones is not always straight forward, because we might not know all the places that need modification. This is even more of a problem when several developers need to know about how to change the clones. In this paper, we correlate the code clones with the time of the modification and with the developer that performed the modification to detect patterns of how developers copy from one another. We develop visualization, named clone evolution view, to represent the evolution of the duplicated code. We show the relevance of our approach on several large case studies and we distill our experience in forms of interesting copy patterns

The LAN-simulation: a refactoring teaching example

The notion of refactoring - transforming the source-code of an object-oriented program without changing its external behaviour - has been studied intensively within the last decade. This diversity has created a plethora of toy-examples, cases and code snippets, which make it hard to assess the current state-of-the-art. Moreover, due to this diversity, there is currently no accepted way of teaching good refactoring practices, despite the acknowledgment in the software engineering body of knowledge. Therefore, this paper presents a common example - the LAN simulation - which has been used by a number of European Universities for both research and teaching purposes.The notion of refactoring —- transforming the source-code of an object-oriented program without changing its external behaviour —- has been studied intensively within the last decade. This diversity has created a plethora of toy-examples, cases and code snippets, which make it hard to assess the current state-of-the-art. Moreover, due to this diversity, there is currently no accepted way of teaching good refactoring practices, despite the acknowledgment in the software engineering body of knowledge. Therefore, this paper presents a common example —- the LAN simulation —- which has been used by a number of European Universities for both research and teaching purposes.

InCode: Continuous Quality Assessment and Improvement

While significant progress has been made over the last ten years in the research field of quality assessment, developers still can’t take full advantage of the benefits of these new tools and technique. We believe that there at least two main causes for this lack of adoption: (i) the lack of integration in mainstream IDEs and (ii) the lack of support for a continuous (daily) usage of QA tools. In this context we created INCODE as an Eclipe plug in that would transform quality assessment and code inspections from a standalone activity, into a continuous, agile process, fully integrated in the development life-cycle. But INCODE not only assesses continuously the quality of Java systems, it also assists developers in taking restructuring decisions, and even supports them in triggering refactorings.

The LAN-simulation: A Research and Teaching Example for Refactoring

The notion of refactoring - transforming the source-code of an object-oriented program without changing its external behaviour - has been studied intensively within the last decade. This diversity has created a plethora of toy-examples, cases and code snippets, which make it hard to assess the current state-of-the-art. Moreover, due to this diversity, there is currently no accepted way of teaching good refactoring practices, despite the acknowledgment in the software engineering body of knowledge. Therefore, this paper presents a common example - the LAN simulation - which has been used by a number of European Universities for both research and teaching purposes.The notion of refactoring —- transforming the source-code of an object-oriented program without changing its external behaviour —- has been studied intensively within the last decade. This diversity has created a plethora of toy-examples, cases and code snippets, which make it hard to assess the current state-of-the-art. Moreover, due to this diversity, there is currently no accepted way of teaching good refactoring practices, despite the acknowledgment in the software engineering body of knowledge. Therefore, this paper presents a common example —- the LAN simulation —- which has been used by a number of European Universities for both research and teaching purposes.

Towards a simplified implementation of object-oriented design metrics

In order to compute metrics automatically, these must be implemented as software programs. As metrics become increasingly complex, implementing them using imperative and interrogative programming is oftentimes cumbersome. Consequently, their understanding, testing and reuse are severely hampered. In this paper we identify a set of key mechanisms that are involved in the implementation of design metrics and, more general, of design-related structural analyses: navigation, selection, set arithmetic, filtering and property aggregation. We show that neither of the aforementioned approaches offers a simple support for all these mechanisms and, as a result, an undesirable overhead of complexity is added to the implementation of metrics. The paper introduces SAIL, a language designed to offer a proper support to a simplified writing of design metrics and similar design-related analyses, with special emphasis on object-oriented design. In order to validate the expressiveness of SAIL the paper provides a comprehensive comparison with the other two approaches