Quality and Multi-language Systems Yann-Gal Guhneuc KAIST - - PowerPoint PPT Presentation

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

KAIST 13/10/14

2/126

3/126

Typical software developers?

4/126

5/126

Software costs?

6/126

7/126

8/126

Cost of bugs

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

9/126

10/126

11/126

Cost of quality

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

• r 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 Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour 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

• n 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 models

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 Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour Factors Measures

42/126

43/126

Practice, practice and 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

• ccurs 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

• ccurring 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 an elegant architecture

52/126

Good Practices

 Pattern solution = Motif which

connotes an elegant architecture

53/126

Good Practices

 Pattern solution = Motif which

connotes an elegant architecture

54/126

Good Practices

We can identify in the architecture

• f a systems

micro-architectures similar to design motifs to explain the problem solved

To compose objects in a tree-like structure to describe whole–part hierarchies

• peration()

• peration()

• peration()

55/126

Good Practices

We can identify in the architecture

• f a systems

micro-architectures similar to design motifs to explain the problem solved

To compose objects in a tree-like structure to describe whole–part hierarchies

• peration()

• peration()

• peration()

56/126

Good Practices

We can identify in the architecture

• f a systems

micro-architectures similar to design motifs to explain the problem solved

To compose objects in a tree-like structure to describe whole–part hierarchies

• peration()

• peration()

• peration()

57/126

Good Practices

We can identify in the architecture

• f a systems

micro-architectures similar to design motifs to explain the problem solved

To compose objects in a tree-like structure to describe whole–part hierarchies

• peration()

• peration()

• peration()

58/126

Good Practices

 Conclusions

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

59/126

Maintainability Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour 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

• f 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 Gender

Ph.D. M.Sc. B.Sc. Male Female

11 10 3 15 9

Accuracy Time Effort

69/126

Maintainability Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour 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

 Picking into developers’ thought processes

74/126

Developers Studies

 Picking into developers’ thought processes

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 for modeling's sake?

83/126

Aristote

384 BC–Mar 7, 322 BC

84/126

Aristote

384 BC–Mar 7, 322 BC

Galileo Galilei

Feb 15, 1564–Jan 8, 1642

85/126

Aristote

384 BC–Mar 7, 322 BC

Galileo Galilei

Feb 15, 1564–Jan 8, 1642

Isaac Newton

Dec 25, 1642–Mar 20, 1727

86/126

Aristote

384 BC–Mar 7, 322 BC

Galileo Galilei

Feb 15, 1564–Jan 8, 1642

Isaac Newton

Dec 25, 1642–Mar 20, 1727

Max Tegmark

May 5, 1967–

87/126

Aristote

384 BC–Mar 7, 322 BC

Galileo Galilei

Feb 15, 1564–Jan 8, 1642

Usefulness?

Isaac Newton

Dec 25, 1642–Mar 20, 1727

Max Tegmark

May 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

Impact of Quality Models

 MQL

– Dedicated measurement process

90/126

Impact of Quality Models

 MQL

– Web-based reports

91/126

Impact of Quality Models

 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

Impact of Quality Models

 Subjects

– 44 systems

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

93/126

Impact of Quality Models

94/126

Impact of Quality Models

95/126

Impact of Quality Models

96/126

Impact of Quality Models

97/126

Impact of Quality Models

 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

Challenges with Multi-language Systems

 New challenges

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

112/126

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

113/126

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

114/126

Challenges with Multi-language Systems

 Different computational models

115/126

Challenges with Multi-language Systems

 Different computational models

static 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

Challenges with Multi-language Systems

 Different computational models

static 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

 What motifs and what model for these

motifs?

 What model for the program architecture?  How to perform the identification?

131/126

Good Practices

 What motifs and what model for these

motifs?

 What model for the program architecture?  How to perform the identification?

Design motifs and a motif meta-model

132/126

Good Practices

 What motifs and what model for these

motifs?

 What model for the program architecture?  How to perform the identification?

Design motifs and a motif meta-model

133/126

Good Practices

 What motifs and what model for these

motifs?

 What model for the program architecture?  How to perform the identification?

Design Meta-model Design motifs and a motif meta-model

134/126

Good Practices

 What motifs and what model for these

motifs?

 What model for the program architecture?  How to perform the identification?

Design Meta-model Design motifs and a motif meta-model

135/126

Good Practices

 What motifs and what model for these

motifs?

 What model for the program architecture?  How to perform the identification?

Design Meta-model Design motifs and a motif meta-model

136/126

Good Practices

 What motifs and what model for these

motifs?

 What model for the program architecture?  How to perform the identification?

Design Meta-model Design motifs and a motif 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

• peration()

Leaf

• peration()

Composite

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

• peration()

ramification

For each components component.operation()

1..n Client

141/126

Good Practices – Example

 Example of JHotDraw

– Erich Gamma and Thomas Eggenschwiler – 2D drawing – Design patterns

142/126

Good Practices – Example

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

143/126

Good Practices – Example

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

144/126

Good Practices – Example

 Micro-architecture ( )  Maintainability  Understandability

Figure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

145/126

Component

• peration()

Leaf

• peration()

Composite

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

• peration()

ramification

For each components component.operation()

1..n Client

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

e-CP

V = {component, leaf, composite} C = {leaf < component, composite < component, composite component} D = {DrawingEditor, DrawingView…}

146/126

Component

• peration()

Leaf

• peration()

Composite

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

• peration()

ramification

For each components component.operation()

1..n Client

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

e-CP

V = {component, leaf, composite} C = {leaf < component, composite < component, composite component} D = {DrawingEditor, DrawingView…}

147/126

Component

• peration()

Leaf

• peration()

Composite

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

• peration()

ramification

For each components component.operation()

1..n Client

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

e-CP

V = {component, leaf, composite} C = {leaf < component, composite < component, composite component} D = {DrawingEditor, DrawingView…}

148/126

Component

• peration()

Leaf

• peration()

Composite

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

• peration()

ramification

For each components component.operation()

1..n Client

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

e-CP

V = {component, leaf, composite} C = {leaf < component, composite < component, composite component} D = {DrawingEditor, DrawingView…}

149/126

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

e-CP

V = {component, leaf, composite} C = {leaf < component, composite < component, composite component} D = {DrawingEditor, DrawingView…}

Component

• peration()

Leaf

• peration()

Composite

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

• peration()

ramification

For each components component.operation()

1..n Client

150/126

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

e-CP

V = {component, leaf, composite} C = {leaf < component, composite < component, composite component} D = {DrawingEditor, DrawingView…}



< < < <

Component

• peration()

Leaf

• peration()

Composite

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

• peration()

ramification

For each components component.operation()

1..n Client

151/126

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

e-CP

V = {component, leaf, composite} C = {leaf < component, composite < component, composite component} D = {DrawingEditor, DrawingView…}



< < < <

Component

• peration()

Leaf

• peration()

Composite

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

• peration()

ramification

For each components component.operation()

1..n Client

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