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

Modélisation et Génie logiciel

Présentations similaires


Présentation au sujet: "Modélisation et Génie logiciel"— Transcription de la présentation:

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

2 Frédérique Laforest, Télécommunications, Services & Usages
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 d’information avec les modèles d’UML Connaître les principes des Design Patterns, leur intérêt ainsi que les plus reconnus Frédérique Laforest, Télécommunications, Services & Usages

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

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

5 Frédérique Laforest, Télécommunications, Services & Usages
 Génie logiciel 1 Introduction 2 Cycle de vie, prototype 3 Normalisation 4 Tests 5 Refactoring 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 Frédérique Laforest, Télécommunications, Services & Usages

7 Frédérique Laforest, Télécommunications, Services & Usages
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. 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 Frédérique Laforest, Télécommunications, Services & Usages

9 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages

10 Frédérique Laforest, Télécommunications, Services & Usages
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. Frédérique Laforest, Télécommunications, Services & Usages

11 Frédérique Laforest, Télécommunications, Services & Usages
Concevoir un SI C’est 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 ? Frédérique Laforest, Télécommunications, Services & Usages

12 Modèles, méthodes et outils pour les SI
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) Frédérique Laforest, Télécommunications, Services & Usages

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

14 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages

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

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

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

18 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages

19 Frédérique Laforest, Télécommunications, Services & Usages
3- 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 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. 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:   ~18.59   21.4-r1 Chez d'autres encore, il n'y a qu'un numéro tout court : $ eix xterm      * x11-terms/xterm          Available versions:   204   207   ~208 Frédérique Laforest, Télécommunications, Services & Usages

22 Mesurer la qualité d’un 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é 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... Frédérique Laforest, Télécommunications, Services & Usages

24 Frédérique Laforest, Télécommunications, Services & Usages
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é Frédérique Laforest, Télécommunications, Services & Usages

25 Frédérique Laforest, Télécommunications, Services & Usages
Critères de Mc Call 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é 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 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…) ... Frédérique Laforest, Télécommunications, Services & Usages

27 Frédérique Laforest, Télécommunications, Services & Usages
4- 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! Frédérique Laforest, Télécommunications, Services & Usages

28 E-mail de M. Arnoldi à K. Beck (traduit)
« Malheureusement, pour moi en tout cas (et pas seulement pour moi), les tests vont à l’encontre de la nature humaine. Quand on lâche le porc qu’on a en soi, on s’aperçoit qu’on est capable de programmer sans tests. Ce n’est qu’au bout d’un moment que notre côté rationnel regagne le dessus, et qu’on 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. » 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) 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 l’ensemble des cas d’utilisation 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 » Frédérique Laforest, Télécommunications, Services & Usages

31 Frédérique Laforest, Télécommunications, Services & Usages
Types de tests Unitaires : ceux du programmeur Tests fonction par fonction doivent être positifs à 100% sur le code passé et courant Tests d’inté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% Frédérique Laforest, Télécommunications, Services & Usages

32 Frédérique Laforest, Télécommunications, Services & Usages
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 n’importe 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? Frédérique Laforest, Télécommunications, Services & Usages

33 Frédérique Laforest, Télécommunications, Services & Usages
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 table pleine , table vide fichier inexistant Frédérique Laforest, Télécommunications, Services & Usages

34 S’organiser 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 l’utilisateur, tout en dur Faire un makefile /ant pour compiler et lancer automatiquement tous les tests Frédérique Laforest, Télécommunications, Services & Usages

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

36 Frédérique Laforest, Télécommunications, Services & Usages
5- 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." Frédérique Laforest, Télécommunications, Services & Usages

37 Frédérique Laforest, Télécommunications, Services & Usages
Refactoring Pourquoi? Améliorer la conception et la structure du code Plus facile à maintenir Plus facile à comprendre Plus facile à modifier Plus facile d’ajouter 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. 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 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. 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. Frédérique Laforest, Télécommunications, Services & Usages

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

42 / Introduction : Objets
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) Frédérique Laforest, Télécommunications, Services & Usages

43 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages

44 Frédérique Laforest, Télécommunications, Services & Usages
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 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é 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 Frédérique Laforest, Télécommunications, Services & Usages

47 Concepts objet : identité et égalité, visibilité
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 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 Roue Guidon Cadre Rayon Jante Pneu ... Médecin Patient 1..n 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 Appartient Voiture Propriétaire Elève Professeur Enseignement 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 Losange Carré 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 Délégué 1 propagation message client "interface" propagation Nb : cf. Les proxys Délégué 2 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 Frédérique Laforest, Télécommunications, Services & Usages

53 Frédérique Laforest, Télécommunications, Services & Usages
UML - historique 1994, Rumbaugh rejoint Booch chez Rational Software but : créer une méthode en commun 1995 : présentation v0.5 1995, 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 Frédérique Laforest, Télécommunications, Services & Usages

54 Frédérique Laforest, Télécommunications, Services & Usages
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 l’utilisation des diagrammes Frédérique Laforest, Télécommunications, Services & Usages

55 UML : les mécanismes de base
Assurent l’inté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 Frédérique Laforest, Télécommunications, Services & Usages

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

57 UML : Diagramme des cas d'utilisation
d'un véhicule Acteur Cas d'utilisation Bornes du système 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 d’essais Un diagramme comprend les acteurs, le système, les cas d'utilisation eux-mêmes Frédérique Laforest, Télécommunications, Services & Usages

59 Frédérique Laforest, Télécommunications, Services & Usages
UML : acteurs 4 catégories d’acteurs 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 l’application autres systèmes avec lesquels le système doit interagir Frédérique Laforest, Télécommunications, Services & Usages

60 UML : cas d’utilisation
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. Frédérique Laforest, Télécommunications, Services & Usages

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

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

63 Encore un autre exemple diagramme séquence
Multithread/ multiprocess appel en interne, récursivité 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 Frédérique Laforest, Télécommunications, Services & Usages

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

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

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

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

69 Diagramme de classes : Paquetages
Regroupement logique de classes clarté partage du travail dans une équipe Gestion 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 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 classes Diagramme d'objets 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 portes ascenseur 5 ouvrir ^ 8 fermer ^ 11 ouvrir ^ 13 fermer ^ 1Appui bouton étage > ascenseur 3 déplacer > 6Appui bouton ascenseur > contrôleur ascenseur 9 déplacer > 7 allumer < 10 éteindre < 2 allumer > 12 timer 4 éteindre > bouton ascenseur bouton étage Frédérique Laforest, Télécommunications, Services & Usages

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

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

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

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

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

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

79 Frédérique Laforest, Télécommunications, Services & Usages
UML : les 9 diagrammes Cas d’utilisation 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 ... 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 d’une opération en termes d’actions Composants dépendances de compilation et/ou d'exécution des composants d'une application Déploiement équipements et modes de connexion 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 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 Frédérique Laforest, Télécommunications, Services & Usages

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

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

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

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

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

88 Frédérique Laforest, Télécommunications, Services & Usages
Conclusion UML UML n’est 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 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 4TC-MPO Stéphane Frénot (tiré de [Jia 2000], réadapté par F. Laforest) Frédérique Laforest, Télécommunications, Services & Usages

90 Frédérique Laforest, Télécommunications, Services & Usages
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 » 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é…) 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... Frédérique Laforest, Télécommunications, Services & Usages

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

94 Frédérique Laforest, Télécommunications, Services & Usages
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 d’application : 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 d’impression) Structure : Singleton Singleton Public Static getInstance() public operation() public getDonnées() protected Singleton() private static Singleton lInstance protected données Frédérique Laforest, Télécommunications, Services & Usages

95 Exemple d'implantation du Singleton
public class Singleton { } public class Singleton { public static Singleton getInstance(){ if (lInstance==null){ lInstance=new Singleton(); } return lInstance; protected Singleton(){ (Initialisation des champs); (champs et méthodes d'instance) private static Singleton lInstance==null; Frédérique Laforest, Télécommunications, Services & Usages

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

97 Frédérique Laforest, Télécommunications, Services & Usages
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 ... 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 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 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(…){ Public class CalculFactorisé { } public class CalculFactorisé { void calculTout(){ calculEtape1(); calculEtape2(); calculEtape3(); } void méthode1 (…){ //… calculTout(); void méthode2(…){ 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 { } Public class Commune { void calculTout (…){ calculEtape1(); calculEtape2(); calculEtape3(); } public class CalculA extends Commune { void méthode1 (…){ //... calculTout(); Frédérique Laforest, Télécommunications, Services & Usages

102 Factorisation par délégation
Utiliser un objet d’une autre classe pour faire le calcul sans utiliser d’héritage (souplesse pour les langages sans héritage multiple) public class CalculA { } public class Helper { } Public class Helper { void calculTout (…){ calculEtape1(); calculEtape2(); calculEtape3(); } public class CalculA { void méthode1 (…){ //… helper.calculTout(); Helper helper; Frédérique Laforest, Télécommunications, Services & Usages

103 Factorisation : allons plus loin
Insertion de code spécifique au milieu de code commun 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) } Frédérique Laforest, Télécommunications, Services & Usages

104 Frédérique Laforest, Télécommunications, Services & Usages
1ère solution 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) Frédérique Laforest, Télécommunications, Services & Usages

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

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

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

109 Frédérique Laforest, Télécommunications, Services & Usages
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. » Frédérique Laforest, Télécommunications, Services & Usages

110 Frédérique Laforest, Télécommunications, Services & Usages
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); ... } Frédérique Laforest, Télécommunications, Services & Usages

111 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages

112 Frédérique Laforest, Télécommunications, Services & Usages
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; } Frédérique Laforest, Télécommunications, Services & Usages

113 Frédérique Laforest, Télécommunications, Services & Usages
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 Afficheur Affiche() * Decapsule decapsuler() Frédérique Laforest, Télécommunications, Services & Usages implements IP decapsuler() MAC decapsuler() TCP decapsuler()

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 Frédérique Laforest, Télécommunications, Services & Usages

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

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

117 Frédérique Laforest, Télécommunications, Services & Usages
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 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; } Frédérique Laforest, Télécommunications, Services & Usages

119 Solution 1 : Accès direct
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); ... Nécessite que les champs et la classe interne Node soient accessibles des clients du service 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: on ne peut pas imbriquer deux boucles sur la meme liste, car il n’y a qu’un seul index de position sur la liste for (list.reset();list.hasNext();){ obl=list.next(); obj2=list.next(); if obj.compareTo(obj2)… } marche pas! Le 2ème for déplace le pointeur du premier! Problème des boucles imbriquées 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 IterateurDeliste it1=null; IterateurDeliste it2=null; for (it1=new IterateurDeListe(list); it1.hasNext();){ obj=it1.next(); for (it2=new IterateurDeListe(list); it2.hasNext();){ obj2=it2.next(); if obj.compareTo(obj2)… } 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(); } Frédérique Laforest, Télécommunications, Services & Usages

123 Sol 4 : Itérateur abstrait
public class Liste { //… méthodes de la liste } public class Liste { //… méthodes de la liste public Iterator iterator(){return new IterateurDeListe();} private class IterateurDeListe implements Iterator { public boolean hasNext(){return cur!=null;} public Object next(){ Object obj=null; if (cur!=null){ obj=cur.element; cur=cur.next; } return obj; public boolean remove(){ throw new UnsupportedOperationException(); private Liste.Node cur; IterateurDeListe(){ cur=head;} Frédérique Laforest, Télécommunications, Services & Usages

124 Les clients utilisent l'itérateur
Chercher les paquets de même pile protocolaire dans la liste maListe (utiliser la méthode isSameStack()) Liste maListe=new Liste(); //… Insertion des éléments Iterator iter1=liste.iterator(); for (;iter1.hasNext();){ Paquet p1=(Paquet)iter1.next(); Iterator iter2=list.iterator(),; for (;iter2.hasNext();){ Paquet p2=(Paquet)iter2.next(); if (p2.isSameStack(p1)){ System.out.println(p1+" appartient à la même pile que "+p2); } 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) Frédérique Laforest, Télécommunications, Services & Usages

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

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

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

129 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages

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

131 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages

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

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

134 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages

135 Frédérique Laforest, Télécommunications, Services & Usages
Awt : Schéma UML 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 Frédérique Laforest, Télécommunications, Services & Usages

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

138 Design pattern : Décorateur
Pour ajouter dynamiquement des fonctionnalités à un objet 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... 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"))); 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 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. Frédérique Laforest, Télécommunications, Services & Usages

143 Décorateur : structure
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 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 Frédérique Laforest, Télécommunications, Services & Usages

146 Exemple éditeur de document
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 Frédérique Laforest, Télécommunications, Services & Usages

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

149 Frédérique Laforest, Télécommunications, Services & Usages
Les patterns du GOF 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 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 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 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 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 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 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 Frédérique Laforest, Télécommunications, Services & Usages

157 Frédérique Laforest, Télécommunications, Services & Usages
Frameworks 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) 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 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é Frédérique Laforest, Télécommunications, Services & Usages

161 Exemples de frameworks
L’AWT : 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 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 Frédérique Laforest, Télécommunications, Services & Usages

163 MVC : Modèle, Vue, Contrôleur
fonctionnalités de l’application (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 d’action émanant de l’interface 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 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) s’inscrit auprès du contrôleur pour être prévenu des modifications des propriétés qui l’intéressent. Le contrôleur enregistre une liste d’abonnés à des propriétés. A chaque fois qu’il reçoit une annonce de modification, il la propage à tous les inscrits. Frédérique Laforest, Télécommunications, Services & Usages

165 Frédérique Laforest, Télécommunications, Services & Usages
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) Frédérique Laforest, Télécommunications, Services & Usages

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

167 Frédérique Laforest, Télécommunications, Services & Usages
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… Frédérique Laforest, Télécommunications, Services & Usages

168 Frédérique Laforest, Télécommunications, Services & Usages
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); Frédérique Laforest, Télécommunications, Services & Usages

169 Frédérique Laforest, Télécommunications, Services & Usages
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); } …/… Frédérique Laforest, Télécommunications, Services & Usages

170 Frédérique Laforest, Télécommunications, Services & Usages
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)); Frédérique Laforest, Télécommunications, Services & Usages

171 Frédérique Laforest, Télécommunications, Services & Usages
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 d’information est un processus complexe et nécessite l’utilisation 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 Frédérique Laforest, Télécommunications, Services & Usages

172 Frédérique Laforest, Télécommunications, Services & Usages
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 Frédérique Laforest, Télécommunications, Services & Usages


Télécharger ppt "Modélisation et Génie logiciel"

Présentations similaires


Annonces Google