Class Responsibility Assignment as Fuzzy Constraint Satisfaction

Class Responsibility
Assignment
as
Fuzzy Constraint
Satisfaction
Shinpei Hayashi†,TakutoYanagida‡,
Motoshi Saeki†, and Hidenori Mimura‡
†Tokyo Institute of Technology ‡Shizuoka University

Assignment (CRA)
l  Deciding a mapping A : M à K
2
MAX
Piece()
name
faceValue
Die()
roll()
getFaceValue()
location
getLocation()
setLocation()
Player()
board
getLocation()
piece
dice
takeTurn()
getName()
Knowing responsibilities:
Doing responsibilities:
Responsibilities (M) Classes (K)
Assignment(A)
Player
Die
Piece

Towards Quality CRA
l  Example criterion: Low Coupling
3
Die
MAX
faceValue
Die()
getFaceValue()
Piece
location
Piece()
getLocation()
setLocation()
Player
name
piece
board
dice
Player()
takeTurn()
getLocation()
getName()
roll()
Die
MAX
faceValue
Die()
getFaceValue()
roll()
Piece
location
Piece()
getLocation()
setLocation()
Player
name
piece
board
dice
Player()
takeTurn()
getLocation()
getName()
roll()
CRA 1 CRA 2

Challenges for
Automating CRA
l  CRA is over-constrained
– Low Coupling: The distance between two classes
having related responsibilities should be short.
– High Cohesion: The relation between two
responsibilities in close classes should be close.
4
Trade-off
A realistic solution needed,
which satisfies constraints to some extent

Toward InteractiveTool
l  Support of trial-and-error in design process
– Stability:
•  "I want to improve my manually-assigned model.
Do not DRASTICALLY modify it!"
– Users Intention:
•  "I found that these two responsibilities should be
assigned to the same class / different classes"
5
Flexibly configurable technique is needed

Our Approach
l  Formulating CRA using Fuzzy Constraint
Satisfaction Problem (FCSP)
– Combinational search problem in AI field
– Benefits
•  No need to define a monolithic evaluation
function
– Each criterion is naturally represented
as fuzzy constraints
•  Usage of well-maintained solvers
6

FCSP
l  Variable: X = { x1, x2, ..., xn }
l  Domain: D = { D1, D2, ..., Dn }
l  Constraint: C = { c1, c2, ..., cr }
– inc. Unary and binary constraints
– Each constraint has
its satisfaction degree (µR) [0, 1]
l  Objective:
– Maximizing min µR
7
c1
c2
x1
x2 x3
c4
c3
c6c5
D1
D3D2
c∈C

Formulation
l  Variable x
l  Domain D
l  Constraint c
8
roll()
setLocation() takeTurn()
c1
c2
x1
x2 x3
c4ClassA
ClassB
c3
c6c5
ClassA
ClassB
ClassA
ClassB
(3 responsibilities)
ß Responsibility m ∈ M
ß Set of classes K
ß Assignment strategy

Given Information
l  Normalized two measures are used
–  Class Distance cd : K2 à [0, 1]
–  Responsibility Relevance mr : M2 → [0, 1]
9
0 1
When k1 = k2
cd(k1, k2)
When the distance between
k1 and k2 is the farthest
0 1
When m1 is no
relevance with m2
mr(m1, m2)
When the relevance between
m1 and m2 is the highest

Constraints
l  clc: Low Coupling
– relevant responsibilities are in distant classes
l  chc: High Cohesion
– irrelevant responsibilities are in closer classes
l  cs: Stability
– responsibilities moved from the initial assignment
l  csame, cdiff: Users Intention
– distance between the specified responsibilities does
not follow
10

clc: Low Coupling
l  Binary constraint for a pair of variables
l  Satisfaction degree decreases when
relevant responsibilities are in distant classes
11
cd
1
1
Satisfaction
degree
0
1
1
1
mr
µRc(k1, k2) = { –mr(m1, m2)cd(k1, k2) + 1 }w
For m1 and m2,
(When w = 1)

chc: High Cohesion
l  Binary constraint for a pair of variables
l  Satisfaction degree decreases when
irrelevant responsibilities are in closer classes
12
µRc(k1, k2) = { (1 – mr(m1, m2))cd(k1, k2) + mr(m1, m2) }w
For m1 and m2,
Satisfaction
degree
mr
cd
0
1
1
1
1
1
1
(When w = 1)

cs: Stability
l  Unary constraint for each variable
l  Satisfaction degree decreases when the class to
which a responsibility belongs in the current
assignment is far from that in the given assignment
13
µRc(k) = { 1 – cd(korig, k) }wFor m,

csame / cdiff : Intention
l  Binary constraint for each pair of variables
l  Satisfaction degree decreases based on the
distance between the target classes
14
µRcsame(k1, k2) = { 1 – cd(k1, k2) }w
µRcdiff(k1, k2) = cd(k1, k2)w
For m1 and m2,

15
Example: Constraints
ClassA
ClassB
ClassA
ClassB
ClassA
ClassB
roll()

16
•  Low Coupling
•  High Cohesion
•  (Intention)
ClassA
ClassB
ClassA
ClassB
ClassA
ClassB
roll()

17
ClassA
ClassB
ClassA
ClassB
ClassA
ClassB
roll()
•  Low Coupling
•  High Cohesion
•  Intention
Stability

Evaluation Questions
l  EQ 1:
How accurately does our technique assign responsibilities from
scratch?
l  EQ 2:
How accurately does our technique fix the assignment of
responsibilities if an initial assignment is given?
l  EQ 3:
Does our technique fix the assignment
when users’ intentions are given?
l  EQ 4:
Is the calculation of the assignment performed fast enough?
18

Summary of Evaluation
l  EQ 1:
How accurately does our technique
assign responsibilities from scratch?
l  EQ 2
How accurately does our technique
fix the assignment of responsibilities
if an initial assignment is given?
l  EQ 3
Does our technique fix the assignment
when users’ intentions are given?
l  EQ 4
Is the calculation of the assignment
performed fast enough?
19
A certain level of precision.
Monopoly: 69%
NextGenPos: 33%
Good level of precision.
Monopoly: 58%
NextGenPos: 73%
Yes.
2 of 3 constraints hold.
Yes.
e.g., Fix: <1ms

Experimental Setup
l  Example models from a CRA textbook
l  Reverse engineering from source code
– Examples and oracles were extracted from textbook
– Class distance cd and Responsibility relevance mr
were measured based on the oracle
20
System # classes # responsibilities
Monopoly 6 26
NextGenPos 9 30

EQ 1 (from scratch)
l  Prepared an empty model and assigned all the
responsibilities
21
Die()
roll()
getFaceValue()
MonopolyGame() [MonopolyGame]
Player() [Player]
takeTurn() [Player]
getLocation() [Player]
Piece()
getLocation()
setLocation()
getName() [Player]
Square() [Square]
getName() [Square]
getIndex() [Square]
Class 2 (Die)
playGame()
getPlayers()
playRound()
Class 3 (MonopolyGame) Board()
getSquare()
getStartSquare()
buildSquares()
build()
linkSquares()
link()
Class 1 (Board)
Class 5 (Player)
setNextSquare()
getNextSquare()
Class 6 (Square)
Class 4 (Piece)
How accurately does our technique assign responsibilities from scratch?
Class 2 (Die)
Class 3 (MonopolyGame)
Class 1 (Board)
Class 5 (Player)
Class 6 (Square)
Class 4 (Piece)

EQ 1 (from scratch)
22
Die()
roll()
getFaceValue()
Player() [Player]
takeTurn() [Player]
Class 2 (Die)
playGame()
getPlayers()
playRound()
getSquare()
getStartSquare()
buildSquares()
build()
linkSquares()
link()
Class 1 (Board)
Square() [Square]
getName() [Square]
getIndex() [Square]
Class 5 (Player)
setNextSquare()
getNextSquare()
Class 6 (Square)
Piece()
getLocation()
setLocation()
getName() [Player]
Class 4 (Piece)
Incorrect assignment [Oracle]
Monopoly: 69%
getRegister() [Store]
Class 8 (SaleLineItem)
becomeComplete()
isComplete()
Class 7 (Sale)
Payment()
getAmount()
makePayment() [Sale]
Class 3 (Payment)
Money()
add()
minus()
times()
getBalance() [Sale]
getTotal() [Sale]
Class 2 (Money)
getProductDescription() [ProductCatalog]
Register() [Register]
endSale() [Register]
enterItem() [Register]
makeNewSale() [Register]
makePayment() [Register]
makeLineItem() [Sale]
Class 5 (ProductDescription)
ItemID()
toString()
ProductCatalog() [ProductCatalog]
Class 1 (ItemID)
ProductDescription() [ProductDescription]
getItemID() [ProductDescription]
getPrice() [ProductDescription]
getDescription() [ProductDescription]
Class 4 (ProductCatalog)
SalesLineItem() [SalesLineItem]
getSubTotal() [SalesLineItem]
Class 9 (Store)
Sale() [Sale]
Class 6 (Register)
NextGenPos: 33%
How accurately does our technique assign responsibilities from scratch?

EQ 2 (with initial model)
l  Detached each responsibility and re-assigned it
23
How accurately does our technique fix the assignment of responsibilities
if an initial assignment is given?
Die()
roll()
getFaceValue()
Piece()
getLocation()
setLocation()
Player()
takeTurn()
getLocation()
getName()
Class 2 (Die)
MonopolyGame()
playGame()
getPlayers()
playRound()
Class 3 (MonopolyGame)
Board()
getSquare()
getStartSquare()
build()
linkSquares()
link()
Class 1 (Board)
Class 5 (Player)
Square()
getName()
getIndex()
setNextSquare()
getNextSquare()
Class 6 (Square)
Class 4 (Piece)
? l  Result
– Monopoly: 58%
(15 resp.)
– NextGenPos: 73%
(22 resp.)

EQ 3 (intention)
l  Added 3 intention constraints in Monopoly
→ 2 of 3 were worked well
24
Does our technique fix the assignment when users’ intentions are given?
Users intention-based
constraints are feasible.
Die()
roll()
getFaceValue()
Player() [Player]
takeTurn() [Player]
Class 2 (Die)
playGame()
getPlayers()
playRound()
getSquare()
getStartSquare()
buildSquares()
build()
linkSquares()
link()
Class 1 (Board)
Square() [Square]
getName() [Square]
getIndex() [Square]
Class 5 (Player)
setNextSquare()
getNextSquare()
Class 6 (Square)
Piece()
getLocation()
setLocation()
getName() [Player]
Class 4 (Piece)
csame csame
cdiff

EQ 4 (execution time)
l  Implementation
–  Our FCSP library w/ fuzzy forward checking
–  on Java 7 (Window 7, Intel Core i7, 2.93GHz)
l  Result
–  Experiment for EQ 1 (≠ actual usage)
•  Monopoly: 20 ms
•  NextGenPos: 8550 ms
–  Experiment for EQ 2
•  < 1 ms
–  Experiment for EQ 3
•  20 ms
25
Yes, fast enough.
Is the calculation of the assignment performed fast enough?

Discussion/Conclusion
26
(Flexibility by formulating CRA as fuzzy CSP)
EQ 2:
improvement of
existing model
EQ 3:
Addition of
users intention
EQ 4:
Execution time
Might be feasible to develop
an interactive CASE tool for supporting CRA

Future Work
l  Richer case studies for confirming scalability
– Applying our technique to real systems
l  Use of other software metrics
– e.g., LCOM*
l  Expressing other strategies as fuzzy constraints
– e.g., GRASP
27
Implementing CASE tool for designers

Assignment (CRA)
!  Deciding a mapping A : M " K
2
MAX
Piece()
name
faceValue
Die()
roll()
getFaceValue()
location
getLocation()
setLocation()
Player()
board
getLocation()
piece
dice
takeTurn()
getName()
Knowing responsibilities:
Doing responsibilities:
Responsibilities (M) Classes (K)
Assignment(A)
Player
Die
Piece
Formulation
!  Variable x
!  Domain D
!  Constraint c
8
roll()
c1
c2
x1
x2 x3
c4ClassA
ClassB
c3
c6c5
ClassA
ClassB
ClassA
ClassB
(3 responsibilities)
# Responsibility m ∈ M
# Set of classes K
# Assignment strategy
Constraints
!  clc: Low Coupling
– relevant responsibilities are in distant classes
!  chc: High Cohesion
– irrelevant responsibilities are in closer classes
!  cs: Stability
– responsibilities moved from the initial assignment
!  csame, cdiff: Users Intention
– distance between the specified responsibilities does
not follow
10
Discussion/Conclusion
27
(Flexibility by formulating CRA as fuzzy CSP)
EQ 2:
improvement of
existing model
EQ 3:
Addition of
users intention
EQ 4:
Execution time
Might be feasible to develop
an interactive CASE tool for supporting CRA

Credits
l  Photo by teamaskins
– CRC Cards | Flickr
http://www.flickr.com/photos/teamaskins/130003950/
29

Class Responsibility Assignment as Fuzzy Constraint Satisfaction

More Related Content

What's hot (10)

Viewers also liked (20)

Similar to Class Responsibility Assignment as Fuzzy Constraint Satisfaction (20)

More from Institute of Science Tokyo (9)

Recently uploaded (20)

Class Responsibility Assignment as Fuzzy Constraint Satisfaction