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

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


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


Plan global

Introduction Génie logiciel UMLDesign Patterns


Outils

Partie faite par F Le Mouël


Génie logiciel

1 Introduction

2 Cycle de vie, prototype

3 Normalisation

4 Tests

5 Refactoring


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


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.


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


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


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.


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 ?


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)


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


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


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


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


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


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


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


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.


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


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é


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...


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é


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é


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…)– ...


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!


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. »


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)


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 »


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%


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?


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


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


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


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


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.


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



– 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.



– 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.


UML

/Introduction aux objets

/Objet, classe

/Les modèles d'UML

/ Etude de cas


/ 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)


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


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


/ 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é


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


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


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


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


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


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


/ 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


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


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


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


<<persistant>>Œuvre

Etat=testé

Auteur

écrire

{ordonne}

UML : mécanismes de base

Contrainte

Relation

Note

Stéréotype

Etiquette


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


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


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


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.


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


Autre exemple diagramme de séquence


Encore un autre exemple diagramme séquence

Multithread/multiprocess

appel en interne,

récursivité


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


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


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


Diagramme de classes : Généralisation

ProduitDistribue

Aliment Boisson

Friandise CasseCroute() Liquide BoissonBoite

{disjoint}

Contraintes possibles : complete, incomplete, disjoint, overlapping


Diagramme de classes : Associations

Personne Employeur

*

travailler pour

*

Banque PersonnenuméroCompte : int

1..*numéroCompte : int

1..*

possède

Machine

Piece

Consommateur


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


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


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


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 >


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


UML : Diagramme d’activités

• Donne la liste des étapes suivies pour accomplir une action

• (algorithme d’une fonction)


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


Dia

gram

me

d’ac

tivi

tés

enco

re


UML : diagramme de composants

Facture

Abonné

1

**

1 Forfait

main()

Abonné


UML : diagramme de déploiement

Serveur

PC

Terminal X

<<TCP/IP>>

Imprimante

<<RNIS>>


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

...


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


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


/ Etude de cas : distributeur de boissons

• Application Distri : un distributeur automatique de boissons

• Les classes– acteur Client

– acteur Employé

– Machine Distributeur


Distri : Diagramme des cas d'utilisation

Client

Employé

Prendreune

boisson

Gérer lamachine

Machine distributrice


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


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


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)


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


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


4TC-MPO

Stéphane Frénot(tiré de [Jia 2000], réadapté par F. Laforest)

Les Design Patterns


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 »


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é…)


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...


Design Pattern : Singleton

Pour des services "centralisés"


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


Exemple d'implantation du Singleton

public class Singleton {

}


Design Pattern : Template Method

Pour factoriser les codes communs


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 ...


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


Techniques de factorisation

• Par généralisation des méthodes• Par héritage• Par délégation


Factorisation de méthodes

Public class Calcul {

void méthode1 (…){

//…

calculEtape1();

calculEtape2();

calculEtape3();

//…

}

void méthode2(…){

//…

calculEtape1();

calculEtape2();

calculEtape3();

//…

}

}

Public class CalculFactorisé {

}


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 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)


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)


Factorisation : allons plus loin

• Insertion de code spécifique au milieu de code commun


• 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 (…){


1ère solution


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


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


Template Method : Structure

GenericClass

tem plateM ethod() hookM ethod1() hookM ethod2()

ConcreteClass

hookM ethod1() hookM ethod2()

...hookM ethod1()

...hookM ethod2()

...


Design Pattern : Strategy

Pour des fonctionnalités génériques


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. »


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); ...}


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


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; } }


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


Design Pattern : Strategy

– Nom : Strategy


– 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


Strategy : Structure

ConcreteStrategyA

algorithm()

ConcreteStrategyB

algorithm()

Context

contextMethod()

Strategy

algorithm()

**


Design Pattern : Iterator

Pour des parcours indépendants & multiples de collections


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


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; }}


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);...


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


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


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();}


Sol 4 : Itérateur abstrait

public class Liste { //… méthodes de la liste

}


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())


Design Pattern : Iterator

– Nom : Iterator


– 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)


Iterator : structure

CollectionAbstraite

iterator()

CollectionConcrete

+iterator()

Iterator

hasNext() next() remove()

IteratorConcret

hasNext() next() rem ove()

Créé

Retourn new IteratorConcret()


Design Pattern : Usine

Pour des instanciations génériques


Afficheur : Schéma UML

AfficheurPile

in itia liseAnalyseur() a jouteFonctionD ecapsulation()

AfficheurTCPIP

in itia liseAnalyseur() a jouteFonctionD ecapsulation()

Decapsule

decapsuler(x : Paquet)

MAC


IP


C réé

C réé

0..n


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


L'usine : schéma UML

AfficheurPile

in itia liseAnalyseur()

AfficheurTCPIP

in itia liseAnalyseur()

Decapsule


MAC


IP


C rééC réé

0..n

UsineDeDecapsuleur

m akeD ecapsuleur()

lU sine

UsineStatique

m akeD ecapsuleur()


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


Usine : Structure

UsineAbstraite

UsineConcrete

ProduitAbstrait

ProduitConcretfabrique


Design Pattern : Composite

Pour représenter toute hiérarchie de composition


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


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

*


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


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

*


Design pattern : Décorateur

Pour ajouter dynamiquement des fonctionnalités à un objet


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...


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")));


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


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.


Décorateur : structure

Component

operation()

ComposantConcret

operation()

Decorator

operation()com ponent.operation()

ConcreteDecoratorA

operation()

addedState : S tate

ConcreteDecoratorB

operation() addedOperation()

super.operation()addedOperation()

*


Design pattern : Médiateur

Autre nom : Proxy

Pour ne pas donner un accès direct à un objet, mais utiliser un intermédiaire


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


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();}


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


Médiateur : structure

Sujet

ObjetRéel Proxy

LeClient

unClientsujet

unProxysujetReel

unObjetReel


Les patterns du GOF


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


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


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


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


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



• 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



• 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


Frameworks


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)


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


Conception d'un framework

• ! Plus complexe à concevoir qu'une appli.• Complétude • Adaptabilité• Efficacité• Sécurisé• Simplicité• Extensibilité


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


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


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


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.


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)


MVC en java

• Classe PropertyChangeSupport– Pour le contrôleur

– public void addPropertyChangeListener(String propertyName, PropertyChangeListener o)

– public void firePropertyChange(PropertyChangeEvent e)


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…}


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); }}


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); } …/…


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); }}}


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


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

Documents

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