Post on 10-May-2015
description
Yann-Gaël Guéhéneuc
This work is licensed under a Creative Commons Attribution-NonCommercial-
ShareAlike 3.0 Unported License
How and Why Design Patterns Impact Quality and Future Challenges
AsianPLoP, Tokyo, Japan05/03/14
2/184
“Patterns help people to share experience-based proven solutions and design products, manage processes, projects and organizations, and communicate each other more efficiently and effectively.”
http://patterns-wg.fuka.info.waseda.ac.jp/asianplop/
3/184
“Advantages:– Using patterns improves programmer
productivity and program quality– Novices can increase their design skills
significantly by studying and applying patterns– Patterns encourage best practices, even for
experiences designers– Design patterns improve communication, both
among developers and with maintainers”—Zhang and Budgen, 2012
(With minor adaptations)
4/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
5/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
6/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
Why?
7/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
Why?
How?
8/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
9/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
10/184
“The captain asked the passengers to fasten the seat belts. They were ready to take off.”
—Kohls and Scheiter, 2008
Christian Kohls and Katharina Scheiter.The Relation between Design Patterns and Schema Theory.Proceedings of the 15th Conference on Pattern Languages of Programs, ACM Press, 2008
11/184
“This situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.”
—Kohls and Scheiter, 2008(With minor adaptations)
12/184
“Human brains operate fundamentally in terms of pattern recognition rather than of logic. They are highly constructive in settling on given schema and at the same time are constantly open to error.”
—Edelman, 2006(With minor adaptations)
13/184
14/184
15/184
16/184
17/184
18/184
19/184
Schema
Abstract representation of multiple instances of the same kinds of – Concept– Situation– Plan– Behaviour– …
20/184
“Abstract representation to recognise similar or discriminate dissimilar experiences, access common concepts, draw inferences, create goals, develop plans, use skills.”
—Kohls and Scheiter, 2008(With minor adaptations)
21/184
“Examples of schemata include academic rubrics, social schemas, stereotypes, social roles, scripts, worldviews, and archetypes. In Piaget's theory of development, children adopt a series of schemata to understand the world.”
—Wikipedia, 2014
22/184
Schema
Variables (or slots or attributes)
(Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory
Constraints among variables and their values
23/184
Schema
Variables (or slots or attributes)
(Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory
Constraints among variables and their values
24/184
Schema
Variables (or slots or attributes)
(Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory
Constraints among variables and their values
25/184
Schema
Variables (or slots or attributes)
(Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory
Constraints among variables and their values
26/184
Schema
Prototypical object
27/184
Schema
Prototypical object
28/184
Schema
Prototypical object
Object space and (mental) object generator
29/184
Schema
Prototypical object
Object space and (mental) object generator
30/184
Schema
Prototypical object
Object space and (mental) object generator
31/184
Schema
Prototypical object
Object space and (mental) object generator
32/184
Schema
Relations among schemas
33/184
Schema
Relations among schemas
– Part-of
34/184
Schema
Relations among schemas
– Part-of
35/184
Schema
Relations among schemas
– Coupling
36/184
Schema
Relations among schemas
– Coupling
37/184
Schema
Relations among schemas
– Is-a
38/184
Schema
Relations among schemas
– Is-a
39/184
Schema
Hierarchy– Contexts– Forces– Probabilities
40/184
Schema
Hierarchy– Contexts– Forces– Probabilities
41/184
Schema
Hierarchy– Contexts– Forces– Probabilities
42/184
Schema
43/184
44/184
David Rumelhart and Donald Norman.Accretion, tuning and restructuring: Three modes of learning.Semantic Factors in Cognition, Erlbaum, 1978
45/184
Learning
Comprehension: pattern matching of memorised schema that cooperates and competes
46/184
Learning
Comprehension: pattern matching of memorised schema that cooperates and competes
47/184
Learning
Comprehension: pattern matching of memorised schema that cooperates and competes
48/184
Learning
Comprehension: pattern matching of memorised schema that cooperates and competes
49/184
50/184
Learning
Accretion: specific situation or experience stored in schemas used to reconstruct original experience– Episodic memory– Specific details
51/184
Learning
Accretion: specific situation or experience stored in schemas used to reconstruct original experience– Episodic memory– Specific details
52/184
Learning
Accommodation / Tuning: schemas modifications– Variables– Ranges– Probabilities
53/184
54/184
Learning
Assimilation / Restructuring: schemas creations– Schema generation by analogies with existing
schema, is-a– Schema induction from existing schema, has-a
55/184
Learning
Assimilation / Restructuring: schemas creations– Schema generation by analogies with existing
schema, is-a– Schema induction from existing schema, has-a
56/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
57/184
“This situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.”
—Kohls and Scheiter, 2008(With minor adaptations)
58/184
“This situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.”
—Kohls and Scheiter, 2008(With minor adaptations)
59/184
“This situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.”
—Kohls and Scheiter, 2008(With minor adaptations)
“The pattern is an attempt to discover some invariant features, which distinguishes good places from bad places with respect to some particular system of forces.”
—Christopher Alexander, 1979
60/184
Schema– Variables– Ranges of values– Constraints among variables and their values
61/184
Schema– Variables– Ranges of values– Constraints among variables and their values
What class plays this role?
62/184
Schema– Variables– Ranges of values– Constraints among variables and their values
Possible classes playing this roleplus their relations, implementation…
63/184
Schema– Variables– Ranges of values– Constraints among variables and their values
Relations, interactions…
64/184
Comprehension
65/184
Comprehension
66/184
Comprehension
We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto explain theproblem solved
67/184
Comprehension
We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto 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
68/184
Comprehension
We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto 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
69/184
Comprehension
We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto 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
70/184
Comprehension
We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto 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
71/184
“The solution part of a good pattern describes both a process and a thing: the ‘thing’ is created by the ‘process’.”
—Christopher Alexander, 1979
“Furthermore, a pattern tells about a form not only what it is but also what it does.”
—Christopher Alexander, 1964
72/184
“A pattern describes a coherent yet infinite design space, not a finite set of implementations in that space.”
—Frank Buschmann, Kevlin Henney, and Douglas C. Schmidt, 2007
73/184
“A pattern describes a coherent yet infinite design space, not a finite set of implementations in that space.”
—Frank Buschmann, Kevlin Henney, and Douglas C. Schmidt, 2007
74/184
75/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
76/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
Why?
77/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
Schema Theory
78/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
How?
Schema Theory
79/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
80/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
81/184
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
82/184
Developers Studies
Studying developers’ thought processes– Yarbus’ eye-movements and vision studies– Just and Carpenter’s eye–mind hypothesis– Palmer’s vision science– …
83/184
Developers Studies
84/184
Developers Studies
Picking into developers’ thought processes
85/184
Developers Studies
Picking into developers’ thought processes
86/184
Developers Studies
Picking into developers’ thought processes
87/184
Developers Studies
Developers’ thought processes– Reading code [Maletic et al.]
– Reading design models [Cepeda and Guéhéneuc]
• Content• Form
– …
88/184
Developers Studies
Developers’ thought processes– Reading code [Maletic et al.]
– Reading design models [Cepeda and Guéhéneuc]
• Content• Form
– …
Gerardo Cepeda Porras and Yann-Gaël Guéhéneuc. An Empirical Study on the Efficiency of Different Design Pattern Representations in UML Class Diagrams.Journal of Empirical Software Engineering, 15(5), Springer, 2010
89/184
Developers Studies
Developers’ use of design pattern notations during program understandability– Strongly visual [Schauer and Keller]
– Strongly textual [Dong et al.]
– Mixed [Vlissides et al.]
90/184
Developers Studies
Independent variables– Design pattern notations– Tasks: Participation, Composition, Role
Dependent variables– Average fixation duration– Ratio of fixations– Ration of fixation times
91/184
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
92/184
Developers Studies
Importance– Understand– Do better
93/184
Developers Studies
Importance– Understand– Do better
94/184
Developers Studies
Importance– Understand– Do better
Limits– Confounding factors– Actionable results?
95/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
96/184
Social Studies
Developers’ characteristics– Knowledge [Ng et al.]
– Gender [Sharafi et al.]
– Status [Soh et al.]
– Expertise [Soh et al.]
– Processes [Lavallée and Robillard]
– …
97/184
Social Studies
Developers’ characteristics– Knowledge [Ng et al.]
– Gender [Sharafi et al.]
– Status [Soh et al.]
– Expertise [Soh et al.]
– Processes [Lavallée and Robillard]
– …
98/184
Social Studies
Independent variables– Tasks– Roles
Dependent variables– Use of patterns
– Fault proneness
T. H. Ng, S. C. Cheung, W. K. Chan, Yuen-Tak Yu.Do Maintainers Utilize Deployed Design Patterns Effectively?Proceedings of the 29th ICSE, ACM Press, 2007
99/184
Social Studies
Subjects– 215 under-graduate students– Java programming course – Hong Kong University of Science and
Technology
100/184
Social Studies
Conclusion– Results “support the deployment of design
patterns as they were utilized by most of the subjects to complete the anticipated changes.”
– “Utilizing deployed design patterns does not necessarily mean that better codes are delivered.”
101/184
Social Studies
Importance– Difference among tasks– Visualisation – Documentation
102/184
Importance– Difference among tasks– Visualisation – Documentation
103/184
Importance– Difference among tasks– Visualisation – Documentation
Limits– Confounding factors– Actionable results?
104/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
105/184
Code Studies
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
106/184
Design Patterns
Important assumptions– “Patterns can be codified in such a way that they
can be shared between different designers”
– “Reuse will lead to “better” designs. There is an obvious question here of what constitutes “better”, but a key measure is maintainability”
107/184
Design Patterns
Problem– Problem recurring in object-oriented design
Solution– Repeatable– Effective
108/184
Design Patterns
Positive impact?
109/184
Design Patterns
Positive impact?– Fault proneness
110/184
Design Patterns
Positive impact?– Fault proneness
– Change proneness
111/184
Design Patterns
Positive impact?– Fault proneness
– Change proneness
– Comprehension
112/184
Design Patterns
Positive impact?– Fault proneness
– Change proneness
– Comprehension
T. H. Ng, S. C. Cheung, W. K. Chan, Yuen-Tak Yu.Do Maintainers Utilize Deployed Design Patterns Effectively?Proceedings of the 29th ICSE, ACM Press, 2007
113/184
Design Patterns
Positive impact?– Fault proneness
– Change proneness
Comprehension
T. H. Ng, S. C. Cheung, W. K. Chan, Yuen-Tak Yu.Do Maintainers Utilize Deployed Design Patterns Effectively?Proceedings of the 29th ICSE, ACM Press, 2007
James M. Bieman, Greg Straw, Huxia Wang, P. Willard Munger, Roger T. Alexander.Design Patterns and Change Proneness: An Examination of Five Evolving Systems.Proceedings of the 9th METRICS, IEEE CS Press, 2003
114/184
Design Patterns
Positive impact?– Fault proneness
– Change proneness
Comprehension
T. H. Ng, S. C. Cheung, W. K. Chan, Yuen-Tak Yu.Do Maintainers Utilize Deployed Design Patterns Effectively?Proceedings of the 29th ICSE, ACM Press, 2007
James M. Bieman, Greg Straw, Huxia Wang, P. Willard Munger, Roger T. Alexander.Design Patterns and Change Proneness: An Examination of Five Evolving Systems.Proceedings of the 9th METRICS, IEEE CS Press, 2003
Sébastien Jeanmart, Yann-Gaël Guéhéneuc,Houari A. Sahraoui, Naji Habra.Impact of the Visitor Pattern on Program Comprehension and Maintenance.Proceedings of the 3rd ESEM, IEEE CS Press, 2009
115/184
Code Studies
Design patterns– Codify experts’ experience– Help train novice developers– Help developers’ communicate– Lead to improved quality
116/184
Design Antipatterns
Important assumptions– Poor design choices that are conjectured to
make object-oriented systems harder to maintain
– Yet, maybe the best and possibly only way to implement some requirements and–or some functionalities
117/184
Design Antipatterns
Problem– Problem recurring in object-oriented design
Poor solution– Initially may look like a good idea
Alternative solution– Repeatable (design pattern)– Effective
118/184
Design Antipatterns
Negative impact
119/184
Design Antipatterns
Negative impact– Fault proneness– Change proneness
Foutse Khomh, Massimiliano Di Penta, Yann-Gaël Guéhéneuc, Giuliano Antoniol.An Exploratory Study of the Impact of Antipatterns on Class Change- and Fault-proneness.Empirical Software Engineering, 17(3), Springer, 2012
120/184
Design Antipatterns
Negative impact– Fault proneness– Change proneness
Comprehension
Foutse Khomh, Massimiliano Di Penta, Yann-Gaël Guéhéneuc, Giuliano Antoniol.An Exploratory Study of the Impact of Antipatterns on Class Change- and Fault-proneness.Empirical Software Engineering, 17(3), Springer, 2012
Marwen Abbes, Foutse Khomh, Yann-Gaël Guéhéneuc, Giuliano Antoniol.An Empirical Study of the Impact of Two Antipatterns on Program Comprehension.Proceedings of the 15th CSMR, IEEE CS Press, 2011
121/184
Code Studies
Design antipatterns– Codify experts’ “bad” experience– Help train novice developers– Help developers’ communicate– Lead to decreased quality
122/184
Code Studies
Limits– So many patterns– So many
• Programming languages• Development contexts• Application domains• Expertises
123/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
Schema Theory
124/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
How?
Schema Theory
125/184
“Important assumptions– That software patterns can be codified in such a
way that they can be shared between and reused by 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)
Schema Theory
Pattern Studies
126/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
127/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
128/184
“Quality model are models with the objective to describe, assess, and–or predict quality”
—Deissenboeck et al., WOSQ, 2009(With minor adaptations)
Florian Deissenboeck, Elmar Juergens, Klaus Lochmann, and Stefan Wagner.Software Quality Models: Purposes, Usage Scenarios and Requirements.International Workshop on Software Quality, 24th International Symposium on Computer and Information Sciences, IEEE CS Press, 2009
129/184
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
130/184
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
131/184
Quality Models
Basis for quality models – Software measures (aka metrics)
• LOC• Chidamber and Kemerer• Briand et al.• …
– Relationships among characteristics and metrics• Theoretical• Practical
132/184
Who needs models?
133/184
134/184
•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/archaeology •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
135/184
136/184
137/184
Measures without models!http://hardsci.wordpress.com/2013/09/17/the-hotness-iq-tradeoff-in-academia/
138/184
Modeling formodeling's sake?
139/184
Aristotle384 BC–Mar 7, 322 BC
140/184
Aristotle384 BC–Mar 7, 322 BC
Galileo GalileiFeb 15, 1564–Jan 8, 1642
141/184
Aristotle384 BC–Mar 7, 322 BC
Galileo GalileiFeb 15, 1564–Jan 8, 1642
Isaac NewtonDec 25, 1642–Mar 20, 1727
142/184
Aristotle384 BC–Mar 7, 322 BC
Galileo GalileiFeb 15, 1564–Jan 8, 1642
Isaac NewtonDec 25, 1642–Mar 20, 1727
Max TegmarkMay 5, 1967–
143/184
Quality Models
Different input metrics, output characteristics– Menzies et al.’s models
• Code metrics• Defectiveness
– Zimmermann et al.’s models• Code and historical metrics• Fault-proneness
– Bansiya and Davis’ QMOOD• Design metrics• Maintainability-related characteristics
144/184
Quality Models
Different input metrics, output characteristics– Menzies et al.’s models
• Code metrics• Defectiveness
– Zimmermann et al.’s models• Code and historical metrics• Fault-proneness
– Bansiya and Davis’ QMOOD• Design metrics• Maintainability-related characteristics
145/184
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
Jagdish Bansiya and Carl G. Davis.A Hierarchical Model for Object-oriented Design Quality Assessment.Transactions on Software Engineering, 28(1), IEEE CS Press, 2002
146/184
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(Source code)
147/184
Quality Models
Bansiya and Davis’ QMOOD
148/184
Quality Models
Conclusions– Sound basis to measure different quality
characteristics
Limits– Relation between metrics and quality
characteristics, such as maintainability– Relation between metrics and design choices,
good practices…
149/184
Quality Models
Limits
150/184
Quality Models
Limits– Relation between metrics and quality
characteristics, such as maintainability
151/184
Quality Models
Limits– Relation between metrics and quality
characteristics, such as maintainability– Relation between metrics and design
choices, good practices…
152/184
“Having an ideal concept of a thing lets one judge the beauty of it.”
—Kohls and Scheiter, 2008
“For Alexander, patterns are not an end in themselves, they are only a means to an end; his objective is to generate the quality without a name”
—Kelly, 2012
153/184
Quality Models
Feedback– Measures– Occurrences– Factors
to build “better” quality models
154/184
Quality Models
Feedback– Measures– Occurrences– Factors
to build “better” quality models
155/184
Agenda
Why?– Schema, Learning, and Patterns
How?– Developers, Social, and Code Studies
Challenges– Quality Models– Multi-language Systems
156/184
What’s with today’s systems?
157/184
158/184
159/184
160/184
161/184
162/184
163/184
164/184
165/184
166/184
167/184
Multi-language Systems
Today’s systems are multi-languages– Facebook– Twitter– …
– Even your “regular” software system is now multi-language, typically a Web application
168/184
Multi-language Systems
New problems– Different computational models– Complex interfaces (API)– Wrong assumptions– Wrong conversions– …
169/184
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++
Gang Tan and Jason Croft.An Empirical Security Study of the Native Code in the JDK.Proceedings of the 17th Security Symposium, USENIX Association, 2008
170/184
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– …
171/184
Multi-language Systems
Different computational models
172/184
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;...
}
173/184
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 setjmp(…) or related calls!
174/184
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!
No setjmp(…) or related calls!
175/184
What challenges?
176/184
Unbalanced focus on “mono”-language systems vs. multi-language systems
177/184
Multi-language Systems
Maintainability– Quality models
• Metrics?• Relations?
– Patterns• “Border-line” practices?
– Social and developers studies• Independent variables?
178/184
Conclusion
179/184
180/184
181/184
182/184
183/184
Future directions
184/184
Multi-language system quality models
– Definition and modelling– Computation– Characterisation– Impact