Detec%ng
So+ware
       Modularity
Viola%ons
       Sunny
Wong,^*
Yuanfang
Cai,*
       Miryung
Kim,†
and
Michael
Dalton*
...
Mo%va%on
    The
Essence
of
Modularity:

          Allows
for
independent
module
evolu%on
           [Parnas
72;
Baldwin...
Limita%ons
of
Exis%ng
Approaches
    Verifica%on
and
valida%on
          Modularity
viola%ons
usually
do
not
affect
func%o...
Approach
Overview
    Step
1:
Find
which
modules
should
change
together
from
their
     design
structure
          Input...
Example
(Maze
Game)
          [Gamma
et
al.
94]

Design
Rule
Hierarchy
Analysis


            [Wong
et
al.
09]

Step
1:
Structure‐based
Impact
Analysis

                              Green: change seed                              Blu...
Step
2:
History‐based
Impact
Analysis

                            Green: change seed                            Red: hist...
Step
3:
Find
Discrepancies

                              Green: change seed                              Blue: structure-...
Iden%fy
Recurring
Discrepancies
as
          Modularity
Viola%ons
    Example
discrepancy
sets:
{a,
b},
{a,
b,
c},
{a,
b}...
Evalua%on
    Evalua%on
ques%ons

          Q1:

How
accurate
are
the
viola%ons
iden%fied
by
Clio?
          Q2:

How
ea...
Evalua%on
Subjects
    Eclipse
JDT
          10
releases
(~3
years)
          27806
commits
in
revision
history
      ...
Q1:
Accuracy
of
Detected
Modularity

Viola%ons
                Reported
      Total
                                      ...
Q2:
Timeliness
of
Modularity
Viola%on

          Detec%on
    Hadoop:
Clio
detects
modularity
viola%ons,
on
average,
6
  ...
Q3:
Characteris%cs
of
Modularity

             Viola%ons
    Analyzed
symptoms
of
modularity
viola%ons
          Cyclic
...
Summary
    We
define
modularity
viola-on
as
the
mismatches
between
     designed
modular
structure
and
actual
evolu%on
pa...
Detec%ng
So+ware
       Modularity
Viola%ons
       Sunny
Wong,^*
Yuanfang
Cai,*
       Miryung
Kim,†
and
Michael
Dalton*
...
Upcoming SlideShare
Loading in …5
×

ICSE 2011 Research Paper on Modularity Violations

1,313 views

Published on

Detecting Software Modularity Violations, Sunny Wong, Yuanfang Cai, Miryung Kim, Michael Dalton, ICSE' 11: Proceedings of the 2011 ACM and IEEE 33rd International Conference on Software Engineering

Published in: Technology
2 Comments
0 Likes
Statistics
Notes
  • I am student of University of Limerick, i need this Ppt , will you allow me to download it please .
    regards
    Kamran
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Excellent Research Paper Ppt
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
1,313
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
2
Likes
0
Embeds 0
No embeds

No notes for slide

ICSE 2011 Research Paper on Modularity Violations

  1. 1. Detec%ng
So+ware
 Modularity
Viola%ons
 Sunny
Wong,^*
Yuanfang
Cai,*
 Miryung
Kim,†
and
Michael
Dalton*
 *
Drexel
University
 †
University
of
Texas
at
Aus%n
 ^
Siemens
Healthcare
Supported
in
part
by
NSF
CCF‐0916891,
CCF‐1043810,
and
DUE‐0837665

  2. 2. Mo%va%on
  The
Essence
of
Modularity:

   Allows
for
independent
module
evolu%on
 [Parnas
72;
Baldwin
and
Clark
00]
  In
reality,
modules
do
not
always
change
independently
   Quick
and
dirty
implementa%on
leaves
technical
debts
   So+ware
evolves
in
a
way
that
deviates
from
original
design

  Modularity
viola%on:

   Components
that
are
designed
to
evolve
independently
yet
change
 together
in
reality
frequently
  Our
goal:

   Detect
modularity
viola%ons
   Slow
down
modularity
decay

  3. 3. Limita%ons
of
Exis%ng
Approaches
  Verifica%on
and
valida%on
   Modularity
viola%ons
usually
do
not
affect
func%onality
   Not
testable
   Not
problema%c
un%l
maintenance
  Tradi%onal
modularity
analyses
   Prevailing
metrics
(e.g.,
coupling,
cohesion)
do
not
measure
 independence
of
module
evolu%on
   Do
not
detect
the
mismatches
between
design
and
reality
  Code
smell
analyses
   Not
all
code
smells
cause
modularity
viola%on
   Not
all
modularity
viola%ons
are
code
smells

  4. 4. Approach
Overview
  Step
1:
Find
which
modules
should
change
together
from
their
 design
structure
   Input:
design
model
(e.g.,
UML,
source
code)

   Clio
finds
modules
from
derived
design
structure
matrix
(DSM)
 [Baldwin
and
Clark
00]
  Step
2:
Find
which
modules
actually
change
together
in
reality
   Input:
revision
history
   Clio
finds
logical
coupling
of
components
[Ying
et
al.
04]
  Step
3:
Discover
recurring
discrepancies
between
the
output
 of
step
1
and
the
output
of
step
2
as
modularity
viola-ons
   Clio
compares
which
modules
should
change
together
with
which
 modules
actually
change
together
   Recurring
discrepancies
are
reported
as
modularity
viola%ons

  5. 5. Example
(Maze
Game)
 [Gamma
et
al.
94]

  6. 6. Design
Rule
Hierarchy
Analysis


 [Wong
et
al.
09]

  7. 7. Step
1:
Structure‐based
Impact
Analysis

 Green: change seed Blue: structure-based impact scopeChange seed: DoorStructure Impact-scope: MazeFactory DoorNeedingSpell … Change seed: EnchantedMazeFactory Structure Impact-scope: (none)
  8. 8. Step
2:
History‐based
Impact
Analysis

 Green: change seed Red: history-based impact scopeChange seed: DoorHistory Impact-scope: MapSite Change seed: EnchantedMazeFactory History Impact-scope: BombedMazeFactory
  9. 9. Step
3:
Find
Discrepancies

 Green: change seed Blue: structure-based impact scope Red: history-based impact scopeChange seed: DoorStructure Impact-scope: MazeFactory DoorNeedingSpell …History Impact-scope: MapSite Change seed: EnchantedMazeFactory Structure Impact-scope: (none) History Impact-scope: BombedMazeFactory
  10. 10. Iden%fy
Recurring
Discrepancies
as
 Modularity
Viola%ons
  Example
discrepancy
sets:
{a,
b},
{a,
b,
c},
{a,
b}
 Frequency
 {a,
b}
 3
 {a,
c}
 1
 {a,
b,
c}
 1
  Clio
takes
minimal
frequency
threshold
as
input,
and
orders
 the
discrepancies
according
to
their
frequencies.


  11. 11. Evalua%on
  Evalua%on
ques%ons

   Q1:

How
accurate
are
the
viola%ons
iden%fied
by
Clio?
   Q2:

How
early
can
Clio
iden%fy
viola%ons?
   Q3:

What
are
the
characteris%cs
of
viola%ons
iden%fied
by
Clio?
  Manually
confirm
viola%ons
by
looking
forward
in
history
   Refactoring
in
codebase
   Developer
recogni%on
(e.g.,
change
request)
   Symptoms
of
code
smells
  Conserva%ve
confirma%on

  12. 12. Evalua%on
Subjects
  Eclipse
JDT
   10
releases
(~3
years)
   27806
commits
in
revision
history
   3458
modifica%on
requests
   222
KSLOC
in
latest
version
  Hadoop
Common
   15
releases
(~3
years)
   3001
commits
in
revision
history
   490
modifica%on
requests
   64
KSLOC
in
latest
version
  Experimental
Serngs
   Minimal
threshold
of
recurring
discrepancies:
2
   Length
of
sliding
window
for
analysis:

5
releases


  13. 13. Q1:
Accuracy
of
Detected
Modularity

Viola%ons
 Reported
 Total
 Precision
 Viola3ons
 Confirmed
 Eclipse
JDT
 399
 161
 40%
 Hadoop
 231
 152
 66%

  14. 14. Q2:
Timeliness
of
Modularity
Viola%on

 Detec%on
  Hadoop:
Clio
detects
modularity
viola%ons,
on
average,
6
 releases
before
developers
iden%fy
the
design
problems
  Eclipse:
Clio
detects
modularity
viola%ons,
on
average,
5
 releases
before
developers
iden%fy
the
design
problems

  15. 15. Q3:
Characteris%cs
of
Modularity

 Viola%ons
  Analyzed
symptoms
of
modularity
viola%ons
   Cyclic
dependencies
   Cloned
code
   Poor
inheritance
hierarchy
   Unnamed
coupling
(43%
in
Hadoop,
16%
in
Eclipse)
  Example
of
unnamed
coupling
   Several
classes
iden%fied
as
a
part
of
modularity
viola%ons,
but
do
not
 exhibit
any
symptoms
of
bad
code
smells.

   Open
modifica%on
request
to
“redesign/refactor”
those
classes
 because
they
are
“hard
to
maintain,
briwle,
and
merits
some
rework”

  16. 16. Summary
  We
define
modularity
viola-on
as
the
mismatches
between
 designed
modular
structure
and
actual
evolu%on
path
  Clio
compares
how
modules
should
change
together
against
 how
modules
actually
change
together
to
discover
modularity
 viola-ons
  Can
detect
modularity
viola%ons
with
40%
accuracy
for
Eclipse
 and
66%
accuracy
for
Hadoop
  Can
iden%fy
modularity
viola%ons
several
releases
before
 developers
discover
them

  Symptoms
of
modularity
viola%ons
observed
in
our
study
go
 beyond
known
bad
smells


  17. 17. Detec%ng
So+ware
 Modularity
Viola%ons
 Sunny
Wong,^*
Yuanfang
Cai,*
 Miryung
Kim,†
and
Michael
Dalton*
 *
Drexel
University
 †
University
of
Texas
at
Aus%n
 ^
Siemens
Healthcare
Supported
in
part
by
NSF
CCF‐0916891,
CCF‐1043810,
and
DUE‐0837665


×