Quality and Multi-language Systems - Latece · Quality and Multi-language Systems LATÈCE UQÀM...

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

LATÈCEUQÀM

16/05/18

2/90

Short Bio.

� Born in France, Brittany, Nantes, 1975� Live in Montréal, Québec, Canada, 2003

� Full professor at Polytechnique Montréal � Invited professor at SNU and Yonsei U. in

Korea in 2013–2014

3/90

Short Bio.

� 1998: Engineering and “M.Sc.” degrees – École des Mines – Université de Nantes

– Title: Syntax Error-tolerant Java parser

– Focus on parsing, tool building, and Java

4/90

Short Bio.

� 2003: “Ph.D.” in computer science– École des Mines – Université de Nantes

– Title: A framework for the traceability of design motifs

– Focus on design patterns and reverse-engineering

5/90

Short Bio.

� Canada Research Chair

– 2009, on Software Patterns and Patterns of Software

– 2014, on Patterns in Mixed-language Systems

6/90

7/90

Five Main Directions

� Design patterns and their impact on code

� Design antipatterns and their impact on code

� Patterns and their impact on developers

� Identifier traces and their use to developers

� Feature identification and their traceability to requirements

8/90

Five Main Directions




� Identifier traces and their use to developers

� Feature identification and their traceability to requirements

9/90

Short Bio.


– Change proneness

– Kind of changes

Massimiliano Di Penta, Luigi Cerulo, Yann-Gaël Guéhéneuc, and Giuliano Antoniol.An Empirical Study of the Relationships between Design Pattern Roles and Class Change Proneness.Proceedings of the 24th International Conference on Software Maintenance (ICSM).September--October 2008. IEEE Computer Society Press.

10/90

Short Bio.


– Change proneness

– Fault proneness

Foutse Khomh, Massimiliano Di Penta, Yann-Gaël Guéhéneuc, and Giuliano Antoniol.An Exploratory Study of the Impact of Antipatterns on Class Change- and Fault-Proneness.Empirical Software Engineering (EMSE), 17(3):243--275, August 2012. Springer

11/90

Short Bio.


– Visual effort

– Developers’ characteristics

Zéphyrin Soh, Zohreh Sharafi, Bertrand van den Plas, Gerardo Cepeda Porras, Y.-G. Guéhéneuc, and G. Antoniol.Professional Status and Expertise for UML Class Diagram Comprehension: An Empirical Study. Proceedings of the 20th International Conference on Program Comprehension (ICPC), June 2012. IEEE Computer Society Press.

12/90

Software Development

13/90

More Information

� www.ptidej.net

� www.yann-gael.gueheneuc.net

14/90

Typical software developers?

Software costs?

15/90

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

16/90

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

17/90

Agenda

� Short Bio.� Quality

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

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

18/90

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

19/90

Quality

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

20/90

Quality

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

– Quality in use

21/90

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

22/90

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

23/90

Quality

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

24/90

Quality

� Definitions of internal quality characteristics– Maintainability

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

25/90

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

—IEEE Standard Glossary of Software Engineering Terminology, 2013

26/90

Maintainability

Quality Models Models

Good Practices Definition

Metrics

Detection Occurrences

Social Studies Characteristics

Developers Studies Behaviour

Factors

Measures

27/90

Maintainability



Metrics




Factors

Measures

28/90

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

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

29/90

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

30/90

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

31/90

Quality Models

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

• Theoretical• Practical

32/90

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)

33/90

Who needs models?

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

•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

34/90

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

– …

35/90

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

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

37/90

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

38/90

Quality Models

� Bansiya and Davis’ QMOOD

39/90

Quality Models

� Conclusions– Sound basis to measure different quality

characteristics

� Limits– Relation between metrics and characteristics– Relation between metrics and real phenomena– Considered inputs and levels of abstraction

40/90

Maintainability



Metrics




Factors

Measures

41/90

Practice, practiceand practice more

42/90

Good Practices

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

43/90

Good Practices

� Maintainers can follow good practices– SOLID– Design patterns

– Design antipatterns

– …

44/90

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)

45/90

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

46/90

Good Practices

47/90

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)

48/90

Good Practices

� Pattern solution = Motif which connotes anelegant architecture

49/90

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 components

component.operation()

1..nClient

50/90

Good Practices

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

51/90

Good Practices

� Contributions– Modeling and identification of structural design

patterns with DeMIMA– Modeling and identification of behavioural and

creational design patterns (more difficult)– Also use of bit-vector algorithms and metrics– Impact of design patterns on change proneness

52/90

Maintainability



Metrics




Factors

Measures

53/90

Social Studies

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

54/90

Agile programming,anyone?

55/90

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)

56/90

Social Studies

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

– Identifier quality [Lawrie]

– Developers’ gender and identifiers [Sharafi]

– …

57/90

Social Studies

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

– Identifier quality [Lawrie]

– Developers’ gender and identifiers [Sharafi]

– …

58/90

Social Studies

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

� Dependent variables

– Accuracy

– Time

– Effort

59/90

Social Studies

� Subjects

� Summary

Subjects’ Demography

(24 Subjects)

Academic background Gender

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

11 10 3 15 9

Accuracy Time Effort

60/90

Social Studies

� Conclusions– Software development is as much engineering

as it is creative craft• SEWBOK and other textbooks• From requirements to implementation

– Developers’ characteristics impact quality

61/90

Social Studies

� Contributions– Preferred source code entities– Impact of anti-patterns on understanding effort– Efficiency of graphical/textual representations– Program exploration strategies and effort– Gender, professional status, and expertise

62/90

Maintainability



Metrics




Factors

Measures

63/90

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

64/90

Developers Studies

� Studying developers’thought processes– Yarbus’ eye-movements

and vision studies– Just and Carpenter’s

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

65/90

Developers Studies

� Picking into developers’ thought processes

66/90

Developers Studies

� Picking into developers’ thought processes

67/90

Developers Studies

� Developers’ thought processes– Reading code– Reading design models

• Content• Form

– …

68/90

Developers Studies

� Developers’ thought processes– Reading code– Reading design models

• Content• Form

– …

69/90

Developers Studies

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

– Strongly textual [Dong et al.]

– Mixed [Vlissides]

70/90

Developers Studies

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

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

71/90

Developers Studies

� Subjects– 24 Ph.D. and M.Sc. students

� Summary– 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

72/90

Developers Studies

� Conclusions– Software development imposes a heavy load on

developers’ cognitive processes

– Understanding how developers understand software systems could help

• Building more effective representations• Building more effective tools

73/90

Developers Studies

� Contributions– Linguistic smells and identifier renamings– Identifier splitting and expansion– Concept extractions from traces– Requirements traceability– Feature location using execution scenarios and

information retrieval techniques

74/90

Feedback Loop

� Use– Measures– Occurrences– Factors

to build “better” quality models

75/90

Modeling formodeling's sake?

Aristotle384 BC–Mar 7, 322 BC

Galileo GalileiFeb 15, 1564–Jan 8, 1642

Usefulness?

Isaac NewtonDec 25, 1642–Mar 20, 1727

Max TegmarkMay 5, 1967–

76/90

Impact of Quality Models

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

– 2003• Quality team

77/90


� MQL– Dedicated measurement process

78/90


� MQL– Web-based reports

79/90


� 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

80/90


� Subjects– 44 systems

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

81/90


82/90


� Conclusions– Impact on all dependent variables – Statistical practical significance

� Limits– Applicability to today’s software systems

83/90

What’s with today’s systems?

84/90

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

85/90


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

86/90


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

87/90


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

88/90


� 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!

89/90

Conclusion

90/90

Future directions� Multi-language system quality characteristics

– Definition and modelling– Computation– Characterisation– Impact

91/90

92/90

Good Practices

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

93/90

Good Practices

� What motifs and what model for these motifs?

� What model for the program architecture?

� How to perform the identification?

94/90

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

95/90

Good Practices

� Multi-layer framework for design motif identification

� Information retrieval– Search space– Query– Results

96/90

Good Practices

� Multi-layer framework for design motif identification

Code

Model

Model +

Associations,

aggregations

Model +

Associations,

aggregations,

and composition

97/90

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

98/90

Good Practices – Example

� Design motif ( )

Component

operation()

Leaf

operation()

Composite

add(Component)

remove(Component)

getComponent(int)

operation()

ramification

For each components


1..nClient

99/90


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

100/90

Go

od

Pra

ctic

es –

Ex

amp

leFrame

DrawingEditor

Tool

Handle

Panel

DrawingView

Drawing

Figure

AbstractFigure


101/90


� Micro-architecture ( )

� Maintainability� Understandability

Figure


102/90

Component

operation()

Leaf

operation()

Composite

add(Component)

remove(Component)

getComponent(int)

operation()

ramification

For each components


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…⟩}

103/90

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…⟩}

�

<< <<

Component

operation()

Leaf

operation()

Composite

add(Component)

remove(Component)

getComponent(int)

operation()

ramification

For each components


1..nClient

104/90

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

Date post:	29-Apr-2018
Category:	Documents
Upload:	nguyenkiet
View:	213 times
Download:	0 times

Quality and Multi-language Systems - Latece · Quality and Multi-language Systems LATÈCE UQÀM...

Documents