Quelques défis de la maintenance

1. 1
Département d’informatique et de recherche opérationnelle
Université de Montréal
Yann-Gaël Guéhéneuc
© Yann-Gaël Guéhéneuc 2004
Quelques défis de la
maintenance
Professeur adjoint
guehene@iro.umontreal.ca, local 2345
Séminaire du DIRO – 2004/04/01
Bonjour à tous…

2. 2
2/50
Résumé
n Défis actuels de la maintenance
– Visualisation de l’architecture
– Identification des choix de conception
– Évaluation de la qualité
– Restructuration
automatiques…
n Nos propositions
– Plus de questions que de réponses !
Dans cette présentation, je vais parler de quatre défis de la maintenance des
programmes : la visualisation de l’architecture, l’identification des choix de
conception, l’évaluation de la qualité et la restructuration automatiques de
programmes.
Je vais d’abord motiver les raisons pour lesquels je m’intéresseà ces quatre
points. Ensuite, je développerais nos solutions qui apportent quelques réponses
dans les cas de la visualisation et de l’identification des choix de conception et
nos questions pour l’évaluation de la qualité et la restructuration de
programmes. Je conclurais avec des questions ouvertes. Cette présentation est
volontairement prospective, aussi n’hésitez pas à m’interrompre.
Avec cette présentation, je voudrais vous montrer l’importance et la difficulté
de la maintenance des programmes et discuter avec vous des défis à relever et
d’approches pour les surmonter qui sont très souvent multi-disciplinaires.
À la fin de chaque partie, je présenterais des questions ouvertes, des questions
pour lesquelles il n’existe pas encore de réponse claire et peut-être pourrons-
nous alors en discuter.

3. 3
3/50
Contexte (1/3)
n Qui a déjà dû expliquer l’architecture
d’un programme à objets de plus de
sept [Mil56] classes ?
n Qui a déjà dû comprendre l’architecture
d’un programme à objets de plus de
sept classes ?
Le contexte de nos recherches sur la maintenance des programmes est assez
simple, il se résume en deux questions…
Expliquer l’architecture d’un programme, c’est expliquer les choix de
conception explicites ou implicites fait lors de la conception et de
l’implantation du programme. Les choix de conception justifient l’existence
des classes, lors organisation et l’attribution des responsabilités à leurs
instances.
Comprendre l’architecture d’un programme, c’est identifier les choix de
conception explicites et implicites pris lors de la conception et de
l’implantation. Ces choix de conception aident à comprendre le
fonctionnement du programme, à juger de sa flexibilité et à évaluer sa qualité,
indépendamment de l’implantation stricte des algorithmes. La compréhension
de l’architecture est donc très importante pour comprendre et évaluer le
programme.
Le chiffre sept est un peu un chiffre magique, Miller et d’autres auteurs en
sciences cognitives ont montré que sept est plus ou moins (suivant les
individus) le nombre maximal d’éléments qu’une personne peut garder en
mémoire simultanément.

4. 4
4/50
Contexte (2/3)
n Qui a déjà eu des problèmes pour
– Comprendre
– Évaluer
l’architecture d’un programme ?
– Choix de conception
pour finalement découvrir comment le
programme marche vraiment et
– Restructurer
Les activités de compréhension, d’explication et d’évaluation de l’architecture
de programme sont difficiles. En particulier l’architecture d’un programme est
souvent (toujours) réalisée sur la base de choix de conception plus ou moins
implicites, qu’il est difficile d’identifier juste en lisant le code source du
programme.
Il faut alors parcourir le code source pour se former une image mentale de
l’architecture du programme, image qui sera modifiée et adaptée au fur et à
mesure de la lecture du code source et au fur et à mesure que la compréhension
des tenants et aboutissants se complète.
C’est en cela que nous pensons que l’identification des choix de conception est
importante. En effet, l’identification automatique des choix de conception
permettrait de faciliter la compréhension, l’explication et l’évaluation des
programmes.

5. 5
5/50
Contexte (3/3)
n Les mainteneurs passent au moins 75%
[Sha96] de leur temps à lire et à comprendre
les programmes
n La maintenance représente au moins
50% [Ric99] du coût total de développement
L’identification des choix de conception est d’autant plus importante lorsqu’on
considère les coûts de la maintenance. En particulier, la plupart des études
montrent que la maintenance représente au moins la moitié des coûts de
développement et que les trois quart du temps de maintenance est passé à
comprendre le code source des programmes.

6. 6
6/50
Motivations
n Proposer des outils automatique pour
– Identifier les choix de conception
– Évaluer l’architecture
– Restructurer l’architecture
des programmes
Ø Faciliter la compréhension
Ø Réduire les coûts de maintenance
Nous voulons donc proposer des outils automatiques pour identifier les choix
de conception, évaluer et restructurer l’architecture des programmes.
Les programmes doivent être automatiques parce que les programmes à
maintenir sont généralement de grandes tailles, avec de nombreuses classes, de
nombreuses bibliothèques de classes. En cela, nous nous plaçons délibérément
dans le cadre du génie logiciel automatique et expérimental. Au delà de la
théorie, nous voulons apporter une aide concrète aux mainteneurs et nous
assurer que nous aidons vraiment (expérimentalement) les mainteneurs.
D’abord, nous voulons identifier les choix de conception pris lors de la
conception et de l’implantation des programmes pour aider à la compréhension
de l’architecture.
Ensuite, nous voulons proposer des moyens automatiques d’évaluer
l’architecture des programmes, c’est-à-dire d’évaluer l’architecture des
programmes par rapport à des caractéristiques de qualité bien définies et
révélatrices.
Enfin, nous voulons aider à la restructuration automatique de l’architecture des
programmes. La restructuration est aussi un moyen d’aider à la
compréhension. D’une part, elle permet d’améliorer l’architecture et de rendre
plus explicite les choix de conception. D’autre part, elle permet aux
mainteneurs de se familiariser avec l’architecture du programme et son code
source, de vérifier des hypothèses sur le fonctionnement du programme.
Ainsi, identifier les choix de conception, évaluer la qualité architecturale et
restructurer l’architecture facilitent la compréhension des programmes et
permettent à terme de réduire les coûts de la maintenance.

7. 7
7/50
Exemple fil conducteur (1/9)
n Un programme de sept classes
n Trois tâches de maintenance
– Comprendre l’architecture
– Évaluer l’architecture
– Restructurer l’architecture
• (Flexibilité)
Avant de détailler les défis rencontrer et à surmonter pour pouvoir offrir des
outils automatique d’identification, d’évaluation et de restructuration, je vais
vous présenter un simple exemple, un programme de sept classes que nous
allons essayer de comprendre, d’évaluer l’architecture et de restructurer (pour
comprendre et pour améliorer sa flexibilité).

8. 8
8/50
Exemple fil conducteur (2/9)
n Exécution de programme
Hypothèse que le problème peut s’exécuter
Hypothèse que l’exécution contrôlée du
programme est possible
0: Introduction
We present a new approach...
1: Motivations
Maintainance is important...
...50% of overall devleopment cost...
...understanding ... 75% of maintainance...
2: Our approach
...
!ê
!ê
Nous faisons deux hypothèses fortes, que le programme peut s’exécuter et que
l’exécution contrôlé du programme est possible. Exécution contrôlée veut dire
que le programme peut être exécuter indépendamment du reste, qu’il ne fait
pas d’effets de bords irréversibles dans des bases de données.
Nous exécutons le programme et sa sortie est reproduite ici… Il semble que le
programme imprime dans la console un article…

9. 9
9/50
Exemple fil conducteur (3/9)
package ptidej.example.composite6;
public class Main {
public static void main(final String[] args) {
final Document document = new Document();
document.addElement(
new Title("Introduction"));
document.addElement(
new Paragraph("We present a new approach..."));
document.addElement(
new Title("Motivations"));
document.addElement(
new Paragraph("Maintainance is important..."));
document.addElement(
new IndentedParagraph("...50% of overall devleopment cost..."));
document.addElement(
new IndentedParagraph("...understanding ... 75% of maintainance..."));
document.addElement(
new Title("Our approach"));
document.addElement(
new Paragraph("..."));
document.printAll();
}
}
Nous lisons maintenant le code source de la classe définissant une méthode
main(). On voit ici que, effectivement, le programme permet de décriredes
documents. Un document est instancié puis des éléments lui sont rajoutés : des
titres, des paragraphes, des paragraphes indentés. Finalement, le document
créé est imprimé dans la console. Nous avons de la chance que les classes et
les méthodes du programme portent des noms assez révélateurs.

10. 10
10/50
Exemple fil conducteur (4/9)
package ptidej.example.composite6;
public abstract class AbstractDocument {
public void print() {
System.out.println(this.getClass());
}
}
package ptidej.example.composite6;
public class IndentedParagraph extends Paragraph {
public IndentedParagraph(final String aText) {
super(aText);
}
public void print() {
System.out.print("tt");
System.out.println(this.getText());
}
}
Le programme est composé ensuite d’une classe abstract
AbstractDocument qui définit une méthode print(). La classe
IndentedParagraph, quant à elle, étend une classe Paragraph et
redéfinit la méthode print().

11. 11
11/50
Exemple fil conducteur (5/9)
package ptidej.example.composite6;
public class Paragraph extends Element {
public Paragraph(final String aText) {
super(aText);
}
public void print() {
System.out.print('t');
System.out.println(this.getText());
}
}
package ptidej.example.composite6;
public class Title extends Element {
private static int titleNumber = 0;
public Title(final String aText) {
super(aText);
}
public void print() {
System.out.print(titleNumber++);
System.out.print(": ");
System.out.println(this.getText());
}
}
La classe Paragraph étend une classe Element et redéfinit également la
méthode print(). La classe Titre est similaire à la classe Paragraph.
Elle définit en plus une variable de classe pour numéroter les titres.

12. 12
12/50
Exemple fil conducteur (6/9)
package ptidej.example.composite6;
import java.util.Vector;
public class Document {
private Vector elements = new Vector();
public void addElement(final Element e) {
this.elements.add(e);
}
public Element getElement(final int pos) {
return (Element) this.elements.get(pos);
}
public void printAll() {
for (int i = 0; i < this.elements.size(); i++) {
((Element) elements.get(i)).print();
}
}
public Element removeElement(final Element e) {
this.elements.remove(e);
return e;
}
}
La classe Document définit une variable d’instances de type Vector, dans
laquelle sont stockés les éléments ajoutés. La méthode printAll() réalise
bien, comme attendu, l’impression dans la console des différents éléments.

13. 13
13/50
Exemple fil conducteur (7/9)
package ptidej.example.composite6;
public abstract class Element extends AbstractDocument {
private StringBuffer text = new StringBuffer();
public Element(final String aText) {
this.addText(aText);
}
public void setText(final String aText) {
this.removeText();
this.addText(aText);
}
public void addText(final String aText) {
this.text.append(aText);
}
public String getText() {
return this.text.toString();
}
public void removeText() {
this.text.setLength(0);
}
public void print() {
System.out.println(this.getText());
}
}
Enfin, la classe Element définit un tampon dans lequel est mémorisé un
texte. Elle propose aussi toutes les méthodes nécessaires à la gestion du
tampon.

14. 14
14/50
Exemple fil conducteur (8/9)
n Comprendre l’architecture
– À quoi sert AbstractDocument ?
– De quoi est composé un Document ?
n Évaluer l’architecture
– Quels sont ses défauts ? Ses qualités ?
n Restructurer l’architecture
– Que faut-il changer ?
– Comment le changer ?
Très bien, maintenant, qui pourrait me dire à quoi sert la classe
AbstractDocument ? De quoi un document est-il composé ? Qui pourrait
proposer une évaluation de l’architecture du programme ? Si l’architecture
devait être restructurée, que faudrait-il changer, comment le changer ?
Toutes ces questions, comme vous pouvez le voir, ne sont pasfaciles à
répondre. Pourtant le programme ne fait que sept classes et une centaine de
lignes de code source pas trop (trop) mal écrit. Dans le cas de programmes
beaucoup plus gros, ces questions deviennent vraiment difficiles à répondre.

15. 15
15/50
Exemple fil conducteur (9/9)
n Nos besoins
– Représentation abstraite, synthétique de
l’architecture du programme
– Identification des choix de conception et
les expliquer
– Évaluation de la qualité architecturale,
quantitative et qualitative
– Restructuration de l’architecture, impact
syntaxique et sémantique
Aussi, avons nous besoin de moyens pour abstraire l’architecturedu
programme, pour y identifier des choix de conception et les expliquer, pour
évaluer la qualité architecturale quantitativement et qualitativement et pour la
restructurer en prenant garde à l’impact syntaxique et sémantique des
restructurations.
Voici les quelques défis de la maintenance des programmes que nous essayons
de surmonter. Il est facile de voir que l’importance de ces défis est non-
négligeable à partir de l’exemple précédent.
Nous avons besoin d’une vue abstraite de l’architecture pour répondre à des
questions telles que « À quoi sert la classe AbstractDocument ? ». Nous
avons besoin de moyens automatiques pour identifier les choix de conception
pour répondre à des questions telle que « Que peut contenir un document ? » et
pour évaluer qualitativement l’architecture des programmes. Nous avons
besoin de moyens automatiques pour évaluer quantitativement l’architecture,
également. Enfin, nous avons besoins de moyens pour restructurer
l’architecture du programme tout en prenant garde à l’impact syntaxique et
sémantique des modifications.

16. 16
16/50
L’approche poursuivie…
n Le projet Ptidej
– Pattern Trace Identification, Detection, and
Enhancement in Java
– Historiquement
• Identification de défauts de conception
• Correction des défauts de conception
« It is hard to solve any very complicated problem without giving
essentially full attention, at different times, to different sub-problems »
Marvin Minsky [Min74]
Notre approche pour apporter des réponses aux défis précédents vient
historiquement de nos travaux sur l’identification et la correction des défauts
de conception. Nous continuons le projet Ptidej dont le but est d’offrir des
outils pour automatiquement identifier des motifs de conception et des défauts
de conception et restructurer l’architecture des programmes.

17. 17
17/50
Défi 1 : visualisation (1/9)
n Modèle pour l’architecture des
programmes
– Comment décrire les données
représentant l’architecture ?
– Quelles données décrire ?
n Visualisation de l’architecture
– UML (de facto standard) ?
– Mise en page de la représentation
graphique ?
Le premier défi concerne la visualisation de l’architecture des programmes…
En particulier, la notation UML est devenu un standard de facto, ce n’est pas
tout à fait un hasard car cette notation est l’héritière d’une longue lignée de
notation et de méthode de conception et elle est suffisamment souple pour
s’adapter à toute sorte d’utilisation. Aussi, nous nous préoccupons de la mise
en page graphique des diagrammes de classes UML, car à notre connaissance
seuls quelques outils proposent des algorithmes de mise en page pour les
diagrammes de classes UML et ces algorithmes ne sont pas encore entièrement
satisfaisants.

18. 18
18/50
Défi 1 : visualisation (2/9)
n Métamodèle
– Ensemble de classes dont les instances
décrivent des constituants de l’architecture
– À comparer avec l’approche par réseaux
[Jah97], par prédicats Prolog [Wuy98]
n PADL
– Pattern and Abstract-level Description
Language
Pour visualiser l’architecture des programmes, nous proposons d’abord un
métamodèle pour décrire l’architecture des programmes. Ce métamodèle,
PADL, défini un ensemble de classes, dont les instances décrivent
l’architecture. L’intérêt de la métamodélisation sur d’autres approches est que
les modèles issus du métamodèle sont des entités de premières classes dans les
programmes qui les utilisent, ils peuvent donc est facilement manipulés
(ajout/retrait d’instances représentant des classes, des interfaces, des relations,
parcours des modèles).

19. 19
19/50
Défi 1 : visualisation (3/9)
n Constituants d’un diagramme de
classes UML
– Attributs, opérations, méthodes
– Classes, classes incluses, types, classes
d’implantation, interfaces, classes
paramétriques, classes liées, métaclasses,
powertype, type de données,
énumérations, classes utilitaires
Ensuite, nous devons définir les données que nous voulons décrire par la
métamodélisation. Les constituants d’un diagramme de classe UML (d’un
modèle UML) sont d’abord les attributs, les opérations et les méthodes. Il y a
ensuite de nombreux Classifiers.

20. 20
20/50
Défi 1 : visualisation (4/9)
n Autres constituants d’un diagramme de
classes UML
– Relations entre classes
• Utilisations
• Associations
• Associations n-aires
• Multiplicité, qualificateur, classe d’association
– Paquetages, noms qualifiés, éléments
dérivés, stéréotypes
• Agrégation
• Composition
• Généralisation
Enfin, il y a différentes relations entre Classifiers et divers constituants
utilitaires.

21. 21
21/50
Défi 1 : visualisation (5/9)
n Problème avec UML
– Pas de définitions claires
– Pas de définitions opérationnelles
Ø Étude systématique des constituants et
correspondance avec les constructions
de langages de programmation [Gué04]
Le problème avec tous ces constituants est leur manque de définitions claires
et opérationnelles. Les versions successives des spécifications UML raffinent
peu à peu les définitions des constituants mais n’explicitent toujours pas
clairement ce à quoi correspondent vraiment les constituants dans des langages
de programmation. Aussi, nous avons proposé une étude systématique des
constituants des diagrammes de classes UML avec des constructions des
langages de programmation C++, Java et Smalltalk.

22. 22
22/50
Défi 1 : visualisation (6/9)nPtidejUIViewer
À partir de cette correspondance entre constituants UML et constructions dans
des langages de programmation, nous avons développé un programme qui
permet d’obtenir un modèle de l’architecture des programmes avec les
constituants d’UML. Sur cette copie d’écran, vous pouvez voir le modèle de
l’architecture du programme présenté précédemment. La représentation
graphique ne suit pas tout à fait les spécifications UML mais l’essentiel est que
le modèle de l’architecture représente tous les constituants UML du code
source du programme.
Avec cette représentation, nous pouvons répondre aux questions sur le rôle de
la classe AbstractDocument et sur ce que contient un document…

23. 23
23/50
Défi 1 : visualisation (7/9)
n Modèle pour l’architecture des
programmes
– Comment décrire les données
représentant l’architecture ?
– Quelles données décrire ?
n Visualisation de l’architecture
– UML (de facto standard) ?
– Mise en page de la représentation
graphique ?
Métamodélisation
Étude
systématique
Heuristiques
Ainsi, notre proposition pour représenter l’architecture des programmes
s’articulent autour de…

24. 24
24/50
Défi 1 : visualisation (8/9)
n Questions ouvertes
– Données nécessaires pour les tâches de
maintenance ?
– Passage à l’échelle des modèles issus du
métamodèle ?
– Définitions des constituants UML ?
– Mise en page des représentations UML ?
– Autres techniques de représentation ?
Même si cette approche semble prometteuse, il reste encore beaucoup de
question ouverte. Les modèles de l’architecture des programmes obtenus sont-
ils pertinents pour les tâches de maintenance ? Les modèles issus de notre
métamodèle prennent de la place en mémoire, comment faire pour réduire
l’espace mémoire utiliser et assurer le passage à l’échelle ? Les définitions des
constituants UML sont-elles correctes dans tous les cas ? Comment
automatiser la mise en page des représentation des modèles, quelque soit la
taille des modèles ? Comment pourrions-nous appliquer des techniques de
traitement des langues naturelles pour enrichir ou raffiner les modèles obtenus
? Quelles techniques d’analyses statiques plus performantes nous permettraient
d’obtenir des données plus précise ?

25. 25
25/50
Défi 1 : visualisation (9/9)
n Directions de recherche
– Traitement des langues naturelles pour
enrichir les données dans les modèles
– Analyses de flots pour la relation de
composition
– Programmation par contraintes pour la
mise en page des représentations UML
– Représentation par matrices d’adjacences
Nous proposons ces directions de recherche pour répondre aux questions
précédentes sur la visualisation de l’architecture des programmes.
Nous considérons utiliser des algorithmes de traitement du langage naturel
pour enrichir les données disponibles dans les modèles. Par exemple, l’analyse
des noms de classes, de méthodes, de champs, des commentaires, pourraient
aider à résoudre des ambiguïtés sur les relations existantes vraiment entre deux
classes. (Philippe Langlais)
Nous allons essayer de développer des analyses statiques de flots pour raffiner
l’identification des relations entre classes, en particulier pour identifier
statiquement les propriétés dynamiques (partage et durée de vie) de la relation
de composition. (Stefan Monnier)
Nous voulons appliquer des algorithmes de résolutions de contraintes pour
mettre en page les représentations UML des modèle de l’architecture. Les
variables sont les coordonnées dans un plan des constituants d’un modèle, les
contraintes sont les contraintes de position entre constituant (une super-classe
doit être au-dessus de sa sous-classe…) et le domaine des variables est
l’ensemble des coordonnées possible dans un plan pour un constituant.

26. 26
26/50
Défi 2 : choix de conception (1/8)
n Choix de conception
– Décisions architecturales qui répondent à
un besoin (usager, technique…)
n Identification automatique
– Découverte ?
– Modélisation ?
– Catalogue ?
– Formes dégradées ?
Le deuxième défi concerne les choix de conception. Un choix de conception
est en général une décision architecturale qui répond à un besoin (usager,
technique). Comment identifier ces choix automatiquement ? Est-il d’abord
possible de découvrir ces choix sans autres formes de modélisation ? À ma
connaissance, personne n’a encore tenté de répondre à cette question. Il s’agit
d’un problème à la fois théorique, comment découvrir un choix de conception
en l’absence de toutes données sur les choix possibles et pratique, est-il
possible d’automatiser cette découverte ? D’un autre côté, comment modéliser
des choix de conception, quel catalogue utiliser et comment gérer les formes
dégradées. Les formes dégradées sont particulièrement importantes car les
choix de conception sont toujours adaptés au contexte du programme et ne se
retrouvent donc pas tels quelsdans l’architecture des programmes.

27. 27
27/50
Défi 2 : choix de conception (2/8)
n Catalogue
– Design Patterns, par Gamma et al. [Gam94]
n Métamodèle
– PADL
– À comparer avec l’approche par graphe
[See98], par prédicats Prolog [Wuy98]
Comme catalogue de choix de conception, nous utilisons le livres Design
Patterns, qui introduit 23 patrons de conception qui décrivent des choix de
conception généraux. Nous modélisons les motifs de conception qui représente
la partie solution des patrons de conception.
Pour décrire les choix de conception, nous utilisons la même approche que
pour décrire l’architecture des programmes. Cette approche est plus
intéressante sous certains aspects que d’autres approches basées sur les
mathématiques ou sur des prédicats Prolog. D’une part, les modèles sont là
aussi manipulable directement de manière programmatique. Mais en plus, ces
modèles sont décrit avec le même formalisme que l’architecture. Il est ainsi
possible d’appliquer aux modèles de conception les mêmes outils qu’aux
modèles d’architecture (visualisation, sérialisation…).

28. 28
28/50
Défi 2 : choix de conception (3/8)
n Programmation par contraintes avec
explications (PPaE) [Jus01]
– Modèle d’un motif de conception →
Variables et contraintes
– Modèle de l’architecture d’un programme
→ Domaine des variables
– Explications, relaxation dynamique des
contraintes et du problème
Nous utilisons la programmation par contraintes avec explications pour
identifier des choix de conception dans l’architecture de programmes. Pour
cela, nous traduisons le modèle d’un motif de conception (représenté par une
instance du métamodèle PADL) sous la forme d’un système de contraintes
(variables = classes, contraintes = relations entre classes). Nous traduisons le
modèle de l’architecture d’un programme (représenté par une instance du
métamodèle PADL) en un domaine pour les variables du système de
contraintes. Nous obtenons ainsi un problème de satisfaction de contraintes
dont les solutions seront les Classifiers de l’architecture du programme
qui satisfont les relations préconisé par un motif de conception. La
programmation par contraintes avec explications nous permet d’obtenir des
solutions dégradées par relaxation dynamique de contraintes et du problème.

29. 29
29/50
Défi 2 : choix de conception (4/8)
n PPaE
– Explications
• Plus de solutions
• Contraintes impossibles à satisfaire
– Relaxation des contraintes et du problème
• Remplacer les contraintes par des contraintes
sémantiquement moins fortes
• Retirer les contraintes du problème
– À comparer à l’approche par logique floue
[Jah97], par unification Prolog [Wuy98]
Pour cela, lorsque le solveur de contraintes ne peut trouver de solutions (plus
ou pas), une explication est créée qui contient un sous-ensemble des
contraintes impossibles à satisfaire. Nous remplaçons alors ces contraintes par
des contraintes sémantiquement moins fortes (par exemple, nous remplaçons
une relation de composition par une relation d’agrégation) ou nous retirons ces
contraintes du problème. Cette approche est plus intéressante que des
approches par logique floue ou par unification logique grâce aux explications.

30. 30
30/50
Défi 2 : choix de conception (5/8)nPtidejSolver+
PtidejUIViewer
Par exemple, l’identification des micro-architectures similaires au motif de
conception Composite dans l’architecture du programme précédent donne
comme résultat…
Ainsi, nous pouvons préciser notre réponse sur ce que contient un document et
commencer à répondre à la question de la qualité (évaluation) de
l’architecture…

31. 31
31/50
Défi 2 : choix de conception (6/8)
n Choix de conception
– Décisions architecturales qui répondent à
un besoin (usager, technique…)
n Identification automatique
– Découverte
– Modélisation
– Catalogue
– Formes dégradées
Difficile !
Métamodélisation
Design Patterns
PPaE
Pour résumer, voici les réponses que nous apportons au défi de l’identification
des choix de conception…
Mais notre approche est limitée à l’identification de la structure des motifs de
conception.

32. 32
32/50
Défi 2 : choix de conception (7/8)
n Qualité, pertinence des choix de
conception identifiées ?
n Défauts de conception ?
n Données nécessaires à l’identification
de choix de conception ?
n Idiomes de programmation, patrons de
conception architecturaux ?
Il reste encore de nombreuses questions ouvertes quant à l’identification des
choix de conception. Il existe différents «niveaux » de patrons de conception,
les idiomes, les patrons architecturaux, les patrons de sécurité… Comment
rendre compte de leur diversité. Comment ne pas limiter l’identification à la
partie structurelle des motifs de conception ? Comment décrire les défauts de
conception, quels défauts de conception ? Toutes les données nécessaires à
l’identification des motifs de conception sont elles présentes dans les modèles
de l’architecture des programmes ? Comment juger de la pertinence des choix
de conception ?

33. 33
33/50
Défi 2 : choix de conception (8/8)
n Directions de recherche
– Expérimentation pour évaluer la qualité et
la pertinence des choix de conception
– Impact cognitif de l’identification des choix
de conception
– Ajout de données quantitative (métriques)
pour améliorer la qualité, réduire l’espace
de recherche
– Autres techniques (homomorphismes…)

34. 34
34/50
Défi 3 : évaluation (1/7)
n Évaluation quantitative de la qualité
architecturale
– Caractéristiques ?
– Facteurs ?
– Métriques ?
– Automatisation ?
– Pertinence ?
L’évaluation quantitative de la qualité architecturale met en jeu des modèles
prédictifs de qualité. Ces modèles définissent des caractéristiques de qualité,
décomposé en facteur de qualité, eux-mêmes évalués par des métriques.
Certaines caractéristiques de qualité ne sont pas aisément automatisable, par
exemple lorsqu’elles concernent les interaction avec les utilisateurs et d’autres
ne sont pertinentes quand dans des cas restreints. Aussi, l’évaluation
quantitative de la qualité architecturale n’est pas encore aujourd’hui possible
facilement.

35. 35
35/50
Défi 3 : évaluation (2/7)
n Caractéristiques de qualité
– Fonctionnalité
– Fiabilité
– Utilisabilité
– Maintenabilité
– Efficacité
– …
Voici quelques caractéristique de qualité parmi les plus connues…

36. 36
36/50
Défi 3 : évaluation (3/7)
n Facteurs de qualité
– …
– Maintenabilité
• Analysabilité
• Changeabilité
• Stabilité
• Testabilité
– …
Ces caractéristiques de qualité se décompose en facteur de qualité, aussi
appelé sous-caractéristiques de qualité. Par exemple, la maintenabilité se
décompose en analysabilité, changeabilité, stabilité et testabilité. Cette
décomposition n’est pas unique et varie suivant les auteurs ou les normes (par
exemple, IEEE, ISO…).

37. 37
37/50
Défi 3 : évaluation (4/7)
n Métriques
– DIT (Depth of Inheritance Tree)
– WMC (Weighted Method Count)
– LCOM (Lack of Cohesion in Methods)
– Iv (design complexity)
– PR6 (Problem Reports in 6 months)
– …
– Plus de 200 métriques dans la littérature !
Quant aux métriques utilisées pour définir les facteurs de qualité, elles sont
très nombreuses, parfois assez mal définies, souvent dépendantes du langage
de programmation et pas tout le temps automatisable (par exemple PR6, le
nombre de rapport de problème en six derniers mois).

38. 38
38/50
Défi 3 : évaluation (5/7)nPtidejUIViewer+
POM
Pourtant, nous avons commencé à implanter des métriques dans notre outil. À
partir d’une idée de Houari, nous avons implanté un ensemble de métriques
pour les programmes orientés objets (celles de Chidamber et Kemerer).
Ces valeurs telles que ne nous permettent pas encore d’évaluer
quantitativement la qualité de l’architecture du programme…

39. 39
39/50
Défi 3 : évaluation (6/7)
n Définitions consensuelles
– Caractéristiques ?
– Facteurs ?
– Métriques ?
n Relations, agrégation, entre métriques,
facteurs et caractéristiques ?
n Pertinence pour les ingénieurs et les
utilisateurs des caractéristiques
mesurées ?
En effet, il reste encore de nombreuse questions en suspens. D’abord, existe-t-
il des définitions consensuelles des caractéristiques de qualité, de leurs facteurs
et des métriques suggérées pour les mesurer ? Ensuite, autre question très
importante, quelle sont les relations entre métriques, facteurs et
caractéristiques. Le passage entre valeurs des métriques, facteurs de qualité et
caractéristiques de qualité n’est encore aujourd’hui clairement défini que pour
un petit nombre de caractéristiques de qualité. Enfin, à notre connaissance, il
n’existe pas d’étude de la pertinence des caractéristiques mesurées.

40. 40
40/50
Défi 3 : évaluation (7/7)
n Directions de recherche
– État de l’art des définitions des
caractéristiques, des facteurs, des
métriques et compilation des résultats
– Expérimentation pour évaluer la pertinence
des caractéristiques de qualité
C’est pourquoi, nous travaillons à un état de l’art des définitions des modèles
prédictifs de qualité. (Khashayar Khosravi)
Nous allons aussi essayer de mettre en place des expérimentations pour
prouver ou non la pertinence de ces modèles.

41. 41
41/50
Défi 4 : restructuration (1/6)
n Restructurations [Fow99]
– Transformations du code source qui
conservent les propriétés sémantiques du
programme
n Restructuration automatique
– Source des transformations ?
– Propriétés conservées ?
Enfin, la restructuration automatique de l’architecture des programmes pour en
améliorer la qualité (et la compréhension) soulèvent deux questions
essentielles : quelles sont les sources des transformations ? Quelles doivent
être les propriétés conservées par les transformations ?

42. 42
42/50
Défi 4 : restructuration (2/6)
n Source des transformations ?
– Explications obtenues lors de
l’identification des choix de conception
n Propriétés conservées ?
– Syntaxiques
– Sémantiques
• Comportements du programme
• Performances
• Sécurité
Nous proposons d’utiliser les explications obtenues lors de l’identification des
choix de conception comme source des transformations. L’identification des
choix de conception avec la programmation par contraintes avec explication
génère des explications (ensembles de contraintes qu’il n’est pas possible au
solveur de satisfaire). À partir des contraintes impossibles à satisfaire (qui
représentent des relations entre Classifiers non-existantes), nous pensons
qu’il doit être possible de générer automatiquement des transformations pour
implanter ces relations manquantes. Cependant, se pose alors la question des
propriétés qui doivent être conservées. En effet, il est possible que
l’implantation première d’un programme ne permettent pas de satisfaire les
relations attendues sans «casser » l’architecture du programme ailleurs. Casser
signifie que le programme pourrait ne plus être compilable, exécutable, ou
s’exécuter avec une sémantique différente.

43. 43
43/50
Défi 4 : restructuration (3/6)nPtidejUIViewer
Pour illustrer une possible transformation, nous avons modifié à la main
l’implantation du programme pour satisfaire la relation d’héritage entre les
classes Document et Element (contrainte non-satisfaite lors de
l’identification des choix de conception). Voici la représentation graphique du
modèle du programme obtenu. L’architecture du programme ressemble
maintenant plus au motif de conception Composite. Mais la sémantique du
programme a changé : en effet, il est maintenant possible de mettre des
documents dans des documents !

44. 44
44/50
Défi 4 : restructuration (4/6)
n Restructurations
– Transformations du code source qui
conservent les propriétés sémantiques du
programme
n Restructuration automatique
– Source des transformations ?
– Propriétés conservées ?
Explications
À étudier…
C’est pourquoi, si nous avons répondu (dans une certaine mesure) à la question
sur la source des transformations, nous n’avons pas encore de réponse au
problème des propriétés des programmes qui doivent être conservées.

45. 45
45/50
Défi 4 : restructuration (5/6)
n Propriétés conservées
– Syntaxiques ?
• Compilation
– Sémantiques ?
• Exécution, performance, domaine
– Spécifications ?
• Attente des utilisateurs
Les propriétés peuvent être syntaxique (est-ce que le programme compile
encore ?), sémantique (est-ce que l’exécution du programme est toujours
correct par rapport à ce que l’utilisateur attend ? Est-ce que les performances
sont les mêmes ?)

46. 46
46/50
Défi 4 : restructuration (6/6)
n Directions de recherche
– Études des propriétés préservées ou non
par les restructurations
– Définitions de modèles d’analyse de
l’impact des changements prenant en
compte leurs différentes dimensions
C’est pourquoi, nous orientons nos recherches vers l’études des propriétés
préservées ou non par les restructurations, et sur la définition de modèles
d’analyse pour mesurer et prévoir l’impact des changement suivant les
dimension syntaxique, sémantique et spécifications.

47. 47
47/50
Conclusion
n Défis à relever
– Visualisation
• Modèles, analyses, représentation
– Choix de conception
• Identification, défauts, pertinence
– Évaluation de la qualité
• Modèle, métriques, retour d’expériences
– Restructuration
• Impact syntaxique et sémantique
Pour conclure, la maintenance des programmes est aujourd’hui de plus en plus
importante (50% du coût de développement, 75% passer à comprendre).
Pourtant, il reste encore de nombreux défis à relever pour faciliter la
maintenance des programmes…

48. 48
48/50
Conclusion
n Intégration de méthodologies et de
techniques d’autres disciplines
– Mise en page de graphes
– Programmation par contraintes
– Langage de programmation
– Génie logiciel expérimental
– Traitement des langues naturelles
– Sciences cognitives
– …
Nous avons essayé dans cette présentation de montrer quelques défis de la
maintenance et de proposer des grandes lignes de solutions. L’essentiel à
retenir étant que surmonter ces défis fait appelle à des théories et des
techniques venant de divers disciplines.

49. 49
49/50
Merci de votre attention !
n Questions
n Commentaires ?
Merci de votre attention !

50. 50
50/50
Références
n [Fow99] Martin Fowler ; Refactoring – Improving the Design of Existing Code ; Addison-Wesley, 1st edition,
June 1999
n [Gam94] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides ; Design Patterns – Elements of
Reusable Object-Oriented Software ; Addison-Wesley, 1st edition, 1994
n [Gué04] Yann-Gaël Guéhéneuc ; Abstract and Precise Recovery of UML Class Diagram Constituents ;
submitted for publication to ICSM’04
n [Jah97] Jens H. Jahnke, Wilhelm Schäfer and Albert Zündorf ; Generic Fuzzy Reasoning Nets as a Basis
for Reverse Engineering Relational Database Applications ; proceedings of the 6th European Software
Engineering Conference, pp. 193–210,September 1997
n [Jus01] Narendra Jussien ; Programmation Par Contraintes Avec Explications ; actes des 7e Journées
Nationales sur la résolution de Problèmes NP-Complets, pp. 147–158, juin 2001
n [Mil56] George A. Miller ; The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity
for Processing Information ; The Psychological Review 63 (2), pp. 81–97, American Psychological
Association, March 1956
n [Min74] Marvin Minsky ; A Framework for Representing Knowledge ; Memo 306, MIT AI Laboratory,
June 1974
n [Ric99] Tamar Richner and Stéphane Ducasse ; Recovering High-Level Views of Object-Oriented
Applications from Static and Dynamic Information ; proceedings of 7th International Conference on
Software Maintenance, pp. 13–22, August 1999
n [Sha96] David Sharon ; Meeting the Challenge of Software Maintenance ; Software13 (1), pp. 122–126,
IEEE Computer SocietyPress, January 1996
n [See98] Jochen Seemann and Jürgen Wolff von Gudenberg ; Pattern-based Design Recovery of Java
Software ; proceedings of 5th international symposium on Foundations of Software Engineering, pp. 10–16,
November 1998
n [Wuy98 ] Roel Wuyts ; Declarative Reasoning About the Structure of Object-Oriented Systems ;
proceedings of the 26th conference on the Technology of Object-Oriented Languages and Systems, pp.
112–124, August 1998