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.

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

13. 13/184

14. 14/184

15. 15/184

16. 16/184

17. 17/184

18. 18/184

19. Schema
 Abstract
representation of multiple instances
of the same kinds of
– Concept
– Situation
– Plan
– Behaviour
–…
19/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

26. Schema
 Prototypical
object
26/184

27. Schema
 Prototypical
object
27/184

28. Schema
 Prototypical
 Object
object
space and (mental) object generator
28/184

29. Schema
 Prototypical
 Object
object
space and (mental) object generator
29/184

30. Schema
 Prototypical
 Object
object
space and (mental) object generator
30/184

31. Schema
 Prototypical
 Object
object
space and (mental) object generator
31/184

32. Schema
 Relations
among schemas
32/184

33. Schema
 Relations
among schemas
– Part-of
33/184

34. Schema
 Relations
among schemas
– Part-of
34/184

35. Schema
 Relations
among schemas
– Coupling
35/184

36. Schema
 Relations
among schemas
– Coupling
36/184

37. Schema
 Relations
among schemas
– Is-a
37/184

38. Schema
 Relations
among schemas
– Is-a
38/184

39. Schema
 Hierarchy
– Contexts
– Forces
– Probabilities
39/184

40. Schema
 Hierarchy
– Contexts
– Forces
– Probabilities
40/184

41. Schema
 Hierarchy
– Contexts
– Forces
– Probabilities
41/184

42. Schema
42/184

43. 43/184

44. David Rumelhart and Donald Norman.
Accretion, tuning and restructuring: Three modes of learning.
Semantic Factors in Cognition, Erlbaum, 1978
44/184

45. Learning
 Comprehension:
pattern matching of
memorised schema that cooperates and
competes
45/184

46. Learning
 Comprehension:
pattern matching of
memorised schema that cooperates and
competes
46/184

47. Learning
 Comprehension:
pattern matching of
memorised schema that cooperates and
competes
47/184

48. Learning
 Comprehension:
pattern matching of
memorised schema that cooperates and
competes
48/184

49. 
49/184

50. Learning
 Accretion:
specific situation or experience
stored in schemas used to reconstruct
original experience
– Episodic memory
– Specific details
50/184

51. Learning
 Accretion:
specific situation or experience
stored in schemas used to reconstruct
original experience
– Episodic memory
– Specific details
51/184

52. Learning
 Accommodation
/ Tuning:
schemas modifications
– Variables
– Ranges
– Probabilities
52/184

53. 
53/184

54. Learning
 Assimilation
/ Restructuring:
schemas creations
– Schema generation by analogies with existing
schema, is-a
– Schema induction from existing schema, has-a
54/184

55. Learning
 Assimilation
/ Restructuring:
schemas creations
– Schema generation by analogies with existing
schema, is-a
– Schema induction from existing schema, has-a
55/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

60.  Schema
– Variables
– Ranges of values
– Constraints among variables and their values
60/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

63. Relations, interactions…
 Schema
– Variables
– Ranges of values
– Constraints among variables and their values
63/184

64. Comprehension
64/184

65. Comprehension
65/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

74. 74/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

81. Developers Studies
 Developers’
thought processes
– Cognitive theories
•
•
•
•
Brooks’
Von Mayrhauser’s
Pennington’s
Soloway’s
– Memory theories
•
•
•
•
Kelly’s categories
Minsky’s frames
Piaget’s schema
Schank’s scripts
– Mental models
• Gentner and Stevens’ mental models
81/184

82. Developers Studies
 Studying
developers’ thought processes
– Yarbus’ eye-movements and vision studies
– Just and Carpenter’s eye–mind hypothesis
– Palmer’s vision science
–…
82/184

83. Developers Studies
83/184

84. Developers Studies
 Picking
into developers’ thought processes
84/184

85. Developers Studies
 Picking
into developers’ thought processes
85/184

86. Developers Studies
 Picking
into developers’ thought processes
86/184

87. Developers Studies
 Developers’
thought processes
– Reading code [Maletic et al.]
– Reading design models [Cepeda and Guéhéneuc]
• Content
• Form
–…
87/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

92. Developers Studies
 Importance
– Understand
– Do better
92/184

93. Developers Studies
 Importance
– Understand
– Do better
93/184

94. Developers Studies
 Importance
– Understand
– Do better
 Limits
– Confounding factors
– Actionable results?
94/184

95. Agenda
 Why?
– Schema, Learning, and Patterns
 How?
– Developers, Social, and Code Studies
 Challenges
– Quality Models
– Multi-language Systems
95/184

96. 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]
–…
96/184

97. 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

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

101. Social Studies
 Importance
– Difference among tasks
– Visualisation
– Documentation
101/184

102.  Importance
– Difference among tasks
– Visualisation
– Documentation
102/184

103.  Importance
– Difference among tasks
– Visualisation
– Documentation
 Limits
– Confounding factors
– Actionable results?
103/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

108. Design Patterns
 Positive
impact?
108/184

109. Design Patterns
 Positive
impact?
– Fault proneness
109/184

110. Design Patterns
 Positive
impact?
– Fault proneness
– Change proneness
110/184

111. Design Patterns
 Positive
impact?
– Fault proneness
– Change proneness
– Comprehension
111/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

118. Design Antipatterns
 Negative
impact
118/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

132. Who needs models?
132/184

133. 133/184

134. • 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
134/184

135. 135/184

136. 136/184

137. Measures without models!
http://hardsci.wordpress.com/2013/09/17/the-hotness-iq-tradeoff-in-academia/
137/184

138. Modeling for
modeling's sake?
138/184

139. Aristotle
384 BC–Mar 7, 322 BC
139/184

140. Aristotle
384 BC–Mar 7, 322 BC
Galileo Galilei
Feb 15, 1564–Jan 8, 1642
140/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

147. Quality Models
 Bansiya
and Davis’ QMOOD
147/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

149. Quality Models
 Limits
149/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

153. Quality Models
 Feedback
– Measures
– Occurrences
– Factors
to build “better” quality models
153/184

154. Quality Models
 Feedback
– Measures
– Occurrences
– Factors
to build “better” quality models
154/184

155. Agenda
 Why?
– Schema, Learning, and Patterns
 How?
– Developers, Social, and Code Studies
 Challenges
– Quality Models
– Multi-language Systems
155/184

156. What’s with
today’s systems?
156/184

157. 157/184

158. 158/184

159. 159/184

160. 160/184

161. 161/184

162. 162/184

163. 163/184

164. 164/184

165. 165/184

166. 166/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

168. Multi-language Systems
 New
problems
– Different computational models
– Complex interfaces (API)
– Wrong assumptions
– Wrong conversions
–…
168/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

170. 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
–…
170/184

171. Multi-language Systems
 Different
computational models
171/184

172. Multi-language Systems
 Different
computational models
static 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;
...
}
172/184

173. Multi-language Systems
 Different computational models
No setjmp(…) or related calls!
static 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

174. Multi-language Systems
 Different computational models
No setjmp(…) or related calls!
static 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!
174/184

175. What challenges?
175/184

176. Unbalanced focus on
“mono”-language systems
vs. multi-language systems
176/184

177. Multi-language Systems
 Maintainability
– Quality models
• Metrics?
• Relations?
– Patterns
• “Border-line” practices?
– Social and developers studies
• Independent variables?
177/184

178. Conclusion
178/184

179. 179/184

180. 180/184

181. 181/184

182. 182/184

183. Future directions
183/184

184.  Multi-language
system quality models
– Definition and modelling
– Computation
– Characterisation
– Impact
184/184