CSMR12.ppt
0 likes219 views
The document summarizes an approach called ADvISE to evaluate architectural decay in software systems. It proposes measuring architectural changes between versions by using diagram matching techniques and metrics to identify signs of decay. The approach involves preprocessing class diagrams from source code, detecting class renamings using structural and textual similarities, and matching architectural diagrams between versions using a bit-vector algorithm.
![CSMR 2012
Architectural Decay
Salima Hassaine,
Yann-Ga¨l
e
Gu´h´neuc, Sylvie
e e
Hamel, Giuliano
Antoniol
Introduction Architectural Decay is defined as “the deviation of
Approach actual architecture from planned or original design”.
Empirical Study [1,2]
Study Results
Conclusion
[1] L. Hochstein and M. Lindvall, Combating architectural degeneration: a
survey. Information Software Technology, vol.47, pp.643-656, 2005.
[2] B. Williams and J. Carver, Characterizing software architecture changes:
An initial study. Empirical software Engineering and Measurement,
3 / 23](https://image.slidesharecdn.com/csmr12-ppt-130410095607-phpapp02/85/CSMR12-ppt-3-320.jpg)
![CSMR 2012
Step 2: Class Renaming Detection (1/3)
Salima Hassaine,
Yann-Ga¨l
e
Gu´h´neuc, Sylvie
e e
Hamel, Giuliano
Antoniol
Introduction
Approach Structure-based Similarity
Empirical Study
Study Results
Let S(CA ) and S(CB ) to be the set of methods, attributes,
Conclusion
and relationships of class CA (respectively CB ). The
structure-based similarity of CA and CB is given by:
2 × |S(CA ) ∩ S(CB )|
StrS(CA , CB ) = ∈ [0, 1]
|S(CA ) ∪ S(CB )|
Our algorithm reports, given CA , the CB with the highest
StrS similarity score as the class renamed from CA .
8 / 23](https://image.slidesharecdn.com/csmr12-ppt-130410095607-phpapp02/85/CSMR12-ppt-8-320.jpg)
![CSMR 2012
Step 2: Class Renaming Detection (2/3)
Salima Hassaine,
Yann-Ga¨l
e
Gu´h´neuc, Sylvie
e e
Hamel, Giuliano
Antoniol
Camel-based Similarity
Introduction
Let T (CA ) and T (CB ) to be the set of tokens of CA
Approach
(respectively CB ) names, using a Camel Case Splitter.
Empirical Study
Study Results
2 × |T (CA ) ∩ T (CB )|
CamelS(CA , CB ) = ∈ [0, 1]
|T (CA ) ∪ T (CB )|
Conclusion
Levenstein-based Similarity
We use the normalized edit distance (ND), given by:
LEV (CA , CB )
ND(CA , CB ) = ∈ [0, 1]
sum(length(CA ), length(CB )
where LEV computes the Levenshtein
9 / 23](https://image.slidesharecdn.com/csmr12-ppt-130410095607-phpapp02/85/CSMR12-ppt-9-320.jpg)
CSMR12.ppt
- 1. CSMR 2012 Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction ADvISE: Architectural Decay In Approach Software Evolution Empirical Study Study Results Conclusion Salima Hassaine, Yann-Ga¨l Gu´h´neuc, Sylvie Hamel, e e e Giuliano Antoniol ´ SOCCER Lab. and Ptidej Team – DGIGL, Ecole Polytechnique de Montr´al, Qu´bec, Canada e e March 30, 2012 Pattern Trace Identification, Detection, and Enhancement in Java SOftware Cost-effective Change and Evolution Research Lab
- 2. CSMR 2012 Context and Motivation Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Software evolution is the on-going enhancement of Approach existing software systems, involving both development Empirical Study and maintenance. Study Results Conclusion As these systems are adapted to changing requirements, they may suffer from signs of aging. Their architecture can deviate substantially from the architecture originally designed i.e., their architecture tends to decay with time and it becomes less adaptable to new, emerging requirements. 2 / 23
- 3. CSMR 2012 Architectural Decay Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Architectural Decay is defined as “the deviation of Approach actual architecture from planned or original design”. Empirical Study [1,2] Study Results Conclusion [1] L. Hochstein and M. Lindvall, Combating architectural degeneration: a survey. Information Software Technology, vol.47, pp.643-656, 2005. [2] B. Williams and J. Carver, Characterizing software architecture changes: An initial study. Empirical software Engineering and Measurement, 3 / 23
- 4. CSMR 2012 Existing approaches Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Software Stability Approach Several authors suggested stability or resilience as a Empirical Study primary criterion for evaluating an architecture. Study Results However, none of these approaches have been used to Conclusion study the signs of software aging or architectural decay. Architectural Decay Other authors suggested that decayed architectures make their systems more prone to defects and that, in some not-so-rare cases, a system architecture and its implementation code must be thrown away because it is too hard to maintain, unless the decay can be stopped before the architecture is completely unworkable 4 / 23
- 5. CSMR 2012 Our goal Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach Empirical Study Propose a novel approach ADvISE and a set of Study Results measures to evaluate architectural decay. Conclusion Propose a diagram matching technique to identify structural changes among versions of architectures. Propose a set of metrics to identify the signs of architectural decay. 5 / 23
- 6. CSMR 2012 Approach overview Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach Empirical Study Study Results Conclusion 6 / 23
- 7. CSMR 2012 Step 1: Pre-processing Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Reverse-engineer class diagrams from the source code of Antoniol object oriented programs using PADL tool. Introduction Convert the program model into a string representation Approach using EPI tool. Empirical Study ag as Study Results A F G ag as in Conclusion A F G B in cr cr cr B dm cr cr cr in in in C D E co in in in dm dm dm dm C D E co (b) UML-like model (c) Eulerian model (d) String representation of the Eulerian model Figure: The conversion of a class diagram into string. 7 / 23
- 8. CSMR 2012 Step 2: Class Renaming Detection (1/3) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach Structure-based Similarity Empirical Study Study Results Let S(CA ) and S(CB ) to be the set of methods, attributes, Conclusion and relationships of class CA (respectively CB ). The structure-based similarity of CA and CB is given by: 2 × |S(CA ) ∩ S(CB )| StrS(CA , CB ) = ∈ [0, 1] |S(CA ) ∪ S(CB )| Our algorithm reports, given CA , the CB with the highest StrS similarity score as the class renamed from CA . 8 / 23
- 9. CSMR 2012 Step 2: Class Renaming Detection (2/3) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Camel-based Similarity Introduction Let T (CA ) and T (CB ) to be the set of tokens of CA Approach (respectively CB ) names, using a Camel Case Splitter. Empirical Study Study Results 2 × |T (CA ) ∩ T (CB )| CamelS(CA , CB ) = ∈ [0, 1] |T (CA ) ∪ T (CB )| Conclusion Levenstein-based Similarity We use the normalized edit distance (ND), given by: LEV (CA , CB ) ND(CA , CB ) = ∈ [0, 1] sum(length(CA ), length(CB ) where LEV computes the Levenshtein 9 / 23
- 10. CSMR 2012 Step 2: Class Renaming Detection (3/3) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Combination of Similarities Antoniol Introduction 1. First, we compare the structure-based similarities Approach (StrS) of a candidate renamed class CA to many target Empirical Study classes {CB1 , ..., CBn }. Study Results 2. Second, we select the set of target classes having the Conclusion highest StrS value. Then, we compute their textual similarities (ND and CamelS). 3. Third, if we do not find a target class that has the lowest ND and the highest CamelS. Then, for each target class {CB1 , ..., CBn }, we compare ND and CamelS similarities to given thresholds. 4. Finally, if none of the target classes has ND lower than the 0.40 threshold and CamelS higher than the 0.50 threshold. Then, we can consider that class CA was deleted and not renamed. 10 / 23
- 11. CSMR 2012 Step 3: Architectural Diagram Matching Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Bit-Vector Algorithm Hamel, Giuliano Antoniol We build the characteristic vectors of each token in the Introduction string representation of version 1. Approach We read the string representation of version 2, triplets Empirical Study by triplets. For each triplets T in version 2, we verify Study Results whether it exists in version 1, as follows: Conclusion 11 / 23
- 12. CSMR 2012 Step 4: Architectural Diagram Clustering Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach Empirical Study Study Results Conclusion 12 / 23
- 13. CSMR 2012 Step 5: Architectural Decay Evaluation Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction We perform a pairwise matching of subsequent program Approach architectures. Empirical Study We use the sets of stable triplets as indicators of the Study Results architectural stability, as follows: Conclusion Stability of the original design: we compute the number of triplets that has a match in all the versions. These triplets are considered to be part of a tunnel, the backbone part of the system. Stability of the architecture with an enriched functionality: we compute the number of triplets that have not changed since their first appearance in a given version of a system. 13 / 23
- 14. CSMR 2012 Empirical Study Design Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Goal: to show the applicability and usefulness of our Introduction approach Approach Empirical Study Purpose: to provide an approach for identifying class Study Results renaming and evaluating architectural decay Conclusion Quality focus: the accuracy of the architectural decay evaluation Perspective: both researchers, who want to study class renaming, and practitioners who analyse software evolution to estimate the effort required for future maintenance tasks. Context: three open source systems: JFreeChart, Rhino and Xerces-J. 14 / 23
- 15. CSMR 2012 Research Questions (1/2) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach Empirical Study RQ1: What are signs of architectural decay and how can Study Results they be tracked down? Conclusion We investigate whether the numbers of stable triplets are good indicators to measure the architectural decay, and if they provide useful insights to developers regarding the signs of software aging. 15 / 23
- 16. CSMR 2012 Research Questions (2/2) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach Empirical Study Study Results RQ2: Do stable and unstable micro-architectures have the Conclusion same risk to be fault prone? This question leads to the following null hypothesis: H0 : The proportions of faults carried by stable and unstable micro-architectures are the same. 16 / 23
- 17. CSMR 2012 Analysis Methods (1/2) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach RQ1: Empirical Study Study Results We perform a pair by pair matching of subsequent Conclusion program architectures to identify stable triplets in JFreeChart and Xerces-J We study the graph of architectures evolution for each system to assess whether, these indicators provide us useful insights regarding the signs of software aging. 17 / 23
- 18. CSMR 2012 Analysis Methods (2/2) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction RQ2: Approach To attempt rejecting H0 , we test whether the Empirical Study proportion of classes that compose unstable Study Results Conclusion (respectively stable) micro-architectures take part (or not) in significantly more faults than those in stable (respectively unstable) micro-architectures. We use the contingency tables to assess the direction of the difference, if any. We use Fisher’s exact test, to check whether the difference is significative. 18 / 23
- 19. CSMR 2012 Study Results (1/3) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol RQ1: What are signs of architectural decay and how can they be tracked down? Introduction Approach Empirical Study Study Results Conclusion (a) The evolution of JFreeChart architecture 19 / 23
- 20. CSMR 2012 Study Results (2/3) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano RQ1: What are signs of architectural decay and how can Antoniol they be tracked down? Introduction Approach Empirical Study Study Results Conclusion (b) The evolution of XercesJ architecture 20 / 23
- 21. CSMR 2012 Study Results (3/3) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano RQ2: Do stable and unstable micro-architectures have the Antoniol same risk to be fault prone? Introduction Approach Faulty classes Clean classes Empirical Study Unstable classes 105 14 Study Results Stable classes 39 17 Conclusion Fisher’s test 0.005 Odd-ratio 3.244 Table: Contingency table and Fisher test results for unstable classes with at least one fault. We can answer to RQ2 as follows: we showed that stable micro-architectures, belonging to the original design, are significantly less bug-prone than unstable micro-architectures. 21 / 23
- 22. CSMR 2012 Conclusion (1/2) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach Architectural decay is defined as the deviation from an Empirical Study original design, i.e., the violation of architecture caused Study Results by the process of evolution. Conclusion When evolution occurs in an uncontrolled manner, the systems become more complex over time and thus, harder to maintain. Thus, decayed architectures make their systems more prone to defects We proposed an approach to evaluate the architectural decay. 22 / 23
- 23. CSMR 2012 Conclusion (2/2) Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano We proposed a set of structure-based and text-based Antoniol similarities to identify class renamings in evolving Introduction architectures. Approach We proposed a bit-vector and incremental clustering Empirical Study algorithms to perform the matching between several Study Results versions of an architecture and find stable Conclusion micro-architectures, which exist in all versions. We proposed the numbers of common triplets between several versions of an architecture as indicators of decay, and thus, predictors of fault proneness. We also perform a quantitative and two qualitative studies, to show the applicability and usefulness of our approach. Future work: Apply our approach to other programs to confirm our observations. 23 / 23
- 24. CSMR 2012 Questions? Salima Hassaine, Yann-Ga¨l e Gu´h´neuc, Sylvie e e Hamel, Giuliano Antoniol Introduction Approach Empirical Study Study Results Conclusion 24 / 23