131014 yann-gael gueheneuc - quality, patterns, and multi-language systems

Yann-Gaël Guéhéneuc

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

ShareAlike 3.0 Unported License

Quality and Multi-language Systems

KAIST13/10/14

Typical software developers?

Software costs?

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

10/126

11/126

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

12/126

Agenda

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

Impact of Quality Models Challenges with Multi-language Systems

13/126

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

Quality

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

15/126

Quality

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

16/126

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

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

Quality

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

19/126

Quality

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

20/126

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

—IEEE Standard Glossary of Software Engineering Terminology, 2013

21/126

Maintainability

Quality Models Models

Good Practices Definition

Metrics

Detection Occurrences

Social Studies Characteristics

Developers Studies Behaviour

Factors

Measures

22/126

Maintainability

Metrics

Factors

Measures

23/126

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

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

24/126

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

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

Quality Models

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

• Theoretical• Practical

27/126

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

29/126

Who needs models?

30/126

31/126

•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

32/126

33/126

34/126

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

35/126

Quality Models

Different input metrics, different output characteristics– Bansiya and Davis’ QMOOD

• Design metrics• Maintainability-related characteristics

– Zimmermann et al.’s models• Code and historical metrics• Fault-proneness

– …

36/126

Quality Models

Different input metrics, different output characteristics– Bansiya and Davis’ QMOOD

• Design metrics• Maintainability-related characteristics

– Zimmermann et al.’s models• Code and historical metrics• Fault-proneness

– …

37/126

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

38/126

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

39/126

Quality Models

Bansiya and Davis’ QMOOD

40/126

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

41/126

Maintainability

Metrics

Factors

Measures

42/126

43/126

Practice, practiceand practice more

44/126

45/126

Good Practices

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

46/126

Good Practices

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

47/126

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)

48/126

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

49/126

Good Practices

50/126

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)

51/126

Good Practices

Pattern solution = Motif which connotes anelegant architecture

52/126

Good Practices

53/126

Good Practices

54/126

Good Practices

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

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

Component

operation()

Composite

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

ramification

For each componentscomponent.operation()

1..nClient

55/126

Good Practices

Figure

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

Component

operation()

Composite

ramification

1..nClient

56/126

Good Practices

Figure

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

Component

operation()

Composite

ramification

1..nClient

57/126

Good Practices

Figure

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

Component

operation()

Composite

ramification

1..nClient

58/126

Good Practices

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

59/126

Maintainability

Metrics

Factors

Measures

60/126

Social Studies

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

61/126

62/126

Agile programming,anyone?

63/126

64/126

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)

65/126

Social Studies

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

– Identifier quality [Lawrie]

– Developers’ gender and identifiers [Sharafi]

– …

66/126

Social Studies

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

– Identifier quality [Lawrie]

– Developers’ gender and identifiers [Sharafi]

– …

67/126

Social Studies

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

Dependent variables– Accuracy

– Time

– Effort

68/126

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

69/126

Maintainability

Metrics

Factors

Measures

70/126

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

71/126

Developers Studies

Studying developers’thought processes– Yarbus’ eye-movements

and vision studies– Just and Carpenter’s

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

72/126

Developers Studies

Picking into developers’ thought processes

73/126

Developers Studies

74/126

Developers Studies

75/126

Developers Studies

Developers’ thought processes– Reading code– Reading design models

• Content• Form

– …

76/126

Developers Studies

Developers’ thought processes– Reading code– Reading design models

• Content• Form

– …

77/126

Developers Studies

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

– Strongly textual [Dong et al.]

– Mixed [Vlissides]

78/126

Developers Studies

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

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

79/126

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

80/126

Feedback Loop

Use– Measures– Occurrences– Factors

to build “better” quality models

81/126

82/126

Modeling formodeling's sake?

83/126

Aristote384 BC–Mar 7, 322 BC

84/126

Galileo GalileiFeb 15, 1564–Jan 8, 1642

85/126

Isaac NewtonDec 25, 1642–Mar 20, 1727

86/126

Max TegmarkMay 5, 1967–

87/126

Usefulness?

Max TegmarkMay 5, 1967–

88/126

Impact of Quality Models

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

– 2003• Quality team

89/126

MQL– Dedicated measurement process

90/126

MQL– Web-based reports

91/126

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

92/126

Subjects– 44 systems

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

93/126

94/126

95/126

96/126

97/126

Conclusions– Impact on all dependent variables – Statistical practical significance

Limits– Applicability to today’s software systems

98/126

99/126

What’s with today’s systems?

100/126

101/126

102/126

103/126

104/126

105/126

106/126

107/126

108/126

109/126

110/126

Challenges with Multi-language Systems

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

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

111/126

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

112/126

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

113/126

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

114/126

Different computational models

115/126

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

116/126

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!

117/126

118/126

Conclusion

119/126

120/126

121/126

122/126

123/126

Future directions

124/126

125/126

126/126

Multi-language system quality characteristics

– Definition and modelling– Computation– Characterisation– Impact

127/126

128/126

Good Practices

Martin and Feather’s SOLID– Single responsibility– Open/closed– Liskov substitution– Interface segregation– Dependency inversion

129/126

Good Practices

What motifs and what model for these motifs?

What model for the program architecture?

How to perform the identification?

130/126

Good Practices

131/126

Good Practices

Design motifs and a motif meta-model

132/126

Good Practices

133/126

Good Practices

Design Meta-model

134/126

Good Practices

Design Meta-model

135/126

Good Practices

Design Meta-model

136/126

Good Practices

Design Meta-model

137/126

Good Practices

Multi-layer framework for design motif identification

Information retrieval– Search space– Query– Results

138/126

Good Practices

Multi-layer framework for design motif identification

Model + Associations, aggregations

Model + Associations, aggregations,

and composition

139/126

Good Practices

Constraint satisfaction problem solved with explanation-based constraint programming (e-CP) to obtain – No a priori descriptions of variations– Justification of the identified micro-architectures– Strong interaction with the developers

140/126

Good Practices – Example

Design motif ( )

Component

operation()

Composite

ramification

1..nClient

141/126

Example of JHotDraw– Erich Gamma and Thomas Eggenschwiler– 2D drawing– Design patterns

142/126

es –

ple Frame

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

143/126

es –

ple Frame

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

144/126

Micro-architecture ( )

Maintainability Understandability

Figure

145/126

Component

operation()

Composite

ramification

1..nClient

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

V = {component, leaf, composite}C = {leaf < component, composite < component, composite component}D = {DrawingEditor, DrawingView…}

146/126

Component

operation()

Composite

ramification

1..nClient

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

147/126

Component

operation()

Composite

ramification

1..nClient

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

148/126

Component

operation()

Composite

ramification

1..nClient

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

149/126

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

Component

operation()

Composite

ramification

1..nClient

150/126

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

Component

operation()

Composite

ramification

1..nClient

151/126

DrawingEditor

Handle

DrawingView

Drawing

Figure

AbstractFigure

Component

operation()

Composite

ramification

1..nClient

152/126

Good Practices

Search space can be very large and the efficiency in time of the search very low

Use metrics and topology to reduce the search space

131014 yann-gael gueheneuc - quality, patterns, and multi-language systems

Technology

discover gael

mooring components - gael force group

yann...

fine gael manifesto web

book gael leguirinec

131014 hobart city council agenda

songs of gael

young fine gael summer informer

daikin vrv catalog 131014

convocatoria atp ems 131014 (3)

fine gael summer newsletter

gael winds, fall 2012

the gael, fall 2011

cumann luthchleas gael cuman lúthchleas gael financial

gael product integrations

yann presentation

yann...

gael garcia bernal

gael force

clanna gael fontenoy coaching manual