• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges
 

AsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges

on

  • 1,531 views

Since their inception in the field of software engineering, design patterns have been the topic of much research work. This work as roughly divided into two directions: identifying, formalising, and ...

Since their inception in the field of software engineering, design patterns have been the topic of much research work. This work as roughly divided into two directions: identifying, formalising, and publishing new design patterns on the one hand and measuring the impact of these design patterns on the other. Starting from a high-level view of quality, we discuss how design pattern can impact quality and be used to measure quality. Then, we discuss why design patterns can impact quality, in particular from the developers' perspective. Finally, we introduce new challenges faced the community defining and measuring design patterns due to multi-language systems.

Statistics

Views

Total Views
1,531
Views on SlideShare
1,504
Embed Views
27

Actions

Likes
0
Downloads
3
Comments
0

4 Embeds 27

http://www.ptidej.net 19
http://squirrel.polymtl.ca 4
http://ptidej.net 3
http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    AsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges AsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges Presentation Transcript

    • 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
    • “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
    • “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
    • “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
    • “Important assumptions – That software patterns can be codified in such a way that they can be shared between and reused by different designers – That reuse will lead to “better” designs. There is an obvious question here of what constitutes “better”, but a key measure is maintainability” —Zhang and Budgen, 2012 (With minor adaptations) 5/184
    • “Important assumptions – That software patterns can be codified in such a way that they can be shared between and reused by different designers 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
    • “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
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 8/184
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 9/184
    • “The captain asked the passengers to fasten the seat belts. They were ready to take off.” —Kohls and Scheiter, 2008 Christian Kohls and Katharina Scheiter. The Relation between Design Patterns and Schema Theory. Proceedings of the 15th Conference on Pattern Languages of Programs, ACM Press, 2008 10/184
    • “This situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.” —Kohls and Scheiter, 2008 (With minor adaptations) 11/184
    • “Human brains operate fundamentally in terms of pattern recognition rather than of logic. They are highly constructive in settling on given schema and at the same time are constantly open to error.” —Edelman, 2006 (With minor adaptations) 12/184
    • 13/184
    • 14/184
    • 15/184
    • 16/184
    • 17/184
    • 18/184
    • Schema  Abstract representation of multiple instances of the same kinds of – Concept – Situation – Plan – Behaviour –… 19/184
    • “Abstract representation to recognise similar or discriminate dissimilar experiences, access common concepts, draw inferences, create goals, develop plans, use skills.” —Kohls and Scheiter, 2008 (With minor adaptations) 20/184
    • “Examples of schemata include academic rubrics, social schemas, stereotypes, social roles, scripts, worldviews, and archetypes. In Piaget's theory of development, children adopt a series of schemata to understand the world.” —Wikipedia, 2014 21/184
    • 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
    • Schema  Variables (or slots or attributes)  (Constrained) Ranges of values – People’s experience – Constants – Optional or mandatory  Constraints among variables and their values 23/184
    • Schema  Variables (or slots or attributes)  (Constrained) Ranges of values – People’s experience – Constants – Optional or mandatory  Constraints among variables and their values 24/184
    • Schema  Variables (or slots or attributes)  (Constrained) Ranges of values – People’s experience – Constants – Optional or mandatory  Constraints among variables and their values 25/184
    • Schema  Prototypical object 26/184
    • Schema  Prototypical object 27/184
    • Schema  Prototypical  Object object space and (mental) object generator 28/184
    • Schema  Prototypical  Object object space and (mental) object generator 29/184
    • Schema  Prototypical  Object object space and (mental) object generator 30/184
    • Schema  Prototypical  Object object space and (mental) object generator 31/184
    • Schema  Relations among schemas 32/184
    • Schema  Relations among schemas – Part-of 33/184
    • Schema  Relations among schemas – Part-of 34/184
    • Schema  Relations among schemas – Coupling 35/184
    • Schema  Relations among schemas – Coupling 36/184
    • Schema  Relations among schemas – Is-a 37/184
    • Schema  Relations among schemas – Is-a 38/184
    • Schema  Hierarchy – Contexts – Forces – Probabilities 39/184
    • Schema  Hierarchy – Contexts – Forces – Probabilities 40/184
    • Schema  Hierarchy – Contexts – Forces – Probabilities 41/184
    • Schema 42/184
    • 43/184
    • David Rumelhart and Donald Norman. Accretion, tuning and restructuring: Three modes of learning. Semantic Factors in Cognition, Erlbaum, 1978 44/184
    • Learning  Comprehension: pattern matching of memorised schema that cooperates and competes 45/184
    • Learning  Comprehension: pattern matching of memorised schema that cooperates and competes 46/184
    • Learning  Comprehension: pattern matching of memorised schema that cooperates and competes 47/184
    • Learning  Comprehension: pattern matching of memorised schema that cooperates and competes 48/184
    •  49/184
    • Learning  Accretion: specific situation or experience stored in schemas used to reconstruct original experience – Episodic memory – Specific details 50/184
    • Learning  Accretion: specific situation or experience stored in schemas used to reconstruct original experience – Episodic memory – Specific details 51/184
    • Learning  Accommodation / Tuning: schemas modifications – Variables – Ranges – Probabilities 52/184
    •  53/184
    • Learning  Assimilation / Restructuring: schemas creations – Schema generation by analogies with existing schema, is-a – Schema induction from existing schema, has-a 54/184
    • Learning  Assimilation / Restructuring: schemas creations – Schema generation by analogies with existing schema, is-a – Schema induction from existing schema, has-a 55/184
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 56/184
    • “This situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.” —Kohls and Scheiter, 2008 (With minor adaptations) 57/184
    • “This situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.” —Kohls and Scheiter, 2008 (With minor adaptations) 58/184
    • “This situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.” —Kohls and Scheiter, 2008 (With minor adaptations) “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
    •  Schema – Variables – Ranges of values – Constraints among variables and their values 60/184
    • What class plays this role?  Schema – Variables – Ranges of values – Constraints among variables and their values 61/184
    • Possible classes playing this role plus their relations, implementation…  Schema – Variables – Ranges of values – Constraints among variables and their values 62/184
    • Relations, interactions…  Schema – Variables – Ranges of values – Constraints among variables and their values 63/184
    • Comprehension 64/184
    • Comprehension 65/184
    • Comprehension We can identify in the architecture of a systems micro-architectures similar to design patterns to explain the problem solved 66/184
    • 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
    • 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
    • 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
    • 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
    • “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
    • “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
    • “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/184
    • “Important assumptions – That software patterns can be codified in such a way that they can be shared between and reused by different designers – That reuse will lead to “better” designs. There is an obvious question here of what constitutes “better”, but a key measure is maintainability” —Zhang and Budgen, 2012 (With minor adaptations) 75/184
    • “Important assumptions – That software patterns can be codified in such a way that they can be shared between and reused by different designers 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
    • “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
    • “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
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 79/184
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 80/184
    • 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
    • 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
    • Developers Studies 83/184
    • Developers Studies  Picking into developers’ thought processes 84/184
    • Developers Studies  Picking into developers’ thought processes 85/184
    • Developers Studies  Picking into developers’ thought processes 86/184
    • Developers Studies  Developers’ thought processes – Reading code [Maletic et al.] – Reading design models [Cepeda and Guéhéneuc] • Content • Form –… 87/184
    • Developers Studies  Developers’ thought processes – Reading code [Maletic et al.] – Reading design models [Cepeda and Guéhéneuc] • Content • Form –… Gerardo Cepeda Porras and Yann-Gaël Guéhéneuc. An Empirical Study on the Efficiency of Different Design Pattern Representations in UML Class Diagrams. Journal of Empirical Software Engineering, 15(5), Springer, 2010 88/184
    • Developers Studies  Developers’ use of design pattern notations during program understandability – Strongly visual [Schauer and Keller] – Strongly textual [Dong et al.] – Mixed [Vlissides et al.] 89/184
    • 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
    • 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
    • Developers Studies  Importance – Understand – Do better 92/184
    • Developers Studies  Importance – Understand – Do better 93/184
    • Developers Studies  Importance – Understand – Do better  Limits – Confounding factors – Actionable results? 94/184
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 95/184
    • Social Studies  Developers’ characteristics – Knowledge [Ng et al.] – Gender [Sharafi et al.] – Status [Soh et al.] – Expertise [Soh et al.] – Processes [Lavallée and Robillard] –… 96/184
    • Social Studies  Developers’ characteristics – Knowledge [Ng et al.] – Gender [Sharafi et al.] – Status [Soh et al.] – Expertise [Soh et al.] – Processes [Lavallée and Robillard] –… 97/184
    • Social Studies  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
    • Social Studies  Subjects – 215 under-graduate students – Java programming course – Hong Kong University of Science and Technology 99/184
    • Social Studies  Conclusion – Results “support the deployment of design patterns as they were utilized by most of the subjects to complete the anticipated changes.” – “Utilizing deployed design patterns does not necessarily mean that better codes are delivered.” 100/184
    • Social Studies  Importance – Difference among tasks – Visualisation – Documentation 101/184
    •  Importance – Difference among tasks – Visualisation – Documentation 102/184
    •  Importance – Difference among tasks – Visualisation – Documentation  Limits – Confounding factors – Actionable results? 103/184
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 104/184
    • Code Studies  Design patterns – A general reusable solution to a commonly occurring problem within a given context in software design  Design antipatterns – A design pattern that may be commonly used but is ineffective/counterproductive in practice 105/184
    • Design Patterns  Important assumptions – “Patterns can be codified in such a way that they can be shared between different designers” – “Reuse will lead to “better” designs. There is an obvious question here of what constitutes “better”, but a key measure is maintainability” 106/184
    • Design Patterns  Problem – Problem recurring in object-oriented design  Solution – Repeatable – Effective 107/184
    • Design Patterns  Positive impact? 108/184
    • Design Patterns  Positive impact? – Fault proneness 109/184
    • Design Patterns  Positive impact? – Fault proneness – Change proneness 110/184
    • Design Patterns  Positive impact? – Fault proneness – Change proneness – Comprehension 111/184
    • 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
    • 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
    • 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
    • Code Studies  Design patterns – Codify experts’ experience – Help train novice developers – Help developers’ communicate – Lead to improved quality 115/184
    • Design Antipatterns  Important assumptions – Poor design choices that are conjectured to make object-oriented systems harder to maintain – Yet, maybe the best and possibly only way to implement some requirements and–or some functionalities 116/184
    • Design Antipatterns  Problem – Problem recurring in object-oriented design  Poor solution – Initially may look like a good idea  Alternative solution – Repeatable (design pattern) – Effective 117/184
    • Design Antipatterns  Negative impact 118/184
    • Design Antipatterns  Negative impact – Fault proneness – Change proneness Foutse Khomh, Massimiliano Di Penta, Yann-Gaël Guéhéneuc, Giuliano Antoniol. An Exploratory Study of the Impact of Antipatterns on Class Change- and Fault-proneness. Empirical Software Engineering, 17(3), Springer, 2012 119/184
    • Design Antipatterns  Negative impact – Fault proneness – Change proneness Foutse Khomh, Massimiliano Di Penta, Yann-Gaël Guéhéneuc, Giuliano Antoniol. An Exploratory Study of the Impact of Antipatterns on Class Change- and Fault-proneness. Empirical Software Engineering, 17(3), Springer, 2012 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
    • Code Studies  Design antipatterns – Codify experts’ “bad” experience – Help train novice developers – Help developers’ communicate – Lead to decreased quality 121/184
    • Code Studies  Limits – So many patterns – So many • • • • Programming languages Development contexts Application domains Expertises 122/184
    • “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
    • “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
    • “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
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 126/184
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 127/184
    • “Quality model are models with the objective to describe, assess, and–or predict quality” —Deissenboeck et al., WOSQ, 2009 (With minor adaptations) Florian Deissenboeck, Elmar Juergens, Klaus Lochmann, and Stefan Wagner. Software Quality Models: Purposes, Usage Scenarios and Requirements. International Workshop on Software Quality, 24th International Symposium on Computer and Information Sciences, IEEE CS Press, 2009 128/184
    • Quality Models  Division of quality models according to Deissenboeck et al. – Describe quality characteristics and their relationships – Assess the quality characteristics of some software systems – Predict the future quality of some software systems 129/184
    • Quality Models  Division of quality models according to Deissenboeck et al. – Describe quality characteristics and their relationships – Assess the quality characteristics of some software systems – Predict the future quality of some software systems 130/184
    • Quality Models  Basis for quality models – Software measures (aka metrics) • • • • LOC Chidamber and Kemerer Briand et al. … – Relationships among characteristics and metrics • Theoretical • Practical 131/184
    • Who needs models? 132/184
    • 133/184
    • • 130.0 Physics • 129.0 Mathematics • 128.5 Computer Science • 128.0 Economics • 127.5 Chemical engineering • 127.0 Material science • 126.0 Electrical engineering • 125.5 Mechanical engineering • 125.0 Philosophy • 124.0 Chemistry • 123.0 Earth sciences • 122.0 Industrial engineering • 122.0 Civil engineering • 121.5 Biology • 120.1 English/literature • 120.0 Religion/theology • 119.8 Political science • 119.7 History • 118.0 Art history • 117.7 Anthropology/archaeology • 116.5 Architecture • 116.0 Business • 115.0 Sociology • 114.0 Psychology • 114.0 Medicine • 112.0 Communication • 109.0 Education • 106.0 Public administration 134/184
    • 135/184
    • 136/184
    • Measures without models! http://hardsci.wordpress.com/2013/09/17/the-hotness-iq-tradeoff-in-academia/ 137/184
    • Modeling for modeling's sake? 138/184
    • Aristotle 384 BC–Mar 7, 322 BC 139/184
    • Aristotle 384 BC–Mar 7, 322 BC Galileo Galilei Feb 15, 1564–Jan 8, 1642 140/184
    • 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
    • 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
    • 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
    • Quality Models  Different input metrics, output characteristics – Menzies et al.’s models • Code metrics • Defectiveness – Zimmermann et al.’s models • Code and historical metrics • Fault-proneness – Bansiya and Davis’ QMOOD • Design metrics • Maintainability-related characteristics 144/184
    • Quality Models  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
    • 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
    • Quality Models  Bansiya and Davis’ QMOOD 147/184
    • Quality Models  Conclusions – Sound basis to measure different quality characteristics  Limits – Relation between metrics and quality characteristics, such as maintainability – Relation between metrics and design choices, good practices… 148/184
    • Quality Models  Limits 149/184
    • Quality Models  Limits – Relation between metrics and quality characteristics, such as maintainability 150/184
    • Quality Models  Limits – Relation between metrics and quality characteristics, such as maintainability – Relation between metrics and design choices, good practices… 151/184
    • “Having an ideal concept of a thing lets one judge the beauty of it.” —Kohls and Scheiter, 2008 “For Alexander, patterns are not an end in themselves, they are only a means to an end; his objective is to generate the quality without a name” —Kelly, 2012 152/184
    • Quality Models  Feedback – Measures – Occurrences – Factors to build “better” quality models 153/184
    • Quality Models  Feedback – Measures – Occurrences – Factors to build “better” quality models 154/184
    • Agenda  Why? – Schema, Learning, and Patterns  How? – Developers, Social, and Code Studies  Challenges – Quality Models – Multi-language Systems 155/184
    • What’s with today’s systems? 156/184
    • 157/184
    • 158/184
    • 159/184
    • 160/184
    • 161/184
    • 162/184
    • 163/184
    • 164/184
    • 165/184
    • 166/184
    • Multi-language Systems  Today’s systems are multi-languages – Facebook – Twitter –… – Even your “regular” software system is now multi-language, typically a Web application 167/184
    • Multi-language Systems  New problems – Different computational models – Complex interfaces (API) – Wrong assumptions – Wrong conversions –… 168/184
    • 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
    • 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
    • Multi-language Systems  Different computational models 171/184
    • 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
    • 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
    • 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
    • What challenges? 175/184
    • Unbalanced focus on “mono”-language systems vs. multi-language systems 176/184
    • Multi-language Systems  Maintainability – Quality models • Metrics? • Relations? – Patterns • “Border-line” practices? – Social and developers studies • Independent variables? 177/184
    • Conclusion 178/184
    • 179/184
    • 180/184
    • 181/184
    • 182/184
    • Future directions 183/184
    •  Multi-language system quality models – Definition and modelling – Computation – Characterisation – Impact 184/184