Christine Solnon
INSA de Lyon - 3IF
2012 - 2013
Utiliser des diagrammes UML pour modéliser un objet d’étude
Interpréter un diagramme UML donné
; IF3-UML, IF4-DevOO, IF4-IHM
Concevoir un diagramme UML modélisant un objet d’étude
; IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-IHM, IF4-LG
Vérifier la cohérence de différents diagrammes modélisant un même objet d’étude
; IF3-UML, IF4-DevOO, IF4-LG
Concevoir l’architecture d’un logiciel orienté objet
Structurer un logiciel en paquetages et classes faiblement couplés et fortement cohésifs
; IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-LG
Utiliser des Design Patterns
; IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-LG
Pour en savoir plus
Sur la modélisation en général
Modèles et Métamodèles
Guy Caplat
Sur le méta-modèle de référence d’UML :
http
Sur UML et la modélisation objet
Modélisation Objet avec UML
Pierre-Alain Muller, Nathalie Gaertner
; Chapitre sur la notation téléchargeable sur le site d’Eyrolles
Sur les design patterns et la conception orientée objet
UML 2 et les design patterns
Craig Larman
Tête la première : Design Patterns
Eric Freeman & Elizabeth Freeman
et plein d’autres ouvrages à Doc’INSA !
Introduction à la modélisation
Introduction à UML
Modéliser la structure avec UML
Principes et patrons de conception orientée objet
Qu’est-ce qu’un modèle?
Modèle = Objet conçu et construit (artefact) :
Pour représenter un sujet d’études Représentativité
Exemple de sujet : les circuits électriques
S’appliquant à plusieurs cas de ce sujet d’étude Généricité Exemple de cas : des mesures (tension, intensité, ) sur des circuits
Incarnant un point de vue sur ces cas Abstraction
Exemple de point de vue : U = RI ; Abstraction de la longueur des fils, la forme du circuit,
Un même sujet d’études peut avoir plusieurs modèles
; Chaque modèle donne un point de vue différent sur le sujet
Langages utilisés pour exprimer un modèle :
Langues naturelles : qui évoluent hors du contrôle d’une théorie Ex : Français, Anglais,
Langages artificiels : conçus pour des usages particuliers
Langages formels : syntaxe définie par une grammaire
Ex : Logique, langages informatique (C, Java, SQL, ),
Pouvoir d’expression d’un langage :
| ; |
Ensemble des modèles que l’on peut exprimer
Le choix du langage influence la conception du modéle
et donc la perception du sujet d’études !
Interprétation d’un langage :
| ; |
Procédure pour comprendre un modèle (Sémantique)
Modèle ambigü : Plusieurs interprétations différentes possibles
Modèle exécutable : Interprétation exécutable par une machine
Langages de modélisation basés sur les graphes
Introduction à la modélisation
Introduction à UML
Modéliser la structure avec UML
Modéliser le comportement avec UML
Principes et patrons de conception orientée objet
[Image empruntée à Wikipedia]
OMG = Object Management Group () :
Fondé en 1989 pour standardiser et promouvoir l’objet
Version 1.0 d’UML (Unified Modeling Language) en janvier 1997 Version 2.4.1 en aout 2011
Définition d’UML selon l’OMG :
Langage visuel dédié à la spécification, la construction et la documentation des artefacts d’un système logiciel
L’OMG définit le méta-modèle d’UML
; Syntaxe et interprétation en partie formalisées
Attention : UML est un langage pas une méthode
; Méthode dans le cours 4IF “Développement Orienté Objet"
(On y reviendra en 4IF )
Mode esquisse (méthodes Agile) :
Diagrammes tracés à la main, informels et incomplets ; Support de communication pour concevoir les parties critiques
Mode plan :
Diagrammes formels relativement détaillés Annotations en langue naturelle
| ; |
Génération d’un squelette de code à partir des diagrammes
; Nécessité de compléter le code pour obtenir un exécutable
Mode programmation (Model Driven Architecture / MDA) : Spécification complète et formelle en UML
| ; |
Génération automatique d’un exécutable à partir des diagrammes
| ; |
Limité à des applications bien particulières
; Un peu utopique ( pour le moment ?)
UML peut être utilisé pour définir de nombreux modèles :
Modèles descriptifs vs prescriptifs
Descriptifs ;;Décrire l’existant (domaine, métier) Prescriptifs Décrire le futur système à réaliser
Modèles destinés à différents acteurs
Pour l’utilisateur ; Décrire le quoi ;
Pour les concepteurs/développeurs Décrire le comment
Modèles statiques vs dynamiques
Statiques ; Décrire les aspects structurels;
Dynamiques Décrire comportements et interactions
Les modèles sont décrits par des diagrammes (des graphes)
; Chaque diagramme donne un point de vue différent sur le système
[Image empruntée à Muller et Gaertner]
Stéréotypes et mots-clés (on y reviendra en 4IF ) :
Définition d’une utilisation particulière d’éléments de modélisation
; Interprétation (sémantique) particulière
Nombreux stéréotypes et mots-clés prédéfinis : «invariant», «create», «actor», {abstract}, {bind}, {use}
Valeurs marquées (on y reviendra aussi en 4IF ) :
Ajout d’une propriété à un élément de modélisation
Notation : { nom1 = valeur1, , nomn = valeurn}
Valeurs marquées prédéfinies (ex. : derived : Bool) ou personnalisées (ex. : auteur : Chaîne)
Commentaires :
Information en langue naturelle
Notation : o- - - - - - - - - - - - - - - - - - -
Relations de dépendance :
Notation : [source]- - - - - - - - - >[cible]
; Modification de la source peut impliquer une modification de la cible
Nombreux stéréotypes prédéfinis : «bind», «realize», «use», «create», «call»,
Contraintes (on y reviendra aussi en 4IF) :
Relations entre éléments de modélisation
| ; |
Propriétés qui doivent être vérifiées
; Attention : les contraintes n’ont pas d’effet de bord
Notation : o- - - - - - - -{ contrainte } 3 types de contraintes :
Contraintes prédéfinies : disjoint, ordered, xor, Contraintes exprimées en langue naturelle
Ex. : temps d’exécution inférieur à 10 ms
Contraintes exprimées avec OCL (Object Constraint Language)
Ex. : context Pile inv : self.nbElts >= 0
Stéréotypes : «invariant», «précondition», «postcondition»
Introduction
Modéliser le comportement avec UML
Principes et patrons de conception orientée objet
Introduction
Structuration Orientée Objet
Diagrammes d’objets
Diagrammes de classes
Diagrammes de paquetage
Diagrammes de composants
Diagrammes de déploiement
Principes et patrons de conception orientée objet
Pourquoi une structuration orientée objet?
Qu’est-ce qu’un objet?
Etat d’un objet :
Ensemble de valeurs décrivant l’objet 
| ; |
Chaque valeur est associée à un attribut (propriété)
; Les valeurs sont également des objets (? liens entre objets)
Comportement d’un objet :
Ensemble d’opérations que l’objet peut effectuer
Chaque opération est déclenchée par l’envoi d’un message
; Exécution d’une méthode
Identité d’un objet :
Permet de distinguer les objets indépendamment de leur état ; 2 objets différents peuvent avoir le même état
Attribuée implicitement à la création de l’objet
; L’identité d’un objet ne peut être modifiée
Attention : identité 6= nom de la variable qui référence l’objet
Qu’est ce qu’une classe d’objets?
Classe = regroupement d’objets similaires (appelés instances)
Toutes les instances d’une classe ont les mêmes attributs et opérations
; Abstraction des caractéristiques non communes
Classes sans instance
Classes abstraites :
; Certaines opérations peuvent être abstraites (non définies)
Interfaces :
; Pas d’attribut et toutes les opérations sont abstraites
Relation de spécialisation/généralisation entre classes
Une classe A est une spécialisation d’une classe B si tout attribut/opération de B est également attribut/opération de A
Implémentation par héritage
Introduction
Structuration Orientée Objet
Diagrammes d’objets
Diagrammes de classes
Diagrammes de paquetage
Diagrammes de composants
Diagrammes de déploiement
Modéliser le comportement avec UML
Principes et patrons de conception orientée objet
[Image empruntée à J.-M. Jezequel]
Au travail!
Pierre, Paul, Jacques, Marie et Anne sont étudiants au département IF.
Robert et Suzie sont enseignants au département IF.
Robert enseigne le C et le réseau ;
Pierre, Paul et Marie suivent les cours de C, de réseau et Java ; Jacques et Anne suivent les cours de C, math et anglais.
Introduction
Structuration Orientée Objet
Diagrammes d’objets
Diagrammes de classes
Diagrammes de paquetage
Diagrammes de composants
Diagrammes de déploiement
Modéliser le comportement avec UML
Principes et patrons de conception orientée objet
Abstraction d’un ensemble de diagrammes d’objets
[Image empruntée à J.-M. Jezequel]
Un diagramme de classes est un graphe :
Nœud du graphe = Classe
; Abstraction d’un ensemble d’objets
Arc du graphe = Relation entre des classes :
Relation d’association
; Abstraction d’un d’ensemble de liens entre objets
Relation de généralisation / spécialisation
; Factorisation de propriétés communes à plusieurs classes
Très nombreuses utilisations, à différents niveaux :
Pendant la capture des besoins : Modèle du domaine
; Classes correspondant à des objets du domaine
Pendant la conception/implémentation : Modèle de conception
; Classes correspondant à des objets logiciels
|
|
|
Format de description d’un attribut :
[Vis] Nom [Mult] [":" TypeAtt] ["=" Val] [Prop]
Vis : + (public), - (privé), # (protégé), ? (package)
Mult : "[" nbElt "]" ou "[" Min .. Max "]"
TypeAtt : type primitif (Entier, Chaîne, ) ou classe
Val : valeur initiale à la création de l’objet
Prop : {gelé}, {variable}, {ajoutUniquement},
Attributs de classe (statiques) soulignés
Attributs dérivés précédés de "/"
Format de description d’une opération :
Visibilité : + (public), - (privé), # (protégé) Arg : liste des arguments selon le format
[Dir] NomArgument : TypeArgument où Dir = in (par défaut), out, ou inout
Type : type de la valeur retournée (type primitif ou classe)
Opérations abstraites (non implémentées) en italique
Opérations de classe (statiques) soulignées
Possibilité d’annoter avec des contraintes stéréotypées
«precondition» et «postcondition»
; Programmation par contrats
Possibilité de surcharger une opération : ; même nom, mais paramètres différents
Stéréotypes d’opérations : «create» et «destroy»
| C1 | C2 | C3 | C4 | ||||||
1..* 1..* 1 0..1 0..1 0..2
Role de C1 dans l’association Sens de lecture
(ex. : 1, 0..1, *, 1..*, 4, 4..10, )
Interprétation en langage de programmation orienté objet
La classe C1 a un attribut de nom rôle2
; Type = C2 si mult2 ?{1,0..1}, ou collection de C2 sinon
La classe C2 a un attribut de nom rôle1
; Type = C1 si mult1 ?{1,0..1}, ou collection de C1 sinon
Exemple :
employeur Est employée par employé
Entreprise Personne
0..1 1..*
Au travail!
Chaque étudiant du département IF suit un ensemble d’unités d’enseignement (UE).
Chaque cours, TD ou TP a une date. Les cours sont faits en amphi, les TD en salle de classe et les TP en salle machine.
Pour les TP et TD, les étudiants sont répartis dans des groupes. Pour chaque TP, chaque étudiant est en binôme avec un autre étudiant.
Les cours et les TD sont assurés par un enseignant. Les TP sont assurés par deux enseignants.
Pour chaque UE, l’étudiant a une note de devoir surveillé ; pour chaque TP, le binôme a une note de TP.
Classes-associations
Niveau conceptuel : Généralisation
Relation transitive, non réflexive, et non symétrique
La sous-classe “est-une-sorte-de” la super classe
; Toute instance de la sous-classe est instance de la super classe
Niveau implémentation : Héritage
Mécanisme proposé par les langages de programmation Objet "B hérite de A" signifie que B possède :
Toutes les propriétés de A (attributs, op., assoc., contraintes)
Possibilité de redéfinir les opérations de la sous-classe ; Polymorphisme
Ainsi que des nouvelles propriétés qui lui sont propres
| ; |
Permet de factoriser les propriétés communes à plusieurs classes
; Une opération définie pour A est accessible aux sous-classes de A
Comment représenter ces 2 solutions en UML ?
Comment représenter ces 2 solutions en UML ?
Quelle solution choisissez-vous ?
46/137
Comment représenter ces 2 solutions en UML ?
Quelle solution choisissez-vous ?
Et si on veut modéliser le fait qu’il y a des personnes hommes et des personnes femmes ?
46/137
Comment représenter ces 2 solutions en UML ?
Comment représenter ces 2 solutions en UML ? Quelle solution choisissez-vous ?
Comment représenter ces 2
; On y reviendra avec les Design Patterns
Contraintes sur les relations de généralisation
48/137
Classes génériques (templates)
Classes abstraites
Qu’est-ce qu’une interface?
Classe sans attribut dont toutes les opérations sont abstraites Ne peut être instanciée
| ; |
Doit être réalisée (implémentée) par des classes non abstraites
; Peut hériter d’une autre interface
Pourquoi des interfaces?
Utilisation similaire aux classes abstraites
En Java : une classe ne peut hériter de plus d’une classe, mais elle peut réaliser plusieurs interfaces
Notations UML :
Nom : «interface» Itf1
Héritage : Itf1 —Itf2
Itf1
Réalisation : Class1 Itf1 ou Class1 ——-O
Itf1
Utilisation : Class2 - - «use» - -> Itf1 ou Class2 ——-C
51/137
[image empruntée à Craig Larman]
52/137
{abstract} : classe abstraite (alternative : nom en italique)
«interface» : interface
«énumération» : instances appartiennent à un ensemble fini de littéraux
«type primitif» : instances sont des valeurs d’un type primitif
«classe implémentation» : implémentation d’une classe dans un langage de prog.
«utilitaire» : variables et procédures globales
53/137
Association
Navigable dans les 2 sens : —————— Navigable dans un sens : ——————>
ou –X—————>
Composition : ——————
Agrégation : ——————<>
Généralisation : ——————
Réalisation d’une interface : ——————O ou - - - - - - - - - - - Utilisation d’une interface : ——————C ou - - - - «use» - - - - >
Intanciation d’une classe générique : - - - - «bind» (Type) - - - - >
Dépendance : - - - - - - - - - - - - >
54/137
Navigabilité : Tout objet doit être accessible via une association
55/137
56/137
Eviter les associations redondantes :
| ; |
Le vol d’un bagage est obtenu à partir du passager
; Les bagages d’un vol sont obtenus à partir des passagers
Possibilité de spécifier que l’association Bagage-Vol est dérivée
56/137
57/137
Navigabilité : En l’absence de réservations, on ne peut accéder ni aux chambres ni aux clients
Introduction
Structuration Orientée Objet
Diagrammes d’objets
Diagrammes de classes
Diagrammes de paquetage
Diagrammes de composants
Diagrammes de déploiement
Modéliser le comportement avec UML
Principes et patrons de conception orientée objet
2 éléments dans 2 paquetages différents sont différents, quel que soit leur nom
Nom complet = nom préfixé par les noms des paquetages englobants : Banque::Compte6= Commerce::Compte
Visibilité d’un élément : + (public) ou - (privé) Les éléments d’un paquetage P voient :
Les autres éléments de P
Les éléments des paquetages englobant P
Reflètent les dépendances entre éléments des paquetages :
Une classe A dépend d’une classe B (noté A - - - - - - - - > B) si :
Il existe une association navigable de A vers B
(ou A possède un attribut de type B)
Une méthode de A a un paramètre ou une var. locale de type B
Stéréotypes sur les dépendances inter-paquetage
A - - - «accède» - - - > B :
Tout élément public de B est accessible par son nom complet depuis A
A - - - «importe» - - - > B :
Tout élément public de B est accessible par son nom depuis A
; Création d’alias si nécessaire
Paquetage visible par tous les autres paquetages
; Inutile de montrer les dépendances vers ce paquetage
Introduction
Structuration Orientée Objet
Diagrammes d’objets
Diagrammes de classes
Diagrammes de paquetage
Diagrammes de composants
Diagrammes de déploiement
Modéliser le comportement avec UML
Principes et patrons de conception orientée objet
[Image extraite de ]
Diagrammes de déploiement
Introduction
Structuration Orientée Objet
Diagrammes d’objets
Diagrammes de classes
Diagrammes de paquetage
Diagrammes de composants
Diagrammes de déploiement
Modéliser le comportement avec UML
Diagrammes de déploiement
Introduction
Modéliser la structure avec UML
Principes et patrons de conception orientée objet
Décrire le comportement du système en termes d’interactions
Système vu comme une boite noire :
Qui interagit avec le système, et dans quel but ?
; Diagramme de cas d’utilisation
Comment interagit le système avec son environnement ?
; Diagramme de séquence système Système vu comme une boite blanche :
Comment interagissent les objets du système ? ; Diagramme de séquence et/ou de communication
Décrire l’évolution du système dans le temps
Comment évoluent les états des objets ?
; Diagrammes d’états-transitions
Introduction
Modéliser la structure avec UML
Diagrammes d’interaction
Diagrammes de cas d’utilisation
Diagrammes d’états-transitions
Message dont l’émetteur n’est pas connu
Objet anonyme
Valeur retournée (facultatif)
Durée de vie d’o2
Délai de propagation
x y
Mot réservé pour déclarer un diagramme de séquence
Nom du diagramme de séquence
Existe aussi : par, opt, critique
[Figure extraite du livre de C. Larman]
Introduction
Modéliser la structure avec UML
Diagrammes d’interaction
Diagrammes de cas d’utilisation
Diagrammes d’états-transitions
Principes et patrons de conception orientée objet
Pourquoi faire?
Permettre au client de décrire ses besoins
Parvenir à un accord (contrat) entre clients et développeurs
Point d’entrée pour les étapes suivantes du développement
Qu’est ce qu’un cas d’utilisation?
Usage que des acteurs font du système
Acteur : Entité extérieure qui interagit avec le système Une même personne peut jouer le rôle de différents acteurs ; Un acteur peut être un autre système (SGBD, Horloge, )
Usage : Séquence d’interactions entre le système et les acteurs
Généralement composé de plusieurs scénarios (instances)
| ; |
Scénario de base et ses variantes (cas particuliers)
; Description des scénarios à l’aide de diagrammes de séquence Comment découvrir les cas d’utilisation?
Délimiter le périmètre du système
Identifier les acteurs interagissant avec le système :
Ceux qui utilisent le système
Ceux qui fournissent un service au système
Identifier les acteurs principaux
; Ceux qui utilisent le système pour atteindre un but
Définir les cas d’utilisation correspondant à ces buts
; Nom = Verbe à l’infinitif + Groupe nominal
Comment décrire les cas d’utilisation?
Diagramme de cas d’utilisations
; Récapitulatif graphique des interactions entre acteurs et cas
Diagramme de séquence
| ; |
Description de chaque scénario
Généralisation : ————
Inclusion : - - - - - «include» - - - - - >
Extension : - - - - - «extend» - - - - - > (préciser la condition) ; A utiliser avec modération
Introduction
Modéliser la structure avec UML
Diagrammes d’interaction
Diagrammes de cas d’utilisation
Diagrammes d’états-transitions
Principes et patrons de conception orientée objet
Les automates finis déterministes sont très efficaces
Complexité en temps linéaire / taille du mot
Mais ils ont un pouvoir d’expression limité aux langages réguliers
Ne peuvent reconnaître les expressions bien parenthésées (entre autres)
Un automate à pile a un pouvoir d’expression supérieur
A chaque transition, on peut empiler ou dépiler des symboles
Permet de reconnaître tous les langages hors-contexte
; Langages de programmation (C++, Java, )
Mais certains langages ne peuvent pas être reconnus par un automate à pile
Une machine de Turing est un automate encore plus puissant
A chaque transition, on peut écrire ou lire sur un ruban
Permet de reconnaître tous les langages « décidables » ; Pouvoir de calcul équivalent à un ordinateur Mais certains langages sont indécidables !
Différents types d’événements :
Signaux :
nomSignal
Q0 ————————————–> Q1
Appels d’opérations :
nomOp(paramètres) Q0 ————————————–> Q1
; Les paramètres peuvent être typés ou non Evénements temporels :
after(qté tps)
Q0 ————————————–> Q1
when(cond)
Q0 ————————————–> Q1
; Passage dans l’état Q1 quand cond devient vraie
Etats concurrents (1/2)
Gardes et transitions composites
Quelques conseils
Pas de transition sans événement
L’automate doit être déterministe (en général )
Si plusieurs transitions partant d’un état ont le même événement, alors il doit y avoir des gardes qui garantissent le déterminisme
Tous les états doivent être accessibles depuis l’état initial
S’il y a des états terminaux alors, pour chaque état non terminal, il doit exister un chemin de cet état vers un état terminal ( en général)
Compléter ce diagramme :
Emission d’une tonalité quand on décroche
Emission d’un bip quand on compose un chiffre
Cas d’un faux numéro
Variante des diagrammes d’états-transitions
; Modélisation de flux
[Image empruntée à J.-L. Sourrouille]
Introduction
Modéliser la structure avec UML
Modéliser le comportement avec UML
Principes et patrons de conception orientée objet
Drawing UML diagrams is a reflection of making decisions about the object design. The object design skills are what really matter, rather than knowing how to draw UML diagrams.
Fundamental object design requires knowledge of :
Principles of responsibility assignments
Design patterns
[Extrait du livre de C. Larman]
Ou comment concevoir des logiciels maintenables et réutilisables
Protection des variations : Identifier les points de variation et d’évolution, et séparer ces aspects de ceux qui demeurent constants
Faible couplage : Réduire l’impact des modifications en affectant les responsabilités de façon à minimiser les dépendances entre classes
Indirection : Limiter le couplage et protéger des variations en ajoutant des objets intermédiaires
Composer au lieu d’hériter : Limiter le couplage en utilisant la composition (boite noire) au lieu de l’héritage (boite blanche) pour déléguer une tâche à un objet
Ces principes se retrouvent dans beaucoup de Design Patterns
Patrons architecturaux vs patrons de conception
Patrons architecturaux : Structuration globale en paquetages ; Couches, MVC, Client-serveur, Multi-tiers,
Patrons de conception : Structuration détaillée en classes
Attributs et opérations des classes : qui doit savoir, qui doit faire ?
Relations entre classes : délégation, héritage, réalisation, ?
Description d’un patron de conception
Nom ; Vocabulaire de conception
Problème : Description du sujet à traiter et de son contexte
Solution : Description des éléments, de leurs relations/coopérations et
de leurs rôles dans la résolution du problème Description générique ; Illustration sur un exemple
Conséquences : Effets résultants de la mise en œuvre du patron
; Complexité en temps/mémoire, impact sur la flexibilité, portabilité,
Introduction
Modéliser la structure avec UML
Modéliser le comportement avec UML
Iterator, Strategy, State, Observer, Command
Adapter, Facade, Decorator, Composite
Introduction
Modéliser la structure avec UML
Modéliser le comportement avec UML
Iterator, Strategy, State, Observer, Command
Adapter, Facade, Decorator, Composite
Iterator (1/2)
Iterator (2/2)
Problème :
Changer dynamiquement le comportement d’un objet
Dans un jeu vidéo, des personnages combattent des monstres
; méthode combat(Monstre m) de la classe Perso
et le code de combat peut être différent d’un personnage à l’autre
Sol. 1 : combat contient un cas pour chaque type de combat Sol. 2 : La classe Perso est spécialisée en sous-classes qui redéfinissent combat
Sol. 3 : La classe Perso délègue le combat à des classes encapsulant des codes de combat et réalisant toutes une même interface
Représenter ces solutions en UML. Peut-on facilement :
Ajouter un nouveau type de combat ?
Changer le type de combat d’un personnage ?
117/137
Strategy (2/3)
Strategy (2/3)
State (1/3)
State (3/3)
Problème :
Faire savoir à un ensemble d’objets (observateurs/abonnés) qu’un autre objet (observable/publieur) a été modifié
Illustration sur l’exemple du jeu vidéo :
La représentation (vue) des personnages dépend de leur niveau
et on peut avoir plusieurs vues (graphique, sonore, textuelle, etc) et on veut se protéger des évolutions et variations sur ces vues
| ; |
Utilisation du patron architectural Model-View-Controller (MVC)
Modèle : traite les données
Vue : affiche les données, reçoit les evt clavier/souris et les envoie au contrôleur
Contrôleur : analyse les evt
clavier/souris et active le modèle et/ou la
Flêche pleine = dépendance vue en conséquence
Pointillés = événements Modèle est observable, Vue est observateur
124/137
Observer (aka Publish/Subscribe) (3/3)
Introduction
Modéliser la structure avec UML
Modéliser le comportement avec UML
Iterator, Strategy, State, Observer, Command
; Application des principes “indirection” et “protection des variations”
Composite (1/2)
Autres patterns?
