measuring software: from data to actionable knowledge

Measuring Software: From Data to Actionable Knowledge

16 May 2015

International Workshop on Software Architecture and Metrics

Radu Marinescu [email protected]

@radu_marinescu

mailto:[email protected]?subject=

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

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)

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



12 Person-Years

1 issues / 8 LOChttp://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”?!



Picture from http://www.savvykidsofarkansas.com/event/the-boy-who-cried-wolf/

http://www.savvykidsofarkansas.com/event/the-boy-who-cried-wolf/

The most efficient 7 weeks in the history of software development…



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…


are these separate problems?


who “authorized” these thresholds?



reducing CYCLO takes only 1 min / branch ?



reducing CYCLO takes only 1 min / branch ?

reducing CYCLO for class is easier (137’) than for methods (285’)



never knew it’s so easy to change a signature!



but what if…

solving duplication does only depend on the number of blocks?



…are these 2 cases equally easy?

Image from http://imgur.com/gallery/iWKad22

http://imgur.com/gallery/iWKad22

Let’s summarize…

1 Irrelevant Warnings


2 Misleading Debt Quantification



3 Toxic/Stupid Refactoring Advices



3 Toxic/Stupid Refactoring Advices

4 Phony Thresholds

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

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

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/**



int/** * The entry's user id. */


int

}

public

public

public

publicDat

a

Class

public/**



/** * The entry's user id. */


int

}

public/**





int

}

private

private

private

private

public/**





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.


hdr.TarHeader}

TarEntry

TarHeader hdr

hdr.name

hdr.mode

hdr.userId

hdr.groupId

parseTarHeader

public

public

hdr.TarHeader.


TarHeader.


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


TarHeader.


hdr.TarHeader.


hdr.TarHeader}

TarEntry

TarHeader hdr

hdr.name

hdr.mode

hdr.userId

hdr.groupId

parseTarHeader


Move the method (TarEntry > TarHeader)1

however …

public

public inthdr.

header, offset, TarHeader.


hdr.offset, TarHeader.




hdr.offset, TarHeader

} public

int




long

offset = TarHeader.getLongOctalBytes( size, outbuf, offset, TarHeader.

}

hdr.mode = (int)TarHeader.parseOctal( header,


offset, TarHeader.MODELEN );




hdr.userId = (int)TarHeader.parseOctal( header,


offset, TarHeader.UIDLEN );

parseTarHeader

writeEntryHeader

public

public inthdr.








} public

int




long


}







hdr.userId = (int)TarHeader.parseOctal( header,


offset, TarHeader.UIDLEN );

parseTarHeader

writeEntryHeader

Duplic

ated

Code

public

public inthdr.








} public

int




long


}

hdr.mode

hdr.mode

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.








} public

int




long


}

hdr.mode

hdr.mode

offset, TarHeader.

offset, TarHeader.



hdr.userId


offset, TarHeader.

parseTarHeader

writeEntryHeader


Move the newly created method (in TarHeader)2

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

http://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

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?

Experts, right?

Image from http://www.dilbert.com

http://www.dilbert.com

5 projects?!?! < 100 classes?!?!






Lanza · Marinescu

Ob

ject-Orien

ted

Metrics in

Practice


783540 2442959

ISBN 3-540-24429-8

› springer.com









13

1






Lanza · Marinescu

Ob

ject-Orien

ted

Metrics in

Practice


783540 2442959

ISBN 3-540-24429-8

› springer.com









13

1

37/45 projects…

4800 projects (SourceForge) 300.000.000 lines of code

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

mailto:[email protected]?subject=

measuring software: from data to actionable knowledge

Software

albastru indigo

valor este o combinaie

loc http

personyears http

subsystems now6 months

software metrics

nd valorile sale

metrics radu marinescu