Icsm10b.ppt
0 likes31 views
- The document discusses applying game theory techniques to identify opportunities for extract class refactoring. - It models the refactoring decision as a non-cooperative game to find a compromise between high class cohesion and low coupling. Players choose between moving methods to existing classes or creating a new class. - An evaluation on two systems found the game theory approach achieved higher cohesion than other extract class refactoring techniques like MaxFlow and MinCut. Future work includes investigating other game types and comparing to clustering/search-based approaches.
Icsm10b.ppt
- 1. Playing with Refactoring Identifying Extract Class Opportunities through Game Theory Gabriele Bavota*, Rocco Oliveto*, Andrea De Lucia* Giuliano Antoniol✝, Yann-Gaël Guéhéneuc✝ * DMI, University of Salerno, Fisciano (SA), Italy ✝ DGIGL, École Polytechnique de Montreál, Québec, Canada
- 2. contents Context Refactoring Software Systems:Why and How GameTheory Background The Prisoner’s Dilemma GameTheory meets SE Game-based Extract Class Refactoring
- 4. GameTheory - is a branch of mathematics widely applied in the social sciences - capture behavior in strategic situations, in which an individual’s success in making choices depends on the choices of others - a game consists of: • a set of players (2 or more); • a set of moves available to those players; • payoffs for each combination of moves
- 5. The Prisoner’s Dilemma TomTom confess not confess Sally confess (5, 5) (0, 7) Sally not confess (7, 0) (4, 4)
- 6. The Prisoner’s Dilemma TomTom confess not confess Sally confess (5, 5) (0, 7) Sally not confess (7, 0) (4, 4) NASHEQUILIBRIUM
- 7. GameTheory:Summarizing - Natural application in strategic situations - How to find a compromise between contrasting goals (Nash Equilibrium) - In software engineering: • optimal solution to many problems involves finding a compromise between contrasting goals, e.g., create classes with high cohesion and low coupling
- 8. Context Refactoring Software Systems: Why and How
- 9. Refactoring...Why? - Changing software without modifying its external behaviour - Improve non-functional attributes of the software? - Software evolution ... continuous changes - Changes cause a drift of the original design, reducing its quality, e.g., Class Cohesion
- 10. Focusing on Class Cohesion - How strongly related and focused the various responsibilites of a class are - High cohesion is desiderable...easier maintenance class class class class class class class - Programmers often add wrong responsibilities to a class - The class becomes too complex and its cohesion decreases
- 11. Focusing on Class Cohesion - How strongly related and focused the various responsibilites of a class are - High cohesion is desiderable...easier maintenance classclass class Extract Class Refactoring Splitting a class with many responsibilities into different classes
- 12. GameTheory meets SE Game-based Extract Class Refactoring
- 13. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00)
- 14. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00) (-1, -1) if i = j
- 15. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00) 0.70 = sim(m1, m2) - sim(m1, m4)
- 16. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00) 0.70 = sim(m1, m2) - sim(m1, m4) COHESION COUPLING
- 17. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00)
- 18. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00) NASHEQUILIBRIUM
- 19. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00) NASHEQUILIBRIUM
- 20. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00) NASHEQUILIBRIUM
- 21. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m2 m3 m4 N m2 m3 m4 N m1 m5 (-1.00, -1.00) (-1.00, -1.00) (0.49, 0.22) (0.70, 0.80) (0.70, 0.50) (-0.49, -0.24) (0.21, 0.58) (0.21, 0.28) (-0.21, -0.58)(-0.70, -0.80) (-1.00, -1.00) (0.00, -0.30) (0.29, 0.22)(-0.20, 0.00) (0.50, 0.80) (-1.00, -1.00) NASHEQUILIBRIUM
- 22. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m3 N m3 N m1 m5 (-1.00, -1.00) (0.21, 0.28) (0.29, 0.22) (-1.00, -1.00) m4 m2
- 23. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m3 N m3 N m1 m5 (-1.00, -1.00) (0.21, 0.28) (0.29, 0.22) (-1.00, -1.00) m4 m2 NASHEQUILIBRIUM
- 24. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S m3 N m3 N m1 m5 (-1.00, -1.00) (0.21, 0.28) (0.29, 0.22) (-1.00, -1.00) m4 m2 NASHEQUILIBRIUM
- 25. Playing with Refactoring Modelling a non-cooperative game ..choosing the better strategy T S N m3 N m1 m5 (-1.00, -1.00) (0.21, 0.28) (0.29, 0.22) (-1.00, -1.00) m4 m2 NASHEQUILIBRIUM m3
- 26. Preliminary Evaluation Game-based Extract Class Refactoring
- 27. Case Study Design Goal Systems Metrics RQ1 Comparison with Pareto Optimum ArgoUML, JHotDraw F-measure RQ2 Comparison with others Extract Class Refactoring approaches ArgoUML, JHotDraw F-measure
- 28. Experiment Execution method1 ... methodn attr1 ... attrm Original Class C1 method1 ... methods attr1 ... attrm Original Class C1 method1 ... methodn attr1 ... attrm Original Class Ci method1 ... methodn attr1 ... attrm Original Class C1 method1 ... methody attr1 ... attrm Original Class C1 method1 ... methodn+s attr1 ... attrm+k Mutated Class Ci + Cj method1 ... methodn attr1 ... attrm Original Class C1 method1 ... methods attr1 ... attrm Original Class C1 method1 ... methodk attr1 ... attrh Refactored Class C'i Input original system System mutation Comparision of orginal and mutated system mutated system refactored system System refactoring results 88% F-MEASURE
- 29. Results System Game Theory Pareto Optimum MaxFlow MinCut ArgoUML 90% 88% 77% JHotDraw 85% 82% 76%
- 31. Conclusion... The first recommendation system that exploits game theory techniques
- 32. Conclusion... Preliminary evaluation of the proposed approach
- 33. ...and FutureWork investigate about other kind of games, e.g., cooperative game direct comparison with clustering and search-based approach apply Game Theory to Software Re-modularization
- 34. Thank you! Questions and/or comments Gabriele Bavota PhD Student DMI - University of Salerno gbavota@unisa.it