Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | xyla-thomas |
View: | 23 times |
Download: | 0 times |
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