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

3/126

Typical software developers?

5/126

Software costs?

8/126

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

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

10/126

11/126

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

http://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/

http://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

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

55/126

Good Practices


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

56/126

Good Practices


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

57/126

Good Practices


Figure



Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


Component

operation()

Leaf

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

Code

Model

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

Leaf

operation()

Composite


ramification


1..nClient

141/126


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

142/126

Goo

d Pr

actic

es –

Exam

ple Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


143/126

Goo

d Pr

actic

es –

Exam

ple Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


144/126


Micro-architecture ( )

Maintainability Understandability

Figure


145/126

Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


e-CP

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

146/126

Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


e-CP


147/126

Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


e-CP


148/126

Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


e-CP


149/126

Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


e-CP


Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

150/126

Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


e-CP


<< <<

Component

operation()

Leaf

operation()

Composite


ramification


1..nClient

151/126

Frame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


e-CP


<< <<

Component

operation()

Leaf

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