frédérique laforest, télécommunications, services & usages 1 modélisation et génie...
TRANSCRIPT
Frédérique Laforest, Télécommunications, Services & Usages1
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 & Usages2
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 & Usages3
Plan global
Introduction Génie logiciel UMLDesign Patterns
Frédérique Laforest, Télécommunications, Services & Usages4
Outils
Partie faite par F Le Mouël
Frédérique Laforest, Télécommunications, Services & Usages5
Génie logiciel
1 Introduction
2 Cycle de vie, prototype
3 Normalisation
4 Tests
5 Refactoring
Frédérique Laforest, Télécommunications, Services & Usages6
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 & Usages7
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 & Usages8
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 & Usages9
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 & Usages10
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 & Usages11
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 & Usages12
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)
Frédérique Laforest, Télécommunications, Services & Usages13
2- 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
Exploitationet maintenance
Frédérique Laforest, Télécommunications, Services & Usages14
Cycle de vie en cascade
Analyse
conception
Codage
Tests
Chaque étape validée n'est plus remise en causeNe prend pas en compte l'intégralité du cycle de vie
Frédérique Laforest, Télécommunications, Services & Usages15
Modèle en V
Spécification du systèmeet des besoins
Conceptiondu système
Spécificationdes sous-systèmes
Construction
Conceptiondes 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
Frédérique Laforest, Télécommunications, Services & Usages16
Modèle de la fontaine
Processus incrémental et itératifChaque étape peut fournir des résultats modifiant le résultats des précédentes
Maintenance Développementsultérieurs
Test du logiciel
Utilisation
Spécification caractéristiques
Conception
Codage
Analyse besoins
Spécification besoins
Frédérique Laforest, Télécommunications, Services & Usages17
Modèle en spirale Prototype incrémentalCoût cumulatif
Evaluer les alternativesIdentifier et éviter les risques
Développer et vérifier leprochain niveau du produit
Déterminer les objectifs,les alternatives, les contraintes
Organiser les phases suivantes
Prévision besoinsprojet
proto1 proto2proto3
Protoopérationnel
Analysedes
risques
Concevoiropérations
Simul. Modèles Benchmarks
Conceptiondétaillée
ConceptionSpec.besoins
Valider conception Codage
TestsAccepter
tests
Organisationdéveloppement
Intégration et test de l'organisation du projet
Revue critique
Pro
gres
ser
par
étap
es
Frédérique Laforest, Télécommunications, Services & Usages18
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 & Usages19
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 & Usages20
Exemple : numérotation releases
• Pour le noyau Linux (qui sert souvent de modèle) :http://en.wikipedia.org/wiki/Linux_kernel#Versions
Version.Majeure.Mineure.Révision• Fev 06 : 2.6.15.4
• 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 & Usages21
Exemple : numérotation releases• packages Gentoo, la Révision correspond au -rXX
$ eix firefox-bin * www-client/mozilla-firefox-bin Available versions: 1.0.7 ~1.5-r2 ~1.5.0.1– 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 & Usages22
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 & Usages23
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 & Usages24
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 & Usages25
Critères de Mc Call
Indépendance vis à vis du systèmeIndépendance vis à vis du matérielInstrumentation (traces fonctionnement)
Efficacité de stockageModularitéPrécisionContrôle des accèsRapiditéTolérance aux pannesSimplicitéTraçabilitéVérification des accès
AutodescriptionStandardisation des donnéesStandardisation des interfacesGénéralitéClartéConcisionComplétudeExtensibilitéFacilité d'apprentissageFacilité d'utilisationHomogénéité
Frédérique Laforest, Télécommunications, Services & Usages26
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 & Usages27
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 & Usages28
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 & Usages29
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 & Usages30
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 & Usages31
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 & Usages32
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 & Usages33
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
Frédérique Laforest, Télécommunications, Services & Usages34
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 & Usages35
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 & Usages36
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."
http://www.cs.usfca.edu/~parrt/course/601/lectures/refactoring/refactoring.html
Frédérique Laforest, Télécommunications, Services & Usages37
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 & Usages38
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 & Usages39
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 & Usages40
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 & Usages41
UML
/Introduction aux objets
/Objet, classe
/Les modèles d'UML
/ Etude de cas
Frédérique Laforest, Télécommunications, Services & Usages42
/ 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)
Frédérique Laforest, Télécommunications, Services & Usages43
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 & Usages44
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 & Usages45
/ 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 & Usages46
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 & Usages47
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
Frédérique Laforest, Télécommunications, Services & Usages48
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 nomenclatureBicyclette
Roue Guidon Cadre
Rayon Jante Pneu
...
Médecin
Patient
1..n
Frédérique Laforest, Télécommunications, Services & Usages49
Concepts objet : associations entre classes
• On utilise souvent les associations binaires
• Les associations peuvent être aussi traduites par des objets
Elève Professeur
Enseignement
Voiture PropriétaireAppartient
Frédérique Laforest, Télécommunications, Services & Usages50
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
Frédérique Laforest, Télécommunications, Services & Usages51
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 propagati
on
propagation
Nb : cf. Les proxys
Frédérique Laforest, Télécommunications, Services & Usages52
/ 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
• http://www.rational.com
Frédérique Laforest, Télécommunications, Services & Usages53
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 & Usages54
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 & Usages55
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 & Usages56
<<persistant>>Œuvre
Etat=testé
Auteur
écrire
{ordonne}
UML : mécanismes de base
Contrainte
Relation
Note
Stéréotype
Etiquette
Frédérique Laforest, Télécommunications, Services & Usages57
UML : Diagramme des cas d'utilisation
conduireclient
vendeurvendre
réparer
mecanicienentretenir
diagramme descas d'utilisationd'un véhicule
Acteur
Cas d'utilisation
Bornes du système
Frédérique Laforest, Télécommunications, Services & Usages58
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 & Usages59
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 & Usages60
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 & Usages61
UML : Diagramme de séquence
user 1
bouton étage bouton ascenseur
contrôleur ascenceur
ascenceur portes ascenceur
1: appui bouton étage
2: allumer3: deplacer
4: eteindre5: ouvrir
6: appui bouton ascenceur
7: allumer8: fermer
9: deplacer10: eteindre
11: ouvrir12: timer
13: fermer
Frédérique Laforest, Télécommunications, Services & Usages62
Autre exemple diagramme de séquence
Frédérique Laforest, Télécommunications, Services & Usages63
Encore un autre exemple diagramme séquence
Multithread/multiprocess
appel en interne,
récursivité
Frédérique Laforest, Télécommunications, Services & Usages64
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 & Usages65
Diagramme de classes : Classes
Client<<Actor>>
UneClasse
privé : intpublicprotégé
opprivee( )oppublique( )opprotégée( )
+ public- privé# protégé
vector
Classe paramétrée
vector<entier>
Instanciation d'uneclasse paramétrée
Frédérique Laforest, Télécommunications, Services & Usages66
Diagramme de classes : Agrégation
Ensemble Boisson
Boissons
nbrBoissons : int = 0
preparer (unChoix : Choix)verser ()
1 1produits boissonPreparee11
Boissons
nbrBoissons : int = 0produits : EnsembleboissonPreparee : Boisson
preparer (unChoix : Choix)verser ()
compositioncomposition
ChauffeurCamion*
affecter
*
référenceréférence
Frédérique Laforest, Télécommunications, Services & Usages67
Diagramme de classes : Généralisation
ProduitDistribue
Aliment Boisson
Friandise CasseCroute() Liquide BoissonBoite
{disjoint}
Contraintes possibles : complete, incomplete, disjoint, overlapping
Frédérique Laforest, Télécommunications, Services & Usages68
Diagramme de classes : Associations
Personne Employeur
*
travailler pour
*
Banque PersonnenuméroCompte : int
1..*numéroCompte : int
1..*
possède
Machine
Piece
Consommateur
Frédérique Laforest, Télécommunications, Services & Usages69
Diagramme de classes : Paquetages
clients
Gestion
PersistanceReseaux
Client
(from Logical View)
Compte
Banque
Gestion
• Regroupement logique de classes– clarté
– partage du travail dans une équipe
Frédérique Laforest, Télécommunications, Services & Usages70
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 & Usages71
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
PatronDenis:Personne
PatronPersonne
1
*
Patron
Collaborateur
1
*
Diagramme de classes Diagramme d'objets
Frédérique Laforest, Télécommunications, Services & Usages72
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
user 1
contrôleurascenseur
portes ascenseur
bouton ascenseur bouton étage
ascenseur
1Appui bouton étage >6Appui bouton ascenseur >
5 ouvrir ^11 ouvrir ^
8 fermer ^13 fermer ^
12 timer7 allumer <
10 éteindre <
3 déplacer >
9 déplacer >
2 allumer >4 éteindre >
Frédérique Laforest, Télécommunications, Services & Usages73
UML : diagramme Etats-transitions
Porte fermée
appuiBouton [non verrouillée] / ouvrir()
Porte ouverte
appuiBouton [non verrouillée] / fermer()
• Les changements d’état d’un objet d’une classe pendant sa durée de vie
Frédérique Laforest, Télécommunications, Services & Usages74
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 & Usages75
Autre exemple diagramme d'activités
Mesurer température
RefroidirChauffer
[trop froid] [trop chaud]
garde
Arrêterchauffage
Ouvrir la fenêtre
synchronisation
Aérer
Fermer la fenêtre
Donner consigne t°Thermostat
Consigne atteinte
Envoi et réceptionde signaux
Frédérique Laforest, Télécommunications, Services & Usages76
Dia
gram
me
d’ac
tivi
tés
enco
re
Frédérique Laforest, Télécommunications, Services & Usages77
UML : diagramme de composants
Facture
Abonné
1
**
1 Forfait
main()
Abonné
Frédérique Laforest, Télécommunications, Services & Usages78
UML : diagramme de déploiement
Serveur
PC
Terminal X
<<TCP/IP>>
Imprimante
<<RNIS>>
Frédérique Laforest, Télécommunications, Services & Usages79
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 & Usages80
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 & Usages81
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 & Usages82
/ 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 & Usages83
Distri : Diagramme des cas d'utilisation
Client
Employé
Prendreune
boisson
Gérer lamachine
Machine distributrice
Frédérique Laforest, Télécommunications, Services & Usages84
Distri : Diagramme de séquence
un distrib : Distri
gestionnaire : Gestionaire
gobelets : Gobelets
boissons : Boissonsunclient : Client
1: selectionnerChoix(unchoix)
2: sommeSuffisante(unChoix)
3:
4: [reste verres] placer()
5:
6: [reste produit] preparer()
7:
Etc...
:Automate Gobelets
:Automate Boissons
Frédérique Laforest, Télécommunications, Services & Usages85
Distri : diagramme de classes
ConsommateurDistributeurDeBoissons
Monnayeur
AutomateBoissons
AutomateGobeletsStatic nbGobelets
introduction
récupérer rendre
choisir
retirer
distribution
1
1
1
1
1
1
1..*
0..* 0..*
0..1
Frédérique Laforest, Télécommunications, Services & Usages86
Distri : diagramme de collaborations
Pièces : Monnayeur
leGestionnaire : Gestionnaire
uneMDB : DistributeurDeBoissons
unGobelet :AutomateGobelets uneBoisson : AutomateBoissons
unEcran : Ecran
selectionnerChoix(unChoix)
1.1. Placer() 1.1.1. Préparer()1.1.1.1.1. Verser()
1. sommeSuffisante(unChoix):booleen1.1.2.2. sommeIntroduite():Somme1.1.1.1.2. sommeARendre(unChoix):Somme1.1.1.1.4. Stop()1.2.1. sommeManquante(unChoix):Somme
1.1.2.3. rendreMonnaie(somme)1.1.1.1.3. rendreMonnaie(somme)
Frédérique Laforest, Télécommunications, Services & Usages87
Nouvelle version diagramme de classes
Consommateur DistributeurDeBoissonssélectionnerChoix()
MonnayeurVector piecesDisporendreMonnaie()
AutomateBoissonsPréparer()Verser()
AutomateGobeletsStatic nbGobeletsPlacer()
introduction
récupérer
rendre
choisir
retirer
distribution
1 1
1
1
1
1
1..*
0..* 0..*
0..1
Frédérique Laforest, Télécommunications, Services & Usages88
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 & Usages89
4TC-MPO
Stéphane Frénot(tiré de [Jia 2000], réadapté par F. Laforest)
Les Design Patterns
Frédérique Laforest, Télécommunications, Services & Usages90
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 & Usages91
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 & Usages92
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 & Usages93
Design Pattern : Singleton
Pour des services "centralisés"
Frédérique Laforest, Télécommunications, Services & Usages94
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
Frédérique Laforest, Télécommunications, Services & Usages95
Exemple d'implantation du Singleton
public class Singleton {
}
Frédérique Laforest, Télécommunications, Services & Usages96
Design Pattern : Template Method
Pour factoriser les codes communs
Frédérique Laforest, Télécommunications, Services & Usages97
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 & Usages98
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 & Usages99
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 & Usages100
Factorisation de méthodes
Public class Calcul {
void méthode1 (…){
//…
calculEtape1();
calculEtape2();
calculEtape3();
//…
}
void méthode2(…){
//…
calculEtape1();
calculEtape2();
calculEtape3();
//…
}
}
Public class CalculFactorisé {
}
Frédérique Laforest, Télécommunications, Services & Usages101
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 {
}
Frédérique Laforest, Télécommunications, Services & Usages102
public class Helper {
}
public class CalculA {
}
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)
Frédérique Laforest, Télécommunications, Services & Usages103
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
Frédérique Laforest, Télécommunications, Services & Usages104
• 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
Frédérique Laforest, Télécommunications, Services & Usages105
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
Frédérique Laforest, Télécommunications, Services & Usages106
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 & Usages107
Template Method : Structure
GenericClass
tem plateM ethod() hookM ethod1() hookM ethod2()
ConcreteClass
hookM ethod1() hookM ethod2()
...hookM ethod1()
...hookM ethod2()
...
Frédérique Laforest, Télécommunications, Services & Usages108
Design Pattern : Strategy
Pour des fonctionnalités génériques
Frédérique Laforest, Télécommunications, Services & Usages109
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 & Usages110
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 & Usages111
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 & Usages112
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 & Usages113
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
Frédérique Laforest, Télécommunications, Services & Usages114
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 & Usages115
Strategy : Structure
ConcreteStrategyA
algorithm()
ConcreteStrategyB
algorithm()
Context
contextMethod()
Strategy
algorithm()
**
Frédérique Laforest, Télécommunications, Services & Usages116
Design Pattern : Iterator
Pour des parcours indépendants & multiples de collections
Frédérique Laforest, Télécommunications, Services & Usages117
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 & Usages118
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 & Usages119
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 listefor (Liste.Node cur=list.head; cur != null; cur=cur.next){System.out.println(cur.element);...
Frédérique Laforest, Télécommunications, Services & Usages120
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 paquetsfor (list.reset(); list.hasNext(); )System.out.println(list.next());...
Problème des boucles imbriquées
Frédérique Laforest, Télécommunications, Services & Usages121
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
Frédérique Laforest, Télécommunications, Services & Usages122
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 & Usages123
Sol 4 : Itérateur abstrait
public class Liste { //… méthodes de la liste
}
Frédérique Laforest, Télécommunications, Services & Usages124
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())
Frédérique Laforest, Télécommunications, Services & Usages125
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 & Usages126
Iterator : structure
CollectionAbstraite
iterator()
CollectionConcrete
+iterator()
Iterator
hasNext() next() remove()
IteratorConcret
hasNext() next() rem ove()
Créé
Retourn new IteratorConcret()
Frédérique Laforest, Télécommunications, Services & Usages127
Design Pattern : Usine
Pour des instanciations génériques
Frédérique Laforest, Télécommunications, Services & Usages128
Afficheur : Schéma UML
AfficheurPile
in itia liseAnalyseur() a jouteFonctionD ecapsulation()
AfficheurTCPIP
in itia liseAnalyseur() a jouteFonctionD ecapsulation()
Decapsule
decapsuler(x : Paquet)
MAC
decapsuler(x : Paquet)
IP
decapsuler(x : Paquet)
C réé
C réé
0..n
Frédérique Laforest, Télécommunications, Services & Usages129
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 & Usages130
L'usine : schéma UML
AfficheurPile
in itia liseAnalyseur()
AfficheurTCPIP
in itia liseAnalyseur()
Decapsule
decapsuler(x : Paquet)
MAC
decapsuler(x : Paquet)
IP
decapsuler(x : Paquet)
C rééC réé
0..n
UsineDeDecapsuleur
m akeD ecapsuleur()
lU sine
UsineStatique
m akeD ecapsuleur()
Frédérique Laforest, Télécommunications, Services & Usages131
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 & Usages132
Usine : Structure
UsineAbstraite
UsineConcrete
ProduitAbstrait
ProduitConcretfabrique
Frédérique Laforest, Télécommunications, Services & Usages133
Design Pattern : Composite
Pour représenter toute hiérarchie de composition
Frédérique Laforest, Télécommunications, Services & Usages134
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 containerjava.awt.Window
java.awt.Framejava.awt.Dialog
java.awt.FileDialogjava.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 & Usages135
Awt : Schéma UML
C om ponent
B utton
C anvas
C heckB ox
Labe l
L ist
S cro llB ar
TextC om ponent
TextA rea TextF ie ld
C onta iner
P ane l W indow
Fram e D ia log
F ileD ia log
java.app le tA pp le t
*
Frédérique Laforest, Télécommunications, Services & Usages136
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 & Usages137
Composite UML
Component
operation() add(Component)() remove(Component)() getChild(int)()
Feuille
operation()
Composite
operation() add(Com ponent)() rem ove(Com ponent)() getChild(int)()
C lient
*
Frédérique Laforest, Télécommunications, Services & Usages138
Design pattern : Décorateur
Pour ajouter dynamiquement des fonctionnalités à un objet
Frédérique Laforest, Télécommunications, Services & Usages139
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 & Usages140
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 & Usages141
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 & Usages142
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 & Usages143
Décorateur : structure
Component
operation()
ComposantConcret
operation()
Decorator
operation()com ponent.operation()
ConcreteDecoratorA
operation()
addedState : S tate
ConcreteDecoratorB
operation() addedOperation()
super.operation()addedOperation()
*
Frédérique Laforest, Télécommunications, Services & Usages144
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 & Usages145
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 & Usages146
Exemple éditeur de document
EditeurDocument
Graphic
<<abstract>> draw()<<abstract>> getExtent()<<abstract>> store()<<abstract>> load()
ImageProxy
fileNameextent
draw()getExtent()store()load()
Image
imageImpextent
draw()getExtent()store()load()
if (image==null){ image=loadImage(fileName);}image.draw();
if (image==null){ return extent;} else{ return image.getExtent();}
Frédérique Laforest, Télécommunications, Services & Usages147
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 & Usages148
Médiateur : structure
Sujet
ObjetRéel Proxy
LeClient
unClientsujet
unProxysujetReel
unObjetReel
Frédérique Laforest, Télécommunications, Services & Usages149
Les patterns du GOF
Frédérique Laforest, Télécommunications, Services & Usages150
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 & Usages151
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 & Usages152
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 & Usages153
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 & Usages154
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 & Usages155
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 & Usages156
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 & Usages157
Frameworks
Frédérique Laforest, Télécommunications, Services & Usages158
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 & Usages159
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 & Usages160
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 & Usages161
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 & Usages162
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 & Usages163
MVC : Modèle, Vue, Contrôleur
• Modèle– 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 & Usages164
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 & Usages165
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 & Usages166
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 & Usages167
Exemplepublic 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 & Usages168
Exemplepublic 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 & Usages169
Exemplepublic 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 & Usages170
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); }}}
Frédérique Laforest, Télécommunications, Services & Usages171
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 & Usages172
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