The document discusses schemas, design patterns, and how patterns relate to schemas and learning. It notes that schemas are mental representations that allow people to recognize patterns. Design patterns aim to capture best practices and reusable solutions to common problems. When patterns are reused, it activates existing schemas and can lead to better design through experiences being shared. The document explores how pattern reuse relates to theories of schema and learning, and how patterns can be codified and shared between designers based on these theories.
How Design Patterns Impact Quality and Future Challenges
1. How and Why Design
Patterns Impact Quality
and Future Challenges
Yann-GaĂŤl GuĂŠhĂŠneuc
AsianPLoP, Tokyo, Japan
05/03/14
This work is licensed under a Creative
Commons Attribution-NonCommercialShareAlike 3.0 Unported License
2. âPatterns help people to share experiencebased 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/
2/184
3. â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)
3/184
4. â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)
4/184
5. â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
6. âImportant assumptions
â That software patterns can be codified in such a
way that they can be shared between and
reused by different designers
Why?
â 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
7. âImportant assumptions
â That software patterns can be codified in such a
way that they can be shared between and
reused by different designers
Why?
â That reuse will lead to âbetterâ designs. There is
an obvious question here of what constitutes
âbetterâ, but a key measure is maintainabilityâ
How?
âZhang and Budgen, 2012
(With minor adaptations)
7/184
8. Agenda
ďŽ Why?
â Schema, Learning, and Patterns
ďŽ How?
â Developers, Social, and Code Studies
ďŽ Challenges
â Quality Models
â Multi-language Systems
8/184
9. Agenda
ďŽ Why?
â Schema, Learning, and Patterns
ďŽ How?
â Developers, Social, and Code Studies
ďŽ Challenges
â Quality Models
â Multi-language Systems
9/184
10. â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
10/184
11. â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)
11/184
12. â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)
12/184
20. â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)
20/184
21. â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
21/184
22. Schema
ďŽ Variables
(or slots or attributes)
ďŽ (Constrained)
Ranges of values
â Peopleâs experience
â Constants
â Optional or mandatory
ďŽ Constraints
among variables
and their values
22/184
23. 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
24. 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
25. 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
44. David Rumelhart and Donald Norman.
Accretion, tuning and restructuring: Three modes of learning.
Semantic Factors in Cognition, Erlbaum, 1978
44/184
56. Agenda
ďŽ Why?
â Schema, Learning, and Patterns
ďŽ How?
â Developers, Social, and Code Studies
ďŽ Challenges
â Quality Models
â Multi-language Systems
56/184
57. â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)
57/184
58. â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
59. â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
59/184
61. What class plays this role?
ďŽ Schema
â Variables
â Ranges of values
â Constraints among variables and their values
61/184
62. Possible classes playing this role
plus their relations, implementationâŚ
ďŽ Schema
â Variables
â Ranges of values
â Constraints among variables and their values
62/184
66. Comprehension
We can identify
in the architecture
of a systems
micro-architectures
similar to
design patterns
to explain the
problem solved
66/184
67. Frame
DrawingEditor
Drawing
Handle
We can identify
in the architecture
of a systems
micro-architectures
similar to
design patterns
to explain the
problem solved
DrawingView
Tool
Comprehension
Panel
Figure
AbstractFigure
AttributeFigure
DecoratorFigure
PolyLineFigure
CompositeFigure
Figure
AttributeFigure
Component
Client
DecoratorFigure
PolyLineFigure
CompositeFigure
1..n
operation()
ramification
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
For each components
component.operation()
To compose objects
in a tree-like structure
to describe wholeâpart
hierarchies
67/184
68. Frame
DrawingEditor
Drawing
Handle
We can identify
in the architecture
of a systems
micro-architectures
similar to
design patterns
to explain the
problem solved
DrawingView
Tool
Comprehension
Panel
Figure
AbstractFigure
AttributeFigure
DecoratorFigure
PolyLineFigure
CompositeFigure
Figure
AttributeFigure
Component
Client
DecoratorFigure
PolyLineFigure
CompositeFigure
1..n
operation()
ramification
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
For each components
component.operation()
To compose objects
in a tree-like structure
to describe wholeâpart
hierarchies
68/184
69. Frame
DrawingEditor
Drawing
Handle
We can identify
in the architecture
of a systems
micro-architectures
similar to
design patterns
to explain the
problem solved
DrawingView
Tool
Comprehension
Panel
Figure
AbstractFigure
AttributeFigure
DecoratorFigure
PolyLineFigure
CompositeFigure
Figure
AttributeFigure
Component
Client
DecoratorFigure
PolyLineFigure
CompositeFigure
1..n
operation()
ramification
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
For each components
component.operation()
To compose objects
in a tree-like structure
to describe wholeâpart
hierarchies
69/184
70. Frame
DrawingEditor
Drawing
Handle
We can identify
in the architecture
of a systems
micro-architectures
similar to
design patterns
to explain the
problem solved
DrawingView
Tool
Comprehension
Panel
Figure
AbstractFigure
AttributeFigure
DecoratorFigure
PolyLineFigure
CompositeFigure
Figure
AttributeFigure
Component
Client
DecoratorFigure
PolyLineFigure
CompositeFigure
1..n
operation()
ramification
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
For each components
component.operation()
To compose objects
in a tree-like structure
to describe wholeâpart
hierarchies
70/184
71. â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
71/184
72. â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
72/184
73. â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
75. â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)
75/184
76. âImportant assumptions
â That software patterns can be codified in such a
way that they can be shared between and
reused by different designers
Why?
â 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
77. âImportant assumptions
â That software patterns can be codified in such a
way that they can be shared between and
reused by different designers
Schema Theory
â 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)
77/184
78. âImportant assumptions
â That software patterns can be codified in such a
way that they can be shared between and
reused by different designers
Schema Theory
â That reuse will lead to âbetterâ designs. There is
an obvious question here of what constitutes
âbetterâ, but a key measure is maintainabilityâ
How?
âZhang and Budgen, 2012
(With minor adaptations)
78/184
79. Agenda
ďŽ Why?
â Schema, Learning, and Patterns
ďŽ How?
â Developers, Social, and Code Studies
ďŽ Challenges
â Quality Models
â Multi-language Systems
79/184
80. Agenda
ďŽ Why?
â Schema, Learning, and Patterns
ďŽ How?
â Developers, Social, and Code Studies
ďŽ Challenges
â Quality Models
â Multi-language Systems
80/184
88. 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
88/184
89. 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.]
89/184
90. Developers Studies
ďŽ Independent
variables
â Design pattern notations
â Tasks: Participation, Composition, Role
ďŽ Dependent
variables
â Average fixation duration
â Ratio of fixations
â Ration of fixation times
90/184
91. 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 patternenhanced class diagrams more efficient for
Participation
91/184
98. 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
98/184
99. Social Studies
ďŽ Subjects
â 215 under-graduate students
â Java programming course
â Hong Kong University of Science and
Technology
99/184
100. 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.â
100/184
104. Agenda
ďŽ Why?
â Schema, Learning, and Patterns
ďŽ How?
â Developers, Social, and Code Studies
ďŽ Challenges
â Quality Models
â Multi-language Systems
104/184
105. 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
105/184
106. 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â
106/184
107. Design Patterns
ďŽ Problem
â Problem recurring in object-oriented design
ďŽ Solution
â Repeatable
â Effective
107/184
112. Design Patterns
ďŽ Positive
impact?
â 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
â Change proneness
â Comprehension
112/184
113. Design Patterns
ďŽ Positive
impact?
â 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
â Change proneness
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
Comprehension
113/184
114. Design Patterns
ďŽ Positive
impact?
â 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
â Change proneness
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
Comprehension
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
114/184
115. Code Studies
ďŽ Design
patterns
â Codify expertsâ experience
â Help train novice developers
â Help developersâ communicate
â Lead to improved quality
115/184
116. 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
116/184
117. Design Antipatterns
ďŽ Problem
â Problem recurring in object-oriented design
ďŽ Poor
solution
â Initially may look like a good idea
ďŽ Alternative
solution
â Repeatable (design pattern)
â Effective
117/184
119. 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
119/184
120. 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
Comprehension
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
120/184
121. Code Studies
ďŽ Design
antipatterns
â Codify expertsâ âbadâ experience
â Help train novice developers
â Help developersâ communicate
â Lead to decreased quality
121/184
122. Code Studies
ďŽ Limits
â So many patterns
â So many
â˘
â˘
â˘
â˘
Programming languages
Development contexts
Application domains
Expertises
122/184
123. âImportant assumptions
â That software patterns can be codified in such a
way that they can be shared between and
reused by different designers
Schema Theory
â 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)
123/184
124. âImportant assumptions
â That software patterns can be codified in such a
way that they can be shared between and
reused by different designers
Schema Theory
â That reuse will lead to âbetterâ designs. There is
an obvious question here of what constitutes
âbetterâ, but a key measure is maintainabilityâ
How?
âZhang and Budgen, 2012
(With minor adaptations)
124/184
125. âImportant assumptions
â That software patterns can be codified in such a
way that they can be shared between and
reused by different designers
Schema Theory
â That reuse will lead to âbetterâ designs. There is
an obvious question here of what constitutes
âbetterâ, but a key measure is maintainabilityâ
Pattern Studies
âZhang and Budgen, 2012
(With minor adaptations)
125/184
126. Agenda
ďŽ Why?
â Schema, Learning, and Patterns
ďŽ How?
â Developers, Social, and Code Studies
ďŽ Challenges
â Quality Models
â Multi-language Systems
126/184
127. Agenda
ďŽ Why?
â Schema, Learning, and Patterns
ďŽ How?
â Developers, Social, and Code Studies
ďŽ Challenges
â Quality Models
â Multi-language Systems
127/184
128. â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
128/184
129. 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
129/184
130. 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
131. Quality Models
ďŽ Basis
for quality models
â Software measures (aka metrics)
â˘
â˘
â˘
â˘
LOC
Chidamber and Kemerer
Briand et al.
âŚ
â Relationships among characteristics and metrics
⢠Theoretical
⢠Practical
131/184
141. Aristotle
384 BCâMar 7, 322 BC
Galileo Galilei
Feb 15, 1564âJan 8, 1642
Isaac Newton
Dec 25, 1642âMar 20, 1727
141/184
142. Aristotle
384 BCâMar 7, 322 BC
Galileo Galilei
Feb 15, 1564âJan 8, 1642
Isaac Newton
Dec 25, 1642âMar 20, 1727
Max Tegmark
May 5, 1967â
142/184
143. 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
143/184
144. 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
145. 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
145/184
146. 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)
146/184
148. 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âŚ
148/184
150. Quality Models
ďŽ Limits
â Relation between metrics and quality
characteristics, such as maintainability
150/184
151. Quality Models
ďŽ Limits
â Relation between metrics and quality
characteristics, such as maintainability
â Relation between metrics and design
choices, good practicesâŚ
151/184
152. â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
152/184
167. Multi-language Systems
ďŽ Todayâs
systems are multi-languages
â Facebook
â Twitter
ââŚ
â Even your âregularâ software system is now
multi-language, typically a Web application
167/184
169. Multi-language Systems
ďŽ For
example, control- and data-flows
between Java and ânativeâ C/C++ code
methods in Java are used by Java
classes but (typically) implemented in C/C++
ďŽ native
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
169/184