2IUT de Montreuil UNIV-Paris8

Présentation au sujet: "2IUT de Montreuil UNIV-Paris8"— Transcription de la présentation:

1 2IUT de Montreuil UNIV-Paris8
Design Patterns Arnaud Nauwynck1 & Nédra Mellouli2 1Société Softeam Paris 2IUT de Montreuil UNIV-Paris8

2 Introduction Thèse de Erich Gamma Edité en un livre
Auteurs: E. Gamma, R. Helm, R. Johnson, J. Vlissides Livre devenu best-seller informatique Vision nouvelle(?) et incontournable

3 Plan Orienté-Objet & Design Patterns
Généralités sur les Design Patterns Étude de Cas Utilisation & méthode d’apprentissage Conclusion

4 Mots - clefs Titre : Design Patterns
Catalogue de Modèles de conception réutilisables Elements of Reusable Object-Oriented Software Mots-clefs = architecture, organisation, rôles, simple, intelligible, éprouvé, flexible, concepts OO, modulaire, (ré)utilisable ...

5 Objectifs / Positionnement
Pré requis connaissance Orientée-Objet Langage OO : C++ / Java.. Concepts de Librairies Buts Concepts abstraits Vocabulaire des concepts (complémentaire d’UML) Nouvelle vision du monde du logiciel Non – Buts Pas liés à un langage précis Pas un livre d’apprentissage, pas de recettes !

6 L’Héritage en Orienté-Objets
3 Façons de réutiliser les Objets Héritages (d’interface / de code) Composition Templates (généricité de types..) Héritage de code : souvent utilisé à tords L’héritage d’interface : Light Motifs des Design Patterns

7 Limitation d’une approche naïve de l’Orienté-Objets
Recensement « Merisien » des objets Données, pas Interfaces ! Objets fonctionnels seulement, Pas informatiques! Héritage de code forte corrélation classes / sous-classes.. Traitements mélangés entre classes Grande difficulté de compréhension insuffisance des diagrammes de classes de UML

8 Buts : Rôles des objets Limitation des dépendances / connaissances entre objets Introduction de dépendances dynamiques tardives (« late binding ») Par opposition : suppression des dépendances à la compilation.. Rôles des objets systématiquement épurés, et définis par des interfaces 1 rôle => 1 interface + délégation à 1 objet Possibilité de changement ouverte

9 23 Patterns / 3 classifications
Des objets où, comment, pourquoi faire ?.. Identification et rôles des objets et des relations 1) Modèles Créateurs Créer un objet / Accéder à un objet 2) Modèles Structuraux Combiner les objets en structures 3) Modèles de Comportement Utiliser les objets pour implanter des fonctionnalités

10 Etude de cas : 5 Problèmes
Concevoir l’architecture (classes en UML) d’un logiciel de dessin géométrique supportant les cercles, segments, groupes… Parties à clarifier : Structure interne / Dessins des formes Changements synchronisés Groupes d’objets (Group / Ungroup) Comportements de la souris, des menus contextuels Conversions en multiples formats…

11 Pb 1/5 : MVC Modèle - Vue - Contrôleur
Fichiers / Représentations Internes / Vues / Interactions utilisateurs Séparation Modèle-Contrôleur Contrôleur Séparation Vue-Contrôleur Forme Cercle Segment Dessin Vue Séparation Modèle-Vue!!! Vectoriel Pixel

12 Pb1/5 : MVC (Suite) : Contrôleur Traitements / GUI
Forme Cercle Segment Dessin Notification, affichage Vues Vectoriel Pixel Séparation Modèle-Vue!!!

13 Pb1/5 : MVC (Suite) Architecture 2 tiers
Contrôleur Traitements Contrôleur GUI Requêtes actions évènements GUI Forme Cercle Segment Dessin Notification, affichage Vues Vectoriel Pixel Séparation Modèle-Vue!!! Serveur Applicatif (serveur d’objets) Client Graphique (client léger)

14 Pb1/5 : MVC (Suite) Architecture 3 tiers
Contrôleur DB Contrôleur Traitements Contrôleur GUI Requêtes Persistence Requêtes Sql, Xql.. Forme Cercle Segment Dessin Notification, affichage Vues Vectoriel Pixel Serveur de Base de Données Serveur Applicatif Client Graphique (client léger)

15 Pb2/5 : Publish & Subscribe
Notifications de changement 0..* listVues Sujet Subscribe / addVueListener(v) Resign / removeVueListener(v) FireAll(chgEvent) { for_list(vue,v) v->Notify(chgEvent) } Vue SetSrcObject(o) Notify(chgEvent) 0..1 srcObject

16 Pb 2/5: Publish & Subscribe (Bis)
Indépendance des Vues pour l’Objet 0..* listVues Forme addVueListener(v) removeVueListener(v) FireAll(chgEvent) VueAbstraite SetSrcObject(o) <<Abstract >> Notify(chgEvent) 0..1 srcObject Vue1 Notify() { .. Draw1 } Vue2 Notify() { .. Draw2 }

17 Pb2/5: Publish & Subscribe (Ter)
Indépendance des Objets pour les Vues (cf. MVC) SujetAbstrait addVueListener(v) removeVueListener(v) FireAll(chgEvent) <<abstract>> getXX() <<abstract>> getRenderer() 0..* listVues VueAbstraite SetSrcObject(o) Notify(chgEvent) 0..1 srcObject Vue1 Vue2 Sujet1 getXX getRenderer Sujet2 getXX getRenderer

18 Pb 3/5 : Composite.. Group / Ungroup FormeComposite Forme Cercles
0..* Sous-formes Forme Cercles Segments

19 Pb3/5 : Composite, Proxy.. Formes par procuration
(Rotation, Iconifiée, En cours de chargement, etc..) Proxy 0..1 forme sous-jacente Forme Cercles Segments Composite 0..* Sous-formes

20 Pb4/5 : Délégation, Chaîne de Responsabilité..
Gestion de la souris, des évènements graphiques… GestionApplication Application Vue GestionVue GestionForme Formes Cercles Segments GestionSegment Menu Contextuel

21 Pb 5/5 : Stratégie, Visiteur, Factory, Singleton…
Conversions Multiples, etc.. Formes Cercles Segments ConvertisseurPs Traitement ConvertisseurBmp TypeTraitement createInstance TraitementTypeFactory getTypeTraitement(name) ..Factory.getSingleton() TypeConvertisseurPs TypeConvertisseurBmp

22 Retour sur les 23 Patterns
Les 23 Patterns se trouvent partout Sous formes réduites, déguisées, renommées… Lire des programmes … Savoir les reconnaître et comprendre l’architecture Ecrire : savoir en mettre partout (!!), en respectant les concepts

23 Description des 23 Patterns ? / Réflexion de chacun !!
Découverte Bon sens, mais c’est bien sûr.. 1ère Lecture Catalogue Universitaire ? 1ère pratique Je connais!.. Je vais réessayer pareil… Oups.. Je dois relire quelques détails.. 2ème lecture C’est très fort 2ème pratique On les vois partout ! On en met partout !

24 Liste des Patterns : Modèles créateurs (1/3)
Fabrique Abstraite (Abstract Factory, Kit) Monteur (Builder) Fabrication (Factory method) Prototype Singleton

25 Liste des Patterns : Modèles Structuraux (2/3)
Adaptateur Pont Composite Décorateur Façade Poids Mouche Procuration (Proxy)

26 Liste des Patterns : Modèles Comportementaux (3/3)
Chaîne de responsabilité Commande Interpréteur Itérateur Médiateur Mémento Observateur État Stratégie Patron de méthode Visiteur

27 Conclusion 1 rôle => 1 interface + délégation à 1 objet
Un livre à lire 2 fois 1 rôle => 1 interface + délégation à 1 objet Possibilité de changement ouverte La programmation devient tellement plus simple !

28 Cadre pédagogique à l'IUT de Montreuil : design patterns par la théorie et la pratique
Nelly Ben simon Nédra Mellouli Serge Rosmoduc

29 Nos choix En algorithmique et programmation forte orientation OO
java dès la première année enseignement GI à forte coloration java : jdbc/jsp/servlets

30 Patterns et java Intérêt architectural des patterns : mieux structurer le code intérêt pour la pédagogie OO : systèmes non triviaux de classes qui collaborent Nécessaires pour comprendre les bibliothèques java : les patterns y sont omniprésents swing (Observateur...), jdbc (Abstract Factory)...

31 L'enseignement des patterns
problème : les patterns répondent à des questions que les étudiants ne se posent pas la présentation classique des patterns suppose une expérience de la programmation donner cette expérience par des projets ? long. présentation multiples des patterns En programmation réseau En imagerie numérique (essentiellement le visiteur) En OMGL dans le cadre d'un projet transversal en option GI, depuis cette année

32 Les patterns à Montreuil
trois cours Une conférence suivie d'une séance de TP réalisées par un intervenant de la société Softeam un mini-projet mise en évidence systématique des patterns rencontrés en programmation projet transversal (OMGL/EOG/PROG)

33 Cours principes de conception OO ;
introduction aux design patterns : observateur (MVC, architectures 2/3-3/3) ; design patterns : commande, visiteur Mini-projet « Statistiques :Histogramme, Camenbert et texte ».

34 Mini-projet « Statistiques »
une première partie donnée avant la présentation du MVC une seconde partie donnée après.

35 Première partie : solution proposée par un binôme

36 Deuxième partie : solution proposée par le même binôme

37 Les patterns dans les TPs de programmation
proposer une architecture correcte des programmes développés en TP problème : cela prend du temps (2h de TP par semaine ?!?) solution utilisée : fournir une base déjà développée (voir transparent suivant) demander aux étudiants de la documenter (UML) rester simple

38 Exemple

39 Mandel (exercice sur les threads)
on fournit un programme graphique fonctionnel sa structure est déjà bonne (pas de refactoring nécessaire) on demande de l'améliorer

40 TP JDBC : Annuaire architecture déjà fournie
couches interface/logique métier/modèle/persistance exercice sur les différentes couches implémenter des parties de la couche persistance ajouter des fonctionnalités passer d'une interface texte à une interface graphique, puis jsp

41 « Cas transversal » Mener un grand projet : sur un cas réel
Analyse des besoins du client Organisation de chaque groupe d'étudiant et planning Proposition d'un modèle en UML : utilisatios de certains patterns pour mieux découper : Strategie, proxy, fabrique abstraite, singleton… Validation avec l'accord du client Découpage en différentes tâches Développement de chaque tâche Integration : c'est une phase pénible pour les étudiants Ils s'apperçoivent de leurs erreux et de leurs mauvais choix! C'est une phase de reflexion et d'autocorrection !

42 Les projets tuteurés Les étudiants sont fortement incités par certains tuteurs à mettre les patterns en application programmes d'exemples fournis « dessin géométrique » et « éditeur de MCT/MOT » mise en oeuvre du pattern MVC ; architecture non triviale du modèle ; patterns commande, visiteur... (Voir exécutable)

43 Conclusion sur les projets
Enseigment Cours : très peu Plus de tranversalité TPs : application des patterns progressivement Impossible de maîtriser tous les patterns demandé (observateur, commande, visiteur) Plus de consentration sur l'observateur Cas tranversal Occasion précieuse pour assimiler les design patterns Sacrifier du temps et de l'énergie : nombre d'intervenants, l'encadrement, temps d'encadrement