Upload
ptidej-team
View
207
Download
1
Embed Size (px)
DESCRIPTION
Introduction to software quality. Quality models and studies for quality: patterns, social, and developers studies. Usefulness of quality models and challenges of multi-language systems.
Citation preview
Yann-Gaël Guéhéneuc
This work is licensed under a Creative Commons Attribution-NonCommercial-
ShareAlike 3.0 Unported License
Quality and Multi-language Systems
KAIST13/10/14
2/126
3/126
Typical software developers?
4/126
5/126
Software costs?
6/126
7/126
8/126
Cost of bugshttp://www.di.unito.it/~damiani/ariane5rep.html
9/126
10/126
12/126
Agenda
Quality– Quality Models– Good Practices– Social Studies– Developers Studies
Impact of Quality Models Challenges with Multi-language Systems
13/126
qual·i·ty noun \ˈkwä-lə-tē\: how good or bad something is: a characteristic or feature that someone
or something has : something that can be noticed as a part of a person or thing
: a high level of value or excellence—Merriam-Webster, 2013
14/126
Quality
Division of software quality according to ISO/IEC 9126:2001 and 25000:2005– Process quality– Product quality– Quality in use
15/126
Quality
Division of software quality according to ISO/IEC 9126:2001 and 25000:2005 – Process quality– Product quality– Quality in use
16/126
Quality
Dimensions of product quality– Functional vs. non-functional
• At runtime vs. structural– Internal vs. external
• Maintainability vs. usability– Metric-based vs. practice-based
• Objective vs. subjective
17/126
Quality
Dimensions of product quality– Functional vs. non-functional
• At runtime vs. structural– Internal vs. external
• Maintainability vs. usability– Metric-based vs. practice-based
• Objective vs. subjective
18/126
Quality
Definitions of internal quality characteristics– Maintainability– Flexibility– Portability– Re-usability– Readability– Testability– Understandability
19/126
Quality
Definitions of internal quality characteristics– Maintainability– Flexibility– Portability– Re-usability– Readability– Testability– Understandability
20/126
Maintainability is the ease with which a software system can be modified
—IEEE Standard Glossary of Software Engineering Terminology, 2013
21/126
Maintainability
Quality Models Models
Good Practices Definition
Metrics
Detection Occurrences
Social Studies Characteristics
Developers Studies Behaviour
Factors
Measures
22/126
Maintainability
Quality Models Models
Good Practices Definition
Metrics
Detection Occurrences
Social Studies Characteristics
Developers Studies Behaviour
Factors
Measures
23/126
Quality model are models with the objective to describe, assess, and–or predict quality
—Deissenboeck et al., WOSQ, 2009(With minor adaptations)
24/126
Quality Models
Division of quality models according to Deissenboeck et al.– Describe quality characteristics and their
relationships– Assess the quality characteristics of some
software systems– Predict the future quality of some software
systems
25/126
Quality Models
Division of quality models according to Deissenboeck et al.– Describe quality characteristics and their
relationships– Assess the quality characteristics of some
software systems– Predict the future quality of some software
systems
26/126
Quality Models
Basis for quality models – Software measures (aka metrics)– Relationships among characteristics and metrics
• Theoretical• Practical
27/126
Quality Models
Metrics have been well researched– Chidamber and Kemerer– Hitz and Montazeri– Lorenz and Kidd– McCabe– …
(Do not miss Briand et al.’s surveys on cohesion and coupling metrics)
28/126
29/126
Who needs models?
30/126
31/126
•130.0 Physics •129.0 Mathematics •128.5 Computer Science •128.0 Economics •127.5 Chemical engineering •127.0 Material science •126.0 Electrical engineering •125.5 Mechanical engineering •125.0 Philosophy •124.0 Chemistry •123.0 Earth sciences •122.0 Industrial engineering •122.0 Civil engineering •121.5 Biology •120.1 English/literature •120.0 Religion/theology •119.8 Political science •119.7 History •118.0 Art history •117.7 Anthropology/archeology•116.5 Architecture •116.0 Business •115.0 Sociology •114.0 Psychology •114.0 Medicine •112.0 Communication •109.0 Education •106.0 Public administration
32/126
33/126
34/126
Measures without modelshttp://hardsci.wordpress.com/2013/09/17/the-hotness-iq-tradeoff-in-academia/
35/126
Quality Models
Different input metrics, different output characteristics– Bansiya and Davis’ QMOOD
• Design metrics• Maintainability-related characteristics
– Zimmermann et al.’s models• Code and historical metrics• Fault-proneness
– …
36/126
Quality Models
Different input metrics, different output characteristics– Bansiya and Davis’ QMOOD
• Design metrics• Maintainability-related characteristics
– Zimmermann et al.’s models• Code and historical metrics• Fault-proneness
– …
37/126
Quality Models
Bansiya and Davis’ QMOOD– Characteristics of maintainability
• Effectiveness, extensibility, flexibility, functionality, reusability, and understandability
– Hierarchical model• Structural and behavioural design properties of
classes, objects, and their relationships
38/126
Quality Models
Bansiya and Davis’ QMOOD– Object-oriented design metrics
• Encapsulation, modularity, coupling, and cohesion…• 11 metrics in total
– Validation using empirical and expert opinion on several large commercial systems
• 9 C++ libraries
39/126
Quality Models
Bansiya and Davis’ QMOOD
40/126
Quality Models
Conclusions– Sound basis to measure different quality
characteristics
Limits– Relation between metrics and quality
characteristics, such as maintainability– Relation between metrics and what they are
expected to measure
41/126
Maintainability
Quality Models Models
Good Practices Definition
Metrics
Detection Occurrences
Social Studies Characteristics
Developers Studies Behaviour
Factors
Measures
42/126
43/126
Practice, practiceand practice more
44/126
45/126
Good Practices
Maintainers can follow good practices– SOLID– Design patterns– Design antipatterns– …
46/126
Good Practices
Maintainers can follow good practices– SOLID– Design patterns– Design antipatterns– …
47/126
Each pattern describes a problem which occurs over and over in our environment, and then describes the core of the solution to that problem, in such way that you can use this solution a million times over, without ever doing it the same way twice.
—Christopher Alexander, 1977(With minor adaptations)
48/126
Good Practices
Design patterns– A general reusable solution to a commonly
occurring problem within a given context in software design
Design antipatterns– A design pattern that may be commonly used
but is ineffective/counterproductive in practice
49/126
Good Practices
50/126
Important assumptions– That patterns can be codified in such a way that
they can be shared between different designers– That reuse will lead to “better” designs. There is
an obvious question here of what constitutes “better”, but a key measure is maintainability
—Zhang and Budgen, 2012 (With minor adaptations)
51/126
Good Practices
Pattern solution = Motif which connotes anelegant architecture
52/126
Good Practices
Pattern solution = Motif which connotes anelegant architecture
53/126
Good Practices
Pattern solution = Motif which connotes anelegant architecture
54/126
Good Practices
We can identifyin the architectureof a systemsmicro-architectures similar todesign motifsto explain theproblem solved
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
To compose objectsin a tree-like structureto describe whole–parthierarchies
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
55/126
Good Practices
We can identifyin the architectureof a systemsmicro-architectures similar todesign motifsto explain theproblem solved
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
To compose objectsin a tree-like structureto describe whole–parthierarchies
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
56/126
Good Practices
We can identifyin the architectureof a systemsmicro-architectures similar todesign motifsto explain theproblem solved
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
To compose objectsin a tree-like structureto describe whole–parthierarchies
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
57/126
Good Practices
We can identifyin the architectureof a systemsmicro-architectures similar todesign motifsto explain theproblem solved
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
To compose objectsin a tree-like structureto describe whole–parthierarchies
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
58/126
Good Practices
Conclusions– Codify experts’ experience– Help train novice developers– Help developers’ communicate– Lead to improved quality
59/126
Maintainability
Quality Models Models
Good Practices Definition
Metrics
Detection Occurrences
Social Studies Characteristics
Developers Studies Behaviour
Factors
Measures
60/126
Social Studies
Developers’ characteristics– Gender– Status – Expertise– Training– Processes– …
61/126
62/126
Agile programming,anyone?
63/126
64/126
Social Studies
Need for social studies, typically in the form of experiments– Independent variable (few)– Dependent variables (many)– Statistical analyses (few)
– Threats to validity (many)
65/126
Social Studies
For example, impact on identifiers on program understandability– Identifier styles [Sharif, Binkley]
– Identifier quality [Lawrie]
– Developers’ gender and identifiers [Sharafi]
– …
66/126
Social Studies
For example, impact on identifiers on program understandability– Identifier styles [Sharif, Binkley]
– Identifier quality [Lawrie]
– Developers’ gender and identifiers [Sharafi]
– …
67/126
Social Studies
Independent variables– Gender: male vs. female– Identifier: camel case vs. underscore
Dependent variables– Accuracy
– Time
– Effort
68/126
Social Studies
Subjects
Conclusions
Subjects’ Demography(24 Subjects)
Academic background GenderPh.D. M.Sc. B.Sc. Male Female
11 10 3 15 9
Accuracy Time Effort
69/126
Maintainability
Quality Models Models
Good Practices Definition
Metrics
Detection Occurrences
Social Studies Characteristics
Developers Studies Behaviour
Factors
Measures
70/126
Developers Studies
Developers’ thought processes– Cognitive theories
• Brooks’• Von Mayrhauser’s• Pennington’s• Soloway’s
– Mental models• Gentner and Stevens’ mental models
– Memory theories• Kelly’s categories• Minsky’s frames• Piaget’s schema• Schank’s scripts
71/126
Developers Studies
Studying developers’thought processes– Yarbus’ eye-movements
and vision studies– Just and Carpenter’s
eye–mind hypothesis– Palmer’s vision science– …
72/126
Developers Studies
Picking into developers’ thought processes
73/126
Developers Studies
Picking into developers’ thought processes
74/126
Developers Studies
Picking into developers’ thought processes
75/126
Developers Studies
Developers’ thought processes– Reading code– Reading design models
• Content• Form
– …
76/126
Developers Studies
Developers’ thought processes– Reading code– Reading design models
• Content• Form
– …
77/126
Developers Studies
Developers’ use of design pattern notations during program understandability– Strongly visual [Schauer and Keler]
– Strongly textual [Dong et al.]
– Mixed [Vlissides]
78/126
Developers Studies
Independent variables– Design pattern notations– Tasks: Participation, Composition, Role
Dependent variables– Average fixation duration– Ratio of fixations– Ration of fixation times
79/126
Developers Studies
Subjects– 24 Ph.D. and M.Sc. students
Conclusions– Stereotype-enhanced UML diagram [Dong et al.]
more efficient for Composition and Role– UML collaboration notation and the pattern-
enhanced class diagrams more efficient for Participation
80/126
Feedback Loop
Use– Measures– Occurrences– Factors
to build “better” quality models
81/126
82/126
Modeling formodeling's sake?
83/126
Aristote384 BC–Mar 7, 322 BC
84/126
Aristote384 BC–Mar 7, 322 BC
Galileo GalileiFeb 15, 1564–Jan 8, 1642
85/126
Aristote384 BC–Mar 7, 322 BC
Galileo GalileiFeb 15, 1564–Jan 8, 1642
Isaac NewtonDec 25, 1642–Mar 20, 1727
86/126
Aristote384 BC–Mar 7, 322 BC
Galileo GalileiFeb 15, 1564–Jan 8, 1642
Isaac NewtonDec 25, 1642–Mar 20, 1727
Max TegmarkMay 5, 1967–
87/126
Aristote384 BC–Mar 7, 322 BC
Galileo GalileiFeb 15, 1564–Jan 8, 1642
Usefulness?
Isaac NewtonDec 25, 1642–Mar 20, 1727
Max TegmarkMay 5, 1967–
88/126
Impact of Quality Models
DSIV– SNCF IT department– 1,000+ employees – 200+ millions Euros– Mainframes to assembly to J2EE
– 2003• Quality team
89/126
Impact of Quality Models
MQL– Dedicated measurement process
90/126
Impact of Quality Models
MQL– Web-based reports
91/126
Impact of Quality Models
Independent variables– Use of MQL or not– LOC; team size, maturity, and nature
Dependent variables– Maintainability, evolvability, reusability,
robustness, testability, and architecture quality– Corrective maintenance effort (in time)– Proportions of complex/unstructured code and of
commented methods/functions
92/126
Impact of Quality Models
Subjects– 44 systems
• 22 under MQL (QA=1)• 22 under ad-hoc processes (QA=0)
93/126
Impact of Quality Models
94/126
Impact of Quality Models
95/126
Impact of Quality Models
96/126
Impact of Quality Models
97/126
Impact of Quality Models
Conclusions– Impact on all dependent variables – Statistical practical significance
Limits– Applicability to today’s software systems
98/126
99/126
What’s with today’s systems?
100/126
101/126
102/126
103/126
104/126
105/126
106/126
107/126
108/126
109/126
110/126
Challenges with Multi-language Systems
Today’s systems are multi-languages– Facebook– Twitter– …
– Even your “regular” software system is now multi-language, typically a Web application
111/126
Challenges with Multi-language Systems
New challenges– Different computational models– Complex interfaces (API)– Wrong assumptions– Wrong conversions– …
112/126
Challenges with Multi-language Systems
For example, control- and data-flows between Java and “native” C/C++ code
native methods in Java are used by Java classes but (typically) implemented in C/C++
113/126
Challenges with Multi-language Systems
Control-flow interactions– Java code calls native code– Native code calls Java methods– Native code can “throw” and must catch
exceptions Data-flow interactions
– Java code passes objects (pointers)– Native code creates objects– …
114/126
Challenges with Multi-language Systems
Different computational models
115/126
Challenges with Multi-language Systems
Different computational modelsstatic void *xmalloc(JNIEnv *env, size_t size) {
void *p = malloc(size);if (p == NULL)
JNU_ThrowOutOfMemoryError(env, NULL);return p;
}
#define NEW(type, n) ((type *) xmalloc(env, (n) * sizeof(type)))
static const char *const *splitPath(JNIEnv *env, const char *path) {...pathv = NEW(char *, count+1);pathv[count] = NULL;...
}
116/126
Challenges with Multi-language Systems
Different computational modelsstatic void *xmalloc(JNIEnv *env, size_t size) {
void *p = malloc(size);if (p == NULL)
JNU_ThrowOutOfMemoryError(env, NULL);return p;
}
#define NEW(type, n) ((type *) xmalloc(env, (n) * sizeof(type)))
static const char *const *splitPath(JNIEnv *env, const char *path) {...pathv = NEW(char *, count+1);pathv[count] = NULL;...
}
No diversion of control flow!
117/126
118/126
Conclusion
119/126
120/126
121/126
122/126
123/126
Future directions
124/126
125/126
126/126
Multi-language system quality characteristics
– Definition and modelling– Computation– Characterisation– Impact
127/126
128/126
Good Practices
Martin and Feather’s SOLID– Single responsibility– Open/closed– Liskov substitution– Interface segregation– Dependency inversion
129/126
Good Practices
What motifs and what model for these motifs?
What model for the program architecture?
How to perform the identification?
130/126
Good Practices
What motifs and what model for these motifs?
What model for the program architecture?
How to perform the identification?
131/126
Good Practices
What motifs and what model for these motifs?
What model for the program architecture?
How to perform the identification?
Design motifs and a motif meta-model
132/126
Good Practices
What motifs and what model for these motifs?
What model for the program architecture?
How to perform the identification?
Design motifs and a motif meta-model
133/126
Good Practices
What motifs and what model for these motifs?
What model for the program architecture?
How to perform the identification?
Design Meta-model
Design motifs and a motif meta-model
134/126
Good Practices
What motifs and what model for these motifs?
What model for the program architecture?
How to perform the identification?
Design Meta-model
Design motifs and a motif meta-model
135/126
Good Practices
What motifs and what model for these motifs?
What model for the program architecture?
How to perform the identification?
Design Meta-model
Design motifs and a motif meta-model
136/126
Good Practices
What motifs and what model for these motifs?
What model for the program architecture?
How to perform the identification?
Design Meta-model
Design motifs and a motif meta-model
137/126
Good Practices
Multi-layer framework for design motif identification
Information retrieval– Search space– Query– Results
138/126
Good Practices
Multi-layer framework for design motif identification
Code
Model
Model + Associations, aggregations
Model + Associations, aggregations,
and composition
139/126
Good Practices
Constraint satisfaction problem solved with explanation-based constraint programming (e-CP) to obtain – No a priori descriptions of variations– Justification of the identified micro-architectures– Strong interaction with the developers
140/126
Good Practices – Example
Design motif ( )
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
141/126
Good Practices – Example
Example of JHotDraw– Erich Gamma and Thomas Eggenschwiler– 2D drawing– Design patterns
142/126
Goo
d Pr
actic
es –
Exam
ple Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
143/126
Goo
d Pr
actic
es –
Exam
ple Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
144/126
Good Practices – Example
Micro-architecture ( )
Maintainability Understandability
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
145/126
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
e-CP
V = {component, leaf, composite}C = {leaf < component, composite < component, composite component}D = {DrawingEditor, DrawingView…}
146/126
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
e-CP
V = {component, leaf, composite}C = {leaf < component, composite < component, composite component}D = {DrawingEditor, DrawingView…}
147/126
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
e-CP
V = {component, leaf, composite}C = {leaf < component, composite < component, composite component}D = {DrawingEditor, DrawingView…}
148/126
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
e-CP
V = {component, leaf, composite}C = {leaf < component, composite < component, composite component}D = {DrawingEditor, DrawingView…}
149/126
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
e-CP
V = {component, leaf, composite}C = {leaf < component, composite < component, composite component}D = {DrawingEditor, DrawingView…}
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
150/126
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
e-CP
V = {component, leaf, composite}C = {leaf < component, composite < component, composite component}D = {DrawingEditor, DrawingView…}
<< <<
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
151/126
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
e-CP
V = {component, leaf, composite}C = {leaf < component, composite < component, composite component}D = {DrawingEditor, DrawingView…}
<< <<
Component
operation()
Leaf
operation()
Composite
add(Component)remove(Component)getComponent(int)operation()
ramification
For each componentscomponent.operation()
1..nClient
152/126
Good Practices
Search space can be very large and the efficiency in time of the search very low
Use metrics and topology to reduce the search space