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

Yann-Gaël Guéhéneuc

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

ShareAlike 3.0 Unported License

How and Why Design Patterns Impact Quality and Future Challenges

AsianPLoP, Tokyo, Japan05/03/14

2/184

“Patterns help people to share experience-based 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/

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

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

– 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

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

Why?

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

Why?

How?

8/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

9/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

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

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

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

13/184

14/184

15/184

16/184

17/184

18/184

19/184

Schema

Abstract representation of multiple instances of the same kinds of – Concept– Situation– Plan– Behaviour– …

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

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

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

Variables (or slots or attributes)

(Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory

Constraints among variables and their values

26/184

Schema

Prototypical object

27/184

Schema

Prototypical object

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

Prototypical object

Object space and (mental) object generator

32/184

Schema

Relations among schemas

33/184

Schema

Relations among schemas

– Part-of

34/184

Schema

Relations among schemas

– Part-of

35/184

Schema

Relations among schemas

– Coupling

36/184

Schema

Relations among schemas

– Coupling

37/184

Schema

Relations among schemas

– Is-a

38/184

Schema

Relations among schemas

– Is-a

39/184

Schema

Hierarchy– Contexts– Forces– Probabilities

40/184

Schema

Hierarchy– Contexts– Forces– Probabilities

41/184

Schema

Hierarchy– Contexts– Forces– Probabilities

42/184

Schema

43/184

44/184

David Rumelhart and Donald Norman.Accretion, tuning and restructuring: Three modes of learning.Semantic Factors in Cognition, Erlbaum, 1978

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

Learning

Comprehension: pattern matching of memorised schema that cooperates and competes

49/184

50/184

Learning

Accretion: specific situation or experience stored in schemas used to reconstruct original experience– Episodic memory– Specific details

51/184

Learning

Accretion: specific situation or experience stored in schemas used to reconstruct original experience– Episodic memory– Specific details

52/184

Learning

Accommodation / Tuning: schemas modifications– Variables– Ranges– Probabilities

53/184

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

Learning

Assimilation / Restructuring: schemas creations– Schema generation by analogies with existing

schema, is-a– Schema induction from existing schema, has-a

56/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

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)

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

60/184

Schema– Variables– Ranges of values– Constraints among variables and their values

61/184

Schema– Variables– Ranges of values– Constraints among variables and their values

What class plays this role?

62/184

Schema– Variables– Ranges of values– Constraints among variables and their values

Possible classes playing this roleplus their relations, implementation…

63/184

Schema– Variables– Ranges of values– Constraints among variables and their values

Relations, interactions…

64/184

Comprehension

65/184

Comprehension

66/184

Comprehension

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

67/184

Comprehension

We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto 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

CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

Component

operation()

Leaf

operation()

Composite

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

ramification

For each componentscomponent.operation()

1..nClient

68/184

Comprehension

We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto 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

CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

Component

operation()

Leaf

operation()

Composite

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

ramification

For each componentscomponent.operation()

1..nClient

69/184

Comprehension

We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto 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

CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

Component

operation()

Leaf

operation()

Composite

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

ramification

For each componentscomponent.operation()

1..nClient

70/184

Comprehension

We can identifyin the architectureof a systemsmicro-architectures similar todesign patternsto 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

CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

Component

operation()

Leaf

operation()

Composite

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

ramification

For each componentscomponent.operation()

1..nClient

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

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

“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

74/184

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

– 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

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

Why?

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

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

Schema Theory

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

How?

Schema Theory

79/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

80/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

81/184

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

82/184

Developers Studies

Studying developers’ thought processes– Yarbus’ eye-movements and vision studies– Just and Carpenter’s eye–mind hypothesis– Palmer’s vision science– …

83/184

Developers Studies

84/184

Developers Studies

Picking into developers’ thought processes

85/184

Developers Studies

Picking into developers’ thought processes

86/184

Developers Studies

Picking into developers’ thought processes

87/184

Developers Studies

Developers’ thought processes– Reading code [Maletic et al.]

– Reading design models [Cepeda and Guéhéneuc]

• Content• Form

– …

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

89/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.]

90/184

Developers Studies

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

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

91/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 pattern-

enhanced class diagrams more efficient for Participation

92/184

Developers Studies

Importance– Understand– Do better

93/184

Developers Studies

Importance– Understand– Do better

94/184

Developers Studies

Importance– Understand– Do better

Limits– Confounding factors– Actionable results?

95/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

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

Developers’ characteristics– Knowledge [Ng et al.]

– Gender [Sharafi et al.]

– Status [Soh et al.]

– Expertise [Soh et al.]

– Processes [Lavallée and Robillard]

– …

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

99/184

Social Studies

Subjects– 215 under-graduate students– Java programming course – Hong Kong University of Science and

Technology

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

101/184

Social Studies

Importance– Difference among tasks– Visualisation – Documentation

102/184

Importance– Difference among tasks– Visualisation – Documentation

103/184

Importance– Difference among tasks– Visualisation – Documentation

Limits– Confounding factors– Actionable results?

104/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

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

106/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”

107/184

Design Patterns

Problem– Problem recurring in object-oriented design

Solution– Repeatable– Effective

108/184

Design Patterns

Positive impact?

109/184

Design Patterns

Positive impact?– Fault proneness

110/184

Design Patterns

Positive impact?– Fault proneness

– Change proneness

111/184

Design Patterns

Positive impact?– Fault proneness

– Change proneness

– Comprehension

112/184

Design Patterns

Positive impact?– Fault proneness

– Change proneness

– Comprehension

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

113/184

Design Patterns

Positive impact?– Fault proneness

– Change proneness

Comprehension

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

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

114/184

Design Patterns

Positive impact?– Fault proneness

– Change proneness

Comprehension

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

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

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

115/184

Code Studies

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

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

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

118/184

Design Antipatterns

Negative impact

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

120/184

Design Antipatterns

Negative impact– Fault proneness– Change proneness

Comprehension

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

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

121/184

Code Studies

Design antipatterns– Codify experts’ “bad” experience– Help train novice developers– Help developers’ communicate– Lead to decreased quality

122/184

Code Studies

Limits– So many patterns– So many

• Programming languages• Development contexts• Application domains• Expertises

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

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

Schema Theory

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

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

How?

Schema Theory

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

Schema Theory

Pattern Studies

126/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

127/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

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

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

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

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

132/184

Who needs models?

133/184

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

135/184

136/184

137/184

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

138/184

Modeling formodeling's sake?

139/184

Aristotle384 BC–Mar 7, 322 BC

140/184

Aristotle384 BC–Mar 7, 322 BC

Galileo GalileiFeb 15, 1564–Jan 8, 1642

141/184

Aristotle384 BC–Mar 7, 322 BC

Galileo GalileiFeb 15, 1564–Jan 8, 1642

Isaac NewtonDec 25, 1642–Mar 20, 1727

142/184

Aristotle384 BC–Mar 7, 322 BC

Galileo GalileiFeb 15, 1564–Jan 8, 1642

Isaac NewtonDec 25, 1642–Mar 20, 1727

Max TegmarkMay 5, 1967–

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

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

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

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

147/184

Quality Models

Bansiya and Davis’ QMOOD

148/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…

149/184

Quality Models

Limits

150/184

Quality Models

Limits– Relation between metrics and quality

characteristics, such as maintainability

151/184

Quality Models

Limits– Relation between metrics and quality

characteristics, such as maintainability– Relation between metrics and design

choices, good practices…

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

153/184

Quality Models

Feedback– Measures– Occurrences– Factors

to build “better” quality models

154/184

Quality Models

Feedback– Measures– Occurrences– Factors

to build “better” quality models

155/184

Agenda

Why?– Schema, Learning, and Patterns

How?– Developers, Social, and Code Studies

Challenges– Quality Models– Multi-language Systems

156/184

What’s with today’s systems?

157/184

158/184

159/184

160/184

161/184

162/184

163/184

164/184

165/184

166/184

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

168/184

Multi-language Systems

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

169/184

Multi-language Systems

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

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

171/184

Multi-language Systems

Different computational models

172/184

Multi-language Systems

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

}

173/184

Multi-language Systems

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 setjmp(…) or related calls!

174/184

Multi-language Systems

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!

No setjmp(…) or related calls!

175/184

What challenges?

176/184

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

177/184

Multi-language Systems

Maintainability– Quality models

• Metrics?• Relations?

– Patterns• “Border-line” practices?

– Social and developers studies• Independent variables?

178/184

Conclusion

179/184

180/184

181/184

182/184

183/184

Future directions

184/184

Multi-language system quality models

– Definition and modelling– Computation– Characterisation– Impact