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 radumarinescu@me.com

@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

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

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…

(12 subsystems)

(17 methods)

(3 subsystems)

NOW6 months ago

(1 class)

(10 methods)

(32 classes)

(16 classes)

(28 classes)

(120 methods)

(12 subsystems)

(17 methods)

(3 subsystems)

NOW6 months ago

(1 class)

(10 methods)

(32 classes)

(16 classes)

(28 classes)

(120 methods)

(12 subsystems)

(17 methods)

(3 subsystems)

NOW6 months ago

(1 class)

(10 methods)

(32 classes)

(16 classes)

(28 classes)

(120 methods)

(12 subsystems)

(17 methods)

(3 subsystems)

NOW6 months ago

(1 class)

(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

misuse

http://nemo.sonarqube.org/

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/

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

Let’s summarize…

1 Irrelevant Warnings

2 Misleading Debt Quantification

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

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

Testing DocumentingCoding Understanding

M. Ben-Menachem and G. S. Marliss. Software quality: Producing practical, consistent software. International Thomson Computer Press, 1997

Bugserror-prone

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

public

public/**

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

public

publicDat

public/**

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

public/**

private

public/**

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

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

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

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

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

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

offset, TarHeader.MODELEN );

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

offset, TarHeader.UIDLEN );

parseTarHeader

writeEntryHeader

Duplic

public

public inthdr.

} public

hdr.mode

offset, TarHeader.

hdr.userId

hdr.userIdoffset, TarHeader.

offset, TarHeader.

parseTarHeader

writeEntryHeader

Extract method (by factoring out the duplicated code)1

public

public inthdr.

} public

hdr.mode

offset, TarHeader.

hdr.userId

offset, TarHeader.

parseTarHeader

writeEntryHeader

Move the newly created method (in TarHeader)2

public

public inthdr.

} public

hdr.mode

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

Encapsulate public data (in TarEntry)2

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

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

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

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

Lanza · Marinescu

ject-Orien

Metrics in

Practice

783540 2442959

ISBN 3-540-24429-8

› springer.com

Lanza · Marinescu

ject-Orien

Metrics in

Practice

783540 2442959

ISBN 3-540-24429-8

› springer.com

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

powerf

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 radumarinescu@me.com

@radu_marinescu

measuring software: from data to actionable knowledge

albastru indigo

valor este o combinaie

loc http

personyears http

subsystems now6 months

software metrics

nd valorile sale

metrics radu marinescu

Software

knowledge management for actionable sales and marketing...

measuring the roi of knowledge management 2nd edition ·...

measuring second language vocabulary knowledge...

measuring the impact of knowledge loss.pdf

measuring knowledge

measuring perspective of fraction knowledge: …

an overview of domain-driven data mining: toward...

chapter 2 data mining processes and knowledge discovery...

measuring and managing knowledge

big data, actionable information, scientific knowledge and...

actionable analytics - measuring social media success ·...

serve actionable knowledge empower agile architects

on measuring individual knowledge in organizations measuring...

actionable security awareness: convert the …...actionable...

measuring the true profitability of products,...

measuring pedagogical content knowledge of argumentation...

governing frameworks for sharing actionable knowledge

measuring entrepreneurial knowledge and entrepreneurial

where actionable knowledge exchange is created between...

measuring the knowledge base