supporting design model refactoring for improving class responsibility assignment

† Tokyo Institute of Technology, Japan ‡ Nagoya University, Japan

Supporting Design Model Refactoring

for Improving

Class Responsibility Assignment

Motohiro Akiyama†, Shinpei Hayashi†, Takashi Kobayashi‡, and Motoshi Saeki†

2

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

Abstract

3

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

Background

4

How to model this? − Menu available after authentication − Different menu required according to roles

CRA: an example

for users

Menu • Display admin menu

• Display user menu

Responsibilities + displayMenu(authority: int)

for admins

Classes

hayashi

Login

Login

account password deadbeef

A solution: • Display admin menu • Display user menu

5

“Bad smells” in CRA

if (authority == ADMIN) { …… } else if (authority == VIP) { …… } else { …… }

public void displayMenu(int authoriuty) { if (authority == ADMIN) { …… } else { …… } }

Low maintainability New option causes modification Branches

Menu

+ displayMenu(authority: int)

• Display admin menu

• Display user menu (authority: int)int)

6

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

GRASP [Larman 04] General Responsibility

Assignment Software Pattern

7

CRA Refactoring

Refactor based on Protected Variations Polymorphism

Menu

+ displayMenu(authority: int) • Display admin menu


Menu

+ displayMenu()

Admin-Menu

+ displayMenu()

User-Menu

+ displayMenu()



How to achieve automated support of CRA refactorings?

8

1. How to analyze relationships of responsibilities?

2. How to deal with informal descriptions of GRASP?

Challenges


• To display the menu of users


• Display user menu similar. similar?

When related alternatives or behaviors vary by class, assign responsibility for the behavior using polymorphic operations to the classes for which the behavior varies. operations to the classes for which the behavior varies

When related alternatives or behaviors vary by classassign responsibility for the behavior using polymorphic operations to the classes for which the behavior varies

When related alternatives or behaviors vary by classassign responsibility for the behavior using polymorphic operations to the classes for which the behavior varies

9

1. How to analyze relationships of responsibilities?

2. How to deal with informal descriptions of GRASP?

Our Solutions

Giving formal definition of smell detection rules based on GRASP

Giving a special form for responsibility descriptions enabling easier analysis of responsibilities

10

1. Describing responsibilities in a special form

− enable us to analyze them easily

Our Approach

Requirements documents

(e.g. use case desc.)

Refactor

Responsibilities

CRA

2. Automated CRA refactoring − Detecting CRA smells − Suggesting CRA refactorings − Applying CRA refactoring when accepted

11

Finer-grained than sentence − Describe a responsibility as 7 components − who does what to whom when − Similar to the Case Grammar [Fillmore 68]

Responsibility Form

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

12

Responsibility Form • #1: Display admin menu

id: 1action: Display target: menu mod: admin pos: (nil) cond: (nil) dep: #4

Menu

LoginController

• #4: Check authority of account

id: 4 action: Check target: authority mod: (nil) pos: account cond: (nil) dep: (nil)

13

Detecting using similarity of responsibility descriptions

coordinate Relationship

• #1: Display user menu

id: 1 action: Display target: menu mod: user pos: (nil) cond: (nil) dep: (nil)

• #2: Display admin menu

id: 2 action: Display target: menu mod: admin pos: (nil) cond: (nil) dep: (nil)

same same

different same

14

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

CRA Refactorings

15

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

Introduce Polymorphism

16

Introduce Polymorphism 1. Create new child classes 2. Move responsibilities 3. Create a parent class 4. Rename

Menu



17


Menu

Child1



1. Create new child classes 2. Move responsibilities 3. Create a parent class 4. Rename

18


Menu

Child1




19


Base

Menu

Child1




20


Menu

Admin-Menu

User-Menu




21

Supporting Tool: RAST Supporting Tool: RASTSupporting Tool: RAST

22

Supporting Tool: RAST

Class diagram editor

Responsibility editor

Responsibilities

23


Suggested CRA refactorings

metrics view: • CLCr • LCOMr

lower is better

24


Related classes are highlighted

25


Refactored

26

8 / 9 patterns are supported in RAST

Supported GRASPs

GRASP CRA refactorings supports

✓ Information Expert ✓ Pure Fabrication

✓ Indirection ✓ Creator

✓ Protected Variations ✓ Polymorphism ✓ Low Coupling ✓ High Cohesion

✗ Controller

Move Responsibility Introduce Simple Factory Introduce Facade Introduce Creator Introduce Polymorphism

The metrics view in RAST

(Unsupported)

27

RQ1: Does our method improve the design quality of CRA?

RQ2: Do CRA alternatives suggested by our tool support designers appropriately?

Preliminary Evaluation

Obtained positive results!


28

Subjects

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 − Assigning given responsibilities to classes

Experimental Design (1)

Student 1 (S1)

Expert 1 (E1)

Student 2 (S2)

Expert 2 (E2)

(2 hrs)

29

Experimental Design (2) RQ1: Quality of design

RQ2: Support for designers

Metric • CLCr • NCr • LCOMr

Questionnaires

System

Supply chain management system for a virtual winery• 5 use cases • 46 responsibilities

30

RQ1: Results

S1

E1

S2

E2 average

CLCr 0.67 1.04 0.86

2.53 1.30 1.92

NCr 0.85 1.07 0.96

1.27 1.60 1.43

LCOMr 0.72 0.79 0.76

0.80 0.97 0.89

: RAST’s CRA refactoring available

(Although the result is far from statistical evidence,) All metric values with tool support are better.

31

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)

RQ2: Results

31

Mostly the answers are positive: The subjects prefer the suggested CRA.

32

Improving refactoring rules − Usage of architecture information; e.g. MVC

Evaluation++ − Statistical evidences − Costs for describing responsibilities − Usability of RAST

Future Work

Conclusion

7

CRA Refactoring

Refactor based onProtected VariationsPolymorphism

How to achieve automated support of CRA refactorings? 10

1. Describing responsibilities in aspecial form− enable us to analyze them easily

Our Approach

Requirementsdocuments

(e.g. use case desc.)

Refactor

Responsibilities

CRA

2. Automated CRA refactoring− Detecting CRA smells− Suggesting CRA refactorings− Applying CRA refactoring when accepted

23


Suggested CRA refactorings

metrics view:•CLCr•LCOMr

lower is better

27

RQ1: Does our method improve the design quality of CRA?

RQ2: Do CRA alternatives suggested by our tool support designers appropriately?

Preliminary Evaluation



34

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

Credits





http://myds.jp/

http://myds.jp/

http://motoki-y.sakura.ne.jp/illust/skeleton.shtml


