Quality and Software Design Patterns

Yann-Gaël Guéhéneuc

This work is licensed under a Creative Commons Attribution-NonCommercial-

ShareAlike 3.0 Unported License

Some Theory and Practice on Patterns – Introduction

NII, Tokyo, Japan12/02/14

3/155

Typical software developers?

5/155

Software costs?

8/155

Cost of bugshttp://www.di.unito.it/~damiani/ariane5rep.html

http://www.di.unito.it/~damiani/ariane5rep.html

10/155

11/155

Cost of qualityhttp://calleam.com/WTPF/?p=4914

http://calleam.com/WTPF/?p=4914

12/155

Agenda

QualityMaintainability

– Quality Models– Good Practices– Social Studies– Developers Studies

Impact of Quality Models Challenges with Multi-language Systems

13/155

“qual·i·ty noun \ˈkwä-lə-tē\ how good or bad something is a characteristic or feature that someone

or something has : something that can be noticed as a part of a person or thing

a high level of value or excellence”—Merriam-Webster, 2013

14/155

Quality

Division of software quality according to ISO/IEC 9126:2001, 25000:2005…– Process quality– Product quality– Quality in use

http://www.sqa.net/iso9126.html

http://www.sqa.net/iso9126.html

15/155

Quality

Division of software quality according to ISO/IEC 9126:2001, 25000:2005…– Process quality– Product quality– Quality in use

16/155

Quality

Dimensions of product quality– Functional vs. non-functional

• At runtime vs. structural– Internal vs. external

• Maintainability vs. usability– Metric-based vs. practice-based

• Objective vs. subjective

17/155

Quality

Dimensions of product quality– Functional vs. non-functional

• At runtime vs. structural– Internal vs. external

• Maintainability vs. usability– Metric-based vs. practice-based

• Objective vs. subjective

18/155

Quality

Definitions of internal quality characteristics– Maintainability– Flexibility– Portability– Re-usability– Readability– Testability– Understandability

19/155

Quality

Definitions of internal quality characteristics– Maintainability– Flexibility– Portability– Re-usability– Readability– Testability– Understandability

20/155

“Maintainability is the ease with which a software system can be modified”

—IEEE Standard Glossary of Software Engineering Terminology, 2013

21/155

Maintainability

Quality Models Models

Good Practices Definition

Metrics

Detection Occurrences

Social Studies Characteristics

Developers Studies Behaviour

Factors

Measures

22/155

Maintainability



Metrics




Factors

Measures

23/155

“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, 2009

24/155

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

25/155

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

26/155

Quality Models

Basis for quality models – Software measures (aka metrics)– Relationships among characteristics and metrics

• Theoretical• Practical

27/155

Quality Models

Metrics have been well researched– Chidamber and Kemerer– Hitz and Montazeri– Lorenz and Kidd– McCabe– …

28/155

Quality Models

Typical kinds of metrics– Size– Coupling– Cohesion

• Briand et al.’s surveys on cohesion and coupling– Complexity

Lionel C. Briand, John W. Daly, and Jürgen Wüst ;A Unified Framework for Cohesion Measurement in Object-OrientedSystems ;Journal of Empirical Software Engineering, 3(1), Springer, 1998

Lionel C. Briand, John W. Daly, and Jürgen Wüst ;A Unified Framework for Coupling Measurement in Object-Oriented Systems ;Transactions on Software Engineering, 25(1), IEEE Press, 1999

29/155

Quality Models

Typical metrics– LOC, fan-in and fan-out– LCOM5– CBO– McCabe’s complexity

Typically computed automatically on source code or other intermediate representations

30/155

Quality Models

Trend in computing metrics– Motoral– Samsung– SNCF– …

Dozens of tools– PMD– Sonar– …

31/155

32/155

Who needs models?

33/155

34/155

•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/archeology•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

35/155

36/155

37/155

Measures without modelshttp://hardsci.wordpress.com/2013/09/17/the-hotness-iq-tradeoff-in-academia/

http://hardsci.wordpress.com/2013/09/17/the-hotness-iq-tradeoff-in-academia/

38/155

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

39/155

Quality Models





40/155

Quality Models

Menzies et al.’s models– Characteristics of defectiveness

• Was the class/module involved in one fault or more?

– Three kinds of models• OneR• J48• Naïve Bayesian miner

Tim Menzies, Member, IEEE, Jeremy Greenwald, and Art Frank ;Data Mining Static Code Attributes to Learn Defect Predictors ;Transactions on Software Engineering, 33(1), IEEE, 2007

41/155

Quality Models

Menzies et al.’s models– Code metrics

• McCabe’s cyclomatic, design, essential complexities• LOC (total, blanks, comments…)• Halstead’s numbers of operands and operators (and

variations and combinations)

– Collection and validation using NASA MDP• 8 systems in C and Java

(No source code)http://nasa-softwaredefectdatasets.wikispaces.com/

http://nasa-softwaredefectdatasets.wikispaces.com/

42/155

Quality Models

Menzies et al.’s models

43/155

Quality Models





44/155

Quality Models





45/155

Quality Models





46/155

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 , Carl G. Davis ;A Hierarchical Model for Object-oriented Design Quality Assessment ;Transactions on Software Engineering, 28(1), IEEE, 2002

47/155

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)

48/155

Quality Models

Bansiya and Davis’ QMOOD

49/155

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

50/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

51/155

Quality Models

Feedback– Measures– Occurrences– Factors

to build “better” quality models

52/155

Maintainability



Metrics




Factors

Measures

53/155

54/155

Practice, practiceand practice more

55/155

56/155

Good Practices

Maintainers can follow good practices– SOLID– Design patterns– Design antipatterns– …

57/155

Good Practices

Maintainers can follow good practices– SOLID– Design patterns– Design anti-patterns– …

58/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)

59/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

60/155

Good Practices

61/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)

62/155

Design Patterns

Pattern solution = Motif which connotes anelegant architecture

63/155

Design Patterns


64/155

Design Patterns


65/155

Design Patterns

We can identifyin the architectureof a systemsmicro-architectures similar todesign motifsto explain theproblem solved

Figure

CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

To compose objectsin a tree-like structureto describe whole–parthierarchies

Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite

add(Component)remove(Component)getComponent(int)operation()

ramification

For each componentscomponent.operation()

1..nClient

66/155

Design Patterns


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

67/155

Design Patterns


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

68/155

Design Patterns


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

69/155

Design Patterns

Conclusions– Codify experts’ experience– Help train novice developers– Help developers’ communicate– Lead to improved quality

70/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

71/155


Problem– Problem recurring in object-oriented design

Poor solution– Initially may look like a good idea

Alternative solution– Repeatable (design pattern)– Effective

72/155


Negatively impact– Fault proneness– Change proneness

– Comprehension

73/155


Conclusions– Codify experts’ “bad” experience– Help train novice developers– Help developers’ communicate– Lead to improved quality

74/155

Good Practices

Limits– So many patterns– So many

• Programming languages• Development contexts• Application domains• Expertises

How to use their occurrences in a model?

75/155

Maintainability



Metrics




Factors

Measures

76/155

Social Studies

Developers’ characteristics– Gender– Status – Expertise– Training– Processes– …

77/155

78/155

Agile programming,anyone?

79/155

80/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)

81/155

Social Studies

For example, impact on identifiers on program understandability– Identifier styles [Sharif, Binkley]

– Identifier quality [Lawrie]

– Developers’ gender and identifiers [Sharafi]

– …

82/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 ;Proceeding of 20th International Conference on Program Comprehension, IEEE, 2012

83/155

Social Studies

Independent variables– Gender: male vs. female– Identifier: camel case vs. underscore

Dependent variables– Accuracy

– Time

– Effort

84/155

Social Studies

Subjects

Conclusions

Subjects’ Demography(24 Subjects)

Academic background GenderPh.D. M.Sc. B.Sc. Male Female

11 10 3 15 9

Accuracy Time Effort

85/155

Social Studies

Importance

Limits– Confounding factors– Actionable results?

86/155

Maintainability



Metrics




Factors

Measures

87/155

Developers Studies

Developers’ thought processes– Cognitive theories

• Brooks’• Von Mayrhauser’s• Pennington’s• Soloway’s

– Mental models• Gentner and Stevens’ mental models

– Memory theories• Kelly’s categories• Minsky’s frames• Piaget’s schema• Schank’s scripts

88/155

Developers Studies

Studying developers’thought processes– Yarbus’ eye-movements

and vision studies– Just and Carpenter’s

eye–mind hypothesis– Palmer’s vision science– …

89/155

Developers Studies

Picking into developers’ thought processes

90/155

Developers Studies


91/155

Developers Studies


92/155

Developers Studies

Developers’ thought processes– Reading code [Maletic]

– Reading design models [Cepeda]

• Content• Form

– …

93/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 ;Journal of Empirical Software Engineering, 15(5), Springer, 2010

94/155

Developers Studies

Developers’ use of design pattern notations during program understandability– Strongly visual [Schauer and Keler]

– Strongly textual [Dong et al.]

– Mixed [Vlissides]

95/155

Developers Studies

Independent variables– Design pattern notations– Tasks: Participation, Composition, Role

Dependent variables– Average fixation duration– Ratio of fixations– Ration of fixation times

96/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

97/155

Developers Studies

Importance– Understand– Do better

Limits– Confounding factors– Actionable results?

98/155

Impact of Quality Models

Usefulness of the feedback? Usefulness of the models?

99/155

Feedback?

Trend to use more, diverse, unrelated information as input of quality models– Code source metrics– Historical metrics– Design metrics

100/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

101/155

102/155

Modeling formodeling's sake?

103/155

Aristotle384 BC–Mar 7, 322 BC

104/155


Galileo GalileiFeb 15, 1564–Jan 8, 1642

105/155



Isaac NewtonDec 25, 1642–Mar 20, 1727

106/155




Max TegmarkMay 5, 1967–

107/155



Usefulness?


Max TegmarkMay 5, 1967–

108/155

Usefulness?

DSIV– SNCF IT department– 1,000+ employees – 200+ millions Euros– Mainframes to assembly to J2EE

– 2003• Quality team

Houari Sahraoui, Lionel C. Briand, Yann-Gaël Guéhéneuc , and Olivier Beaurepaire ;Investigating the impact of a measurement program on software quality ;Journal of Information and Software Technology, 52(9), Elsevier, 2010

109/155

Usefulness?

MQL– Dedicated measurement process

110/155

Usefulness?

MQL– Web-based reports

111/155

Usefulness?

Independent variables– Use of MQL or not– LOC; team size, maturity, and nature

Dependent variables– Maintainability, evolvability, reusability,

robustness, testability, and architecture quality– Corrective maintenance effort (in time)– Proportions of complex/unstructured code and of

commented methods/functions

112/155

Usefulness?

Subjects– 44 systems

• 22 under MQL (QA=1)• 22 under ad-hoc processes (QA=0)

113/155

Usefulness?

114/155

Usefulness?

115/155

Usefulness?

116/155

Usefulness?

117/155

Usefulness?

Conclusions– Impact on all dependent variables – Statistical practical significance

Limits– Applicability to today’s software systems

118/155

119/155

What’s with today’s systems?

120/155

121/155

122/155

123/155

124/155

125/155

126/155

127/155

128/155

129/155

130/155

Multi-language Systems

Today’s systems are multi-languages– Facebook– Twitter– …

– Even your “regular” software system is now multi-language, typically a Web application

131/155


New problems– Different computational models– Complex interfaces (API)– Wrong assumptions– Wrong conversions– …

132/155


For example, control- and data-flows between Java and “native” C/C++ code

native methods in Java are used by Java classes but (typically) implemented in C/C++

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

133/155


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– …

134/155


Different computational models

135/155


Different computational modelsstatic 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;...

}

136/155


Different computational modelsstatic 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!

137/155

138/155

What challenges?

139/155

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

140/155

Challenges

Maintainability– Quality models

• Metrics?• Relations?

– Good practices• “Border-line” practices?

– Social and developers’ studies• Independent variables?

141/155

Challenges

Not only for quality assurance!(Just for examples…)

142/155

Challenges


Build systemsdescriptions

143/155

Challenges



Legal issues dueto interrelations

144/155

Challenges


Clone definitionand detection



145/155

Challenges


Clone definitionand detection



Impact on studiesof large systems

146/155

147/155

Conclusion

148/155

149/155

150/155

151/155

152/155

Future directions

153/155

154/155

155/155

Multi-language system quality characteristics

– Definition and modelling– Computation– Characterisation– Impact

Quality and Software Design Patterns

Technology

Transcript of Quality and Software Design Patterns