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

1. Supporting Design Model Refactoring
for Improving
Class Responsibility Assignment
Motohiro Akiyama†,
Shinpei Hayashi†,
Takashi Kobayashi‡, and † Tokyo Institute of Technology, Japan
Motoshi Saeki† ‡ Nagoya University, Japan

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. 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. 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. “Bad smells” in CRA
• Display admin menu Menu
• Display user menu + displayMenu(authority: int)
(authority:
Low maintainability
Branches New option causes modification
public void if (authority == ADMIN) {
displayMenu(int authoriuty) { ……
if (authority == ADMIN) { }
…… else if (authority == VIP) {
} ……
else { }
…… else {
} ……
} }
5

6. General Responsibility
GRASP [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. 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. Challenges
1. How to analyze relationships of
responsibilities?
• Display admin menu • Display admin menu
similar. similar?
• Display user menu • To display the menu of users
2. 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. Our Solutions
1. How to analyze relationships of
responsibilities?
Giving a special form for responsibility
descriptions enabling easier analysis of
responsibilities
2. How to deal with informal
descriptions of GRASP?
Giving formal definition of smell detection rules
based on GRASP
9

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. 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. 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. 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. CRA Refactorings
1. Move Responsibility
− moves a responsibility to more appropriate class
2. Introduce Simple Factory
− unifies creation responsibilities which instantiate the same class
3. Introduce Creator
− moves responsibilities of instantiating a class to an appropriate class
4. Introduce Polymorphism
− separately assigns coordinate responsibilities to individual classes
having a common parent class
5. Introduce Facade
− reorganizes a CRA having complex dependencies among owner
classes of the responsibilities
14

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. Introduce Polymorphism
1. Create new child classes
2. Move responsibilities
3. Create a parent class
4. Rename
Menu
• Display admin menu
• Display user menu
16

17. Introduce Polymorphism
1. Create new child classes
2. Move responsibilities
3. Create a parent class
4. Rename
Menu
• Display admin menu
• Display user menu
Child1
17

18. Introduce Polymorphism
1. Create new child classes
2. Move responsibilities
3. Create a parent class
4. Rename
Menu
• Display admin menu
Child1
• Display user menu
18

19. Introduce Polymorphism
1. Create new child classes
2. Move responsibilities
3. Create a parent class
4. Rename
Menu
• Display admin menu Base
Child1
• Display user menu
19

20. Introduce Polymorphism
1. Create new child classes
2. Move responsibilities
3. Create a parent class
4. Rename
Admin-Menu
• Display admin menu Menu
User-Menu
• Display user menu
20

21. Supporting Tool: RAST
21

22. Supporting Tool: RAST
Responsibilities
Class diagram editor
Responsibility
editor
22

23. Supporting Tool: RAST
metrics view:
• CLCr
• LCOMr
lower is better
Suggested CRA refactorings
23

24. Supporting Tool: RAST
Related classes
are highlighted
24

25. Supporting Tool: RAST
Refactored
25

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. 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. 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. Experimental Design (2)
RQ1: RQ2:
Quality of design Support for designers
• CLCr
Metric • NCr Questionnaires
• LCOMr
Supply chain management system
System for a virtual winery
• 5 use cases
• 46 responsibilities
29

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. 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. Future Work
 Improving refactoring rules
− Usage of architecture information; e.g. MVC
 Evaluation++
− Statistical evidences
− Costs for describing responsibilities
− Usability of RAST
32

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
10
Supporting Tool: RAST Preliminary Evaluation
metrics view:  RQ1: Does our method improve the
•CLCr design quality of CRA?
•LCOMr
Obtained positive results!
lower is better
Suggested CRA refactorings  RQ2: Do CRA alternatives suggested by
our tool support designers appropriately?
Conclusion
Obtained positive results!
23 27

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