lmo08a.ppt

Génération automatique d’algorithmes de

détection des défauts de conception

Naouel Moha, Foutse Khomh, Yann-Gaël Guéhéneuc, Laurence Duchien, Anne-Françoise Le Meur

Ptidej Team, GEODES, Université de Montréal, CanadaLIFL, INRIA Lille - Nord Europe / ADAM Team, Université de Lille, France

LMO’085-7 mars, 2008

Moha © Génération automatique d’algorithmes de détection des défauts de conception 2

Contexte


Contexte


� Patrons de conception sont de “bonnes” solutions à des problèmes de conception récurrents

� Défauts de conception (DCs)� sont de “mauvaises” solutions à des problèmes récurrents� 2 catégories:

� Problèmes de haut niveau (global) : antipatterns [Brown 98]� Problèmes de bas niveau (local) : mauvaises odeurs* [Fowler 99]

“ déviations de spécifications ou d’exigences qui peuvent entraîner desdéfaillances dans les operations ”

* Certaines mauvaises odeurs peuvent être considérées comme défauts de haut niveau

Défauts de conception ?

≠



� 2 exemples de défauts de conception [Brown 98]

� Blob (God Class)

“ Procedural-style design leads to one object with a lion’s share of the responsibilities while most other objects only hold data or execute simple processes ”

� Large classe contrôleur

� Beaucoup de champs et méthodes avec une faible cohésion*

� Dépendent des données localisées dans des classes de données associées

�* À quel point les méthodes sont étroitement liées aux variables d'instance de la classe.


� 2 exemples de défauts de conception [Brown 98]


� Spaghetti Code

“ Ad hoc software structure makes it difficult to extend and optimize code. ”

� Pensée procédurale dans la programmation OO

� Manque de structure : pas d’héritage, pas de réutilisation, pas de polymorphisme

� Longues méthodes sans paramètres avec une faible cohésion

� Noms des classes suggèrent une programmation procédurale

� Utilisation excessive de variables globales


Motivation

� Pourquoi il est important de détecter les DCs ?

� DCs atténuent la qualité des architectures OO et entravent leur évolution et leur maintenance

� La maintenance est coûteuse à cause des DCs [PER 92] : ajout, debuggage, et évolution des fonctionnalités sont plus difficiles

� Une bonne architecture logicielle sans DCs: plus facile àcomprendre, changer, et donc maintenir

� Motivation

� Atteindre un haut niveau de qualité logicielle� Réduire les coûts du développement logiciel et de maintenance


Method DECOR

Specification

Domain

Analysis

Detection

Processing

Validation

Moha ©

Specification

Domain

Analysis

Detection

Processing

Validation

Génération automatique d’algorithmes de détection des défauts de conception 9

Method DECOR

Contributions

� Génération automatique des algorithmes de détection

� Évaluation des algorithmes générés en terme de précision et derappel

Moha ©

Specification

Domain

Analysis

Detection

Processing

Validation


Method DECOR

Moha ©

On all defects On each defect

1

Specification 2

Domain

Analysis

Vocabulary

Taxonomy

Operational

specifications

Brown et al. (1998)

Demeyer (2002)

Dudney (2003)

Fowler (1999)

Riel (1996)

Webster (1995)

Marinescu (2004)

Munro (2005)

Alikacem (2006)

Suspicious

classes

Text-based descriptions

of design defects

Marinescu (2004)

Alikacem (2006)

Travassos : manual detection (1999)

Tools: SmallLint, PMD, CROCOPAT

Detection

4

DECOR Method

Source code

of the system

Processing

3

Specifications Classes having

design defects

Validation

5Source code

of the system

Marinescu (2004)

Munro (2005)

On each system

RULE_CARD : SpaghettiCode {

...

RULE: LongMethodMethodNoParameter { INTER LongMethod MethodNoParameter };

RULE: LongMethod { METRIC LOC_METHOD VERY_HIGH 10.0 };

RULE: MethodNoParameter { METRIC NMNOPARAM VERY_HIGH 10.0 };

...

RULE: NoInheritance { METRIC DIT 1 0.0 } ;

RULE: NoPolymorphism { STRUCT NO_POLYMORPHISM } ;

RULE: ProceduralNameGlobalVariable { UNION ProceduralName GlobalVariable };

RULE: ProceduralName { LEXIC CLASS_NAME (Make, Create, System, Exec) };

RULE: UseGlobalVariable { STRUCT USE_GLOBAL_VARIABLE };

} ;

12

Spécifications

SADSL (Software Architectural Defect Specification Language) [LMO’06]

� Langage pour spécifier les DCs basé sur un méta-modèle

Génération automatique d’algorithmes de détection des défauts de conception

Moha © 13

Spécifications

Méta-modèle SADDL (Software Architectural Defect Definition Language)



1

Specification 2

Domain

Analysis

Vocabulary

Taxonomy

Operational

specifications

Brown et al. (1998)

Demeyer (2002)

Dudney (2003)

Fowler (1999)

Riel (1996)

Webster (1995)

Marinescu (2004)

Munro (2005)

Alikacem (2006)

Suspicious

classes


of design defects

Marinescu (2004)

Alikacem (2006)



Detection

4

DECOR Method

Source code

of the system

Processing

3


design defects

Validation

5Source code

of the system

Marinescu (2004)

Munro (2005)

On each system

Moha ©

Specification

Domain

Analysis

Detection

Processing

Validation


Method DECOR

Moha ©

Specification

Domain

Analysis

Detection

Algorithm

Generation

Validation


Method DECOR


Génération des algosOn all defects On each defect

1

Specification 2

Domain

Analysis

Vocabulary

Taxonomy

Operational

specifications

Brown et al. (1998)

Demeyer (2002)

Dudney (2003)

Fowler (1999)

Riel (1996)

Webster (1995)

Marinescu (2004)

Munro (2005)

Alikacem (2006)

Suspicious

classes


of design defects

Marinescu (2004)

Alikacem (2006)



Detection

4

DECOR Method

Source code

of the system

Processing

3


design defects

Validation

5Source code

of the system

Marinescu (2004)

Munro (2005)

On each system



1

Specification 2

Domain

Analysis

Vocabulary

Taxonomy

Operational

specifications

Brown et al. (1998)

Demeyer (2002)

Dudney (2003)

Fowler (1999)

Riel (1996)

Webster (1995)

Marinescu (2004)

Munro (2005)

Alikacem (2006)

Suspicious

classes


of design defects

Marinescu (2004)

Alikacem (2006)



Detection

4

DECOR Method

Source code

of the system

Processing

3


design defects

Validation

5Source code

of the system

Marinescu (2004)

Munro (2005)

On each system



1

Specification 2

Domain

Analysis

Vocabulary

Taxonomy

Operational

specifications

Brown et al. (1998)

Demeyer (2002)

Dudney (2003)

Fowler (1999)

Riel (1996)

Webster (1995)

Marinescu (2004)

Munro (2005)

Alikacem (2006)

Suspicious

classes


of design defects

Marinescu (2004)

Alikacem (2006)



Detection

4

DECOR Method

Source code

of the system

Processing

3


design defects

Validation

5Source code

of the system

Marinescu (2004)

Munro (2005)

On each system

Plateforme SAD - Méta-modèle pour représenter les programmes OO- Un répertoire de métriques- Des services pour analyser to analyse des relations

structurelles- Des services pour appliquer des analyses

structurelles et lexicales

� Complexité : O((c+op) X n)- c : le nombre de propriétés- op : le nombre d’opérateurs- n : le nombre de classes

Moha ©

1 public class <CODESMELL>Detection

2 extends CodeSmellDetection

3 implements ICodeSmellDetection {

4 public Set performDetection() {

5 IClass c = iteratorOnClasses.next();

6 LOCofSetOfClasses.add(

7 Metrics.compute(<METRIC>, c));

8 ...

9 BoxPlot boxPlot = new BoxPlot(

10 <METRIC>ofSetOfClasses, <FUZZINESS>);

11 Map setOfOutliers =

12 boxPlot.<ORDINAL_VALUE>();

13 ...

14 suspiciousCodeSmells.add( new CodeSmell(

15 <CODESMELL>, setOfOutliers));

16 ...

17 return suspiciousCodeSmells;

18 }



1

Specification 2

Domain

Analysis

Vocabulary

Taxonomy

Operational

specifications

Brown et al. (1998)

Demeyer (2002)

Dudney (2003)

Fowler (1999)

Riel (1996)

Webster (1995)

Marinescu (2004)

Munro (2005)

Alikacem (2006)

Suspicious

classes


of design defects

Marinescu (2004)

Alikacem (2006)



Detection

4

DECOR Method

Source code

of the system

Processing

3


design defects

Validation

5Source code

of the system

Marinescu (2004)

Munro (2005)

On each system


�Visiteur �Gabarit



1

Specification 2

Domain

Analysis

Vocabulary

Taxonomy

Operational

specifications

Brown et al. (1998)

Demeyer (2002)

Dudney (2003)

Fowler (1999)

Riel (1996)

Webster (1995)

Marinescu (2004)

Munro (2005)

Alikacem (2006)

Suspicious

classes


of design defects

Marinescu (2004)

Alikacem (2006)



Detection

4

DECOR Method

Source code

of the system

Processing

3


design defects

Validation

5Source code

of the system

Marinescu (2004)

Munro (2005)

On each system

�Visiteur �Code généré


Moha ©


21

Génération des algos

Box-plot pour les métriques de type ordinal



1

Specification 2

Domain

Analysis

Vocabulary

Taxonomy

Operational

specifications

Brown et al. (1998)

Demeyer (2002)

Dudney (2003)

Fowler (1999)

Riel (1996)

Webster (1995)

Marinescu (2004)

Munro (2005)

Alikacem (2006)

Suspicious

classes


of design defects

Marinescu (2004)

Alikacem (2006)



Detection

4

DECOR Method

Source code

of the system

Processing

3


design defects

Validation

5Source code

of the system

Marinescu (2004)

Munro (2005)

On each system

Moha © 24

Expérimentations But : évaluer les algorithmes générés en terme de précision et rappel

Temps de détection

RappelPrécisionDéfauts détectés

Défauts existants

Nbre de classes

Défauts

2,45s100%88,6%44 (8,6%)39 (7,6%)

513

Blob

0,91s100%51,7%29 (5,6%)15 (2,9%)Functional Decomp.

0,23s100%60,5%76 (14,8%)46 (9,0%)Spaghetti Code

0,08s100%41,1%56 (10,9%)23 (4,5%)Swiss Army Knife


Xerces: 71,217LOC, 513 classes et 162 interfaces


Conclusion

� Method DECOR

Méthode pour générer des algorithmes de détection des DCs

� Contributions� Processus explicite de génération des algorithmes de détection

� Évaluation des algorithmes de détection en terme de précision et de rappel

� Travaux futurs- Expérimentations sur d’autres systèmes et défauts- Plus de flexibilité dans la génération de code en utilisant XML- Intégrer les plateformes existantes


Questions

Merci pour votre attention !

Contact: [email protected]

http://www-etud.iro.umontreal.ca/~mohanaou

lmo08a.ppt

Documents

conception rcurrents

conception dcs

conception brown

patrons de conception

dtection valuation

problmes rcurrents

dcs per

dcs attnuent