Some Theory and Practice on Patterns Introduction Yann-Gal Guhneuc - - PowerPoint PPT Presentation

▶
some theory and practice on patterns introduction
SMART_READER_LITE
LIVE PREVIEW

Some Theory and Practice on Patterns Introduction Yann-Gal Guhneuc - - PowerPoint PPT Presentation

Sep 21, 2023 216 likes •1.79k views

Some Theory and Practice on Patterns Introduction Yann-Gal Guhneuc NII, Tokyo, Japan 12/02/14 This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported License 2/155 Typical software

slide-1
SLIDE 1

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, Japan 12/02/14

slide-2
SLIDE 2

2/155

slide-3
SLIDE 3

3/155

Typical software developers?

slide-4
SLIDE 4

4/155

slide-5
SLIDE 5

5/155

Software costs?

slide-6
SLIDE 6

6/155

slide-7
SLIDE 7

7/155

slide-8
SLIDE 8

8/155

Cost of bugs

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

slide-9
SLIDE 9

9/155

slide-10
SLIDE 10

10/155

slide-11
SLIDE 11

11/155

Cost of quality

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

slide-12
SLIDE 12

12/155

Agenda

 Quality  Maintainability

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

 Impact of Quality Models  Challenges with Multi-language Systems

slide-13
SLIDE 13

13/155

“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

slide-14
SLIDE 14

14/155

Quality

 Division of software quality according to

ISO/IEC 9126:2001, 25000:2005…

– Process quality – Product quality – Quality in use

http://www.sqa.net/iso9126.html

slide-15
SLIDE 15

15/155

Quality

 Division of software quality according to

ISO/IEC 9126:2001, 25000:2005…

– Process quality – Product quality – Quality in use

slide-16
SLIDE 16

16/155

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
slide-17
SLIDE 17

17/155

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
slide-18
SLIDE 18

18/155

Quality

 Definitions of internal quality characteristics

– Maintainability – Flexibility – Portability – Re-usability – Readability – Testability – Understandability

slide-19
SLIDE 19

19/155

Quality

 Definitions of internal quality characteristics

– Maintainability – Flexibility – Portability – Re-usability – Readability – Testability – Understandability

slide-20
SLIDE 20

20/155

“Maintainability is the ease with which a software system can be modified” —IEEE Standard Glossary of Software Engineering Terminology, 2013

slide-21
SLIDE 21

21/155

Maintainability Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour Factors Measures

slide-22
SLIDE 22

22/155

Maintainability Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour Factors Measures

slide-23
SLIDE 23

23/155

“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, 2009

slide-24
SLIDE 24

24/155

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

slide-25
SLIDE 25

25/155

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

slide-26
SLIDE 26

26/155

Quality Models

 Basis for quality models

– Software measures (aka metrics) – Relationships among characteristics and metrics

  • Theoretical
  • Practical
slide-27
SLIDE 27

27/155

Quality Models

 Metrics have been well researched

– Chidamber and Kemerer – Hitz and Montazeri – Lorenz and Kidd – McCabe – …

slide-28
SLIDE 28

28/155

Quality Models

 Typical kinds of metrics

– Size – Coupling – Cohesion

  • Briand et al.’s surveys on cohesion and coupling

– Complexity

Lionel C. Briand, John W. Daly, and Jürgen Wüst ; A Unified Framework for Cohesion Measurement in Object-OrientedSystems ; Journal of Empirical Software Engineering, 3(1), Springer, 1998 Lionel C. Briand, John W. Daly, and Jürgen Wüst ; A Unified Framework for Coupling Measurement in Object-Oriented Systems ; Transactions on Software Engineering, 25(1), IEEE Press, 1999

slide-29
SLIDE 29

29/155

Quality Models

 Typical metrics

– LOC, fan-in and fan-out – LCOM5 – CBO – McCabe’s complexity

 Typically computed automatically on source

code or other intermediate representations

slide-30
SLIDE 30

30/155

Quality Models

 Trend in computing metrics

– Motoral – Samsung – SNCF – …

 Dozens of tools

– PMD – Sonar – …

slide-31
SLIDE 31

31/155

slide-32
SLIDE 32

32/155

Who needs models?

slide-33
SLIDE 33

33/155

slide-34
SLIDE 34

34/155

  • 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
slide-35
SLIDE 35

35/155

slide-36
SLIDE 36

36/155

slide-37
SLIDE 37

37/155

Measures without models

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

slide-38
SLIDE 38

38/155

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
slide-39
SLIDE 39

39/155

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
slide-40
SLIDE 40

40/155

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

Tim Menzies, Member, IEEE, Jeremy Greenwald, and Art Frank ; Data Mining Static Code Attributes to Learn Defect Predictors ; Transactions on Software Engineering, 33(1), IEEE, 2007

slide-41
SLIDE 41

41/155

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)

http://nasa-softwaredefectdatasets.wikispaces.com/

slide-42
SLIDE 42

42/155

Quality Models

 Menzies et al.’s models

slide-43
SLIDE 43

43/155

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
slide-44
SLIDE 44

44/155

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
slide-45
SLIDE 45

45/155

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
slide-46
SLIDE 46

46/155

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 , Carl G. Davis ; A Hierarchical Model for Object-oriented Design Quality Assessment ; Transactions on Software Engineering, 28(1), IEEE, 2002

slide-47
SLIDE 47

47/155

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)

slide-48
SLIDE 48

48/155

Quality Models

 Bansiya and Davis’ QMOOD

slide-49
SLIDE 49

49/155

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

slide-50
SLIDE 50

50/155

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

slide-51
SLIDE 51

51/155

Quality Models

 Feedback

– Measures – Occurrences – Factors

to build “better” quality models

slide-52
SLIDE 52

52/155

Maintainability Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour Factors Measures

slide-53
SLIDE 53

53/155

slide-54
SLIDE 54

54/155

Practice, practice and practice more

slide-55
SLIDE 55

55/155

slide-56
SLIDE 56

56/155

Good Practices

 Maintainers can follow good practices

– SOLID – Design patterns – Design antipatterns – …

slide-57
SLIDE 57

57/155

Good Practices

 Maintainers can follow good practices

– SOLID – Design patterns – Design anti-patterns – …

slide-58
SLIDE 58

58/155

“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

  • ver, without ever doing it the

same way twice.” —Christopher Alexander, 1977

(With minor adaptations)

slide-59
SLIDE 59

59/155

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

slide-60
SLIDE 60

60/155

Good Practices

slide-61
SLIDE 61

61/155

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)

slide-62
SLIDE 62

62/155

Design Patterns

 Pattern solution = Motif which

connotes an elegant architecture

slide-63
SLIDE 63

63/155

Design Patterns

 Pattern solution = Motif which

connotes an elegant architecture

slide-64
SLIDE 64

64/155

Design Patterns

 Pattern solution = Motif which

connotes an elegant architecture

slide-65
SLIDE 65

65/155

Design Patterns

We can identify in the architecture

  • f a systems

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

Figure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

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

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure Component
  • peration()
Leaf
  • peration()
Composite add(Component) remove(Component) getComponent(int)
  • peration()
ramification For each components component.operation() 1..n Client
slide-66
SLIDE 66

66/155

Design Patterns

We can identify in the architecture

  • f a systems

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

Figure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

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

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure Component
  • peration()
Leaf
  • peration()
Composite add(Component) remove(Component) getComponent(int)
  • peration()
ramification For each components component.operation() 1..n Client
slide-67
SLIDE 67

67/155

Design Patterns

We can identify in the architecture

  • f a systems

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

Figure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

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

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure Component
  • peration()
Leaf
  • peration()
Composite add(Component) remove(Component) getComponent(int)
  • peration()
ramification For each components component.operation() 1..n Client
slide-68
SLIDE 68

68/155

Design Patterns

We can identify in the architecture

  • f a systems

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

Figure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure

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

Frame DrawingEditor Tool Handle Panel DrawingView Drawing Figure AbstractFigure CompositeFigure AttributeFigure PolyLineFigure DecoratorFigure Component
  • peration()
Leaf
  • peration()
Composite add(Component) remove(Component) getComponent(int)
  • peration()
ramification For each components component.operation() 1..n Client
slide-69
SLIDE 69

69/155

Design Patterns

 Conclusions

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

slide-70
SLIDE 70

70/155

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

slide-71
SLIDE 71

71/155

Design Anti-patterns

 Problem

– Problem recurring in object-oriented design

 Poor solution

– Initially may look like a good idea

 Alternative solution

– Repeatable (design pattern) – Effective

slide-72
SLIDE 72

72/155

Design Anti-patterns

 Negatively impact

– Fault proneness – Change proneness – Comprehension

slide-73
SLIDE 73

73/155

Design Anti-patterns

 Conclusions

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

slide-74
SLIDE 74

74/155

Good Practices

 Limits

– So many patterns – So many

  • Programming languages
  • Development contexts
  • Application domains
  • Expertises

 How to use their occurrences in a model?

slide-75
SLIDE 75

75/155

Maintainability Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour Factors Measures

slide-76
SLIDE 76

76/155

Social Studies

 Developers’ characteristics

– Gender – Status – Expertise – Training – Processes – …

slide-77
SLIDE 77

77/155

slide-78
SLIDE 78

78/155

Agile programming, anyone?

slide-79
SLIDE 79

79/155

slide-80
SLIDE 80

80/155

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)

slide-81
SLIDE 81

81/155

Social Studies

 For example, impact on identifiers on

program understandability

– Identifier styles [Sharif, Binkley] – Identifier quality [Lawrie] – Developers’ gender and identifiers [Sharafi] – …

slide-82
SLIDE 82

82/155

Social Studies

 For example, impact on identifiers on

program understandability

– Identifier styles [Sharif, Binkley] – Identifier quality [Lawrie] – Developers’ gender and identifiers [Sharafi] – …

Zohreh Sharafi, Zéphyrin Soh, Yann-Gaël Guéhéneuc, and Giuliano Antoniol ; Women & Men: Different but Equal – A Study on the Impact of Identifiers on Source Code Underestanding ; Proceeding of 20th International Conference on Program Comprehension, IEEE, 2012

slide-83
SLIDE 83

83/155

Social Studies

 Independent variables

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

 Dependent variables

– Accuracy – Time – Effort

slide-84
SLIDE 84

84/155

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

slide-85
SLIDE 85

85/155

Social Studies

 Importance  Limits

– Confounding factors – Actionable results?

slide-86
SLIDE 86

86/155

Maintainability Quality Models Models Good Practices Definition Metrics Detection Occurrences Social Studies Characteristics Developers Studies Behaviour Factors Measures

slide-87
SLIDE 87

87/155

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
slide-88
SLIDE 88

88/155

Developers Studies

 Studying developers’

thought processes

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

slide-89
SLIDE 89

89/155

Developers Studies

 Picking into developers’ thought processes

slide-90
SLIDE 90

90/155

Developers Studies

 Picking into developers’ thought processes

slide-91
SLIDE 91

91/155

Developers Studies

 Picking into developers’ thought processes

slide-92
SLIDE 92

92/155

Developers Studies

 Developers’ thought processes

– Reading code [Maletic] – Reading design models [Cepeda]

  • Content
  • Form

– …

slide-93
SLIDE 93

93/155

Developers Studies

 Developers’ thought processes

– Reading code – Reading design models [Cepeda]

  • 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

slide-94
SLIDE 94

94/155

Developers Studies

 Developers’ use of design pattern notations

during program understandability

– Strongly visual [Schauer and Keler] – Strongly textual [Dong et al.] – Mixed [Vlissides]

slide-95
SLIDE 95

95/155

Developers Studies

 Independent variables

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

 Dependent variables

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

slide-96
SLIDE 96

96/155

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

slide-97
SLIDE 97

97/155

Developers Studies

 Importance

– Understand – Do better

 Limits

– Confounding factors – Actionable results?

slide-98
SLIDE 98

98/155

Impact of Quality Models

 Usefulness of the feedback?  Usefulness of the models?

slide-99
SLIDE 99

99/155

Feedback?

 Trend to use more, diverse, unrelated

information as input of quality models

– Code source metrics – Historical metrics – Design metrics

slide-100
SLIDE 100

100/155

Feedback?

 Trend to use more, diverse, unrelated

information as input of quality models

– Code source metrics – Historical metrics – Design metrics – Good practices – Social studies – Developers’ studies

slide-101
SLIDE 101

101/155

slide-102
SLIDE 102

102/155

Modeling for modeling's sake?

slide-103
SLIDE 103

103/155

Aristotle

384 BC–Mar 7, 322 BC

slide-104
SLIDE 104

104/155

Aristotle

384 BC–Mar 7, 322 BC

Galileo Galilei

Feb 15, 1564–Jan 8, 1642

slide-105
SLIDE 105

105/155

Aristotle

384 BC–Mar 7, 322 BC

Galileo Galilei

Feb 15, 1564–Jan 8, 1642

Isaac Newton

Dec 25, 1642–Mar 20, 1727

slide-106
SLIDE 106

106/155

Aristotle

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–

slide-107
SLIDE 107

107/155

Aristotle

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–

slide-108
SLIDE 108

108/155

Usefulness?

 DSIV

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

  • Quality team

Houari Sahraoui, Lionel C. Briand, Yann-Gaël Guéhéneuc , and Olivier Beaurepaire ; Investigating the impact of a measurement program on software quality ; Journal of Information and Software Technology, 52(9), Elsevier, 2010

slide-109
SLIDE 109

109/155

Usefulness?

 MQL

– Dedicated measurement process

slide-110
SLIDE 110

110/155

Usefulness?

 MQL

– Web-based reports

slide-111
SLIDE 111

111/155

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

slide-112
SLIDE 112

112/155

Usefulness?

 Subjects

– 44 systems

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

113/155

Usefulness?

slide-114
SLIDE 114

114/155

Usefulness?

slide-115
SLIDE 115

115/155

Usefulness?

slide-116
SLIDE 116

116/155

Usefulness?

slide-117
SLIDE 117

117/155

Usefulness?

 Conclusions

– Impact on all dependent variables – Statistical practical significance

 Limits

– Applicability to today’s software systems

slide-118
SLIDE 118

118/155

slide-119
SLIDE 119

119/155

What’s with today’s systems?

slide-120
SLIDE 120

120/155

slide-121
SLIDE 121

121/155

slide-122
SLIDE 122

122/155

slide-123
SLIDE 123

123/155

slide-124
SLIDE 124

124/155

slide-125
SLIDE 125

125/155

slide-126
SLIDE 126

126/155

slide-127
SLIDE 127

127/155

slide-128
SLIDE 128

128/155

slide-129
SLIDE 129

129/155

slide-130
SLIDE 130

130/155

Multi-language Systems

 Today’s systems are multi-languages

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

slide-131
SLIDE 131

131/155

Multi-language Systems

 New problems

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

slide-132
SLIDE 132

132/155

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

slide-133
SLIDE 133

133/155

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

slide-134
SLIDE 134

134/155

Multi-language Systems

 Different computational models

slide-135
SLIDE 135

135/155

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

slide-136
SLIDE 136

136/155

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!

slide-137
SLIDE 137

137/155

slide-138
SLIDE 138

138/155

What challenges?

slide-139
SLIDE 139

139/155

Unbalanced focus on “mono”-language systems

  • vs. multi-language systems
slide-140
SLIDE 140

140/155

Challenges

 Maintainability

– Quality models

  • Metrics?
  • Relations?

– Good practices

  • “Border-line” practices?

– Social and developers’ studies

  • Independent variables?
slide-141
SLIDE 141

141/155

Challenges

 Not only for quality assurance!

(Just for examples…)

slide-142
SLIDE 142

142/155

Challenges

 Not only for quality assurance!

(Just for examples…)

Build systems descriptions

slide-143
SLIDE 143

143/155

Challenges

 Not only for quality assurance!

(Just for examples…)

Build systems descriptions Legal issues due to interrelations

slide-144
SLIDE 144

144/155

Challenges

 Not only for quality assurance!

(Just for examples…)

Clone definition and detection Build systems descriptions Legal issues due to interrelations

slide-145
SLIDE 145

145/155

Challenges

 Not only for quality assurance!

(Just for examples…)

Clone definition and detection Build systems descriptions Legal issues due to interrelations Impact on studies

  • f large systems
slide-146
SLIDE 146

146/155

slide-147
SLIDE 147

147/155

Conclusion

slide-148
SLIDE 148

148/155

slide-149
SLIDE 149

149/155

slide-150
SLIDE 150

150/155

slide-151
SLIDE 151

151/155

slide-152
SLIDE 152

152/155

Future directions

slide-153
SLIDE 153

153/155

slide-154
SLIDE 154

154/155

slide-155
SLIDE 155

155/155

 Multi-language system quality characteristics

– Definition and modelling – Computation – Characterisation – Impact