Legacy Software Restructuring: Analyzing a Concrete Case

Software re-modularization is an old preoccupation of reverse engineering research. The advantages of a well structured or modularized system are well known. Yet after so much time and efforts, the field seems unable to come up with solutions that make a clear difference in practice. Recently, some researchers started to question whether some basic assumptions of the field were not overrated. The main one consists in evaluating the high-cohesion/low-coupling dogma with metrics of unknown relevance. In this paper, we study a real structuring case (on the Eclipse platform) to try to better understand if (some) existing metrics would have helped the software engineers in the task. Results show that the cohesion and coupling metrics used in the experiment did not behave as expected and would probably not have helped the maintainers reach there goal. We also measured another possible restructuring which is to decrease the number of cyclic dependencies between modules. Again, the results did not meet expectations

Project-Team RMoD 2013 Activity Report

Activity Report 2013 Project-Team RMOD Analyses and Languages Constructs for Object-Oriented Application Evolutio

Project-Team RMoD (Analyses and Language Constructs for Object-Oriented Application Evolution) 2009 Activity Report

This is the yearly report of the RMOD team. A good way to understand what we are doing

BugMaps-Granger: a tool for visualizing and predicting bugs using Granger causality tests

International audienceBackgroundDespite the increasing number of bug analysis tools for exploring bugs in software systems, there are no tools supporting the investigation of causality relationships between internal quality metrics and bugs. In this paper, we propose an extension of the BugMaps tool called BugMaps-Granger that allows the analysis of source code properties that are more likely to cause bugs. For this purpose, we relied on the Granger Causality Test to evaluate whether past changes to a given time series of source code metrics can be used to forecast changes in a time series of defects. Our tool extracts source code versions from version control platforms, calculates source code metrics and defects time series, computes Granger Test results, and provides interactive visualizations for causal analysis of bugs.ResultsWe provide an example of use of BugMaps-Granger involving data from the Equinox Framework and Eclipse JDT Core systems collected during three years. For these systems, the tool was able to identify the modules with more bugs, the average lifetime and complexity of the bugs, and the source code properties that are more likely to cause bugs.ConclusionsWith the results provided by the tool in hand, a maintainer can perform at least two main software quality assurance activities: (a) refactoring the source code properties that Granger-caused bugs and (b) improving unit tests coverage in classes with more bugs

Pragmatic Visualizations for Roassal: a Florilegium

International audienceSoftware analysis and in particular reverse engineering often in- volves a large amount of structured data. This data should be pre- sented in a meaningful form so that it can be used to improve soft- ware artefacts. The software analysis community has produced nu- merous visual tools to help understand different software elements. However, most of the visualization techniques, when applied to software elements, produce results that are difficult to interpret and comprehend. This paper presents five graph layouts that are both expressive for polymetric views and agnostic to the visualization engine. These layouts favor spatial space reduction while emphasizing on clarity. Our layouts have been implemented in the Roassal visualization engine and are available under the MIT License

Visualisations pour la remodularisation à large échelle des systèmes à objets

National audienceDans ce chapitre, nous abordons deux points critiques de la remodularisa- tion : comment visualiser la structure d'un logiciel pour aider à la rendre mod- ulaire et comment aider le développeur à prendre les bonnes décisions. D'abord nous décrivons certains outils pour visualiser la structure des logiciels et comment nous les adaptons à la remodularisation. Ensuite nous présentons des visualisations adaptées à l'identification des problèmes de modularité. Enfin, nous proposons un outil, nommé Orion, permettant de simuler les changements de structure d'un logi- ciel. Il permet d'analyser l'impact des changements dans la structure et d'évaluer les coûts associés

The Package Blueprint: visually analyzing and quantifying package dependencies

International audienceLarge object-oriented applications are structured over many packages. Packages are important but complex structural entities that are difficult to understand since they act as containers of classes, which can have many dependencies with other classes spread over multiple packages. However to be able to take decisions (e.g., refactoring and/or assessment decisions), maintainers face the challenges of managing (sorting, grouping) the massive amount of dependencies between classes spread over multiple packages. To help maintainers, there is a need for at the same time understanding, and quantifying, dependencies between classes as well as understanding how packages as containers of such classes depend on each other. In this paper, we present a visualization, named Package Blueprint, that reveals in detail package internal structure, as well as the dependencies between an observed package and its neighbors, at both package and class levels. Package Blueprint aims at assisting maintainers in understanding package structure and dependencies, in particular when they focus on few packages and want to take refactoring decisions and/or to assess the structure of those packages. A package blueprint is a space filling matrix-based visualization, using two placement strategies that are enclosure and adjacency. Package blueprint is structured around the notion of surfaces that group classes and their dependencies by their packages (i.e., enclosure placement); whilst surfaces are placed next to their parent node which is the package under-analysis (i.e., adjacency placement). We present two views: one stressing how an observed package depends upon the rest of the system and another stressing how the system depends upon that package. To evaluate the contribution of package blueprint for understanding packages we performed an exploratory user study comparing package blueprint with an advanced IDE. The results shows that users of package blueprint are faster in analyzing and assessing package structure. The results are proved statically significant and they show that package blueprint considerably improve the experience of standard browser users

OZONE: Layer Identification in the presence of Cyclic Dependencies

International audienceA layered software architecture helps understanding the role of software entities (e.g., packages or classes) in a system and hence, the impact of changes on these entities. However, the computation of an optimal layered organization in the presence of cyclic dependencies is difficult. In this paper, we present an approach that (i) provides a strategy supporting the automated detection of cyclic dependencies, (ii) proposes heuristics to break cyclic dependencies, and (iii) computes an organization of software entities in multiple layers even in presence of cyclic dependencies. Our approach performs better than the other existing approaches in terms of accuracy and interactivity, it supports human inputs and constraints. In this paper, we present this approach and compare it to existing solutions. We applied our approach on two large software systems to identify package layers and the results are manually validated by software engineers of the two systems

Proceedings of the 3rd Workshop on FAMIX and MOOSE in Software Reengineering (FAMOOSr'09)

International audienceThe goal of the FAMOOSr workshop is to strengthen the community of researchers and practitioners who are working in re- and reverse engineering, by providing a forum for building future research using Moose and FAMIX as shared infrastructure. Research should be collaborative and supported by tools. The increasing amount of data available about software systems poses new challenges for reengineering research, as the proposed approaches need to scale. In this context, concerns about meta-modeling and analysis techniques need to be augmented by technical concerns about how to reuse and how to build upon the efforts of previous research. That is why Moose is an open-source software for researchers to build and share their analysis, meta-models, and data. Both FAMIX and Moose started in the context of FAMOOS, a European research project on object-oriented frameworks. Back in 1997 Moose was as a simple implementation of the FAMIX meta-model, which was a language independent meta-model for object-oriented systems. However over the past decade, Moose has been used in a growing number of research projects and has evolved to be a generic environment for various reverse and reengineering activities. In the same time, FAMIX was extended to support emerging research interest such as dynamic analysis, evolution analysis, identifier analysis, bug tracking analysis, or visualization. Recent work includes analysis of software architecture and semantic annotations. Currently, several research groups are using Moose as a platform, or FAMIX as a meta-model, and other groups announced interest in using them in the future