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

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.

13beaa3b7239eca3319d54c6a9f3a85a?s=128

ASERG, DCC, UFMG

October 05, 2015
Tweet

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

  3. 3

  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

  33. None
  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
  41. None
  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
  54. None
  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

  66. None