La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Frédérique Laforest, Télécommunications, Services & Usages 1 Modélisation et Génie logiciel 4 TC Frédérique Laforest, Frédéric Le Mouël.

Présentations similaires


Présentation au sujet: "Frédérique Laforest, Télécommunications, Services & Usages 1 Modélisation et Génie logiciel 4 TC Frédérique Laforest, Frédéric Le Mouël."— Transcription de la présentation:

1 Frédérique Laforest, Télécommunications, Services & Usages 1 Modélisation et Génie logiciel 4 TC Frédérique Laforest, Frédéric Le Mouël

2 Frédérique Laforest, Télécommunications, Services & Usages 2 Objectifs du cours Connaître les principes du génie logiciel et leurs intérêts, connaitre les outils du génie logiciel Connaître les principes objet Savoir lire et mener une conception de système dinformation avec les modèles dUML Connaître les principes des Design Patterns, leur intérêt ainsi que les plus reconnus

3 Frédérique Laforest, Télécommunications, Services & Usages 3 Plan global Introduction Génie logiciel UML Design Patterns

4 Frédérique Laforest, Télécommunications, Services & Usages 4 Outils Partie faite par F Le Mouël

5 Frédérique Laforest, Télécommunications, Services & Usages 5 Génie logiciel 1 Introduction 2 Cycle de vie, prototype 3 Normalisation 4 Tests 5 Refactoring

6 Frédérique Laforest, Télécommunications, Services & Usages 6 1- Introduction : Caractéristiques du logiciel Produit unique –conçu et fabriqué une seule fois, reproduit Inusable –défauts pas dus à l'usure mais proviennent de sa conception Complexe –le logiciel est fabriqué pour soulager l'humain d'un problème complexe ; il est donc par nature complexe Invisible –Fabrication du logiciel=activité purement intellectuelle difficulté de perception de la notion de qualité du logiciel Technique non mature –encore artisanal malgré les progrès

7 Frédérique Laforest, Télécommunications, Services & Usages 7 Constats Le coût du développement du logiciel dépasse souvent celui du matériel, Les coûts dans le développement du logiciel : –20% pour le codage et la mise au point individuelle, –30% pour la conception, –50% pour les tests d'intégration, Durée de vie d'un logiciel de 7 à 15 ans, Le coût de la maintenance évolutive et corrective constitue la part prépondérante du coût total, Plus de la moitié des erreurs découvertes en phases de tests proviennent d'erreurs introduites dans les premières étapes, La récupération d'une erreur est d'autant plus coûteuse que sa découverte est tardive.

8 Frédérique Laforest, Télécommunications, Services & Usages 8 Les plaintes classiques des clients Non respect du cahier des charges, Délais et coûts dépassant les prévisions, Maintenance corrective et évolutive difficiles, Non respect des performances, Documentations absentes ou peu claires, Fiabilité discutable. QUALITE du logiciel, Génie logiciel

9 Frédérique Laforest, Télécommunications, Services & Usages 9 Génie logiciel Ensemble des activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi. Arrêté ministériel du 30/12/1983 Procédures, méthodes, langages, ateliers, imposés ou préconisés par les normes, adaptés à l'environnement d'utilisation afin de favoriser la production et la maintenance de composants logiciels de qualité. P. Jaulent

10 Frédérique Laforest, Télécommunications, Services & Usages 10 Concevoir un SI Concevoir : se représenter par la pensée, comprendre La conception : mélange de problèmes –conceptuels (modèles, formalismes), –organisationnels (structure de l'entreprise), –techniques (matériel, logiciel), –économiques (coûts, gains), –sociaux (changement d'emploi, technicité, formation…) En plus, l'entreprise ne s'arrête pas : concevoir dans une organisation –en fonctionnement, –en perpétuelle évolution.

11 Frédérique Laforest, Télécommunications, Services & Usages 11 Concevoir un SI Cest utiliser une démarche bien gérée –Pas de travail empirique –Mais un projet à conduire Utiliser une méthode Méthode = réponse aux questions : –que faire ? –quand ? –où ? –avec qui ? –comment ?

12 Frédérique Laforest, Télécommunications, Services & Usages 12 Modèles, méthodes et outils pour les SI Modèles : –ensemble de concepts permettant de construire une représentation de l'entreprise Démarche (Méthode) : –ensemble coordonné de règles opératoires qui permet de résoudre un problème en accord avec les modèles –découpe le projets en étapes à suivre : spécifier, concevoir, développer, tester, implanter, maintenir Outils logiciels : –ensemble des aides (logiciels) que l'ordinateur fournit dans le processus de conception : on parle d'Atelier Génie Logiciel (AGL) ou Computer Aided System Engineering (CASE)

13 Frédérique Laforest, Télécommunications, Services & Usages Cycle de vie : les étapes du logiciel Compréhension du problème et des besoins Description de ce que le système doit faire : Le que faire Utilisation du logiciel, maintenance corrective et évolutive Vérification de réponse aux spécifications, performances… Assemblage planifié des portions, conformité par rapport aux besoins Développement des sources et tests des portions Le comment faire : algorithmes... Analyse (spécification des besoins) conception préliminaire (spécifications) conception détaillée Codage et tests unitaires Intégration et validation Recette Exploitation et maintenance

14 Frédérique Laforest, Télécommunications, Services & Usages 14 Cycle de vie en cascade Analyse conception Codage Tests Chaque étape validée n'est plus remise en cause Ne prend pas en compte l'intégralité du cycle de vie

15 Frédérique Laforest, Télécommunications, Services & Usages 15 Modèle en V Spécification du système et des besoins Conception du système Spécification des sous-systèmes Construction Conception des modules Test des sous-systèmes Test du système Livraison du système Test des modules Modèle utilisateur Modèle d'implantation Modèle architectural

16 Frédérique Laforest, Télécommunications, Services & Usages 16 Modèle de la fontaine Processus incrémental et itératif Chaque étape peut fournir des résultats modifiant le résultats des précédentes MaintenanceDéveloppements ultérieurs Test du logiciel Utilisation Spécification caractéristiques Conception Codage Analyse besoins Spécification besoins

17 Frédérique Laforest, Télécommunications, Services & Usages 17 Modèle en spirale Prototype incrémental Coût cumulatif Evaluer les alternatives Identifier et éviter les risques Développer et vérifier le prochain niveau du produit Déterminer les objectifs, les alternatives, les contraintes Organiser les phases suivantes Prévision besoins projet proto1 proto2 proto3 Proto opérationnel Analyse des risques Concevoir opérations Simul. Modèles Benchmarks Conception détaillée Conception Spec. besoins Valider conception Codage Tests Accepter tests Organisation développement Intégration et test de l'organisation du projet Revue critique Progresser par étapes

18 Frédérique Laforest, Télécommunications, Services & Usages 18 Prototype Des buts différents : fabrication incrémentale du produit –partir d'une version très allégée –progressivement ajouter des fonctionnalités –prototype "produit" démonstration de la faisabilité –implanter une partie des fonctionnalités –montrer que possible –prototype "jetable" NB : maquette –présentation de l'interface utilisateur, ne fonctionne pas

19 Frédérique Laforest, Télécommunications, Services & Usages Normalisation A de nombreux niveaux –Nommage des variables, classes, packages –Plan-type des documents rédigés (specs, dev, tests…) –Numérotation des versions (releases) –… But : pérenniser le travail effectué, gagner du temps par la suite –Savoir où chercher quelle info –Comprendre la structure à partir des libellés (noms de classes, variables, titres de chapitres…) Chaque organisation / projet a sa norme

20 Frédérique Laforest, Télécommunications, Services & Usages 20 Exemple : numérotation releases Pour le noyau Linux (qui sert souvent de modèle) : Version.Majeure.Mineure.Révision Fev 06 : Changement de –Version : modification radicale de la conception. –Majeure : incompatibilité arrière (gros changements). De plus, n° pair = version stable et n° impair = version de dev. –Mineure : modifications du code source comme ajout de fonctionnalité, correction de bugs, etc. –Révision : modification mineure qui ne nécessite pas forcément une maj.

21 Frédérique Laforest, Télécommunications, Services & Usages 21 Exemple : numérotation releases packages Gentoo, la Révision correspond au -rXX $ eix firefox-bin * www-client/mozilla-firefox-bin Available versions: ~1.5-r2 ~ –NB : Gentoo remplace peu à peu les -rXX par un 4e chiffre, comme pour le noyau Linux. –NB2 : ~ signifie instable ; parfois [M] pour masked (en cours de dev!) Chez d'autres projets, il n'y a qu'un numéro pour Version + Majeure : $ eix emacs -a -C app-editors * app-editors/emacs Available versions: ~ r1 Chez d'autres encore, il n'y a qu'un numéro tout court : $ eix xterm * x11-terms/xterm Available versions: ~208

22 Frédérique Laforest, Télécommunications, Services & Usages 22 Mesurer la qualité dun logiciel Il faut définir des « choses » à mesurer Les mesures peuvent être qualitatives ou quantitatives Elles doivent être explicites! Approche de Mc Call Plan assurance qualité

23 Frédérique Laforest, Télécommunications, Services & Usages 23 Approche de Mc Call : assurance qualité Facteurs (11) : qualité vue de l'utilisateur Critères (23) : qualité vue du réalisateur Mesures (176) : qualité vue du contrôle Liaisons (facteur -> critères -> mesures) intuitives Exemple –facteur : fiabilité –critères : cohérence, robustesse simplicité –mesures : présence d'une administration des données, couverture des tests, taux de panne...

24 Frédérique Laforest, Télécommunications, Services & Usages 24 Facteurs de Mc Call –Conformité –Fiabilité –Intégrité –Maniabilité –Maintenabilité –Testabilité –Evolutivité –Réutilisabilité –Portabilité –Efficacité –Couplabilité On pourrait ajouter (France Télécom) confidentialité auditabilité intégrabilité

25 Frédérique Laforest, Télécommunications, Services & Usages 25 Critères de Mc Call Indépendance vis à vis du système Indépendance vis à vis du matériel Instrumentation (traces fonctionnement) Efficacité de stockage Modularité Précision Contrôle des accès Rapidité Tolérance aux pannes Simplicité Traçabilité Vérification des accès Autodescription Standardisation des données Standardisation des interfaces Généralité Clarté Concision Complétude Extensibilité Facilité d'apprentissage Facilité d'utilisation Homogénéité

26 Frédérique Laforest, Télécommunications, Services & Usages 26 Plan assurance qualité logicielle Document "contractuel" énonçant les modes opératoires, les ressources, la séquence des activités liées à la qualité, se rapportant à un produit, service, contrat ou projet particulier. –Préciser les responsabilités des différents partenaires –Différentes actions d'assurance et de contrôle de qualité –Déterminer les produits attendus et les critères d'acceptation du logiciel –Prévoir l'organisation de la recette des sous-produits –Définir les rôles et les responsabilités des experts internes et externes (audit, sécurité, ergonomie…) –...

27 Frédérique Laforest, Télécommunications, Services & Usages Tests du logiciel Test = technique de contrôle consistant à s'assurer, grâce à l'exécution d'un programme, que son comportement est conforme à un comportement de référence préalablement formalisé dans un document Le test sert à prouver l'existence d'erreurs plutôt que leur absence!

28 Frédérique Laforest, Télécommunications, Services & Usages 28 de M. Arnoldi à K. Beck (traduit) « Malheureusement, pour moi en tout cas (et pas seulement pour moi), les tests vont à lencontre de la nature humaine. Quand on lâche le porc quon a en soi, on saperçoit quon est capable de programmer sans tests. Ce nest quau bout dun moment que notre côté rationnel regagne le dessus, et quon commence à écrire des tests. […] la programmation en binômes réduit la probabilité que les deux partenaires lâchent leur porc respectif au même moment. »

29 Frédérique Laforest, Télécommunications, Services & Usages 29 Tests dans le cycle de vie Les tests sont écrits lors de la rédaction des spécifications! –Spécification fonctionnelle -> tests de validation –Conception préliminaire -> tests d'intégration –Conception détaillée -> tests unitaires (par module)

30 Frédérique Laforest, Télécommunications, Services & Usages 30 Spécifier une fonction Ne pas regarder comment elle fait Mais préciser : –QUOI elle doit faire (description) –Dans quel contexte (pré-conditions) –Avec quel résultat (post-conditions) On peut donc, avant de réfléchir au comment faire –Donner lensemble des cas dutilisation –En déduire la liste des tests à faire et les coder « les tests me donnent une occasion de réfléchir à ce que je veux obtenir sans considération de la façon dont je vais implémenter »

31 Frédérique Laforest, Télécommunications, Services & Usages 31 Types de tests Unitaires : ceux du programmeur –Tests fonction par fonction –doivent être positifs à 100% sur le code passé et courant Tests dintégration : ceux du concepteur –groupent plusieurs fonctions Tests fonctionnels : ceux du client –Tests scénario par scénario –Tant que produit non fini, pas forcément positif à 100%

32 Frédérique Laforest, Télécommunications, Services & Usages 32 Types de tests Autres –Tests parallèles : valider que la nouvelle version fait exactement comme la précédente –Tests en charge –Tests du singe : un ingénu (naive in english) se sert du système et fait nimporte quoi Boîte noire ou boîte blanche? –Test boîte noire : test fonctionnement : sans aller voir à l'intérieur, répond-il au besoin? –Test boîte blanche : test structurel : en allant voir sa composition, répond-il Bien au besoin?

33 Frédérique Laforest, Télécommunications, Services & Usages 33 Classes de tests Test des cas normaux –utilisation normale du logiciel Test des cas anormaux –exemples : vérification des données en entrée validation des procédures de reprise Cas limites et valeurs spéciales –exemples : table pleine, table vide fichier inexistant

34 Frédérique Laforest, Télécommunications, Services & Usages 34 Sorganiser pour tester Certains langages fournissent des bibliothèques de fonctions pour automatiser le lancement des tests et la gestion des résultats –Java Junit par exemple Faire des tests indépendants les uns des autres –Pas de tests imbriqués –Un test qui échoue ne fait pas échouer les tests suivants Faire des tests automatisés –Non équivoques –Pas de saisie de lutilisateur, tout en dur Faire un makefile /ant pour compiler et lancer automatiquement tous les tests

35 Frédérique Laforest, Télécommunications, Services & Usages 35 Conclusion tests Prévoir les tests et les rédiger avant de coder chaque fonction Faire des tests unitaires, puis des tests dintégration, puis des tests fonctionnels Utiliser un environnement de tests pour aller plus vite Réutiliser les tests et leurs résultats comme documentation

36 Frédérique Laforest, Télécommunications, Services & Usages Refactoring Martin Fowler "... process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." Just cleaning up code. Kent Beck "Programs have two kinds of value: what they can do for you today and what they can do for you tomorrow." Don Roberts"The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor."

37 Frédérique Laforest, Télécommunications, Services & Usages 37 Refactoring Pourquoi? –Améliorer la conception et la structure du code –Plus facile à maintenir –Plus facile à comprendre –Plus facile à modifier –Plus facile dajouter des nouvelles fonctionnalités Un élément-clef de l'eXtreme Programming, où par définition le programme peut et doit être constamment remanié pour améliorer sa structure sans modifier son comportement.

38 Frédérique Laforest, Télécommunications, Services & Usages 38 Refactoring sous Eclipse menu Refactor du menu principal, ou du menu contextuel de la zone de code à modifier. –les fonctions proposées dépendent du code sélectionné. une vingtaine de fonctions de refactoring. –Extract Method : Crée une nouvelle méthode encapsulant les éléments sélectionnés, et remplace toutes les références à ces éléments (même ailleurs dans le code), par un appel vers cette méthode. –Rename : Renomme l'élément sélectionné. –Move : Déplace l'élément sélectionné, par exemple enlever la classe du paquetage actuel, et la place dans un autre paquetage –Change Method Signature –Extract Local Variable : crée une nouvelle variable assignée à l'expression sélectionnée. –Inline : fonction inverse de Extract Local Variable

39 Frédérique Laforest, Télécommunications, Services & Usages 39 Refactoring sous Eclipse –Convert Local Variable to Field : Transforme une variable locale, définie dans une méthode, en champ de classe. –Push Down / Pull Up : déplace la sélection vers la sous-classe ou la superclasse actuelle. –Introduce Parameter : Remplace une expression par une référence à un nouveau paramètre, et met à jour toutes les expressions faisant appel à cette méthode. –Extract Constant : Crée un champ de classe avec attributs static et final à partir des expressions sélectionnées, et remplace ces dernières par une référence à la constante. –Use Supertype Where Possible : Remplace les occurrences d'un type par l'un de ses supertypes, non sans avoir identifié auparavant tous les emplacements où ce remplacement est possible.

40 Frédérique Laforest, Télécommunications, Services & Usages 40 Refactoring sous Eclipse –Generalize Type : Présente à l'utilisateur une fenêtre dans laquelle il pourra choisir l'un des supertypes de la référence sélectionnée, celles permettant un changement sans risque de type étant colorées. –Extract Interface : À l'instar des précédentes fonctions de types Extract, celle-ci se charge de prendre les éléments sélectionnes et d'en tirer une classe disposant des méthodes de la classe en cours, et implémente cette interface sur la classe. –Encapsulate Field : Remplace toutes les références à un champ de classe, par des méthodes get et set pour ce champ. –Introduce Factory : Crée une nouvelle méthode de type Factory, en générant pour un constructeur donné la méthode statique appropriée.

41 Frédérique Laforest, Télécommunications, Services & Usages 41 UML / Introduction aux objets / Objet, classe / Les modèles d'UML / Etude de cas

42 Frédérique Laforest, Télécommunications, Services & Usages 42 / Introduction : Objets Objet –Association de données et traitements dans une même entité Idée de base (1966, Simula) –cacher structure de données par opérations de manipulation : Types Abstraits de Données (TAD) Fondement de l'objet (1976, Smalltalk) –ajouter des hiérarchies de généralisation entre les TAD : Classes –(a également été le berceau de l'écran bitmap avec souris)

43 Frédérique Laforest, Télécommunications, Services & Usages 43 Objets : 3 points de vue Structurel –objet = instance d'un type avec structure cachée par opérations : Encapsulation Conceptuel –objet=concept du monde réel qui peut être spécialisé Acteur –objet=entité autonome qui répond à des messages

44 Frédérique Laforest, Télécommunications, Services & Usages 44 Objets : motivations Développement de logiciels complexes –représenter directement les objets réels sans déformation –réutiliser et étendre l'existant –environnements de développement riches –créer rapidement des interfaces homme-machine événementielles –prototypage rapide (implantation partielle) –facilité d'exploitation du parallélisme

45 Frédérique Laforest, Télécommunications, Services & Usages 45 / Concepts objet : objet Objet = identité + état + comportement Identité (OId) –identifiant typiquement interne au système –implantation souvent par pointeurs Etat – valeur simple ou structurée (comportant valeurs, objets…) Comportement –ensemble d'opérations applicables à l'objet définies dans sa classe Par extension, objet = identité + classe + état représenté dans un rectangle avec texte souligné

46 Frédérique Laforest, Télécommunications, Services & Usages 46 Concepts objet : classe Classe = instanciation + attributs + opérations Instanciation –mécanisme de création d'objets –ensemble des objets instanciés = extension de la classe Attributs (ou variables d'instance) –structure de la classe –nom + type (simple ou classe) Opérations (méthodes) –opérations qui peuvent être appliquées aux instances représentée dans un rectangle

47 Frédérique Laforest, Télécommunications, Services & Usages 47 Concepts objet : identité et égalité, visibilité Identité et égalité –Deux objets sont identiques OId identiques –Deux objet sont égaux même état –Liens entre objet = références aux OId Visibilité –Membre public fait partie de l'interface de la classe –Membre privé fait partie de l'implantation de la classe sert uniquement à développer la classe

48 Frédérique Laforest, Télécommunications, Services & Usages 48 Concepts objet : agrégation Des objets complexes comprenant d'autre objets –traduction du verbe avoir –composition : si je détruis l'objet complexe, je détruis ses composants –référence : si je détruis l'objet complexe, je ne détruis pas ceux reliés Exemple type : la nomenclature Bicyclette RoueGuidonCadre RayonJantePneu... Médecin Patient 1..n

49 Frédérique Laforest, Télécommunications, Services & Usages 49 Concepts objet : associations entre classes On utilise souvent les associations binaires Les associations peuvent être aussi traduites par des objets Elève Professeur Enseignement VoiturePropriétaire Appartient

50 Frédérique Laforest, Télécommunications, Services & Usages 50 Concepts objet : généralisation Lorsque tous les objets d'une classe appartiennent aussi à une autre classe plus générale –traduction du verbe être –la sous-classe possède toutes les propriétés et méthodes de la surclasse en plus des siennes propres Exemple : –La classe C (Carré) et la classe L (Losange) –On dit que L généralise C et que C spécialise L –C est une sous-classe de L, L est une sur-classe de C Carré Losange

51 Frédérique Laforest, Télécommunications, Services & Usages 51 Concepts objet : délégation Le client envoie un message à un objet "interface" qui propage le message aux objets exécutants –le client ne connaît pas directement le fournisseur –les exécutants peuvent changer dans le temps client "interface" Délégué 1 Délégué 2 message propagation Nb : cf. Les proxys

52 Frédérique Laforest, Télécommunications, Services & Usages 52 / Objet : vers une notation unifiée De nombreuses méthodes (>100) ayant des avantages et des inconvénients différents Pour pouvoir passer de l'une à l'autre, une notation unifiée : UML UML : Unified Modeling Language –pas de méthode préconisée –un glossaire de termes et de représentations graphiques –rapprochement de OOD, OMT, OOSE

53 Frédérique Laforest, Télécommunications, Services & Usages 53 UML - historique 1994, Rumbaugh rejoint Booch chez Rational Software –but : créer une méthode en commun –1995 : présentation v , rachat d'Objectory, arrivée de Jacobson 1996, LANGAGE unifié UML 1997 –présentation de UML à l'OMG (Object Management Group) –UML 1.1 adopté par la plupart des compagnies

54 Frédérique Laforest, Télécommunications, Services & Usages 54 UML - principes 4 objectifs –représenter des systèmes entiers par des concepts objet –établir un couplage explicite entre concepts et artefacts exécutables –prendre en compte les facteurs d'échelle inhérents aux systèmes complexes et critiques –créer un langage de modélisation utilisable à la fois par les humains et les machines Propose 9 diagrammes différents –A chacun de choisir les diagrammes utiles à son cas –Pas de méthode pour lutilisation des diagrammes

55 Frédérique Laforest, Télécommunications, Services & Usages 55 UML : les mécanismes de base Assurent lintégrité de la notation Stéréotype –classer les éléments du modèle en familles Etiquette –paire (nom,valeur) décrivant une propriété Note –commentaire Relation de dépendance –relation d'utilisation entre 2 éléments Contrainte –restriction aux éléments du modèle

56 Frédérique Laforest, Télécommunications, Services & Usages 56 > Œuvre Etat=testé Auteur écrire {ordonne} UML : mécanismes de base Contrainte Relation Note Stéréotype Etiquette

57 Frédérique Laforest, Télécommunications, Services & Usages 57 UML : Diagramme des cas d'utilisation diagramme des cas d'utilisation d'un véhicule Acteur Cas d'utilisation Bornes du système

58 Frédérique Laforest, Télécommunications, Services & Usages 58 UML : diagramme des cas d'utilisation modéliser –les fonctionnalités du système –et les attentes des utilisateurs servent également de base pour les jeux dessais Un diagramme comprend –les acteurs, –le système, –les cas d'utilisation eux-mêmes

59 Frédérique Laforest, Télécommunications, Services & Usages 59 UML : acteurs 4 catégories dacteurs –acteurs principaux ou utilisateurs des fonctions principales du système –acteurs secondaires qui effectuent des tâches administratives ou de maintenance –matériel externe ou dispositifs incontournables faisant partie du domaine de lapplication –autres systèmes avec lesquels le système doit interagir

60 Frédérique Laforest, Télécommunications, Services & Usages 60 UML : cas dutilisation Avantage –simplicité de représentation Inconvénients –pas hiérarchisés et ne prennent pas en compte la complexité des SI –ne font pas apparaître les ressources exploitées par les fonctions –ne permettent pas une bonne traçabilité vers les autres diagrammes.

61 Frédérique Laforest, Télécommunications, Services & Usages 61 UML : Diagramme de séquence

62 Frédérique Laforest, Télécommunications, Services & Usages 62 Autre exemple diagramme de séquence

63 Frédérique Laforest, Télécommunications, Services & Usages 63 Encore un autre exemple diagramme séquence Multithread/ multiprocess appel en interne, récursivité

64 Frédérique Laforest, Télécommunications, Services & Usages 64 UML : Diagramme de classes Plus ou moins détaillé selon l'étape Classes –nom, attributs, méthodes Relations –relations de composition et référence ("fait partie de") –relations de généralisation ("est une sorte de") –relations quelconques ("est produit par", "est affilié à", "se trouve à", "est conduit par"…) seront traduites par composition, référence, nouvelle classe… Paquetages Interfaces

65 Frédérique Laforest, Télécommunications, Services & Usages 65 Diagramme de classes : Classes + public - privé # protégé Classe paramétrée Instanciation d'une classe paramétrée

66 Frédérique Laforest, Télécommunications, Services & Usages 66 Diagramme de classes : Agrégation composition référence

67 Frédérique Laforest, Télécommunications, Services & Usages 67 Diagramme de classes : Généralisation Contraintes possibles : complete, incomplete, disjoint, overlapping

68 Frédérique Laforest, Télécommunications, Services & Usages 68 Diagramme de classes : Associations

69 Frédérique Laforest, Télécommunications, Services & Usages 69 Diagramme de classes : Paquetages Gestion Regroupement logique de classes –clarté –partage du travail dans une équipe

70 Frédérique Laforest, Télécommunications, Services & Usages 70 Diagramme de classes : Interfaces Présenter un objet sous différentes facettes –une interface= une facette –ensemble de signatures de méthodes sans implantation Contrat d'implantation de méthodes en C++ : des classes virtuelles, en java : des interfaces Exemple –interface "stockable" pour persistance méthodes sauver(), récupérer() –interface "visualisable" pour présentation méthodes afficher(), imprimer() Abonné stockable

71 Frédérique Laforest, Télécommunications, Services & Usages 71 UML : diagramme d'objets Dérivé du diagramme de classes (souligné : objet) –montrer un état mémoire à un instant t –faciliter la compréhension des structures complexes (récursivité, associations ternaires…) Etienne:Personne Jean-Luc:Personne Patron Denis:Personne Patron Diagramme de classesDiagramme d'objets

72 Frédérique Laforest, Télécommunications, Services & Usages 72 UML : diagramme de collaboration Interactions entre objets –diagramme d'objets avec les envois de messages –corrélé au diagramme de séquences qui insiste sur l'aspect chronologique plutôt que sur les interactions contrôleur ascenseur portes ascenseur bouton ascenseurbouton étage ascenseur 1Appui bouton étage > 6Appui bouton ascenseur > 5 ouvrir ^ 11 ouvrir ^ 8 fermer ^ 13 fermer ^ 12 timer 7 allumer < 10 éteindre < 3 déplacer > 9 déplacer > 2 allumer > 4 éteindre >

73 Frédérique Laforest, Télécommunications, Services & Usages 73 UML : diagramme Etats-transitions Porte fermée appuiBouton [non verrouillée] / ouvrir() Porte ouverte appuiBouton [non verrouillée] / fermer() Les changements détat dun objet dune classe pendant sa durée de vie

74 Frédérique Laforest, Télécommunications, Services & Usages 74 UML : Diagramme dactivités Donne la liste des étapes suivies pour accomplir une action (algorithme dune fonction)

75 Frédérique Laforest, Télécommunications, Services & Usages 75 Autre exemple diagramme d'activités Mesurer température RefroidirChauffer [trop froid] [trop chaud] garde Arrêter chauffage Ouvrir la fenêtre synchronisation Aérer Fermer la fenêtre Donner consigne t° Thermostat Consigne atteinte Envoi et réception de signaux

76 Frédérique Laforest, Télécommunications, Services & Usages 76 Diagramme dactivités encore

77 Frédérique Laforest, Télécommunications, Services & Usages 77 UML : diagramme de composants Abonné

78 Frédérique Laforest, Télécommunications, Services & Usages 78 UML : diagramme de déploiement

79 Frédérique Laforest, Télécommunications, Services & Usages 79 UML : les 9 diagrammes Cas dutilisation –vues que les utilisateurs ont du système en termes de fonctions Classes –classes et relations qui les lient Objets –instances de classes Séquence –interactions entre objets ordonnées dans le temps Collaboration –interactions entre objets...

80 Frédérique Laforest, Télécommunications, Services & Usages 80 UML : les 9 diagrammes (suite) Etats-transitions –cycles de vie des objets Activité –sémantique dune opération en termes dactions Composants –dépendances de compilation et/ou d'exécution des composants d'une application Déploiement –équipements et modes de connexion

81 Frédérique Laforest, Télécommunications, Services & Usages 81 Classification des diagrammes Conception –cas d'utilisation –séquence Structure –classes –objets Dynamique –collaboration –séquence –états-transitions –activités Composants –composants Déploiement –déploiement

82 Frédérique Laforest, Télécommunications, Services & Usages 82 / Etude de cas : distributeur de boissons Application Distri : un distributeur automatique de boissons Les classes –acteur Client –acteur Employé –Machine Distributeur

83 Frédérique Laforest, Télécommunications, Services & Usages 83 Distri : Diagramme des cas d'utilisation Prendre une boisson Gérer la machine Machine distributrice

84 Frédérique Laforest, Télécommunications, Services & Usages 84 Distri : Diagramme de séquence Etc... :Automate Gobelets :Automate Boissons

85 Frédérique Laforest, Télécommunications, Services & Usages 85 Distri : diagramme de classes Consommateur DistributeurDeBoissons Monnayeur AutomateBoissons AutomateGobelets Static nbGobelets introduction récupérer rendre choisir retirer distribution * 0..* 0..1

86 Frédérique Laforest, Télécommunications, Services & Usages 86 Distri : diagramme de collaborations Pièces : Monnayeur leGestionnaire : Gestionnaire uneMDB : DistributeurDeBoissons unGobelet :AutomateGobelets uneBoisson : AutomateBoissons unEcran : Ecran selectionnerChoix(unChoix) 1.1. Placer() Préparer() Verser() 1. sommeSuffisante(unChoix):booleen sommeIntroduite():Somme sommeARendre(unChoix):Somme Stop() sommeManquante(unChoix):Somme rendreMonnaie(somme) rendreMonnaie(somme)

87 Frédérique Laforest, Télécommunications, Services & Usages 87 Nouvelle version diagramme de classes Consommateur DistributeurDeBoissons sélectionnerChoix() Monnayeur Vector piecesDispo rendreMonnaie() AutomateBoissons Préparer() Verser() AutomateGobelets Static nbGobelets Placer() introduction récupérer rendre choisir retirer distribution * 0..* 0..1

88 Frédérique Laforest, Télécommunications, Services & Usages 88 Conclusion UML UML nest pas une méthode, mais un ensemble de modèles UML est un standard international Ces modèles sont simples –faciles à lire et donc à communiquer –mais difficiles pour des systèmes très complexes

89 Frédérique Laforest, Télécommunications, Services & Usages 89 4TC-MPO Stéphane Frénot (tiré de [Jia 2000], réadapté par F. Laforest ) Les Design Patterns

90 Frédérique Laforest, Télécommunications, Services & Usages 90 Design patterns Origine : Christopher Alexander pour décrire la conception d'architectures de bâtiments (253 modèles) « Chaque moule (pattern) décrit un problème qui réapparaît de manière régulière dans notre environnement, puis il décrit le noyau de la solution du problème, de telle manière que vous pouvez réutiliser cette solution autant de fois que vous le voulez, sans jamais réaliser la solution finale deux fois de suite de la même manière »

91 Frédérique Laforest, Télécommunications, Services & Usages 91 Architecture bâtiment / conception logiciel Des processus de création qui peuvent se décliner de nombreuses manières Le résultat final doit satisfaire les besoins de l'utilisateur Le résultat final doit être réalisable par les ingénieurs Les concepteurs doivent prendre en compte de nombreux facteurs de contraintes et de nombreux besoins Les concepteurs doivent atteindre certains but intrinsèques mais peu mesurables (élégance, extensibilité…)

92 Frédérique Laforest, Télécommunications, Services & Usages 92 En conception de logiciels Un livre-bible : –le GOF –23 patterns décrits, classés en 3 catégories création structuration comportements Description d'un pattern –Nom, Catégorie, Objectif, Contexte d'application, Structure, Participants...

93 Frédérique Laforest, Télécommunications, Services & Usages 93 Design Pattern : Singleton Pour des services "centralisés"

94 Frédérique Laforest, Télécommunications, Services & Usages 94 Singleton Nom : Singleton Catégorie : Création Objectif : Contraindre qu'une classe ne possède qu'une seule instance, et fournir un point d'accès unique à cet objet Contexte dapplication : Utiliser cette classe quand il ne faut qu'une seule instance de la classe et qu'elle soit accessible de manière unique par les clients (e.g. UNE file dimpression) Structure : Singleton

95 Frédérique Laforest, Télécommunications, Services & Usages 95 Exemple d'implantation du Singleton public class Singleton { }

96 Frédérique Laforest, Télécommunications, Services & Usages 96 Design Pattern : Template Method Pour factoriser les codes communs

97 Frédérique Laforest, Télécommunications, Services & Usages 97 Factorisation Un des objectifs de la programmation OO est de trouver des composants génériques. Pour trouver des composants génériques il faut trouver le code récurrent dans différents objets et le factoriser Intérêts : maintenance, taille du code...

98 Frédérique Laforest, Télécommunications, Services & Usages 98 Principe de factorisation Identifier des segments de code qui implantent la même logique, souvent dans le même morceau de code, dans plusieurs endroits Capturer cette logique dans un composant générique défini une seule fois Réorganiser le code de telle manière que chaque occurrence de code est remplacée par l'utilisation du composant générique

99 Frédérique Laforest, Télécommunications, Services & Usages 99 Techniques de factorisation Par généralisation des méthodes Par héritage Par délégation

100 Frédérique Laforest, Télécommunications, Services & Usages 100 Factorisation de méthodes Public class Calcul { void méthode1 (…){ //… calculEtape1(); calculEtape2(); calculEtape3(); //… } void méthode2(…){ //… calculEtape1(); calculEtape2(); calculEtape3(); //… } Public class CalculFactorisé { }

101 Frédérique Laforest, Télécommunications, Services & Usages 101 Factorisation par héritage Les méthodes à généraliser sont souvent dans des classes différentes public class CalculA { void méthode1 (…){ //… calculEtape1(); calculEtape2(); calculEtape3(); //… } public class CalculB { void méthode1 (…){ //… calculEtape1(); calculEtape2(); calculEtape3(); //… } public class Commune { } public class CalculA { }

102 Frédérique Laforest, Télécommunications, Services & Usages 102 public class Helper { } public class CalculA { } Factorisation par délégation Utiliser un objet dune autre classe pour faire le calcul sans utiliser dhéritage (souplesse pour les langages sans héritage multiple)

103 Frédérique Laforest, Télécommunications, Services & Usages 103 public CalculA { void méthode1 (…){ (code commun Segment1) (code spécifique au contexte) (code commun Segment2) } public CalculB { void méthode1 (…){ (code commun Segment1) (code spécifique au contexte) (code commun Segment2) } Factorisation : allons plus loin Insertion de code spécifique au milieu de code commun

104 Frédérique Laforest, Télécommunications, Services & Usages 104 Factorisation par héritage ou délégation OK si codes 1 et 2 indépendants Sinon rupture de logique ==> problème public Commune { void codeCommun1 (…){ (code commun Segment1) } void codeCommun2 (…){ (code commun Segment2) } 1ère solution

105 Frédérique Laforest, Télécommunications, Services & Usages 105 public abstract class Commune { void code(…){ (code commun Segment1) appelDeContexte(); (code commun Segment2) } abstract void appelDeContexte (…); } On préfère : Template (Patron) Utiliser une classe abstraite –méthode abstraite pour le code spécifique au contexte

106 Frédérique Laforest, Télécommunications, Services & Usages 106 Design Pattern : Template Method –Nom : Template Method –Catégorie : comportement –Objectif : définir le squelette d'un algorithme dans une méthode, en laissant certaines étapes aux sous-classes. Permet ainsi aux sous-classes de redéfinir certaines étapes de l'algorithme –Domaine d'application : il doit être utilisé pour : implanter une seule fois les parties invariantes d'un algorithme et laisser aux sous-classes le comportement qui peut varier factoriser et localiser les comportements communs des sous-classes afin d'éviter la duplication de code

107 Frédérique Laforest, Télécommunications, Services & Usages 107 Template Method : Structure

108 Frédérique Laforest, Télécommunications, Services & Usages 108 Design Pattern : Strategy Pour des fonctionnalités génériques

109 Frédérique Laforest, Télécommunications, Services & Usages 109 Généralisation « La généralisation est le processus qui consiste à prendre une solution spécifique à un problème et la réorganiser afin qu'elle résolve le problème original mais également une catégorie de problèmes similaires. »

110 Frédérique Laforest, Télécommunications, Services & Usages 110 Exemple On veut réaliser un outils d'affichage de piles protocolaires Problème : –Comment séparer les différentes fonctions de désencapsulation du code de l'afficheur Solution directe : –L'afficheur définit autant de méthodes que de fonctions à afficher public abstract Afficheur { abstract double afficheMAC (Paquet x); abstract double afficheIP (Paquet x); abstract double afficheTCP (Paquet x);... }

111 Frédérique Laforest, Télécommunications, Services & Usages 111 Le problème Dans ce cas le code est peu flexible et peu élégant Des codes similaires seront répliqués dans chaque fonction Résiste mal à l'évolution de la pile protocolaire ==> Le mieux est de représenter chaque fonction non pas comme une méthode, mais comme un objet

112 Frédérique Laforest, Télécommunications, Services & Usages 112 Interface On définit une interface qui représente le comportement voulu pour n'importe quelle fonction-objet public interface Decapsule { String decapsuler(Paquet x); } public class IP implements Decapsule { String decapsuler(Paquet x){ // … Code de décapsulation return trameCommentée; }

113 Frédérique Laforest, Télécommunications, Services & Usages 113 Rôle de l'afficheur L'afficheur maintient alors un tableau sur toutes les fonctions à afficher Il doit fournir les méthodes qui lui permettront d'ajouter et de retirer les fonctions à afficher

114 Frédérique Laforest, Télécommunications, Services & Usages 114 Design Pattern : Strategy –Nom : Strategy –Catégorie : comportement –Objectif : définir une famille d'algorithmes, encapsuler chacun et les rendre interchangeables –Domaine d'application : il doit être utilisé quand : De nombreuses classes ne se distinguent que par leur comportement (plusieurs types d'encapsulation) Différentes versions d'algorithmes sont nécessaires Un algorithme utilise des données qu'un client n'a pas à connaître Une classe définit plusieurs comportements qui sont autant de branches conditionnelles dans ses méthodes

115 Frédérique Laforest, Télécommunications, Services & Usages 115 Strategy : Structure

116 Frédérique Laforest, Télécommunications, Services & Usages 116 Design Pattern : Iterator Pour des parcours indépendants & multiples de collections

117 Frédérique Laforest, Télécommunications, Services & Usages 117 Couplage abstrait Technique qui permet à un client de collaborer avec un fournisseur de services Le client accède au service sans connaître l'implantation exacte du service Exemples : téléphonie, réseau … + Technique : Programmer sur une interface et non pas sur une implantation

118 Frédérique Laforest, Télécommunications, Services & Usages 118 Couplage abstrait pour énumérer des éléments Soit une classe de gestion de liste chaînée Et une classe de description de paquets réseau ==> Je veux itérer sur tous les éléments de ma liste public class Liste implements List { protected Node head, tail; protected int count; //Implantation de la liste class Node { Paquet element; Node next, prev; }

119 Frédérique Laforest, Télécommunications, Services & Usages 119 Solution 1 : Accès direct Nécessite que les champs et la classe interne Node soient accessibles des clients du service Liste maListe; //insérer les éléments dans la liste for (Liste.Node cur=list.head; cur != null; cur=cur.next){ System.out.println(cur.element);...

120 Frédérique Laforest, Télécommunications, Services & Usages 120 Sol. 2 : Itérer par l'invocation de méthodes On définit une sous-classe de List qui permet d'invoquer les méthodes d'itération public class ListeIterable extends List { public void reset(){ cur=head; } public Paquet next(){ Paquet obj=null; if (cur!=null){ obj=cur.element; cur=cur.next; } return obj; } public boolean hasNext(){ return (cur!=null);} protected Node cur; } … ListeIterable maListe; //insérer les paquets for (list.reset(); list.hasNext(); ) System.out.println(list.next());... Problème des boucles imbriquées

121 Frédérique Laforest, Télécommunications, Services & Usages 121 Solution 3 : Séparer l'iterateur de la liste On définit une classe d'iteration qui contient une référence sur la liste de base public class IterateurDeListe { public IterateurDeListe(Liste uneListe){ this.liste=uneListe; cur=liste.head; } public Paquet next(){ Paquet obj=null; if (cur!=null){ obj=cur.element; cur=cur.next; } return obj; } public boolean hasNext(){ return (cur!=null);} protected Liste.Node cur; protected Liste liste; } Ne fonctionne que sur la classe Liste

122 Frédérique Laforest, Télécommunications, Services & Usages 122 Sol. 4 : La généralisation En utilisant le couplage abstrait, le client n'utilise qu'une interface itérateur indépendante de la collection sous- jacente On définit une interface de programmation indépendante …...qu'on implante dans les classes sur lesquelles les itérations sont possibles public interface Iterator { boolean hasNext(); Object next(); void remove(); }

123 Frédérique Laforest, Télécommunications, Services & Usages 123 Sol 4 : Itérateur abstrait public class Liste { //… méthodes de la liste }

124 Frédérique Laforest, Télécommunications, Services & Usages 124 Liste maListe=new Liste(); //… Insertion des éléments Les clients utilisent l'itérateur Chercher les paquets de même pile protocolaire dans la liste maListe (utiliser la méthode isSameStack())

125 Frédérique Laforest, Télécommunications, Services & Usages 125 Design Pattern : Iterator –Nom : Iterator –Catégorie : comportement –Objectif : Fournit un moyen d'accéder à des éléments d'une collection de manière séquentielle –Domaine d'application : il doit être utilisé pour : Accéder au contenu d'une collection sans qu'elle publie sa structure interne Permettre des traversées multiples de collection Fournir une interface d'accès uniforme pour traverser les différentes collections (itération polymorphe)

126 Frédérique Laforest, Télécommunications, Services & Usages 126 Iterator : structure

127 Frédérique Laforest, Télécommunications, Services & Usages 127 Design Pattern : Usine Pour des instanciations génériques

128 Frédérique Laforest, Télécommunications, Services & Usages 128 Afficheur : Schéma UML

129 Frédérique Laforest, Télécommunications, Services & Usages 129 Problématique Encore le couplage abstrait : –La classe cliente du service d'analyse de trame doit : Connaître les algorithmes de désencapsulation Réaliser à la fois de l'affichage et de la gestion –Les stratégies ne sont pas suffisamment découplées du client ==> Une solution : l'usine de fabrication

130 Frédérique Laforest, Télécommunications, Services & Usages 130 L'usine : schéma UML

131 Frédérique Laforest, Télécommunications, Services & Usages 131 Design Pattern : Usine –Nom : Abstract Factory –Catégorie : création –Objectif : définit une interface de création d'objets, mais délègue aux sous-classes quelle classe instancier et comment –Domaine d'application : il doit être utilisé quand : Un système doit être indépendant de la manière de fabriquer ses produits

132 Frédérique Laforest, Télécommunications, Services & Usages 132 Usine : Structure

133 Frédérique Laforest, Télécommunications, Services & Usages 133 Design Pattern : Composite Pour représenter toute hiérarchie de composition

134 Frédérique Laforest, Télécommunications, Services & Usages 134 Awt Java Les widgets –java.awt.Button –java.awt.Canvas –java.awt.Checkbox –java.awt.Choice –java.awt.Label –java.awt.List –java.awt.MenuBar –java.awt.MenuItem –java.awt.TextComponent java.awt.TextArea java.awt.TextField Les container java.awt.Window java.awt.Frame java.awt.Dialog java.awt.FileDialog java.awt.Panel java.applet.Applet Tous les composants graphiques sont reliés par des relations container/contenu

135 Frédérique Laforest, Télécommunications, Services & Usages 135 Awt : Schéma UML

136 Frédérique Laforest, Télécommunications, Services & Usages 136 Design Pattern : Composite –Nom : Composite –Catégorie : structuration –Objectif : Organise les objets dans un arbre pour représenter une partie ou la totalité d'une hiérarchie. Le composite permet aux clients de traiter les objets unitaires et les compositions de la même manière –Domaine d'application : il doit être utilisé quand : On veut représenter une hiérarchie partiellement ou entièrement Le client doit ignorer les différences entre les composants et les composés. Traitement des éléments de manière homogène

137 Frédérique Laforest, Télécommunications, Services & Usages 137 Composite UML

138 Frédérique Laforest, Télécommunications, Services & Usages 138 Design pattern : Décorateur Pour ajouter dynamiquement des fonctionnalités à un objet

139 Frédérique Laforest, Télécommunications, Services & Usages 139 Les entrées/sorties en Java Des classes de base et des classes dérivées –java.io.OutputStream => ByteArrayOutputStream, FileOutputStream, FilterOutputStream, ObjectOutputStream, OutputStream, PipedOutputStream – java.io.InputStream => AudioInputStream, ByteArrayInputStream, FileInputStream, FilterInputStream, InputStream, ObjectInputStream, PipedInputStream, SequenceInputStream, StringBufferInputStream –java.io.Writer =>BufferedWriter, CharArrayWriter, FilterWriter, OutputStreamWriter, PipedWriter, PrintWriter, StringWriter Dans les classes dérivées, des fonctionnalités s'ajoutent à la fonction de base : –Buffer, Compression, Encryption...

140 Frédérique Laforest, Télécommunications, Services & Usages 140 Imbrication de fonctionnalités –PrintWriter transformer des représentations formattés d'objets en flux texte –BufferedWriter utilise un buffer intermédiaire et envoie le flux par paquets –FileWriter écrit le flux dans un fichier –Mettre une représentation d'un objet dans un fichier via buffer : PrintWriter out = new PrintWriter(new BufferedWriter(new FileWriter("foo.out")));

141 Frédérique Laforest, Télécommunications, Services & Usages 141 Ajouter des fonctionnalités Pour mettre en œuvre des ajouts et combinaisons : spécialiser les classes ou utiliser le design pattern décorateur Spécialisation : dès la conception prévoir des classes dérivées Décorateur : ajoute dynamiquement des fonctionnalités à un objet

142 Frédérique Laforest, Télécommunications, Services & Usages 142 Design Pattern : Décorateur Nom : Decorator Catégorie : structuration Objectif : Associer des responsabilités à un objet de manière dynamique. Les décorateurs fournissent une approche flexible à l'héritage pour étendre des capacités Domaine d'application : il doit être utilisé pour : –Ajouter dynamiquement des responsabilités à un objet sans affecter les autres objets de la même classe –Pour des responsabilités qui peuvent être retirées –Quand l'extension de l'arbre d'héritage n'est pas pratique et amène à une explosion du nombre de sous-classes pour pouvoir implanter toutes les combinaisons.

143 Frédérique Laforest, Télécommunications, Services & Usages 143 Décorateur : structure

144 Frédérique Laforest, Télécommunications, Services & Usages 144 Design pattern : Médiateur Autre nom : Proxy Pour ne pas donner un accès direct à un objet, mais utiliser un intermédiaire

145 Frédérique Laforest, Télécommunications, Services & Usages 145 Manipuler des objets gourmands Affichage et manipulation d'images –une image est gourmande en espace mémoire –certaines méthodes ne requièrent pas l'instanciation réelle de l'objet image, mais seulement d'avoir des informations sur l'image Idée –ne créer l'objet que quand réellement nécessaire –utiliser un objet intermédiaire qui répond aux demandes et crée l'objet si nécessaire

146 Frédérique Laforest, Télécommunications, Services & Usages 146 Exemple éditeur de document

147 Frédérique Laforest, Télécommunications, Services & Usages 147 Design Pattern : Médiateur –Nom : Proxy –Catégorie : structuration –Objectif : Fournit un subrogé qui représente un autre objet –Domaine d'application : quand il est nécessaire d'avoir une référence d'objet plus sophistiquée ou versatile que la simple référence (pointeur). Situations où le médiateur est nécessaire : remote proxy : le proxy (stub) fournit une représentation locale d'un objet distant virtual proxy : lorsqu'on utilise des objets consommateurs de temps ou d'espace, le proxy ne crée effectivement l'objet que quand c'est indispensable protection proxy : contrôler l'accès à l'objet original

148 Frédérique Laforest, Télécommunications, Services & Usages 148 Médiateur : structure unClient sujet unProxy sujetReel unObjetReel

149 Frédérique Laforest, Télécommunications, Services & Usages 149 Les patterns du GOF

150 Frédérique Laforest, Télécommunications, Services & Usages 150 Patterns de création (1) Abstract factory : provide an interface for creating families of related or dependent objects without specifying their concrete class Builder : separate the construction of a complex object from its representation so that the same construction process can create different representations Factory method : define an interface for creating an object, but let subclasses decide which class to instanciate. Factory method lets a class defer instanciation to subclasses

151 Frédérique Laforest, Télécommunications, Services & Usages 151 Patterns de création (2) Prototype : specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype Singleton : ensure a class only has one instance, and provide a global point of access to it

152 Frédérique Laforest, Télécommunications, Services & Usages 152 Patterns de structure (1) Adapter : converts the interface of a class into another interface clients expect Bridge : decouple an abstraction from its implementation so that the 2 can vary independantly Composite : compose objects into tree structures to represent part-whole hierarchies Decorator : attach additional resposabilities to an object dynamically

153 Frédérique Laforest, Télécommunications, Services & Usages 153 Patterns de structure (2) Facade : provide a unified interface to a set of interfaces in a subsystem Flyweight : use sharing to support large numbers of fine- grained objects efficiently Proxy : provide a surrogate or placeholder for another object to control access to it

154 Frédérique Laforest, Télécommunications, Services & Usages 154 Patterns de comportement (1) Chain of responsibility : avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request Command : encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations Interpreter : given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language

155 Frédérique Laforest, Télécommunications, Services & Usages 155 Patterns de comportement (2) Iterator : provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation Mediator : define an object that encapsulates how a set of objects interact Memento : without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later Observer : Define a one-to-many dependency between objects so that when one object changes state, all its dependants are notified and updated automatically

156 Frédérique Laforest, Télécommunications, Services & Usages 156 Patterns de comportement (3) State : Allow an object to alter its behavior when its internal state changes. The object will appear to change its class Strategy : define a family of algorithms, encapsulate each one, and make them interchangeable template method : define the skeleton of an algorithm in an operation, deferring some steps to subclasses Visitor : represent an operation to be performed on the elements of an object structure

157 Frédérique Laforest, Télécommunications, Services & Usages 157 Frameworks

158 Frédérique Laforest, Télécommunications, Services & Usages 158 Framework : définition Ensemble de classes coopérantes –qui représente une conception réutilisable d'un système dans un domaine d'application ensemble de classes abstraites et d'interfaces –qui font partie d'applications semi-finies –qui peuvent être spécialisées pour obtenir une application spécifique définit également des conventions pour –étendre le FW initial, –implanter les interfaces –et permettre l'interaction entre les objets but principal –permettre la réutilisation de conceptions et d'implantations dans un domaine d'application spécifique (simplification du développement)

159 Frédérique Laforest, Télécommunications, Services & Usages 159 Caractéristiques d'un framework Extensibilité : –Interfaces, classe abstraites, méthodes génériques... Inversion du contrôle : –L'application est cliente du FW Fondée sur les Design patterns –DP = conception, indépendant du langage –FW = compilable, propre à un langage

160 Frédérique Laforest, Télécommunications, Services & Usages 160 Conception d'un framework ! Plus complexe à concevoir qu'une appli. Complétude Adaptabilité Efficacité Sécurisé Simplicité Extensibilité

161 Frédérique Laforest, Télécommunications, Services & Usages 161 Exemples de frameworks LAWT : Abstract Window Toolkit le JDBC : Java DataBases Connectivity les Beans : Composants logiciels réutilisables JNI : Interface sur des langages natifs (C, C++) RMI : Remote Methode Invocation Les EJB : Enterprise JavaBean; objets serveurs distribués

162 Frédérique Laforest, Télécommunications, Services & Usages 162 Le modèle MVC : introduction Objectif –Développer des applications où les interfaces utilisateurs et le code interne sont dissociés au maximum –Intérêt :interchangeabilité, évolutivité 3 « parties » : Modèle, Vue, Contrôleur

163 Frédérique Laforest, Télécommunications, Services & Usages 163 MVC : Modèle, Vue, Contrôleur Modèle –fonctionnalités de lapplication (EJB session e.g.) Vue –interface utilisateur (classe JTable) Contrôleur –Intermédiaire de communication entre Modèle et Vue –MODELE ET VUE NE SE CONNAISSENT PAS –Toute demande daction émanant de linterface est envoyée au contrôleur, qui redirige à la classe du modèle compétente –Toute information émanant du modèle est envoyée au contrôleur, qui redirige à la classe de la vue compétente

164 Frédérique Laforest, Télécommunications, Services & Usages 164 MVC : abonnement et redirection Principe des abonnements –Le modèle (resp. la vue) définit une liste de « propriétés » dont elle annoncera au contrôleur la modification à chaque fois. –La vue (resp. le modèle) sinscrit auprès du contrôleur pour être prévenu des modifications des propriétés qui lintéressent. –Le contrôleur enregistre une liste dabonnés à des propriétés. A chaque fois quil reçoit une annonce de modification, il la propage à tous les inscrits.

165 Frédérique Laforest, Télécommunications, Services & Usages 165 MVC en Java Classe String –Pour les propriétés, juste un libellé! Classe PropertyChangeEvent –Pour expliquer la modification subie par une propriété –e=new PropertyChangeEvent(this, "age",new Integer(previousAge), new Integer(age)); Interface PropertyChangeListener –Pour les abonnés –public void propertyChange(PropertyChangeEvent evt)

166 Frédérique Laforest, Télécommunications, Services & Usages 166 MVC en java Classe PropertyChangeSupport –Pour le contrôleur –public void addPropertyChangeListener(String propertyName, PropertyChangeListener o) –public void firePropertyChange(PropertyChangeEvent e)

167 Frédérique Laforest, Télécommunications, Services & Usages 167 Exemple public class Controleur { protected PropertyChangeSupport pcs; public Controleur() { pcs=new PropertyChangeSupport(this); } public void addPropertyChangeListener(String propertyName, PropertyChangeListener o){ pcs.addPropertyChangeListener(propertyName, o); } public void firePropertyChange(PropertyChangeEvent e){ pcs.firePropertyChange(e); } //etc… }

168 Frédérique Laforest, Télécommunications, Services & Usages 168 Exemple public class Javagotchi implements PropertyChangeListener, Serializable { protected transient Controleur myControleur=null; /… public void setControleur(Controleur c){ myControleur=c; myControleur.addPropertyChangeListener("manger",this); myControleur.addPropertyChangeListener("dormir",this); } public void propertyChange(PropertyChangeEvent evt){ String name=evt.getPropertyName(); Integer newValue=(Integer)evt.getNewValue(); if (name.equals("manger"))manger(); if (name.equals("dormir"))dormir(); } private void santeChanged(){ PropertyChangeEvent e=null; e=new PropertyChangeEvent(this, "sante",new Integer(previousSante), new Integer(sante)); myControleur.firePropertyChange(e); }

169 Frédérique Laforest, Télécommunications, Services & Usages 169 Exemple public class UserInterface extends JFrame implements PropertyChangeListener, ActionListener{ Controleur myControleur=null; //… public void propertyChange(PropertyChangeEvent evt){ String name=evt.getPropertyName(); Integer newValue=(Integer)evt.getNewValue(); if (name.equals("faim"))faimBar.setValue(newValue.intValue()); if (name.equals(« sommeil"))sommeilBar.setValue(newValue.intValue() ); } public UserInterface(Controleur c) { //… myControleur=c; myControleur.addPropertyChangeListener("faim",this); myControleur.addPropertyChangeListener("sommeil",this); }…/…

170 Frédérique Laforest, Télécommunications, Services & Usages 170 Exemple ///suite classe UserInterface public void actionPerformed(ActionEvent e) { if (e.getSource().equals(dormirButton)){ PropertyChangeEvent pce=new PropertyChangeEvent(this, "dormir",new Integer(0), new Integer(1)); myControleur.firePropertyChange(pce); } if (e.getSource().equals(mangerButton)){ PropertyChangeEvent pce=new PropertyChangeEvent(this, "manger",new Integer(0), new Integer(1)); myControleur.firePropertyChange(pce); }

171 Frédérique Laforest, Télécommunications, Services & Usages 171 Conclusion générale Le génie logiciel permet de maîtriser le cycle de vie des logiciels et fournit des outils de contrôle La modélisation des systèmes dinformation est un processus complexe et nécessite lutilisation de méthodes et modèles –UML est un ensemble de modèles standards jeune et pas encore complètement mature Les Design Patterns permettent le développement de logiciels sûrs et réutilisables

172 Frédérique Laforest, Télécommunications, Services & Usages 172 Bibliographie Object oriented modeling and design, Rumbaugh, Blaha & al., Prentice Hall, 1991 UML, Lai, InterEditions, 1997 Modélisation objet avec UML, P.A. Muller, Eyrolles, 1998 Object-oriented software developement using Java, X. Jia, Addison Wesley, 2000 Design Patterns, E. Gamma et al., Addison Wesley, 1995, surnommé The Gang Of Four (GOF) Building Application Frameworks : Object-Oriented foundations of Framework Design, M. Fayad (Ed), D. Schmidt (Ed), John wiley & sons, 1999


Télécharger ppt "Frédérique Laforest, Télécommunications, Services & Usages 1 Modélisation et Génie logiciel 4 TC Frédérique Laforest, Frédéric Le Mouël."

Présentations similaires


Annonces Google