Measuring Software: From Data to Actionable Knowledge
16 May 2015
International Workshop on Software Architecture and Metrics
Radu Marinescu [email protected]
@radu_marinescu
Logo- culori
Culoare pentru o institu]ie unic\ - clar\, curat\, u[or de recunoscut - culoarea este elementul cel mai u[or de recunoscut, albastru indigo reflect\ personalitatea institu]iei de <nv\]\m>nt superior tehnic - ferm, puternic, dar introspectiv, valorizator. Este o combina]ie de albastru [i ro[u, <n care dominant este albastrul cu atributele sale introspective. Griul neutru pune <n valoare albastrul, accentu>nd valorile sale.
Logo- culori
Culoare pentru o institu]ie unic\ - clar\, curat\, u[or de recunoscut - culoarea este elementul cel mai u[or de recunoscut, albastru indigo reflect\ personalitatea institu]iei de <nv\]\m>nt superior tehnic - ferm, puternic, dar introspectiv, valorizator. Este o combina]ie de albastru [i ro[u, <n care dominant este albastrul cu atributele sale introspective. Griul neutru pune <n valoare albastrul, accentu>nd valorile sale.
Logo- culori
Culoare pentru o institu]ie unic\ - clar\, curat\, u[or de recunoscut - culoarea este elementul cel mai u[or de recunoscut, albastru indigo reflect\ personalitatea institu]iei de <nv\]\m>nt superior tehnic - ferm, puternic, dar introspectiv, valorizator. Este o combina]ie de albastru [i ro[u, <n care dominant este albastrul cu atributele sale introspective. Griul neutru pune <n valoare albastrul, accentu>nd valorile sale.
Logo- culori
Culoare pentru o institu]ie unic\ - clar\, curat\, u[or de recunoscut - culoarea este elementul cel mai u[or de recunoscut, albastru indigo reflect\ personalitatea institu]iei de <nv\]\m>nt superior tehnic - ferm, puternic, dar introspectiv, valorizator. Este o combina]ie de albastru [i ro[u, <n care dominant este albastrul cu atributele sale introspective. Griul neutru pune <n valoare albastrul, accentu>nd valorile sale.
Michele LanzaRadu Marinescu
Object-Oriented Metrics
in PracticeUsing Software Metrics to
Characterize, Evaluate, and Improve the Design of Object-Oriented Systems
Foreword by Stéphane Ducasse
Lanza · Marinescu
Object-O
riented M
etrics in Practice
Michele Lanza is an Assistant Professor at the University of Lugano, Switzer-land. His main research interests lie in software (re)engineering and software evo-lution with a special focus on software visualization and metrics. He is the creatorof CodeCrawler, a freely available language-independent software visualizationtool. His Ph.D. work won the Ernst Denert Software Engineering Award in 2003.Radu Marinescu is an Assistant Professor at the Politehnica University ofTimisoara, Romania. His research focus is on object-oriented design, reenginee-ring and quality assurance. He is the author of a suite of novel object-orientedmetrics and the main creator of iPlasma, an integrated and freely available tool-kit for Java and C++ projects. Several of his published research ideas have alreadybeen applied in the well-known “Borland Together Control Center” CASE tool.
783540 2442959
ISBN 3-540-24429-8
› springer.com
Object-Oriented Metrics inPracticeMetrics are paramount in every engineering discipline. However, due to its lackof rigor and its intrinsic complexity, software engineering is not considered aclassical engineering activity. Moreover, defining, understanding and applyingsoftware metrics often looks like an overly complex activity, recommended onlyto ‘trained professionals’. In general, if a software system is delivering theexpected functionality, only few people – if any – care about measuring the qua-lity of its internal structure. Consequently, software metrics are still regardedrather circumspectly by most software developers.
Lanza and Marinescu demystify the design metrics used to assess the size,quality and complexity of object-oriented software systems. Based on a novelapproach, backed by generally accepted semantics for metrics and by statisticalinformation from many industrial projects, they deduce a suite of metrics-basedpatterns for assessing the design of object-oriented software systems. Theyshow in detail how to identify design disharmonies in code, and how to deviseand apply remedies.
The combination of theoretically sound results and practically tested procedu-res and solution paths makes this book an ideal companion for professionalsoftware architects, developers and quality engineers. The pattern-oriented des-cription of disharmonies offers easy access to detecting shortcomings andapplying solutions to real problems.
Features and Benefits:
* comprehensive list of object-oriented disharmony patterns
* many reengineering strategies for poorly structured code
* brief introduction to software visualization
‘’This well-written book is an impor-tant piece of work that takes theseemingly forgotten art of object-oriented metrics to the next level interms of relevance and usefulness.’Richard C. Gronback,Chief Scientist, Borland SoftwareCorporation
13
1
1000+ reprinted 2010/2015
MIP ICSME’14
inFusion
inFusion
inFusion
inFusion
seentoo much…
I have
time & money wasted on…
“hide & seek” bug chasing
playing futile numbers games
code being thrown away
but also…
myriads of useless papers
tens of “mayfly” prototypes
a true story…
180.9
(12 subsystems)
(17 methods)
(3 subsystems)
NOW6 months ago
(1 class)
(22
(10 methods)
(32 classes)
(16 classes)
(28 classes)
(120 methods)
180.9
(12 subsystems)
(17 methods)
(3 subsystems)
NOW6 months ago
(1 class)
(22
(10 methods)
(32 classes)
(16 classes)
(28 classes)
(120 methods)
180.9
(12 subsystems)
(17 methods)
(3 subsystems)
NOW6 months ago
(1 class)
(22
(10 methods)
(32 classes)
(16 classes)
(28 classes)
(120 methods)
180.9
(12 subsystems)
(17 methods)
(3 subsystems)
NOW6 months ago
(1 class)
(22
(10 methods)
(32 classes)
(16 classes)
(28 classes)
(120 methods)
CYCLOMATIC COMPLEXITY
!This is not an isolated story
use of metrics(and other code analyses) in
use of metrics(and other code analyses) in
misuse
http://nemo.sonarqube.org/
12 Person-Years
1 issues / 8 LOC1 “key” issue / 140 LOChttp://nemo.sonarqube.org/
12 Person-Years
1 issues / 8 LOC1 “key” issue / 140 LOC
OMG! How is an “E”?!
http://nemo.sonarqube.org/
Picture from http://www.savvykidsofarkansas.com/event/the-boy-who-cried-wolf/
http://nemo.sonarqube.org/
The most efficient 7 weeks in the history of software development…
http://nemo.sonarqube.org/
The most efficient 7 weeks in the history of software development…
http://nemo.sonarqube.org/
The most efficient 7 weeks in the history of software development…
16.5 Person-Years of Technical Debt vanished!http://nemo.sonarqube.org/
The most efficient 7 weeks in the history of software development…
16.5 Person-Years of Technical Debt vanished!http://nemo.sonarqube.org/
Let’s zoom-in…
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
reducing CYCLO takes only 1 min / branch ?
reducing CYCLO for class is easier (137’) than for methods (285’)
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
http://nemo.sonarqube.org/
never knew it’s so easy to change a signature!
http://nemo.sonarqube.org/
but what if…
but what if…
http://nemo.sonarqube.org/
solving duplication does only depend on the number of blocks?
http://nemo.sonarqube.org/
…are these 2 cases equally easy?
…
Image from http://imgur.com/gallery/iWKad22
Let’s summarize…
1 Irrelevant Warnings
1 Irrelevant Warnings
2 Misleading Debt Quantification
1 Irrelevant Warnings
2 Misleading Debt Quantification
3 Toxic/Stupid Refactoring Advices
1 Irrelevant Warnings
2 Misleading Debt Quantification
3 Toxic/Stupid Refactoring Advices
4 Phony Thresholds
Why ?
Technical Debt
The first scary things was bugs
http://www.google.com/imgres?imgurl=http://micheltriana.com/wp-content/uploads/2010/12/
resharper-8x6.png&imgrefurl=http://micheltriana.com/2010/12/01/configuring-resharper-code-analysis/
&h=459&w=640&tbnid=MFJydOmaXXj3xM:&zoom=1&docid=e0dqbvDRdbGVSM&ei=xOEcVaXfOsiWaoa6gJAI&tbm=isch&client
=safari&ved=0CBwQMygAMAA
http://www.google.com/imgres?imgurl=http://micheltriana.com/wp-content/uploads/2010/12/
resharper-8x6.png&imgrefurl=http://micheltriana.com/2010/12/01/configuring-resharper-code-analysis/
&h=459&w=640&tbnid=MFJydOmaXXj3xM:&zoom=1&docid=e0dqbvDRdbGVSM&ei=xOEcVaXfOsiWaoa6gJAI&tbm=isch&client
=safari&ved=0CBwQMygAMAA
but then we realised…
Most maintenance effort goes into
understanding messy code
47%
19%
6%
28%
Testing DocumentingCoding Understanding
M. Ben-Menachem and G. S. Marliss. Software quality: Producing practical, consistent software. International Thomson Computer Press, 1997
Bugserror-prone
Bugs
Timehard to maintain
error-prone
… and bugs also usually hide in
messy code
Checkstyle
!We missed
an essential distinction
=
Strategic Flaws
Tactical Flaws
Execution Flaws
…system
…statements
…classes and functions
How do I design the…
Execution flaws Tactical flaws
Execution flaws Tactical flaws
Execution flaws Tactical flaws
Execution flaws Tactical flaws
Execution flaws Tactical flaws
PSA
PSA Gleason
PSA Gleason
PSA Gleason
?what about tactical problems
public class TarHeader{ /**
* The entry's name. */public StringBuffer name;/** * The entry's permission mode. */public int mode;/** * The entry's user id. */public int userId;/** * The entry's group id. */public int groupId;
}
public/**
* The entry's name. */
/** * The entry's permission mode. */
int/** * The entry's user id. */
/** * The entry's group id. */
int
}
public
public
public
public
public/**
* The entry's name. */
/** * The entry's permission mode. */
int/** * The entry's user id. */
/** * The entry's group id. */
int
}
public
public
public
publicDat
a
Class
public/**
* The entry's name. */
/** * The entry's permission mode. */
/** * The entry's user id. */
/** * The entry's group id. */
int
}
public/**
* The entry's name. */
/** * The entry's permission mode. */
/** * The entry's user id. */
/** * The entry's group id. */
int
}
private
private
private
private
public/**
* The entry's name. */
/** * The entry's permission mode. */
/** * The entry's user id. */
/** * The entry's group id. */
int
}
private
private
private
private
Encapsulate public data (in TarHeader)1
compile errors!
public class {
public void parseTarHeader( TarHeader hdr, byte[] header ){int offset = 0;hdr.name = TarHeader.parseName( header, offset,
TarHeader.NAMELEN );
offset += TarHeader.NAMELEN;hdr.mode = (int)TarHeader.parseOctal( header, offset,
TarHeader.MODELEN );
offset += TarHeader.MODELEN;
hdr.userId = (int)TarHeader.parseOctal( header, offset, TarHeader.UIDLEN );
offset += TarHeader.UIDLEN;
hdr.groupId = (int)TarHeader.parseOctal( header, offset, TarHeader.GIDLEN );}
TarEntry
public
public
hdr.TarHeader.
offset += TarHeader.hdr.
TarHeader.
offset += TarHeader.
hdr.TarHeader.
offset += TarHeader.
hdr.TarHeader}
TarEntry
TarHeader hdr
hdr.name
hdr.mode
hdr.userId
hdr.groupId
parseTarHeader
public
public
hdr.TarHeader.
offset += TarHeader.hdr.
TarHeader.
offset += TarHeader.
hdr.TarHeader.
offset += TarHeader.
hdr.TarHeader}
TarEntry
TarHeader hdr
hdr.name
hdr.mode
hdr.userId
hdr.groupId
parseTarHeader
Move the method (TarEntry > TarHeader)1
public
public
hdr.TarHeader.
offset += TarHeader.hdr.
TarHeader.
offset += TarHeader.
hdr.TarHeader.
offset += TarHeader.
hdr.TarHeader}
TarEntry
TarHeader hdr
hdr.name
hdr.mode
hdr.userId
hdr.groupId
parseTarHeader
Encapsulate public data (in TarHeader)2
Move the method (TarEntry > TarHeader)1
however …
public
public inthdr.
header, offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader
} public
int
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
long
offset = TarHeader.getLongOctalBytes( size, outbuf, offset, TarHeader.
}
hdr.mode = (int)TarHeader.parseOctal( header,
hdr.mode = (int)TarHeader.parseOctal( header,
offset, TarHeader.MODELEN );
offset, TarHeader.MODELEN );
offset += TarHeader.MODELEN;
offset += TarHeader.MODELEN;
hdr.userId = (int)TarHeader.parseOctal( header,
hdr.userId = (int)TarHeader.parseOctal( header, offset, TarHeader.UIDLEN );
offset, TarHeader.UIDLEN );
parseTarHeader
writeEntryHeader
public
public inthdr.
header, offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader
} public
int
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
long
offset = TarHeader.getLongOctalBytes( size, outbuf, offset, TarHeader.
}
hdr.mode = (int)TarHeader.parseOctal( header,
hdr.mode = (int)TarHeader.parseOctal( header,
offset, TarHeader.MODELEN );
offset, TarHeader.MODELEN );
offset += TarHeader.MODELEN;
offset += TarHeader.MODELEN;
hdr.userId = (int)TarHeader.parseOctal( header,
hdr.userId = (int)TarHeader.parseOctal( header, offset, TarHeader.UIDLEN );
offset, TarHeader.UIDLEN );
parseTarHeader
writeEntryHeader
Duplic
ated
Code
public
public inthdr.
header, offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader
} public
int
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
long
offset = TarHeader.getLongOctalBytes( size, outbuf, offset, TarHeader.
}
hdr.mode
hdr.mode
offset, TarHeader.
offset, TarHeader.
offset += TarHeader.
offset += TarHeader.
hdr.userId
hdr.userIdoffset, TarHeader.
offset, TarHeader.
parseTarHeader
writeEntryHeader
Extract method (by factoring out the duplicated code)1
public
public inthdr.
header, offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader
} public
int
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
long
offset = TarHeader.getLongOctalBytes( size, outbuf, offset, TarHeader.
}
hdr.mode
hdr.mode
offset, TarHeader.
offset, TarHeader.
offset += TarHeader.
offset += TarHeader.
hdr.userId
hdr.userIdoffset, TarHeader.
offset, TarHeader.
parseTarHeader
writeEntryHeader
Extract method (by factoring out the duplicated code)1
Move the newly created method (in TarHeader)2
public
public inthdr.
header, offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader
} public
int
hdr.offset, TarHeader.
offset += TarHeader.
hdr.offset, TarHeader.
long
offset = TarHeader.getLongOctalBytes( size, outbuf, offset, TarHeader.
}
hdr.mode
hdr.mode
offset, TarHeader.
offset, TarHeader.
offset += TarHeader.
offset += TarHeader.
hdr.userId
hdr.userIdoffset, TarHeader.
offset, TarHeader.
parseTarHeader
writeEntryHeader
Extract method (by factoring out the duplicated code)1
Move the newly created method (in TarHeader)2
Encapsulate public data (in TarHeader)3
yet, there is an alternative solution…
Move data (TarHeader > TarEntry)1
Move data (TarHeader > TarEntry)1
Encapsulate public data (in TarEntry)2
vs.
Extract method(out of the duplicated code)1
Move the newly created method(in TarHeader)2
Encapsulate public data(in TarHeader)3
Move data(TarHeader > TarEntry)1
Encapsulate public data(in TarEntry)2
vs.
Which solution is best?
Extract method(out of the duplicated code)1
Move the newly created method(in TarHeader)2
Encapsulate public data(in TarHeader)3
Move data(TarHeader > TarEntry)1
Encapsulate public data(in TarEntry)2
Only the developer who knows the context
can decide!
?How to deal with
tactical flaws
start with
symptom indicators
Checkstyle
Lorenz, Kidd, 1994Chidamber, Kemerer, 1994
LOC - number of lines of code
CYCLO - cyclomatic complexity of a function NOF - number of functions
FANOUT - outgoing coupling
NOA - number of attributes
DIT - depth of inheritance tree
TCC - tight class cohesion
…
The problem is…
Image from pickywallpapers.com
!Tactical flaws must be treated as
first-class entities
!…and symptoms must be
aggregated
for example…
from S.Demeyer, S.Ducasse, O.Nierstrasz - Object-Oriented Reengineering Patterns, 2003
from S.Demeyer, S.Ducasse, O.Nierstrasz - Object-Oriented Reengineering Patterns, 2003
from S.Demeyer, S.Ducasse, O.Nierstrasz - Object-Oriented Reengineering Patterns, 2003
or another example…
God Classes use data from small data-classes, centralize the intelligence of the system, and do everything.
A.Riel, 1996
God Classes break encapsulation, and are complex, and are not cohesive.
A.Riel, 1996
ATFD > FEW
Class uses directly more than a
few attributes of other classes
WMC ≥ VERY HIGH
Functional complexity of the
class is very high
TCC < ONE THIRD
Class cohesion is low
AND GodClass
from M.Lanza, R.Marinescu - Object-Oriented Metrics in Practice, 2006
but there is
one more problem when dealing with metrics…
Thresholds
who “authorized” these thresholds?
5 projects?!?! < 100 classes?!?!
Michele LanzaRadu Marinescu
Object-Oriented Metrics
in PracticeUsing Software Metrics to
Characterize, Evaluate, and Improve the Design of Object-Oriented Systems
Foreword by Stéphane Ducasse
Lanza · Marinescu
Ob
ject-Orien
ted
Metrics in
Practice
Michele Lanza is an Assistant Professor at the University of Lugano, Switzer-land. His main research interests lie in software (re)engineering and software evo-lution with a special focus on software visualization and metrics. He is the creatorof CodeCrawler, a freely available language-independent software visualizationtool. His Ph.D. work won the Ernst Denert Software Engineering Award in 2003.Radu Marinescu is an Assistant Professor at the Politehnica University ofTimisoara, Romania. His research focus is on object-oriented design, reenginee-ring and quality assurance. He is the author of a suite of novel object-orientedmetrics and the main creator of iPlasma, an integrated and freely available tool-kit for Java and C++ projects. Several of his published research ideas have alreadybeen applied in the well-known “Borland Together Control Center” CASE tool.
783540 2442959
ISBN 3-540-24429-8
› springer.com
Object-Oriented Metrics inPracticeMetrics are paramount in every engineering discipline. However, due to its lackof rigor and its intrinsic complexity, software engineering is not considered aclassical engineering activity. Moreover, defining, understanding and applyingsoftware metrics often looks like an overly complex activity, recommended onlyto ‘trained professionals’. In general, if a software system is delivering theexpected functionality, only few people – if any – care about measuring the qua-lity of its internal structure. Consequently, software metrics are still regardedrather circumspectly by most software developers.
Lanza and Marinescu demystify the design metrics used to assess the size,quality and complexity of object-oriented software systems. Based on a novelapproach, backed by generally accepted semantics for metrics and by statisticalinformation from many industrial projects, they deduce a suite of metrics-basedpatterns for assessing the design of object-oriented software systems. Theyshow in detail how to identify design disharmonies in code, and how to deviseand apply remedies.
The combination of theoretically sound results and practically tested procedu-res and solution paths makes this book an ideal companion for professionalsoftware architects, developers and quality engineers. The pattern-oriented des-cription of disharmonies offers easy access to detecting shortcomings andapplying solutions to real problems.
Features and Benefits:
* comprehensive list of object-oriented disharmony patterns
* many reengineering strategies for poorly structured code
* brief introduction to software visualization
‘’This well-written book is an impor-tant piece of work that takes theseemingly forgotten art of object-oriented metrics to the next level interms of relevance and usefulness.’Richard C. Gronback,Chief Scientist, Borland SoftwareCorporation
13
1
Michele LanzaRadu Marinescu
Object-Oriented Metrics
in PracticeUsing Software Metrics to
Characterize, Evaluate, and Improve the Design of Object-Oriented Systems
Foreword by Stéphane Ducasse
Lanza · Marinescu
Ob
ject-Orien
ted
Metrics in
Practice
Michele Lanza is an Assistant Professor at the University of Lugano, Switzer-land. His main research interests lie in software (re)engineering and software evo-lution with a special focus on software visualization and metrics. He is the creatorof CodeCrawler, a freely available language-independent software visualizationtool. His Ph.D. work won the Ernst Denert Software Engineering Award in 2003.Radu Marinescu is an Assistant Professor at the Politehnica University ofTimisoara, Romania. His research focus is on object-oriented design, reenginee-ring and quality assurance. He is the author of a suite of novel object-orientedmetrics and the main creator of iPlasma, an integrated and freely available tool-kit for Java and C++ projects. Several of his published research ideas have alreadybeen applied in the well-known “Borland Together Control Center” CASE tool.
783540 2442959
ISBN 3-540-24429-8
› springer.com
Object-Oriented Metrics inPracticeMetrics are paramount in every engineering discipline. However, due to its lackof rigor and its intrinsic complexity, software engineering is not considered aclassical engineering activity. Moreover, defining, understanding and applyingsoftware metrics often looks like an overly complex activity, recommended onlyto ‘trained professionals’. In general, if a software system is delivering theexpected functionality, only few people – if any – care about measuring the qua-lity of its internal structure. Consequently, software metrics are still regardedrather circumspectly by most software developers.
Lanza and Marinescu demystify the design metrics used to assess the size,quality and complexity of object-oriented software systems. Based on a novelapproach, backed by generally accepted semantics for metrics and by statisticalinformation from many industrial projects, they deduce a suite of metrics-basedpatterns for assessing the design of object-oriented software systems. Theyshow in detail how to identify design disharmonies in code, and how to deviseand apply remedies.
The combination of theoretically sound results and practically tested procedu-res and solution paths makes this book an ideal companion for professionalsoftware architects, developers and quality engineers. The pattern-oriented des-cription of disharmonies offers easy access to detecting shortcomings andapplying solutions to real problems.
Features and Benefits:
* comprehensive list of object-oriented disharmony patterns
* many reengineering strategies for poorly structured code
* brief introduction to software visualization
‘’This well-written book is an impor-tant piece of work that takes theseemingly forgotten art of object-oriented metrics to the next level interms of relevance and usefulness.’Richard C. Gronback,Chief Scientist, Borland SoftwareCorporation
13
1
37/45 projects…
4800 projects (SourceForge) 300.000.000 lines of code
4800 projects (SourceForge) 300.000.000 lines of code inFusion
4800 projects (SourceForge) 300.000.000 lines of code inFusion
Wrapping it up…
#1 Distinguish tactical flaws from execution flaws
#2 Don’t correct tactical flaws by fixing isolated symptoms
#3 Correcting tactical flaws requires exploration tools
#3 Correcting tactical flaws requires exploration tools
powerf
ul
Flaw Summary
Flaw Summary
Visualization
Metrics
Related flaws
Source Highlighter
Dependency Breakout
#4 Improve technical debt calculators
#5 Build massive collection of curated measurement data
“ ”A single arrow is easily broken, but not ten in a bundle.
Japanese proverb
Measuring Software: From Data to Actionable Knowledge
16 May 2015
International Workshop on Software Architecture and Metrics
Radu Marinescu [email protected]
@radu_marinescu