Developers' Perception of Co-change Patterns: An Empirical Study (ICSME 2015)

Co-change clusters are groups of classes that frequently change together. They are proposed as an alternative modular view, which can be used to assess the traditional decomposition of systems in packages. To investigate developer’s perception of co-change clusters, we report in this paper a study with experts on six systems, implemented in two languages. We mine 102 co-change clusters from the version history of such systems, which are classified in three patterns regarding their projection to the package structure: Encapsulated, Crosscutting, and Octopus. We then collect the perception of expert developers on such clusters, aiming to ask two central questions: (a) what concerns and changes are captured by the extracted clusters? (b) do the extracted clusters reveal design anomalies? We conclude that Encapsulated Clusters are often viewed as healthy designs and that Crosscutting Clusters tend to be associated to design anomalies. Octopus Clusters are normally associated to expected class distributions, which are not easy to implement in an encapsulated way, according to the interviewed developers.

Transcript

1. Developers’ Perception of Co-change Patterns: An Empirical Study Luciana Silva, Marco T. Valente Marcelo Maia Nicolas Anquetil UFMG – Brazil UFU – Brazil INRIA – France ICSME 2015, Bremen
2. What is a well-modularized system? 2
4. Modules should hide important design decisions or decisions that are likely to change [Parnas, 1972] . 4
5. How often changes are localized in modules? Do crosscutting changes reveal design problems? 5
6. Co-change Clusters 6
7. Co-change Clusters Assessing Modularity using Co-change Clusters Modularity 2014 7
8. Co-change Clusters Co-change graph Assessing Modularity using Co-change Clusters Modularity 2014 7
9. Co-change Clusters Co-change graph Co-change cluster Assessing Modularity using Co-change Clusters Modularity 2014 7
10. Co-change Clusters Co-change graph Co-change cluster Assessing Modularity using Co-change Clusters Modularity 2014 Distribution map 7
11. Distribution Maps 8
12. Co-change Patterns
13. Encapsulated Clusters 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 MorphicPager 10 10 10 10 10 SeasideExamples 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 SeasideCore 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 SeasideRendering 9
14. Encapsulated Clusters 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 MorphicPager 10 10 10 10 10 SeasideExamples 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 SeasideCore 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 SeasideRendering Nice modules? 9
15. Crosscutting Clusters 8 8 8 8 8 8 8 8 8 session 8 8 action 8 8 8 model.task 8 8 8 model.egp 8 8 8 model.involved 8 8 action.task 8 util 10
16. Crosscutting Clusters 8 8 8 8 8 8 8 8 8 session 8 8 action 8 8 8 model.task 8 8 8 model.egp 8 8 8 model.involved 8 8 action.task 8 util Crosscutting concern? Modularity flaw? Major refactoring? Re-architecting? 10
17. Octopus Clusters 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 Finder 18 RoassalPaintings 18 18 18 18 18 18 11
18. Octopus Clusters 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 Finder 18 RoassalPaintings 18 18 18 18 18 18 Move class refactoring? 11
19. Research Questions RQ #1: To what extent do the proposed co-change patterns cover real instances of clusters? 12
20. Research Questions RQ #1: To what extent do the proposed co-change patterns cover real instances of clusters? RQ #2: How developers describe the clusters matching the proposed co-change patterns? 12
21. Research Questions RQ #1: To what extent do the proposed co-change patterns cover real instances of clusters? RQ #2: How developers describe the clusters matching the proposed co-change patterns? RQ #3: To what extent do the clusters matching the proposed co-change patterns indicate design anomalies? 12
22. Study Design  Java System Description SysPol Automation of criminal investigation process 13
23. Study Design Pharo System Description Seaside Framework for web applications Moose Software and data analysis Fuel Object serialization framework Epicea Tool to share untangled commits Glamour Infrastructure for impl. browsers 14
24. Study Design Pharo System Description Seaside Framework for web applications Moose Software and data analysis Fuel Object serialization framework Epicea Tool to share untangled commits Glamour Infrastructure for impl. browsers 14
25. Study Design Pharo System Description Seaside Framework for web applications Moose Software and data analysis Fuel Object serialization framework Epicea Tool to share untangled commits Glamour Infrastructure for impl. browsers 14
26. Study Design 15
27. RQ#1. Do Pattern Cover Extracted Clusters? 102 mined clusters 16
28. RQ#1. Do Pattern Cover Extracted Clusters? 102 mined clusters 16
29. RQ#1. Do Pattern Cover Extracted Clusters? 17
30. RQ#1. Do Pattern Cover Extracted Clusters? 17
31. RQ#1. Do Pattern Cover Extracted Clusters? 17
32. RQ#1. Do Pattern Cover Extracted Clusters? 18
34. 19 RQ #2. Developer’s Perception
35. RQ #2. Developer’s Perception Implement clean and well-defined concerns 19
36. RQ #2. Developer’s Perception 10 10 10 10 10 SeasideExamples 10 10 10 10 10 SeasideCore 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 SeasideRendering Rendering: web widgets and rendering logic Core: widget library Glamour 20
37. 10 10 10 10 10 SeasideExamples 10 10 10 10 10 SeasideCore 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 SeasideRendering “The Presenter classes represent an abstract description for a widget, … concrete widget by the Renderer. … widget library (Core) is changed, the Renderer logic is also changed. After that, the Examples are updated.” Glamour’s Developer 21 RQ #2. Developer’s Perception
38. 22 RQ #3. Design Anomalies
39. 22 RQ #3. Design Anomalies
40. “The developer … new browser … the guidelines for packages in Glamour. Despite of these classes define clearly the browser creation concern, ...” Glamour’s developer 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 MorphicPager 9 9 9 9 9 9 9 9 9 9 23 RQ #3. Design Anomalies
42. 24 RQ #2. Developer’s Perception
43. 24 RQ #2. Developer’s Perception Functional Concerns “CreateArticle is a quite generic use case … . …, when implementing a new use case, … change classes associated to CreateArticle” Syspol’s developer
44. RQ #2. Developer’s Perception  Non-functional Concerns 8 8 8 8 8 8 8 8 8 session 8 8 action 8 8 8 model.task 8 8 8 model.egp 8 8 8 model.involved 8 8 action.task 8 util This cluster implements Access to database and Article template 25
45. 26 RQ #3. Design Anomalies
46. 26 RQ #3. Design Anomalies
47. 27 RQ #3. Design Anomalies
48. Low cohesion/high coupling 28 RQ #3. Design Anomalies
49. Low cohesion/high coupling Contains “one of the classes with the highest coupling in the system.” SysPol’s developer 28 RQ #3. Design Anomalies
50. Complex concerns 29 RQ #3. Design Anomalies
51. Complex concerns “this is a difficult part to understand in the system and its implementation is quite complex.” SysPol’s developer 29 RQ #3. Design Anomalies
52. Package decomposition problem 30 RQ #3. Design Anomalies
53. Package decomposition problem “this package includes implementation logic that should be in an under layer.” SysPol’s developer 30 RQ #3. Design Anomalies
55. 31 RQ #2. Developer’s Perception
56. 31 RQ #2. Developer’s Perception 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 Finder 18 RoassalPaintings 18 18 18 18 18 18 Used to display visualizations inside browsers. Moose Browsers – Moose panels Generic class for visualization
57. 32 RQ #3. Design Anomalies
58. 32 RQ #3. Design Anomalies
59. 33 RQ #3. Design Anomalies
60. 34 RQ #3. Design Anomalies
61. 35 Could we Remove the Tentacles?
62. “Unfortunately, … difficult to localize changes in just one package. … Shielding changes is not absolutely possible.” Glamour’s developer 36
63. Main Findings 37
64. Main Findings 37
65. Main Findings 37