LMO02.ppt

Ptidej Team
Ptidej TeamPtidej Team
Un méta-modèle pour coupler
          application et détection
            des design patterns


                     Hervé Albin-Amiot
                       Pierre Cointe
                   Yann-Gaël Guéhéneuc
                   {albin, cointe, guehene}@emn.fr

Soft-Maint S.A.,              École des Mines        Object Technology
France                        de Nantes, France      International Inc ., Canada




                                                                                   1
Plan

       n Le contexte
       n Notre objectif
       n Nos besoins
       n Travaux connexes
       n Notre solution : le méta-modèle PDL
       n PDL : principe & mise en œuvre
       n Questions ouvertes
2/17




                                               2
Le contexte

             Améliorer la qualité des développements
             par objets en favorisant l’utilisation des
             design patterns pour aider à :

                 – Implémenter
                 – Comprendre
                 – Documenter


     3/17




Notre but est d’améliorer…


Les design patterns sont bien connus et éprouvés dans la recherche académique
comme dans l’industrie.


Les design patterns se situent à mi- chemin entre le code source et la conception
(micro-architectures).


Dans le reste de cette présentation, le GoF (Gamma et al.) est notre référence.




                                                                                    3
Notre objectif

               n Fournir      un assistant logiciel aidant à :
                  – L’implémentation
                      • Sélection
                      • Paramétrage
                                            Application
                      • Génération
                  – La compréhension et la documentation :
                    détection de formes exactes


      4/17




Deux phases principales pour l’implémentation :
•   la sélection… ;
•   l’application… Qui se décompose elle- même en :
        •    paramétrage… ;
        •    génération…


Une formes exacte = un design pattern tel que décrit dans le GoF. Une forme exacte
   suit à la fois la structure du design pattern et aussi son intention, ses
   collaborations, … telles que décrites dans le GoF.
En opposition avec une forme dégradée dans laquelle certaines caractéristiques
   (rôles, relations, …) ne sont pas vérifiées. Par exemple, dans le design pattern
   Composite, peut-être la relation d’héritage entre Component et Composite
   n’est-elle pas vitale pour satisfaire l’intention du design pattern.




                                                                                      4
Nos besoins

              n Formaliser  les design patterns
              n Décrire les design patterns en tant que :
                  – Entités de « première classe »
                      • Elles savent comment produire du code
                      • Elles savent identifier leurs propres
                        occurrences dans du code
                  – Entités manipulables
                      • Sur lesquelles on peut raisonner
                      • Que l’on peut adapter à un contexte spécifique

     5/17




Le GoF décrit 23 design patterns, mais ne les formalisent pas.


Nous devons formaliser pour pouvoir manipuler avec des outils ⇒ Décrire les
design patterns pour…
• comme des entités de première classes
• comme des entités manipulables


On veut obtenir des entités de premières classes : structure plus une touche de
comportement (commun à tous les design patterns et propre à un certain design
pattern). Il faut bien voir qu’un design pattern ce n’est pas seulement une structure,
c’est aussi un comportement.
On peut comparer cette approche avec la notion de classe dans un langage à
classes.


L’idée de modéliser les design patterns pour l’application et la détection permet
d’apporter une réponse au problème de la traçabilité…




                                                                                         5
Travaux connexes

                n Formalisation         :
                    – LePUS [Eden 2000]
                    – FAMIX [Ducasse 1999]
                    – Fragment Model [Florjin et al. 1997]
                n Application
                    – [Budinsky et al. 1996]
                n Détection
                    – [Wuyts 1998], [Antoniol et al. 1998]
      6/17




Nos travaux sont à la frontière de différents travaux sur les design patterns :
positionnement difficile car on veut faire trois aspects…
Dans notre approche, nous cherchons à formaliser les design patterns pour
appliquer et détecter les design patterns.
La plupart des travaux connexes ne s’intéressent qu’à un seul aspect:
• formalisation :
        • LePus : haut niveau d’abstraction de la formalisation, peu ou pas de
        génération de code, pas de prise en comptes des idiomes de programmation
        propre aux langages ;
        • FAMIX : l’intersection avec notre méta- modèle n’est pas vide mais les
        deux méta- modèles ne sont pas égaux ;
        • Modèle à fragments : granularité très (voire trop) fine, axé sur les
        caractéristique du langage de programmation Smalltalk ;
• application :
        • Budinsky propose un catalogue interactif en HTML des design patterns en
        vue de la génération de code d’exemple, mais il n’y a pas de possibilité de
        paramétrer le code générer pour l’insérer directement dans le code de
        l’utilisateur, de plus la détection n’est pas prise en compte ;
• détection :
        • Wuyts et Antoniol ne représentent que les design patterns structuraux, ils
        ne proposent pas de réelle formalisation, ni de détection.



                                                                                       6
Notre solution :
              le méta-modèle PDL




     7/17




On utilise un méta- modèle pour formaliser les design patterns.
La technique de méta- modélisation est bien connue pour…
Un méta- modèle pour formaliser/décrire les design patterns…
Ce méta- modèle est un compromis entre les constituants pour décrire les design
patterns et pour décrire les langages de programmation cible, car on veut faire à la
fois de la formalisation, de l’application, et de la détection.
Le méta- modèle est très simple pour décrire les design patterns et le la ngage Java,
il peut/doit être adapté pour la génération d’autres langages.




                                                                                        7
PDL : principe
                                                                      Méta-modèle de patterns

                                         Méta-entité            Décrivent
                                       générique Pattern
                                                                                     Constituants   Raffinement    •

                                                    Spécialisation    ‚

                                           Méta-entité                      Méta-entité               Méta-entité
                                            Observer                        Composite                  Proxy


                                                                            Instanciation   ƒ
                                                                                                                                       Sé lection
                                                                      Modèle abstrait Composite

                                                                           Paramétrage       „                                         Paramétrage

                   Modèle concret Composite 1                        Modèle concret Composite 2           Modèle concret Composite n

                                 build()    …                                     build()    …                           build()   …   Application
                       Code Composite 1                                   Code Composite 2                        Code Composite n




     8/17




Les différentes étapes d’utilisation de notre méta- modèle, depuis la définition des
constituants, jusqu’à l’application.
(Voir l’article dans les actes, ou www.yann-
gael.gueheneuc.net/Work/Publications/)




                                                                                                                                                     8
PDL : mise en œuvre
                                             Description
                                                          Descriptions
                                                          informelles du [GoF]




                           Traduction en un                Légende
                           modèle de pattern
                                                        Instance de Pattern
                                                        Instance de PInterface
                                                        Instance de PClass
                                                        Instance de PAssoc
                                                        Instance de PDelegation
     9/17
                                                 name() Instance de PMethod



Exemple…
Et on a un catalogue d’autres design patterns…




                                                                                  9
PDL : mise en œuvre
                Application
                       Component            *

                      paint( )              components




             Button                 Label                      Window

          paint()                paint( )                paint( )
                                                         addComponent(Component)
                                                         removeComponent (Component)
                                                         listComponent( )




        Paramétrage


                                    Génération
                                                            Code source
                                                            Java, Claire
10/17




                                                                                       10
PDL : mise en œuvre
                                               Détection
                                                            Design pattern
                                                            détecté ?



                          Comparaison
                          (arc consistance + algorithmes dédiés)



                                          Reconstruction
                                                            Code source Java
     11/17




Source ou code octal (byte-codes)…
Représentation du code source à l’aide des constituants du méta-modèle…
Chaque design pattern est une entité de première classe et donc on peut lui
demander de se comparer avec quelque chose et donc dire si ils sont équivalents…
L’algorithme utilisé est AC-x + des algorithmes ad-hoc qui permettent d’augmenter
l’efficacité et la pertinence pour prendre en compte les idiomes de programmation.
L’algorithme est implémenté au niveau de la classe Pattern, et chaque design
pattern peut être étendu…




                                                                                     11
Quelques résultats expérimentaux

              n Application
                  – Ptidej
              n Détection         sur plusieurs frameworks :
                  – java.awt.*
                  – JHotDraw
                  – JUnit
                  – PatternsBox
                  – Ptidej

     12/17




C’est difficile de présenter des exemples d’application, car il est plus facile
d’utiliser l’outil…
Pour la détection, c’est plus facile de donner des résultats concrets…




                                                                                  12
Détection              Design
                                    patterns
                                               Frameworks NOC Existing
                                                                             Détection dans PatternsBox

                                                                             Hits Missed False hits
                                                                                                     Time
                                                                                                    (sec.)
                                                                  121   1     1                       1
                                               java.awt.*
                                               JHotDraw           155   1     1                       0,3

                                   Composite        JUnit         34    1            1                0,4

                                                    JEdit         248                                 1,4

                                             PatternsBox          52                                  0,3
                                                     java.awt.*   121                                 0,2
                                                     JHotDraw     155   1     3               2       0,4
                                   Decorator              JUnit    34   1     1                       0,2
                                                          JEdit   248                                 0,4
                                                   PatternsBox     52                                 0,3
                                                     java.awt.*   121   3                             1,1
                                                     JHotDraw     155   2     2      1        1       0,5
                                    Factory               JUnit    34
                                    Method                JEdit   248                                 0,1
                                                   PatternsBox    52                                  0,2
                                                     java.awt.*   121
                                                     JHotDraw     155   3     3                       0,1
                                    Iterator              JUnit    34
                                                          JEdit   248   1     1                       0,1
                                                   PatternsBox     52
                                                     java.awt.*   121                                 3,4
                                                     JHotDraw     155   2     2                       3,2

                                   Observer               JUnit    34   4     4                       2,5
                                                          JEdit   248   3     3                       13
                                                   PatternsBox    52    1     1                       2,8
                                                     java.awt.*   121   3     3                       0,7
                                                     JHotDraw     155   2     2                       0,5
                                   Singleton              JUnit    34                                 0,4
                                                          JEdit   248                                  1
                                                   PatternsBox     52   1     1                       0,5
     13/17
                                                                  610   29   28     2         3      5,8




Nous avons appliqué six design patterns très utilisés (nous pensons) sur cinq
frameworks. Les résultats sont donnés sur la dernière ligne…
Nous avons aussi appliqué nos algorithmes à tout les paquetages de Java (java.*)
et les temps sont restés linéaires.
Mais certains design pattern sont difficilement détectables, comme le design pattern
Façade.




                                                                                                             13
Réalisation de l’objectif

             n Décrire,      appliquer et détecter les design
                patterns
                 – Entités de première classe manipulables

             n Nous      avons un assistant aidant :
                 – L’implémentation
                 – La détection et la documentation de formes
                   exactes de design patterns
                 (Cet assistant est « relativement » simple)
     14/17




Par rapport à notre objectif de départ, notre méta-modèle apporte une solution
satisfaisante…




                                                                                 14
Questions ouvertes                                     1/3

             n   Par rapport au contexte :

                    Améliorer la qualité des
                    développements par objets en
                    favorisant l’utilisation des design
                    patterns


     15/17




Mais au cours de nos recherches, nous avons rencontrés de nombreux problèmes
pour lesquels nous n’avons pas de réponse définitive, encore …




                                                                               15
Questions ouvertes                                           2/3

             n Formalisation           :
                 – Un unique méta-modèle est-il suffisant ?
                 – Comment représenter les compromis ?

             n Application         :
                 – Comment bien décrire le code source ?
                 – Est-ce qu’elle est toujours possible et
                   intéressante ?

     16/17




Un unique méta- modèle : Nous pensons que non, nous cherchons à modéliser
l’intention des design patterns…


Compromis : Pour l’instant, seulement des solutions ad- hoc…


Source code : FAMIX + définitions sémantiquement opérationnelles des relations
d’association, d’agrégation, et de composition…


Possible/intéressante : avec le design patterns Façade, l’utilisateur perd plus de
temps à paramétrer qu’à écrire le code lui- même… Mais c’est quand même utile
pour la validation, la détection, …




                                                                                     16
Questions ouvertes                                           3/3

              n Compréhension              :
                  – Est-il possible de détecter les formes
                    exactes de n’importe quel design pattern ?
                  – Est-il possible de détecter les formes
                    approchées de n’importe quel design
                    pattern ?




     17/17




Formes exactes : Non, mais cela reste une question ouverte…


Formes dégradées : Difficile, quel est le seuil de tolérance ent re une forme
dégradée et quelque chose qui n’est pas un design pattern ?…




                                                                                 17

Recommandé

Projet COM02.ppt par
Projet COM02.pptProjet COM02.ppt
Projet COM02.pptPtidej Team
383 vues17 diapositives
Synthèse des travaux sur la modélisation des connaissances - 14.11.12 par
Synthèse des travaux sur la modélisation des connaissances - 14.11.12Synthèse des travaux sur la modélisation des connaissances - 14.11.12
Synthèse des travaux sur la modélisation des connaissances - 14.11.12Gilbert Paquette
1.8K vues23 diapositives
Apprentissage du java par
Apprentissage du javaApprentissage du java
Apprentissage du javaKheirEddine Tolba
2.2K vues109 diapositives
Language de description d’architecture ACME par
Language de description d’architecture ACMELanguage de description d’architecture ACME
Language de description d’architecture ACMEAmira Hakim
2.7K vues31 diapositives
Bench model of electrical control system for inflatable hemi spherical structure par
Bench model of electrical control system for inflatable hemi spherical structureBench model of electrical control system for inflatable hemi spherical structure
Bench model of electrical control system for inflatable hemi spherical structureAlexander Decker
389 vues7 diapositives
Establishing a common language for designing fluid UIs par
Establishing a common language for designing fluid UIsEstablishing a common language for designing fluid UIs
Establishing a common language for designing fluid UIsJames Nash
517 vues16 diapositives

Contenu connexe

En vedette

CV.Crane Operator par
CV.Crane OperatorCV.Crane Operator
CV.Crane OperatorAmad Saidi
387 vues1 diapositive
Plataforma sm par
Plataforma smPlataforma sm
Plataforma smgraasuncion
327 vues12 diapositives
Manajemen Pendidikan par
Manajemen PendidikanManajemen Pendidikan
Manajemen PendidikanEdy Eko Santoso
1.1K vues10 diapositives
Kickoff da execução do planejamento 2016 par
Kickoff da execução do planejamento 2016Kickoff da execução do planejamento 2016
Kickoff da execução do planejamento 2016César Augusto Pessôa
292 vues9 diapositives
NHS Information risk management Introductory par
NHS Information risk management IntroductoryNHS Information risk management Introductory
NHS Information risk management IntroductoryAndrew Gelder
81 vues1 diapositive

Similaire à LMO02.ppt

Lmo02.ppt par
Lmo02.pptLmo02.ppt
Lmo02.pptYann-Gaël Guéhéneuc
30 vues17 diapositives
Projet+com02.ppt par
Projet+com02.pptProjet+com02.ppt
Projet+com02.pptYann-Gaël Guéhéneuc
33 vues17 diapositives
Jcom02.ppt par
Jcom02.pptJcom02.ppt
Jcom02.pptPtidej Team
919 vues17 diapositives
Soft fluent@md day2011 par
Soft fluent@md day2011Soft fluent@md day2011
Soft fluent@md day2011MDDAY11
700 vues25 diapositives
CM uml-intro par
CM uml-introCM uml-intro
CM uml-introYannick Prié (Enseignement)
1.7K vues30 diapositives
UML Part1-Introduction Mansouri par
UML Part1-Introduction MansouriUML Part1-Introduction Mansouri
UML Part1-Introduction MansouriMansouri Khalifa
1.9K vues60 diapositives

Similaire à LMO02.ppt(20)

Soft fluent@md day2011 par MDDAY11
Soft fluent@md day2011Soft fluent@md day2011
Soft fluent@md day2011
MDDAY11700 vues
Programmation orientee aspect 201401 - Ensim par Laurent Broudoux
Programmation orientee aspect 201401 - EnsimProgrammation orientee aspect 201401 - Ensim
Programmation orientee aspect 201401 - Ensim
Laurent Broudoux1.6K vues
Introduction au Génie Logiciel par guest0032c8
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
guest0032c88.3K vues
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007) par Ardesi Midi-Pyrénées
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Revit prg cdfva2013 par jln94
Revit prg cdfva2013Revit prg cdfva2013
Revit prg cdfva2013
jln94342 vues
Gl slides-cours-1 par Sami Neili
Gl slides-cours-1Gl slides-cours-1
Gl slides-cours-1
Sami Neili1.6K vues
Thesis+of+nesrine+abdelkafi.ppt par Ptidej Team
Thesis+of+nesrine+abdelkafi.pptThesis+of+nesrine+abdelkafi.ppt
Thesis+of+nesrine+abdelkafi.ppt
Ptidej Team179 vues
Génie Logiciel - Unified modeling language par Julien Schneider
Génie Logiciel - Unified modeling languageGénie Logiciel - Unified modeling language
Génie Logiciel - Unified modeling language
Julien Schneider477 vues

Plus de Ptidej Team

From IoT to Software Miniaturisation par
From IoT to Software MiniaturisationFrom IoT to Software Miniaturisation
From IoT to Software MiniaturisationPtidej Team
7.3K vues82 diapositives
Presentation par
PresentationPresentation
PresentationPtidej Team
259 vues45 diapositives
Presentation par
PresentationPresentation
PresentationPtidej Team
191 vues58 diapositives
Presentation par
PresentationPresentation
PresentationPtidej Team
126 vues38 diapositives
Presentation by Lionel Briand par
Presentation by Lionel BriandPresentation by Lionel Briand
Presentation by Lionel BriandPtidej Team
186 vues77 diapositives
Manel Abdellatif par
Manel AbdellatifManel Abdellatif
Manel AbdellatifPtidej Team
116 vues1 diapositive

LMO02.ppt

  • 1. Un méta-modèle pour coupler application et détection des design patterns Hervé Albin-Amiot Pierre Cointe Yann-Gaël Guéhéneuc {albin, cointe, guehene}@emn.fr Soft-Maint S.A., École des Mines Object Technology France de Nantes, France International Inc ., Canada 1
  • 2. Plan n Le contexte n Notre objectif n Nos besoins n Travaux connexes n Notre solution : le méta-modèle PDL n PDL : principe & mise en œuvre n Questions ouvertes 2/17 2
  • 3. Le contexte Améliorer la qualité des développements par objets en favorisant l’utilisation des design patterns pour aider à : – Implémenter – Comprendre – Documenter 3/17 Notre but est d’améliorer… Les design patterns sont bien connus et éprouvés dans la recherche académique comme dans l’industrie. Les design patterns se situent à mi- chemin entre le code source et la conception (micro-architectures). Dans le reste de cette présentation, le GoF (Gamma et al.) est notre référence. 3
  • 4. Notre objectif n Fournir un assistant logiciel aidant à : – L’implémentation • Sélection • Paramétrage Application • Génération – La compréhension et la documentation : détection de formes exactes 4/17 Deux phases principales pour l’implémentation : • la sélection… ; • l’application… Qui se décompose elle- même en : • paramétrage… ; • génération… Une formes exacte = un design pattern tel que décrit dans le GoF. Une forme exacte suit à la fois la structure du design pattern et aussi son intention, ses collaborations, … telles que décrites dans le GoF. En opposition avec une forme dégradée dans laquelle certaines caractéristiques (rôles, relations, …) ne sont pas vérifiées. Par exemple, dans le design pattern Composite, peut-être la relation d’héritage entre Component et Composite n’est-elle pas vitale pour satisfaire l’intention du design pattern. 4
  • 5. Nos besoins n Formaliser les design patterns n Décrire les design patterns en tant que : – Entités de « première classe » • Elles savent comment produire du code • Elles savent identifier leurs propres occurrences dans du code – Entités manipulables • Sur lesquelles on peut raisonner • Que l’on peut adapter à un contexte spécifique 5/17 Le GoF décrit 23 design patterns, mais ne les formalisent pas. Nous devons formaliser pour pouvoir manipuler avec des outils ⇒ Décrire les design patterns pour… • comme des entités de première classes • comme des entités manipulables On veut obtenir des entités de premières classes : structure plus une touche de comportement (commun à tous les design patterns et propre à un certain design pattern). Il faut bien voir qu’un design pattern ce n’est pas seulement une structure, c’est aussi un comportement. On peut comparer cette approche avec la notion de classe dans un langage à classes. L’idée de modéliser les design patterns pour l’application et la détection permet d’apporter une réponse au problème de la traçabilité… 5
  • 6. Travaux connexes n Formalisation : – LePUS [Eden 2000] – FAMIX [Ducasse 1999] – Fragment Model [Florjin et al. 1997] n Application – [Budinsky et al. 1996] n Détection – [Wuyts 1998], [Antoniol et al. 1998] 6/17 Nos travaux sont à la frontière de différents travaux sur les design patterns : positionnement difficile car on veut faire trois aspects… Dans notre approche, nous cherchons à formaliser les design patterns pour appliquer et détecter les design patterns. La plupart des travaux connexes ne s’intéressent qu’à un seul aspect: • formalisation : • LePus : haut niveau d’abstraction de la formalisation, peu ou pas de génération de code, pas de prise en comptes des idiomes de programmation propre aux langages ; • FAMIX : l’intersection avec notre méta- modèle n’est pas vide mais les deux méta- modèles ne sont pas égaux ; • Modèle à fragments : granularité très (voire trop) fine, axé sur les caractéristique du langage de programmation Smalltalk ; • application : • Budinsky propose un catalogue interactif en HTML des design patterns en vue de la génération de code d’exemple, mais il n’y a pas de possibilité de paramétrer le code générer pour l’insérer directement dans le code de l’utilisateur, de plus la détection n’est pas prise en compte ; • détection : • Wuyts et Antoniol ne représentent que les design patterns structuraux, ils ne proposent pas de réelle formalisation, ni de détection. 6
  • 7. Notre solution : le méta-modèle PDL 7/17 On utilise un méta- modèle pour formaliser les design patterns. La technique de méta- modélisation est bien connue pour… Un méta- modèle pour formaliser/décrire les design patterns… Ce méta- modèle est un compromis entre les constituants pour décrire les design patterns et pour décrire les langages de programmation cible, car on veut faire à la fois de la formalisation, de l’application, et de la détection. Le méta- modèle est très simple pour décrire les design patterns et le la ngage Java, il peut/doit être adapté pour la génération d’autres langages. 7
  • 8. PDL : principe Méta-modèle de patterns Méta-entité Décrivent générique Pattern Constituants Raffinement • Spécialisation ‚ Méta-entité Méta-entité Méta-entité Observer Composite Proxy Instanciation ƒ Sé lection Modèle abstrait Composite Paramétrage „ Paramétrage Modèle concret Composite 1 Modèle concret Composite 2 Modèle concret Composite n build() … build() … build() … Application Code Composite 1 Code Composite 2 Code Composite n 8/17 Les différentes étapes d’utilisation de notre méta- modèle, depuis la définition des constituants, jusqu’à l’application. (Voir l’article dans les actes, ou www.yann- gael.gueheneuc.net/Work/Publications/) 8
  • 9. PDL : mise en œuvre Description Descriptions informelles du [GoF] Traduction en un Légende modèle de pattern Instance de Pattern Instance de PInterface Instance de PClass Instance de PAssoc Instance de PDelegation 9/17 name() Instance de PMethod Exemple… Et on a un catalogue d’autres design patterns… 9
  • 10. PDL : mise en œuvre Application Component * paint( ) components Button Label Window paint() paint( ) paint( ) addComponent(Component) removeComponent (Component) listComponent( ) Paramétrage Génération Code source Java, Claire 10/17 10
  • 11. PDL : mise en œuvre Détection Design pattern détecté ? Comparaison (arc consistance + algorithmes dédiés) Reconstruction Code source Java 11/17 Source ou code octal (byte-codes)… Représentation du code source à l’aide des constituants du méta-modèle… Chaque design pattern est une entité de première classe et donc on peut lui demander de se comparer avec quelque chose et donc dire si ils sont équivalents… L’algorithme utilisé est AC-x + des algorithmes ad-hoc qui permettent d’augmenter l’efficacité et la pertinence pour prendre en compte les idiomes de programmation. L’algorithme est implémenté au niveau de la classe Pattern, et chaque design pattern peut être étendu… 11
  • 12. Quelques résultats expérimentaux n Application – Ptidej n Détection sur plusieurs frameworks : – java.awt.* – JHotDraw – JUnit – PatternsBox – Ptidej 12/17 C’est difficile de présenter des exemples d’application, car il est plus facile d’utiliser l’outil… Pour la détection, c’est plus facile de donner des résultats concrets… 12
  • 13. Détection Design patterns Frameworks NOC Existing Détection dans PatternsBox Hits Missed False hits Time (sec.) 121 1 1 1 java.awt.* JHotDraw 155 1 1 0,3 Composite JUnit 34 1 1 0,4 JEdit 248 1,4 PatternsBox 52 0,3 java.awt.* 121 0,2 JHotDraw 155 1 3 2 0,4 Decorator JUnit 34 1 1 0,2 JEdit 248 0,4 PatternsBox 52 0,3 java.awt.* 121 3 1,1 JHotDraw 155 2 2 1 1 0,5 Factory JUnit 34 Method JEdit 248 0,1 PatternsBox 52 0,2 java.awt.* 121 JHotDraw 155 3 3 0,1 Iterator JUnit 34 JEdit 248 1 1 0,1 PatternsBox 52 java.awt.* 121 3,4 JHotDraw 155 2 2 3,2 Observer JUnit 34 4 4 2,5 JEdit 248 3 3 13 PatternsBox 52 1 1 2,8 java.awt.* 121 3 3 0,7 JHotDraw 155 2 2 0,5 Singleton JUnit 34 0,4 JEdit 248 1 PatternsBox 52 1 1 0,5 13/17 610 29 28 2 3 5,8 Nous avons appliqué six design patterns très utilisés (nous pensons) sur cinq frameworks. Les résultats sont donnés sur la dernière ligne… Nous avons aussi appliqué nos algorithmes à tout les paquetages de Java (java.*) et les temps sont restés linéaires. Mais certains design pattern sont difficilement détectables, comme le design pattern Façade. 13
  • 14. Réalisation de l’objectif n Décrire, appliquer et détecter les design patterns – Entités de première classe manipulables n Nous avons un assistant aidant : – L’implémentation – La détection et la documentation de formes exactes de design patterns (Cet assistant est « relativement » simple) 14/17 Par rapport à notre objectif de départ, notre méta-modèle apporte une solution satisfaisante… 14
  • 15. Questions ouvertes 1/3 n Par rapport au contexte : Améliorer la qualité des développements par objets en favorisant l’utilisation des design patterns 15/17 Mais au cours de nos recherches, nous avons rencontrés de nombreux problèmes pour lesquels nous n’avons pas de réponse définitive, encore … 15
  • 16. Questions ouvertes 2/3 n Formalisation : – Un unique méta-modèle est-il suffisant ? – Comment représenter les compromis ? n Application : – Comment bien décrire le code source ? – Est-ce qu’elle est toujours possible et intéressante ? 16/17 Un unique méta- modèle : Nous pensons que non, nous cherchons à modéliser l’intention des design patterns… Compromis : Pour l’instant, seulement des solutions ad- hoc… Source code : FAMIX + définitions sémantiquement opérationnelles des relations d’association, d’agrégation, et de composition… Possible/intéressante : avec le design patterns Façade, l’utilisateur perd plus de temps à paramétrer qu’à écrire le code lui- même… Mais c’est quand même utile pour la validation, la détection, … 16
  • 17. Questions ouvertes 3/3 n Compréhension : – Est-il possible de détecter les formes exactes de n’importe quel design pattern ? – Est-il possible de détecter les formes approchées de n’importe quel design pattern ? 17/17 Formes exactes : Non, mais cela reste une question ouverte… Formes dégradées : Difficile, quel est le seuil de tolérance ent re une forme dégradée et quelque chose qui n’est pas un design pattern ?… 17