Your SlideShare is downloading. ×
0
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
ICSE 2011 Research Paper on Modularity Violations
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

ICSE 2011 Research Paper on Modularity Violations

1,033

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

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,033
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
2
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. 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. 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. Example
(Maze
Game)
 [Gamma
et
al.
94]

  • 6. Design
Rule
Hierarchy
Analysis


 [Wong
et
al.
09]

  • 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. 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. 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. 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. 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. 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. Q1:
Accuracy
of
Detected
Modularity

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

  • 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. 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. 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. 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


×