some theory and practice on patterns – introduction · software design design ... design motifs...

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

Typical software developers?

5/153

Software costs?

8/153

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

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

10/153

11/153

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

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

12/153

Agenda

QualityMaintainability

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

Impact of Quality Models Challenges with Multi-language Systems

13/153

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

Quality

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

15/153

Quality

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

16/153

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

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

Quality

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

19/153

Quality

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

20/153

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

—IEEE Standard Glossary of Software Engineering Terminology, 2013

21/153

Maintainability

Quality Models Models

Good Practices Definition

Metrics

Detection Occurrences

Social Studies Characteristics

Developers Studies Behaviour

Factors

Measures

22/153

Maintainability



Metrics




Factors

Measures

23/153

Quality model are models with the objective to describe, assess, and–or predict quality

—Deissenboeck et al., WOSQ, 2009(With minor adaptations)

24/153

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

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

Quality Models

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

• Theoretical• Practical

27/153

Quality Models

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

(Do not miss Briand et al.’s surveys on cohesion and coupling metrics)

28/153

Quality Models

Typical metrics– LOC– Fan-in and Fan-out– Cohesion and coupling– McCabe complexity– …

Typically computed automatically on source code or other intermediate representations

29/153

Quality Models

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

Dozens of tools– PMD– Sonar– …

30/153

31/153

Who needs models?

32/153

33/153

•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

34/153

35/153

36/153

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/

37/153

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

38/153

Quality Models





39/153

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

40/153

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)

41/153

Quality Models

Menzies et al.’s models

42/153

Quality Models





43/153

Quality Models





44/153

Quality Models





45/153

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

46/153

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)

47/153

Quality Models

Bansiya and Davis’ QMOOD

48/153

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

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

Quality Models

Feedback– Measures– Occurrences– Factors

to build “better” quality models

51/153

52/153

Maintainability



Metrics




Factors

Measures

53/153

Practice, practiceand practice more

54/153

55/153

Good Practices

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

56/153

Good Practices

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

57/153

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

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

Good Practices

60/153

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

Design Patterns

Pattern solution = Motif which connotes anelegant architecture

62/153

Design Patterns


63/153

Design Patterns


64/153

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

65/153

Design Patterns


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

66/153

Design Patterns


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

67/153

Design Patterns


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

68/153

Design Patterns

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

69/153

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


Problem– Problem recurring in object-oriented design

Poor solution– Initially may look like a good idea

Alternative solution– Repeatable (design pattern)– Effective

71/153


Negatively impact– Fault proneness– Change proneness

– Comprehension

72/153


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

73/153


Limits– So many patterns

– So many• Programming languages• Development contexts• Application domains• Expertises

74/153

Maintainability



Metrics




Factors

Measures

75/153

Social Studies

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

76/153

77/153

Agile programming,anyone?

78/153

79/153

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

Social Studies

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

– Identifier quality [Lawrie]

– Developers’ gender and identifiers [Sharafi]

– …

81/153

Social Studies

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

– Identifier quality [Lawrie]

– Developers’ gender and identifiers [Sharafi]

– …

82/153

Social Studies

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

Dependent variables– Accuracy

– Time

– Effort

83/153

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

84/153

Social Studies

Importance

Limits– Confounding factors– Actionable results?

85/153

Maintainability



Metrics




Factors

Measures

86/153

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

87/153

Developers Studies

Studying developers’thought processes– Yarbus’ eye-movements

and vision studies– Just and Carpenter’s

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

88/153

Developers Studies

Picking into developers’ thought processes

89/153

Developers Studies


90/153

Developers Studies


91/153

Developers Studies

Developers’ thought processes– Reading code– Reading design models

• Content• Form

– …

92/153

Developers Studies

Developers’ thought processes– Reading code– Reading design models

• Content• Form

– …

93/153

Developers Studies

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

– Strongly textual [Dong et al.]

– Mixed [Vlissides]

94/153

Developers Studies

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

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

95/153

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

Developers Studies

Importance– Understand– Do better

Limits– Confounding factors– Actionable results?

97/153

Impact of Quality Models

Usefulness of the feedback? Usefulness of the models?

98/153

Feedback?

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

– Historical metrics– Good practices– Social studies– Developers’ studies

99/153

100/153

Modeling formodeling's sake?

101/153

Aristotle384 BC–Mar 7, 322 BC

102/153


Galileo GalileiFeb 15, 1564–Jan 8, 1642

103/153



Isaac NewtonDec 25, 1642–Mar 20, 1727

104/153




Max TegmarkMay 5, 1967–

105/153



Usefulness?


Max TegmarkMay 5, 1967–

106/153

Usefulness?

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

– 2003• Quality team

107/153

Usefulness?

MQL– Dedicated measurement process

108/153

Usefulness?

MQL– Web-based reports

109/153

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

110/153

Usefulness?

Subjects– 44 systems

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

111/153

Usefulness?

112/153

Usefulness?

113/153

Usefulness?

114/153

Usefulness?

115/153

Usefulness?

Conclusions– Impact on all dependent variables – Statistical practical significance

Limits– Applicability to today’s software systems

116/153

117/153

What’s with today’s systems?

118/153

119/153

120/153

121/153

122/153

123/153

124/153

125/153

126/153

127/153

128/153

Multi-language Systems

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

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

129/153


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

130/153


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++

131/153


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

132/153


Different computational models

133/153


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

}

134/153


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!

135/153

136/153

What challenges?

137/153

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

138/153

Challenges

Maintainability– Quality models

• Metrics?• Relations?

– Good practices• “Border-line” practices?

– Social and developers’ studies• Independent variables?

139/153

Challenges

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

140/153

Challenges


Build systemsdescriptions

141/153

Challenges



Legal issues dueto interrelations

142/153

Challenges


Clone definitionand detection



143/153

Challenges


Clone definitionand detection



Impact on studiesof large systems

144/153

145/153

Conclusion

146/153

147/153

148/153

149/153

150/153

Future directions

151/153

152/153

153/153

Multi-language system quality characteristics

– Definition and modelling– Computation– Characterisation– Impact

some theory and practice on patterns – introduction · software design design ... design motifs...

Documents