Alexander Serebrenik, Serguei Roubtsov, and Mark van den Brand

Dn-based Design Quality Comparison of Industrial Java Applications

What makes a good software architecture?

PAGE 2

Among other things…easy to build additions and make changes

Why?

Software evolves: not flexible enough architecture causes early system’s decay when significant changes become costly

Maintenance typically accounts for 75% or more of the total software workload

Goals of good architectural design

• Make software easier to change when we want to

• minimize changes which we have to make

PAGE 3

Flexible design: • more abstract classes and • less dependencies between packages

PAGE 4

Abstractness/stability balance

• Stable packages• Do not depend upon

classes outside• Many dependents• Should be extensible via

inheritance (abstract)

• Instable packages• Depend upon many

classes outside• No dependents• Should not be extensible

via inheritance (concrete)

Stability is related to the amount of work required to make a change [Martin, 2000].

What does balance mean?

PAGE 5

A good real-life package must be instable enough in order to be easily modified 

It must be generic enough to be adaptable to evolving requirements, either without or with only minimal modifications 

Hence: contradictory criteria

How to measure Instability?

Ca – afferent coupling

measures incoming dependencies

Ce – efferent coupling

measures outgoing dependencies

Instability = Ce/(Ce+Ca)

PAGE 7

Dn – Distance from the main sequence

Abstractness = #AbstrClasses/#Classes

Instability = Ce/(Ce+Ca)

1

10

Dn = | Abstractness + Instability – 1 |

main sequence

zone of pain

zone of uselessness

[R.Martin 1994]

Maintainability of software architecture in numbers

PAGE 8

PAGE 9

Instability: What does “depend” mean?

[Martin 1994] [Martin 2000][JDepend]

Still:

Entire architecture?

Ce:

Instability = Ce/(Ce+Ca)

PAGE 10

0.0 0.2 0.4 0.6 0.8 1.0

Dn

Fre

qu

en

cy

2 Flavors of Architecture Assessment

• Averages• Industrial

practice

Benchmarking for Java OSS

DistributionsExpectation for

threshold exceeding values

0.0 0.2 0.4 0.6 0.8 1.0

Dn

Fre

qu

en

cy

PAGE 11

Benchmarks?

• 21 Java OSS• Different domains

• EJB frameworks, entertainment, web-app development tools, machine learning, code analysis, …

• Different ages (2001 - 2008) • Size: ≥ 30 original packages• Development status: focus on Stable/Mature

• Also include alpha, beta and inactive

PAGE 12

Average Dn

1.00

0.00

0.150.25Benchmarks

0.32Dresden OCL Toolkit

But… average is not all!

[-2; +2]

Exceeds + 4

PAGE 13

How are the Dn-values distributed?

Exponential distribution?

PAGE 14

Exponential distribution?

• Exponential distribution:• Support [0;1] rather than [0;):

Hence, we normalize:

• And use max-likelihood fitting to find

1)(1

0

dxxf

xexf )(

1

0

)(

)()(

dxxf

xfxg

PAGE 15

Benchmarking

0 2 4 6 8 10

0.00.1

0.20.3

0.4

c

FreqN

0.0 0.2 0.4 0.6 0.8 1.0

01

23

45

Dn

Frequ

ency

0.0 0.2 0.4 0.6 0.8 1.0

01

23

4

Dn

Frequ

encyB

1

0.0 0.2 0.4 0.6 0.8 1.0

01

23

45

Dn

Frequ

encyB

2

0.0 0.2 0.4 0.6 0.8 1.0

0.51.0

1.52.0

2.53.0

Dn

Frequ

encyG

1

0.0 0.2 0.4 0.6 0.8 1.0

01

23

45

6

Dn

Frequ

encyG

2

0.0 0.2 0.4 0.6 0.8 1.0

0.51.0

1.52.0

2.5

Dn

Frequ

encyM

1

0.0 0.2 0.4 0.6 0.8 1.0

02

46

Dn

Frequ

encyM

2

Dn

Higher •Sharper peaks•Thinner tails

•Smaller averages

increasesWhy is interesting?

PAGE 15

PAGE 16

Estimate excessively high values!

• How many packages exceed threshold z?

zz

n CBAdxxgzDP *)()(1

z

P(Dn ≥z)

-3

+3PAGE 16

PAGE 17

Dn ≥ 0.6

• Dresden OCL Toolkit: 23.7% packages

-3 +34 5 6 7

5

10

15

20

P(Dn ≥0.6)

PAGE 18

Dresden OCL Toolkit: Why?

• Started in 1998.

• BUT:• We are looking at the Eclipse version!

• Version 1.0 – June 2008

• Version 1.1 – December 2008

• Has yet to mature…

Can we compare proprietary systems using Dn?

Case study:

• System A and System B support loan and lease approval business processes

• Both systems employ three-tier enterprise architecture:

• System A uses the IBM Websphere application server

• System B uses a custom made business logic layer implemented on the Tomcat web server

• System A: 249 non-third-party packages

• System B: 284 non-third-party packages

PAGE 19

PAGE 20

Average Dn

1.00

0.00

Benchmarks

0.337 System B

Exceeds + 4

0.186 System A

What about distributions?

PAGE 21

Dn threshold value

% of packages beyond threshold

System B

System A

an average OSS

Independent assessments

• Cyclic dependencies between packages

A, B, C should be released and maintained together

PAGE 22

BA C

JDepend reports # of cyclic dependencies: System A - 1System B - 23

The dependencies between packages must not form cycles [Martin, 2000]

Layering

PAGE 23

System ASystem B

Upcoming dependencies

Chidamber and Kemerer OO metrics

PAGE 24

System A System B NASA avg NASA low NASA high

WMC 10.98 27.91 14.87 45.7 11.1

LCOM 224.25 2506.18 210.11 447.65 78.34

* The lower the better

System A (white bars) has more (%) low-WMC packages than System B (blue bars).

The same holds for LCOM.

PAGE 25

Conclusions

• Java OSS benchmarks for average Dn

• g(x) – statistical model• Expectation for threshold exceeding values• Applicable to other metrics as well!

• practical feasibility of Dn-based assessment of industrial applications