Supporting Design Model Refactoring for Improving Class Responsibility Assignment

5,453 views
6,165 views

Published on

Presented at MODELS 2011
http://dx.doi.org/10.1007/978-3-642-24485-8_33

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,453
On SlideShare
0
From Embeds
0
Number of Embeds
4,121
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Supporting Design Model Refactoring for Improving Class Responsibility Assignment

  1. 1. Supporting Design Model Refactoring for Improving Class Responsibility AssignmentMotohiro Akiyama†,Shinpei Hayashi†,Takashi Kobayashi‡, and † Tokyo Institute of Technology, JapanMotoshi Saeki† ‡ Nagoya University, Japan
  2. 2. Abstract Aim − Computerized support of Class Responsibility Assignment (CRA) Approach: automated CRA refactoring − Usage of GRASP − Defining detection rules of bad smells − Defining transformation rules of refactoring operations Result − Defined 5 CRA refactorings based on GRASP − Implemented an automated tool − Preliminary evaluated our approach by a controlled experiment with 4 human subjects 2
  3. 3. Background Design of high quality Highly maintainable products Our focus: Class Responsibility Assignment (CRA) − A design task before completing class diagrams − Assigning responsibilities to classes Responsibility [Wirfs-Brock 90] − Representing • The actions an object performs • The knowledge an object maintains • Major decisions an object makes that affect others − Basis of the design of methods/attributes 3
  4. 4. CRA: an example Login account hayashi How to model this? password deadbeef Login − Menu available after authentication − Different menu required according to roles for users for admins• Display user menu • Display admin menu A solution: • Display admin menu Menu • Display user menu + displayMenu(authority: int) Responsibilities Classes 4
  5. 5. “Bad smells” in CRA • Display admin menu Menu • Display user menu + displayMenu(authority: int) (authority: Low maintainability Branches New option causes modificationpublic void if (authority == ADMIN) {displayMenu(int authoriuty) { …… if (authority == ADMIN) { } …… else if (authority == VIP) { } …… else { } …… else { } ……} } 5
  6. 6. General ResponsibilityGRASP [Larman 04] Assignment Software Pattern 9 patterns/principles of CRA; e.g. − Polymorphism: When related alternatives or behaviors vary by class, assign responsibility for the behavior using polymorphic operations to the classes for which the behavior varies. − Protected Variations: Identify points of predicted variation or instability; assign responsibilities to create a stable “interface” around them. Can combine multiple patterns − Polymorphism + Protected Variations 6
  7. 7. CRA Refactoring Menu • Display admin menu • Display user menu + displayMenu(authority: int) Refactor based on Polymorphism Protected Variations Admin-Menu • Display admin menu + displayMenu() Menu User-Menu + displayMenu() • Display user menu + displayMenu() How to achieve automated support of CRA refactorings? 7
  8. 8. Challenges1. How to analyze relationships of responsibilities? • Display admin menu • Display admin menusimilar. similar? • Display user menu • To display the menu of users2. How to deal with informal descriptions of GRASP? When related alternatives or behaviors vary by class, class assign responsibility for the behavior using polymorphic operations to the classes for which the behavior varies. varies 8
  9. 9. Our Solutions1. How to analyze relationships of responsibilities? Giving a special form for responsibility descriptions enabling easier analysis of responsibilities2. How to deal with informal descriptions of GRASP? Giving formal definition of smell detection rules based on GRASP 9
  10. 10. Our Approach Requirements documents 1. Describing responsibilities in a(e.g. use case desc.) special form − enable us to analyze them easily Responsibilities 2. Automated CRA refactoring − Detecting CRA smells Refactor − Suggesting CRA refactorings − Applying CRA refactoring when accepted CRA 10
  11. 11. Responsibility Form Finer-grained than sentence − Describe a responsibility as 7 components − who does what to whom when − Similar to the Case Grammar [Fillmore 68] ID (id): unique identifier number Action (action): the verb Target (target): the target of the action Modifier (mod): the modifier of the target Possessive (pos): the modifier which is a possessive case Condition (cond): whether the action is executed or not Dependency (dep): responsibilities to which are referred by this 11
  12. 12. Responsibility Form• #1: Display admin menu id: 1 action: Display Menu target: menu mod: admin pos: (nil) cond: (nil) dep: #4• #4: Check authority of account id: 4 action: Check target: authority LoginController mod: (nil) pos: account cond: (nil) dep: (nil) 12
  13. 13. coordinate Relationship Detecting using similarity of responsibility descriptions • #1: Display user menu • #2: Display admin menu id: 1 id: 2 action: Display action: Display same target: menu target: menu same mod: user mod: admin different pos: (nil) pos: (nil) same cond: (nil) cond: (nil) dep: (nil) dep: (nil) 13
  14. 14. CRA Refactorings1. Move Responsibility − moves a responsibility to more appropriate class2. Introduce Simple Factory − unifies creation responsibilities which instantiate the same class3. Introduce Creator − moves responsibilities of instantiating a class to an appropriate class4. Introduce Polymorphism − separately assigns coordinate responsibilities to individual classes having a common parent class5. Introduce Facade − reorganizes a CRA having complex dependencies among owner classes of the responsibilities 14
  15. 15. Introduce Polymorphism Based on: − Polymorphism When related alternatives or behaviors vary by class, assign responsibility for the behavior using polymorphic operations to the classes for which the behavior varies. − Protected Variations Identify points of predicted variation or instability; assign responsibilities to create a stable “interface” around them. Detection Condition: 1. Finding coordinate relationships 2. Satisfying pre-conditions • There is no common parent class of the target classes 15
  16. 16. Introduce Polymorphism1. Create new child classes2. Move responsibilities3. Create a parent class4. Rename Menu • Display admin menu • Display user menu 16
  17. 17. Introduce Polymorphism1. Create new child classes2. Move responsibilities3. Create a parent class4. Rename Menu • Display admin menu • Display user menu Child1 17
  18. 18. Introduce Polymorphism1. Create new child classes2. Move responsibilities3. Create a parent class4. Rename Menu • Display admin menu Child1 • Display user menu 18
  19. 19. Introduce Polymorphism1. Create new child classes2. Move responsibilities3. Create a parent class4. Rename Menu • Display admin menu Base Child1 • Display user menu 19
  20. 20. Introduce Polymorphism1. Create new child classes2. Move responsibilities3. Create a parent class4. Rename Admin-Menu • Display admin menu Menu User-Menu • Display user menu 20
  21. 21. Supporting Tool: RAST 21
  22. 22. Supporting Tool: RAST ResponsibilitiesClass diagram editor Responsibility editor 22
  23. 23. Supporting Tool: RAST metrics view: • CLCr • LCOMr lower is betterSuggested CRA refactorings 23
  24. 24. Supporting Tool: RAST Related classes are highlighted 24
  25. 25. Supporting Tool: RAST Refactored 25
  26. 26. Supported GRASPs  8 / 9 patterns are supported in RAST GRASP supports CRA refactorings ✓ Information Expert Move Responsibility ✓ Pure Fabrication Introduce Simple Factory ✓ Indirection Introduce Facade ✓ Creator Introduce Creator✓ Protected Variations Introduce Polymorphism ✓ Polymorphism ✓ Low Coupling The metrics ✓ High Cohesion view in RAST ✗ Controller (Unsupported) 26
  27. 27. Preliminary Evaluation RQ1: Does our method improve the design quality of CRA? Obtained positive results! RQ2: Do CRA alternatives suggested by our tool support designers appropriately? Obtained positive results! 27
  28. 28. Experimental Design (1) Subjects Student 1 Expert 1 Student 2 Expert 2 (S1) (E1) (S2) (E2) Given data − Use case descriptions for the target system − Responsibilities extracted from the use case descriptions Tasks − Preparation: Usage lecture (10 min) − Extracting (creating) classes (2 hrs) − Assigning given responsibilities to classes 28
  29. 29. Experimental Design (2) RQ1: RQ2: Quality of design Support for designers • CLCrMetric • NCr Questionnaires • LCOMr Supply chain management systemSystem for a virtual winery • 5 use cases • 46 responsibilities 29
  30. 30. RQ1: Results : RAST’s CRA refactoring available S1 E1 S2 E2 average 0.67 1.04 0.86 CLCr 2.53 1.30 1.92 0.85 1.07 0.96 NCr 1.27 1.60 1.43 0.72 0.79 0.76 LCOMr 0.80 0.97 0.89 (Although the result is far from statistical evidence,) All metric values with tool support are better. 30
  31. 31. RQ2: Results Move Responsibility  Tool suggested just what I intend to move.  Reasonable suggestions. ✗ However many unnecessary suggestions included. Introduce Facade ✗ Makes my design more complicated rather than reduce complexity. Introduce Creator  Reasonable and useful suggestions. Introduce Polymorphism  I just realized coordinate responsibilities when tool suggested this refactoring.  Tool suggested a responsibility split just what I intend to. Introduce Simple Factory − (No suggestions) Mostly the answers are positive: The subjects prefer the suggested CRA. 31
  32. 32. Future Work Improving refactoring rules − Usage of architecture information; e.g. MVC Evaluation++ − Statistical evidences − Costs for describing responsibilities − Usability of RAST 32
  33. 33. CRA Refactoring Our Approach Requirements documents 1. Describing responsibilities in a (e.g. use case desc.) Refactor based on Polymorphism special form Protected Variations − enable us to analyze them easily Responsibilities 2. Automated CRA refactoring − Detecting CRA smells Refactor − Suggesting CRA refactorings − Applying CRA refactoring when accepted How to achieve automated support of CRA refactorings? 7 CRA 10Supporting Tool: RAST Preliminary Evaluation metrics view:  RQ1: Does our method improve the •CLCr design quality of CRA? •LCOMr Obtained positive results! lower is betterSuggested CRA refactorings  RQ2: Do CRA alternatives suggested by our tool support designers appropriately? Conclusion Obtained positive results! 23 27
  34. 34. Credits Photo by teamaskins − CRC Cards | Flickr http://www.flickr.com/photos/teamaskins/130003950/ Illustration by M/Y/D/S − Illustration = http://myds.jp/ − http://motoki-y.sakura.ne.jp/illust/skeleton.shtml 34

×