Christine Solnon

INSA de Lyon - 3IF

2012 - 2013

Positionnement de l’UE / IF

 

Référentiel des compétences

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

Organisation

 

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 !

Plan du cours

Introduction

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

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 de modélisation

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

Plan du cours

Introduction

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

Historique d’UML

 

[Image empruntée à Wikipedia]

UML et l’OMG

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"

3 façons d’utiliser UML selon [Fowler 2003]

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

Différents modèles UML

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

14 types de diagrammes d’UML 2.2

 

Diagrammes UML : Points de vue sur le système

 

[Image empruntée à Muller et Gaertner]

Notations communes à tous les diagrammes (1/2)

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

Notation : «nomDuStéréotype» ou {nomDuMotClé} ou icone

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 : { nom₁ = valeur₁, , nom_n = valeur_n}

Valeurs marquées prédéfinies (ex. : derived : Bool) ou personnalisées (ex. : auteur : Chaîne)

Commentaires :

Information en langue naturelle

Notation : o- - - - - - - - - - - - - - - - - - -

Notations communes à tous les diagrammes (2/2)

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»

Plan du cours

Introduction

Modéliser la structure avec UML

Modéliser le comportement avec UML

Principes et patrons de conception orientée objet

Point de vue statique sur le système

 

Plan du cours

Introduction

Modéliser la structure avec UML

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

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

Plan du cours

Introduction

Modéliser la structure avec UML

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

Diagrammes d’objets

 

Exemple de diagramme d’objets

 

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

Suzie enseigne l’anglais, les math et le Java.

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.

Plan du cours

Introduction

Modéliser la structure avec UML

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]

Diagrammes de classes

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

Représentation UML des classes

 

NomClasse1 attr1 : Chaine attr2 : Entier op1(p1:Entier) : Entier op2() : Chaine

NomClasse2 attr1 attr2

NomClasse3

Représentation UML des attributs

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

 

Représentation UML des opérations

 Format de description d’une opération :

[Visibilité] Nom ["(" Arg ")"] [":" Type]

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

Associations entre classes (1/2)

               Role de C1 dans l’association               Sens de lecture

           C1                                                         C2

(ex. : 1, 0..1, *, 1..*, 4, 4..10, )

 

Associations entre classes (2/2)

 

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 UE a un coefficient et est constituée de cours, de travaux dirigés (TD) et de travaux pratiques (TP).

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.

Navigabilité

 

Propriétés et contraintes sur les associations

 

Associations qualifiées

 

Classes-associations

Associations n-aires

 

Associations particulières : composition et agrégation

 

Généralisation et Héritage

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

Héritage et généralisation : Exemple

 

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 solutions en UML ?

Quelle solution choisissez-vous ?

; On y reviendra avec les Design Patterns

Contraintes sur les relations de généralisation

48/137

Classes génériques (templates)

Classes abstraites

Interface

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

Exemple

 

[image empruntée à Craig Larman]

52/137

Quelques stéréotypes et most-clés

{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

Synthèse des différentes relations

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

Cherchez l’erreur (1/3)

 

55/137

Cherchez l’erreur (1/3)

 

Navigabilité : Tout objet doit être accessible via une association

55/137

Cherchez l’erreur (2/3)

 

56/137

Cherchez l’erreur (2/3)

 

 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

Cherchez l’erreur (3/3)

 

57/137

Cherchez l’erreur (3/3)

 

Navigabilité : En l’absence de réservations, on ne peut accéder ni aux chambres ni aux clients

Plan du cours

Introduction

Modéliser la structure avec UML

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

Diagrammes de paquetages

 

Espaces de nom et visibilité

 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

Dépendances entre paquetages

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

Valeur marquée {global} :

Paquetage visible par tous les autres paquetages

; Inutile de montrer les dépendances vers ce paquetage

Architecture logique

 

Plan du cours

Introduction

Modéliser la structure avec UML

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

Diagrammes de composants

 

[Image extraite de ]

Diagrammes de déploiement

Introduction

Modéliser la structure avec UML

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

Diagrammes de déploiement

Diagrammes de déploiement

Introduction

Modéliser la structure avec UML

Modéliser le comportement avec UML

Principes et patrons de conception orientée objet

Modéliser le comportement avec UML

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

Modéliser le comportement avec UML

Diagrammes d’interaction

Diagrammes de cas d’utilisation

Diagrammes d’états-transitions

Principes et patrons de conception orientée objet

 

Diagrammes de séquence vs diagrammes de communication

 

Message dont l’émetteur n’est pas connu

Objet anonyme

Activation par envoi de message

Valeur retournée (facultatif)

Durée de vie d’o2

Délai de propagation

x y

Diagrammes de séquence : Cadres

Mot réservé pour déclarer un diagramme de séquence

Nom du diagramme de séquence

Existe aussi : par, opt, critique

 

Liens entre diag. de classes et d’interaction

 

[Figure extraite du livre de C. Larman]

 

Plan du cours

Introduction

Modéliser la structure avec UML

Modéliser le comportement avec UML

Diagrammes d’interaction

Diagrammes de cas d’utilisation

Diagrammes d’états-transitions

Principes et patrons de conception orientée objet

Cas d’utilisation

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

; Séquences d’interactions entre les acteurs et le système

 

Relations entre cas d’utilisation

Généralisation : ————

Inclusion : - - - - - «include» - - - - - >

Extension : - - - - - «extend» - - - - - > (préciser la condition) ; A utiliser avec modération

 
 

Plan du cours

Introduction

Modéliser la structure avec UML

Modéliser le comportement avec UML

Diagrammes d’interaction

Diagrammes de cas d’utilisation

Diagrammes d’états-transitions

Principes et patrons de conception orientée objet

Parenthèse sur les automates finis (1/3)

 

Parenthèse sur les automates finis (2/3)

 

Parenthèse sur les automates finis (3/3)

 

Au delà des automates finis

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 !

Retour aux diagrammes d’états-transitions

 

Diagrammes sans gardes ni actions

 

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

; Passage dans l’état Q1 qté tps après l’arrivée dans l’état Q0  Evénements de changement :

when(cond)

Q0 ————————————–> Q1

; Passage dans l’état Q1 quand cond devient vraie

Etats imbriqués (ou composites)

 

Etats concurrents (1/2)

Etats concurrents (2/2)

 

Gardes et transitions composites

Actions et activités

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)

 
 

Exercice 2 : Fonctionnement d’un téléphone

 

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

Diagrammes d’activités

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

De UML à la 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]

Principes de conception orientée objet

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

Forte cohésion : Faciliter la compréhension, gestion et réutilisation des objets en concevant des classes à but unique

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 de conception (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é,

 

Plan du cours

Introduction

Modéliser la structure avec UML

Modéliser le comportement avec UML

Principes et patrons de conception orientée objet Abstract Factory, Factory method, Singleton

Iterator, Strategy, State, Observer, Command

Adapter, Facade, Decorator, Composite

Abstract factory (1/2)

 

Abstract factory (2/2)

 

Singleton

 

Plan du cours

Introduction

Modéliser la structure avec UML

Modéliser le comportement avec UML

Principes et patrons de conception orientée objet Abstract Factory, Factory method, Singleton

Iterator, Strategy, State, Observer, Command

Adapter, Facade, Decorator, Composite

Iterator (1/2)

Iterator (2/2)

Strategy (1/3)

 

Strategy (1/3)

Problème :

Changer dynamiquement le comportement d’un objet

Illustration sur un exemple :

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)

Strategy (3/3)

 

State (1/3)

State (2/3)

 

State (3/3)

Observer (aka Publish/Subscribe) (1/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)

Command (1/3)

 

Command (2/3)

 

Command (3/3)

 

Plan du cours

Introduction

Modéliser la structure avec UML

Modéliser le comportement avec UML

Principes et patrons de conception orientée objet Abstract Factory, Factory method, Singleton

Iterator, Strategy, State, Observer, Command

Adapter, Facade, Decorator, Composite

Adapter

 

Facade

; Application des principes “indirection” et “protection des variations”

Decorator (1/2)

 

Decorator (2/2)

 

Adapter, Facade et Decorator

 

Composite (1/2)

Composite (2/2)

Autres patterns?