This document proposes a new approach to building software quality models that addresses issues with existing models. The approach focuses on design patterns, uses patterns to evaluate subsets of a program's design and architecture, and incorporates human quality estimations using machine learning. Key steps include: 1) identifying quality characteristics of patterns, 2) organizing characteristics, 3) choosing metrics, 4) assessing pattern quality, 5) computing metric values, 6) linking metrics to assessments, and 7) validating the model. The approach was tested on several programs using 23 design patterns and quality was evaluated based on flexibility, reusability, robustness, scalability, and usability.

1. Khashayar Khosravi and Yann-Gaël Guéhéneuc
© Khosravi and Guéhéneuc 2005
Ptidej Team – OO Programs Quality Evaluation and Enhancement using Patterns
Group of Open, Distributed Systems, Experimental Software Engineering
Department of Informatics and Operations Research
University of Montreal
GEODES
On Issues with Software
Quality Model
9th ECOOP workshop on Quantitative Approaches
in Object-Oriented Software Engineering
Glasgow, Scotland
2005/07/25

2. 2/20
Context
n Software industry (non-military, life-
threatening) balance price and quality
n Very high expectations of customers
n No clear consensual relation
among/between models, metrics yet

3. 3/20
Context
n A. Einstein was right: Everything is
relative J
– Rational constructivism
– Computer science = Creating reality
– Truth does not exist: Felicity of choices

4. 4/20
Issues with Quality Models
n Human estimations
n Software metrics
n Quality models

5. 5/20
Human Estimations
n People are the best to judge the quality
of programs, designs, architectures…
n Problems
– Different tastes, different values
– Time-consuming
n Solution?
– Categorize groups of people dealing with
the software product

6. 6/20
Software Metrics
n Only automatic means to evaluate the
quality systematically
n Problems
– Evaluation of source code is not enough
– With different viewpoints, finding
acceptable threshold is difficult
n Solutions?
– Combining dynamic, structural metrics
– Taking into account patterns

7. 7/20
Quality Models
n Several quality models exist at different
level of abstraction
n Problems
– Affecting weights to quality characteristics
(sub-, sub-sub-, metrics…)
– Missing concepts, decomposing quality
n Solutions?
– Coefficients
– Assessing sub-sets of characteristics

8. 8/20
Our Approach (1/12)
n Devise a software quality models
solving some of the previous problems
n Main idea: Design patterns
– Focus on few characteristics
– Use the patterns to take into account
design and architecture
– Use machine learning technique to
incorporate human evaluations

9. 9/20
Our Approach (2/12)
n Design patterns provide “good”
solutions to recurring design problems
n Focus on
– Flexibility
– Reusability
– Robustness
– Scalability
– Usability

10. 10/20
Our Approach (3/12)
n Design patterns are used to build “good”
designs or architectures
n Design patterns provide a means to
evaluate manually the quality of sets of
classes (not just single classes)
– And to learn from these evaluations

11. 11/20
Our Approach (4/12)
n In a Nutshell
Programs Patterns
Metric
values
Sub-characteristics
Characteristics
FindFind Evaluate
Compute
Evaluate
Link with machine
learning technique
vs.

12. 12/20
Our Approach (5/12)
n Steps
1. Identify the quality characteristics shared
by a set of patterns
2. Organise the quality characteristics
3. Choose internal attributes relevant to the
patterns and their characteristics
4. Identify programs using the patterns
5. Assess the quality of the used patterns
using the model from step 2

13. 13/20
Our Approach (6/12)
n Steps
6. Compute the metrics from step 3 on the
program from step 4
7. Link the metric values from step 6 with
the quality assessment from step 5
8. Validate the quality model on other used
patterns from step 5

14. 14/20
Our Approach (7/12)
n Patterns
– 23 design patterns
from the GoF
n Quality Model

15. 15/20
Our Approach (8/12)
n Programs
– JHotDraw
– JUnit
– Lexi

16. 16/20
Our Approach (9/12)
n Metrics
– ACAIC, ACMIC, AID, CBO, CLD,
cohesionAttributes, connectivity, DCAEC,
DCMEC, DIT, ICHClass, LCOM1, LCOM2,
LCOM5, NCM, NMA, NMI, NMO, NOA,
NOC, NOD, NOP, SIX, and WMC

17. 17/20
OurApproach(10/12)
nEstimations

18. 18/20
Our Approach (11/12)
n Results

19. 19/20
Our Approach (12/12)
n Previous rules apply to any micro-
architectures of a OO program
n Evaluate subsets of the program
design, architecture
– Not the complete program
– Not just classes

20. 20/20
Conclusion
n Issues with quality models
n A new approach to building quality
models
– Patterns
– Human estimations
– Design, architecture
n Software metrics?