AsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges
1 like12,453 views
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.
![Developers Studies
Developers’
thought processes
– Reading code [Maletic et al.]
– Reading design models [Cepeda and Guéhéneuc]
• Content
• Form
–…
87/184](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-87-320.jpg)
![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](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-88-320.jpg)
![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](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-89-320.jpg)
![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](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-91-320.jpg)
![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](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-96-320.jpg)
![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](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-97-320.jpg)
![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](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-172-320.jpg)
![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](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-173-320.jpg)
![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](https://image.slidesharecdn.com/presentationsplitted-140308202449-phpapp02/85/AsianPLoP-14-How-and-Why-Design-Patterns-Impact-Quality-and-Future-Challenges-174-320.jpg)
AsianPLoP'14: How and Why 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 184. Multi-language system quality models – Definition and modelling – Computation – Characterisation – Impact 184/184