This document discusses issues with existing software quality models and proposes a new approach using design patterns. The proposed approach focuses on flexibility, reusability, robustness, scalability, and usability. It involves identifying programs that use certain patterns, assessing the quality of pattern usage, computing metrics on the programs, and linking the metrics to quality assessments using machine learning. This allows evaluating subsets of a program's design based on patterns rather than evaluating entire programs or single classes.

1. On Issues with Software
Quality Model
Khashayar Khosravi and Yann-Gaël Guéhéneuc
9th ECOOP workshop on Quantitative Approaches
in Object-Oriented Software Engineering
Glasgow, Scotland
2005/07/25
GEODES 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 © Khosravi and Guéhéneuc 2005

2. 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
2/20

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

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

5. 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
5/20

6. 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
6/20 – Taking into account patterns

7. 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
7/20 – Assessing sub-sets of characteristics

8. 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
8/20 incorporate human evaluations

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

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

11. Our Approach (4/12)
Metric
n In a Nutshell values
ute
mp
Co
Link with machine
Find Programs Find Patterns Evaluate Sub-characteristics learning technique
Ev
alu
ate
Characteristics
vs.
11/20

12. 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
12/20

13. 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
13/20

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

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

16. 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
16/20

17. 17/20
Our Approach (10/12)
n Estimations

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

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

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