Recovering the Evolution Stable Part Using an ECGM Algorithm: Is There a Tunnel in Mozilla?

2011 18th Working Conference on Reverse Engineering

Hamel

et al. 2011

Self Cite

Abstract-The literature describes several approaches to identify the artefacts of programs that change together to reveal the (hidden) dependencies among these artefacts. These approaches analyse historical data, mined from version control systems, and report co-changing artefacts, which hint at the causes, consequences, and actors of the changes. We introduce the novel concepts of macro co-changes (MCC), i.e., of artefacts that co-change within a large time interval, and of dephase macro co-changes (DMCC), i.e., macro co-changes that always happen with the same shifts in time. We describe typical scenarios of MCC and DMCC and we use the Hamming distance to detect approximate occurrences of MCC and DMCC. We present our approach, Macocha, to identify these concepts in large programs. We apply Macocha and compare it in terms of precision and recall with UMLDiff (file stability) and association rules (co-changing files) on four systems: ArgoUML, FreeBSD, SIP, and XalanC. We also use external information to validate the (approximate) MCC and DMCC found by Macocha. We thus answer two research questions showing the existence and usefulness of theses concepts and explaining scenarios of hidden dependencies among artefacts.

Section: A File Stabilitymentioning

confidence: 99%

An Exploratory Study of Macro Co-changes

Jaafar

2011 18th Working Conference on Reverse Engineering

Hamel

et al. 2011

Self Cite

“…Kpodjedo et al [32] [18] proposed to identify all classes that do not change in the history of a program, using an Error Correcting Graph Matching algorithm (ECGM). They studied the evolution of programs and recovered traceability links between subsequent class diagrams.…”

Section: Class Evolutionmentioning

confidence: 99%

On the Relationship between Program Evolution and Fault-Proneness: An Empirical Study

Jaafar

Hassaine

2013 17th European Conference on Software Maintenance and Reengineering

et al. 2013

Abstract-Over the years, many researchers have studied the evolution and maintenance of object-oriented source code in order to understand the possibly costly erosion of the software. However, many studies thus far did not link the evolution of classes to faults. Since (1) some classes evolve independently, other classes have to do it together with others (co-evolution); and (2) not all classes are meant to last forever, but some are meant for experimentation or to try out an idea that was then dropped or modified. In this paper, we group classes based on their evolution to infer their lifetime models and coevolution trends. Then, we link each group's evolution to faults. We create phylogenetic trees showing the evolutionary history of programs and we use such trees to facilitate spotting the program code decay. We perform an empirical study, on three open-source programs: ArgoUML, JFreechart, and XercesJ, to examine the relation between the evolution of object-oriented source code at class level and fault-proneness. Our results indicate that (1) classes having a specific lifetime model are significantly less fault-prone than other classes and (2) faults fixed by maintaining co-evolved classes are significantly more frequent than faults fixed using not co-evolved classes.

“…Their approach does not support relationships. Kpodjedo et al [6] proposed an Error Correcting Graph Matching (ECGM) algorithm to study architectural diagram evolution. This algorithm is derived from searchbased techniques: given two architectural diagrams D 1 and D 2 , the authors aims finding, among the large set of all possible matchings, a solution that is the best true matching between classes of D 1 and D 2 .…”

Section: B Architectural Diagram Evolutionmentioning

confidence: 99%

“…Then, for each target class {C B 1 , ...,C B n }, we compare ND and CamelS similarities to given thresholds. If none of the target classes has ND lower than the 0.40 threshold 5 and CamelS higher than the 0.50 threshold 6 . Then, we can consider that class C A was deleted and not renamed.…”

Section: ) Combination Of Similaritiesmentioning

confidence: 99%

See 1 more Smart Citation

ADvISE: Architectural Decay in Software Evolution

Hassaine

2012 16th European Conference on Software Maintenance and Reengineering

Hamel

et al. 2012

Self Cite

Abstract-Software systems evolve continuously, requiring continuous maintenance and development. Consequently, their architecture tends to degrade with time as it becomes less relevant to new, emerging requirements. Therefore, stability or resilience is a primary criterion for evaluating an architecture. In this paper, we propose a quantitative approach to study the evolution of the architecture of object oriented systems over time. In particular, we represent an architecture as a set of triplets (S, R, T ), where S and T represent two classes and R is a relationship linking them. We use these triplets as basic unit to measure the stability of an architecture. We show the applicability and usefulness of our approach by studying the evolution of three open source systems: JFreeChart and Xerces-J and Rhino.