Quality Models Conclusions – Sound basis to measure different quality characteristics Limits – Relation between metrics and quality characteristics, such as maintainability – Relation between metrics and what they are expected to measure 49/155
Quality Models Limits – Relation between metrics and quality characteristics, such as maintainability – Relation between metrics and what they are expected to measure Overcome by using more, diverse, unrelated information 50/155
Quality Models Feedback – Measures – Occurrences – Factors to build “better” quality models 51/155
Metrics Models Measures Quality Models Good Practices Definition Maintainability Detection Occurrences Social Studies Characteristics Factors Developers Studies Behaviour 52/155
53/155
Practice, practice and practice more 54/155
55/155
Good Practices Maintainers can follow good practices – SOLID – Design patterns – Design antipatterns – … 56/155
Good Practices Maintainers can follow good practices – SOLID – Design patterns – Design anti-patterns – … 57/155
“Each pattern describes a problem which occurs over and over in our environment, and then describes the core of the solution to that problem, in such way that you can use this solution a million times over, without ever doing it the same way twice.” —Christopher Alexander, 1977 (With minor adaptations) 58/155
Good Practices 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 59/155
Good Practices 60/155
Design Patterns “Important assumptions – That patterns can be codified in such a way that they can be shared between 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) 61/155
Design Patterns Pattern solution = Motif which connotes an elegant architecture 62/155
Design Patterns Pattern solution = Motif which connotes an elegant architecture 63/155
Design Patterns Pattern solution = Motif which connotes an elegant architecture 64/155
Frame Panel Design Patterns DrawingEditor DrawingView Tool Drawing Handle Figure We can identify AbstractFigure in the architecture AttributeFigure DecoratorFigure PolyLineFigure CompositeFigure of a systems Figure AttributeFigure DecoratorFigure PolyLineFigure CompositeFigure micro-architectures similar to Component 1..n Client operation() ramification design motifs Leaf Composite add(Component) operation() remove(Component) getComponent(int) For each components operation() to explain the component.operation() To compose objects problem solved in a tree-like structure to describe whole–part hierarchies 65/155
Frame Panel Design Patterns DrawingEditor DrawingView Tool Drawing Handle Figure We can identify AbstractFigure in the architecture AttributeFigure DecoratorFigure PolyLineFigure CompositeFigure of a systems Figure AttributeFigure DecoratorFigure PolyLineFigure CompositeFigure micro-architectures similar to Component 1..n Client operation() ramification design motifs Leaf Composite add(Component) operation() remove(Component) getComponent(int) For each components operation() to explain the component.operation() To compose objects problem solved in a tree-like structure to describe whole–part hierarchies 66/155
Frame Panel Design Patterns DrawingEditor DrawingView Tool Drawing Handle Figure We can identify AbstractFigure in the architecture AttributeFigure DecoratorFigure PolyLineFigure CompositeFigure of a systems Figure AttributeFigure DecoratorFigure PolyLineFigure CompositeFigure micro-architectures similar to Component 1..n Client operation() ramification design motifs Leaf Composite add(Component) operation() remove(Component) getComponent(int) For each components operation() to explain the component.operation() To compose objects problem solved in a tree-like structure to describe whole–part hierarchies 67/155
Frame Panel Design Patterns DrawingEditor DrawingView Tool Drawing Handle Figure We can identify AbstractFigure in the architecture AttributeFigure DecoratorFigure PolyLineFigure CompositeFigure of a systems Figure AttributeFigure DecoratorFigure PolyLineFigure CompositeFigure micro-architectures similar to Component 1..n Client operation() ramification design motifs Leaf Composite add(Component) operation() remove(Component) getComponent(int) For each components operation() to explain the component.operation() To compose objects problem solved in a tree-like structure to describe whole–part hierarchies 68/155
Design Patterns Conclusions – Codify experts’ experience – Help train novice developers – Help developers’ communicate – Lead to improved quality 69/155
Design Anti-patterns 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 70/155
Design Anti-patterns Problem – Problem recurring in object-oriented design Poor solution – Initially may look like a good idea Alternative solution – Repeatable (design pattern) – Effective 71/155
Design Anti-patterns Negatively impact – Fault proneness – Change proneness – Comprehension 72/155
Design Anti-patterns Conclusions – Codify experts’ “bad” experience – Help train novice developers – Help developers’ communicate – Lead to improved quality 73/155
Good Practices Limits – So many patterns – So many • Programming languages • Development contexts • Application domains • Expertises How to use their occurrences in a model? 74/155
Metrics Models Measures Quality Models Good Practices Definition Maintainability Detection Occurrences Social Studies Characteristics Factors Developers Studies Behaviour 75/155
Social Studies Developers’ characteristics – Gender – Status – Expertise – Training – Processes – … 76/155
77/155
Agile programming, anyone? 78/155
79/155
Social Studies Need for social studies, typically in the form of experiments – Independent variable (few) – Dependent variables (many) – Statistical analyses (few) – Threats to validity (many) 80/155
Social Studies For example, impact on identifiers on program understandability – Identifier styles [Sharif, Binkley] – Identifier quality [Lawrie] – Developers’ gender and identifiers [Sharafi] – … 81/155
Social Studies For example, impact on identifiers on program understandability – Identifier styles [Sharif, Binkley] – Identifier quality [Lawrie] – Developers’ gender and identifiers [Sharafi] – … Zohreh Sharafi, Zéphyrin Soh, Yann-Gaël Guéhéneuc, and Giuliano Antoniol ; Women & Men: Different but Equal – A Study on the Impact of Identifiers on Source Code Underestanding ; 82/155 Proceeding of 20th International Conference on Program Comprehension, IEEE, 2012
Social Studies Independent variables – Gender: male vs. female – Identifier: camel case vs. underscore Dependent variables – Accuracy – Time – Effort 83/155
Social Studies Subjects Subjects’ Demography (24 Subjects) Academic background Gender Ph.D. M.Sc. B.Sc. Male Female 11 10 3 15 9 Conclusions Accuracy Time Effort 84/155
Social Studies Importance Limits – Confounding factors – Actionable results? 85/155
Metrics Models Measures Quality Models Good Practices Definition Maintainability Detection Occurrences Social Studies Characteristics Factors Developers Studies Behaviour 86/155
Developers Studies Developers’ thought processes – Cognitive theories – Memory theories • Brooks’ • Kelly’s categories • Von Mayrhauser’s • Minsky’s frames • Pennington’s • Piaget’s schema • Soloway’s • Schank’s scripts – Mental models • Gentner and Stevens’ mental models 87/155
Developers Studies Studying developers’ thought processes – Yarbus’ eye-movements and vision studies – Just and Carpenter’s eye–mind hypothesis – Palmer’s vision science – … 88/155
Developers Studies Picking into developers’ thought processes 89/155
Developers Studies Picking into developers’ thought processes 90/155
Developers Studies Picking into developers’ thought processes 91/155
Developers Studies Developers’ thought processes – Reading code [Maletic] – Reading design models [Cepeda] • Content • Form – … 92/155
Developers Studies Developers’ thought processes – Reading code – Reading design models [Cepeda] • 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 ; 93/155 Journal of Empirical Software Engineering, 15(5), Springer, 2010
Developers Studies Developers’ use of design pattern notations during program understandability – Strongly visual [Schauer and Keler] – Strongly textual [Dong et al.] – Mixed [Vlissides] 94/155
Developers Studies Independent variables – Design pattern notations – Tasks: Participation, Composition, Role Dependent variables – Average fixation duration – Ratio of fixations – Ration of fixation times 95/155
Developers Studies Subjects – 24 Ph.D. and M.Sc. students Conclusions – Stereotype-enhanced UML diagram [Dong et al.] more efficient for Composition and Role – UML collaboration notation and the pattern- enhanced class diagrams more efficient for Participation 96/155
Developers Studies Importance – Understand – Do better Limits – Confounding factors – Actionable results? 97/155
Impact of Quality Models Usefulness of the feedback? Usefulness of the models? 98/155
Feedback? Trend to use more, diverse, unrelated information as input of quality models – Code source metrics – Historical metrics – Design metrics 99/155
Feedback? Trend to use more, diverse, unrelated information as input of quality models – Code source metrics – Historical metrics – Design metrics – Good practices – Social studies – Developers’ studies 100/155
Recommend
More recommend
