u m l analyse et conception objet
Post on 16-Jan-2015
1.784 Views
Preview:
DESCRIPTION
TRANSCRIPT
UMLAnalyse et Conception
Objet (C++)
Plan du cours & Objectifs• Les concepts objets (3)• Les concepts de base d'une conception objet (31)• La notation UML (43)
• UC (52)• Les classes (64)• Les Packages (97)• Les stéréotypes (114)• Diagrammes d'objet (119)• Diagrammes dynamiques (122)• Automates & Activités (131)• Autres diagrammes (138)
•Que faire (comment) avec UML?• Utilisation des diagrammes (148)• La démarche (les démarches)
• Process UP, agilité, XP(153)• Les DP(172)• Une étude de cas
2
Les concepts Objets
• Le problème• Les avantages des techniques OO• Les concepts
• Abstraction• Un programme objet• Encapsulation• Héritage• Polymorphisme
3
Les problèmes
4
Les principales causes de l'échec
5
Les symptômes de l'échec
6
Programmation Objet : Avantages (1)
Les objets apportent :• Fiabilité-sécurité• Productivité• Maintenabilité• Adaptabilité-Evolutivité• Simplicité• Autreté (Réutilisation, composant, Pg visuelle)
7
Les bénéfices des techniques OO
From the corporate Use Of Object Technology
17
11
81714
11
7
6
2
2
5
IncreasedProductivity
Cost savings
Improvedinterfaces
Software reuse
Improvedapplicationmaintenance
Encapsulateexistingapplications
Develop strategicapplicationsquickly
Developapplications asrevenue source
Access new OSand tools
8
OO Versus Dvp classique
0102030405060
OO
Classique
Dvp = 20%
Maintenance = 50%
9
C versus C++ en Maintenance
C++ C++ C++ C C CV0 V1 V2 V0 V1 V2
Average Function LOC 6,66 6,2 6,11 29,62 32,5 37,11Min Function LOC 2 1 1 3 3 3Avg Cyclomatic Complex 1,66 1,59 1,59 5,88 6,25 6,56Avg Comparison Complex 0,25 0,24 0,3 1,38 1,62 2,22Avg Logic Flow Complex 1,91 1,83 1,89 7,25 7,88 8,78Avg Function Complexity 3,69 3,59 3,7 9 9,62 10,56eLoc/100 2,07 2,5 2,68 2,68 2,91 3,53eLOC 207 250 268 268 291 353
10
Notion d'abstraction
ClasseMouleSeau
Constructeur ObjetChateauDeSable
ChateauDeSable
couleur : Bleu, Blanc, Rougepoids : int
MonChateau : ChateauDeSable
c1 : ChateauDeSablec2 : Chateau
DeSable
ChateauDeSable
couleur : Bleu, Blanc, Rougepoids : int
ChateauDeSable(p1 : Couleur, p2 : int)
ChateauDeSable
couleur : Bleu, Blanc, Rougepoids : intVolume : int
ChateauDeSable(p1 : Couleur, p2 : int)Remplir(Quantite : int)Renverser()
~ChateauDeSable() c'est le destructeur11
Un programme objet (1)
12
Un programme objet : Réutilisation
13
Un Objet est Nain et Paresseuxet snob !!!
14
Un programme objet (2)
Mere
Run
Bronzer
Enfant
Creer
JchaiPasQuoiFaire
FaisUnChateau
ChateauDeSable
Creer
Garnir
Casser
JchaiPasQuoiFaire
15
Un programme objet (3)
Mere
Run
Bronzer
Enfant
JchaiPasQuoiFaire
ChateauDeSable
PrendreBain
Delete
16
Un programme objet (3)
Mere
Run
Bronzer
Enfant
JchaiPasQuoiFaire
PrendreBain
Mer
Creer
AllerDans
FaireVagues
BoireTasse
Crier
17
Un programme objet (4)
Mere
Run
Bronzer
Enfant
MerCrier
Delete
18
Un programme objet (5)
Mere
Run
Bronzer
Mer
Fuite Mémoire
19
Un programme objet (6)
EnfantCollege
Lycée
Enfant
Enfant
EnfantUsine
20
Un programme objet (7)
EnfantCollege
Lycée
Enfant
Enfant
EnfantUsine
21
Un programme objet (8)
EnfantCollege
Lycée
Enfant
Enfant
EnfantUsine
22
Un programme objet persistant
EnfantCollege
Lycée
Enfant
Enfant
EnfantUsine
P
P
P
PP P
T
T
23
Les types d’Objet
• Les objets du monde réel : (Analyse)• Concret (Voiture, Personne, …)• Abstrait (Vente, Négociation,….)
• Les objets informatiques : (Conception)• Les objets visibles par l’utilisateur : (IHM)• Les extensions du langage :
• range INT(0:5)• smart pointeur• tableau• les programmes
• Les conteneurs :• tableau, listes, piles, ....• bouts d’application, les patterns, ...
24
Les langages de programmation
AssembleurProgrammation
Fortran (1957) (If-For-Variables )Programmation fonctionnelle-procédurale
PL1 (If-For-Variables + Procédures)Programmation Typée (I=2.5) ADAProgrammation structurée C - Exemple Point(x,y) => p.x & p.yProgrammation Objet Notion de classe (Regroupement des données et des fonctions)
Programmation Logique (Prologue)
25
Les langages Objet
• Simula (67)• Smalltalk• C++ (83) => (87-98)• Java (90)• C# (2000)• Python
Généricité
Object
Arithmétique
26
Compilation-Interprétation
• Les langages Compilés• C, ADA, Cobol, Fortran , C++
• Les langages interprétés• Logo, Prolog, Basic, VB(3-6), vba
• Les langages compilés et interprétés• Java, C#, VB.Net
Source
Compilateur
Binaire
Source
Interpréteur
Source
Compilateur
CodeIntermédiaire
InterpréteurMVJIT
27
EncapsulationPersonne
nom : Stringprenom : Stringpoids : intsexe : booleantaille : intage : int
Manger()Dormir()Travailler()FaireSport()
Public : accessible par tout le monde
Protected : accessible par l'objet et parles héritiers
Private : accessible seulement par l'objet
Les accesseurs :SetAttr et GetAttr
28
Héritage
Personne
nom : Stringpoids : intsexe : booleantaille : intage : int
Manger()Dormir()Travailler()
Personne
nom : Stringpoids : intsexe : booleantaille : intage : int
Manger()Dormir()Travailler()
Dentiste
adresseCabinet
Chirurgien
specialite
Estun
29
Polymorphisme
Personne
nom : Stringpoids : intsexe : booleantaille : intage : int
Manger()Dormir()Travailler()
Dentiste
adresseCabinet
Travailler()
Chirurgien
specialite
Travailler()
Un petit programme :Personne p;Dentiste d;Chirurgien c;
p = d;p.Travailler();p = c;p.Travailler();
Arracher des dents Opérer
Boulanger
Travai ller()
Faire du pain
30
Les concepts d'une bonne conception
Ouverture-Fermeture OCPInversion des dépendances DIP
Substitution de Liskov LSP Séparation des interfaces ISP
31
Exemple : utilisation de la délégation abstraite (OCP)
A gère les cas c1 et c2. Si un nouveau cas c3 doit être géré, il faut modifier le code de A en conséquence :
32
Exemple : (OCP)
Personne
nom : stringage : int
Personne(n : string, a : int)
Appl1
Appl2
BD
ID nom age
Appl3Avec adr
• Rajouter un attribut• Rajouter un constructeur• Rajoute un paramètre au constructeur
• Faire une nouvelle classe PersonneAdr• Rajouter une méthode getAdr même ds Personne
• Rajouter un attribut• Rajouter un constructeur• Rajoute un paramètre au constructeur
• Faire une nouvelle classe PersonneAdr• Rajouter une méthode getAdr même ds Personne
33
Exemple : (OCP) Solution
Appl1
Appl2
Appl3
Personne
nom : stringage : int
Personne(n : string, a : int)GetAdresse() : string
PersonneDomicilee
adresse : string
PersonneDomiciliee(n : string, a : int, adr : string)GetAdresse() : stringSetAdresse(p : string) : void
Rend une chaîne vide:Appl3 peut alors utiliser des Personnes
Jouer sur les méthodes plus tôt que sur les attributsLes gains : 2 versions dans le même exécutable pas besoin de faire de VNR (faites la quand même)
34
Principes de substitution de LISKOV (LSP)
• Pour prétendre à l'héritage, une sous-classe doit être conçue de sorte que ses instances puissent se substituer à des instances de la classe de base partout où cette classe de base est utilisée.
Hériter d’une interface• En insistant sur cette approche de l'héritage, le principe de
substitution s'oppose à une pratique répandue dans laquelle l'héritage est mis en oeuvre pour factoriser du code entre plusieurs classes.
C0
C1 C2
I0<<Interface>>
C1 C2
35
Principes d’inversion des dépendances (DIP)
• Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "métier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :" Le passage à l'abstrait est valorisé"
ObjetMetier
IHM ObjetMetier
IHM
ObjetMetier
IHM
IObjetMetier<<interface>>
ObjetMetier
IHM
IObjetMetier
36
L’abstraction comme technique d’inversion des dépendances (DIP)
Considérons deux classes A et B, A utilisant B comme indiqué sur le schéma ci-dessous :
Pour inverser la dépendance de A vers B, on introduit une classe d'interface I dont dérive B comme suit :
37
Principes de séparation des interfaces (ISP)
• Pollution d'interface par agrégation de services
– On retrouve dans la plupart des designs quelques classes qui rendent
plusieurs services simultanément, comme l'illustre le schéma ci-
dessous :
38
Techniques de séparation (ISP)
• Il existe deux techniques principales de mise en pratique de l'ISP :– L'héritage multiple,– Le Design Pattern "Adapter".
39
Séparation par héritage multiple (ISP)
• Dans cette approche chaque service est représenté par une classe d'interface dont dérive la classe qui implémente les services.
• Les clients ne voient les services qu'au travers de ces classes d'interface comme le montre le schéma suivant :
40
Séparation par adaptateur (ISP)
• Lorsque l'héritage multiple n'est pas possible, les services peuvent être représentés par des classes d'adaptation :
41
UML
• Introduction : notion de modèle• Diagramme de use case
• Acteurs, Use case, Business Modeling• Diagramme de classes• Diagramme d'objets• Diagramme dynamique
• Diagramme d'interaction • Automates• Diagramme d'activité
• Autres diagrammes• Composants et Déploiement
• UML 2.042
La notation UML
Introduction : notion de modèle
43
Le but d ’UML
44
La modélisation : Pourquoi
Une bonne société qui développe des programmes estcelle qui fabrique des programmes de qualité qui satisfont lesbesoins des clients (livraison à temps, utilisation des ressourceshumaines et matérielles optimales)
Le but principal n’est donc pas de produire de beaux documents,ni de conduire de nombreuses réunions, ni de proclamer de beaux slogans, ni de gagner des prix Pulitzer sur les lignes de code;mais simplement de produire des programmes capables de satisfaire le client aujourd’hui et demain.
Tout le reste est secondaireUML-User Guide
45
Notion de Modèle
Ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose
Le petit robert
Top Model
• Toutes abstractions qui incluent toutes lescapacités et propriétés, ou les aspects de ce qui est modélisé sans montrer les détailssuperflus• Un ensemble cohérent de spécifications oud ’information de conception, consistanttypiquement de diagrammes orientés objet et d ’informations
Firesmith-Dictionary of object tecnology46
Un ModèleUn modèle contient :• Des éléments de modélisation
• Des classes (reliées à d'autres classes) avec des opérations etdes attributs
• Des informations supplémentaires sur le comportement des classes (automates, activité)
• Des informations concernant le cahier des charges (UC)• La description des fichiers et des machines supportant l'application
• Des dessins (vues) explicatifs liés les uns aux autres• Des diagrammes de classes réduits• Des diagrammes montrant comment les objets se partagent le
travail (interaction)• Des diagrammes montrant les objets existant à un moment donné
• Toutes ces informations sont organisées dans des packages
47
Les diagrammes UML
2%
5%
4%6%
12%
15%
9%6%
41%
Paquetage
Stéréotypes et tag values
Diag. de classe/objet
Diag. de cas d'utilisation
Diag. de séquence
Diag. de collaboration
Diag. d'états/transitions
Diag. d'activité
Diag. de comp./déploi.
48
+
==
=++++
++++
Les 13 diagrammes UML2.0
49
Un outil UML
Navigateur
Définitions
Boutons génériques
Boutons Spécifiques
Les diagrammes
Classe Use Case
Composants
50
Historique d'UML
Booch-93 Rumbaugh( OMT2)
Oct-950.8
Jacobson (use case - sdl)
Juillet-960.9
Janv-971.0
Nov-971.0
Sept-971.1 (OMG)
20001.4
20052.0
DOC-PDF UML1.3 = 4,7MBDOC-PDF UML2.0 = 5.8 MB
20062.1
51
La notation UML
Diagramme de Use case
52
Diagramme de Use caseLes acteurs
Un acteur est un rôle d’un ou plusieurs objetssitués à l’extérieur du système et qui interagissentavec lui pour remplir une fonctionnalité donnée de ce système.Un acteur caractérise le rôle joué par un objet àl’extérieur du système.
Uti lisateur
• Un acteur parle au système (Acteur principal)• Le système parle à un acteur (Acteur secondaire)• Un acteur est :
• Un humain (via une IHM)• Du soft• Du hard
53
Diagramme de Use caseUse Case
Un Cas d’utilisation ( use case ) est une fonctionnalité remplie par le système et qui semanifeste par un ensemble de messages échangésentre le système et un ou plusieurs acteurs.
UtilisateurVerifierBonneMarche
CapteurTemperature
54
Diagramme de Use caseDescription d'un Use Case
• Titre et numérotation
• Résumé
• Les acteurs
– Acteur principal
– Acteurs secondaires
• Pré-conditions
• Description
• Exceptions
• Post-conditions
(3-5 pages)Ce n ’est pas une
description formelleMais doit être très détaillé
Ceci est l ’usagemais ne fait partiede la norme UML
55
Diagramme de Use caseDescription d'un Use Case
56
Diagramme de Use case
Payer cash
Payer par carte
Manger
Demander facture
Maitre d'hotel
Prendre la commande
clientAller au restaurant<<include>>
<<include>>
Caissier
Payer
<<include>>
<<extend>>
SommelierCommander pinard
<<extend>>
Serveur
Retourner plat en cuisine
<<extend>>
57
Utilisation des Use case
Manger
Descriptions
A
A1()A2()A3()
B
B1()B2()
C
C1()C2()C3()C4()
Distribuer le comportement des fonctionnalitésaux méthodes des objets
58
Use Case : Ex1Une société de vente par correspondance vous demande de développer sonsystème informatique. Ce système doit pouvoir prendre en compte descommandes passées par la poste et des commandes passées par internet. Ildoit suivre les expéditions qui ne sont effectuées que si le paiement est OK.Les paiements se font par carte bancaire dans le cas d'internet et par chèquedans le cas de la poste. Les paiements sont validés par un système bancaire appartenant à la société et existant. Il faut récupérer ce système. Lenouveau système est chargé aussi de la gestion de stocks, lorsqu'un articleatteint un seuil minimal, alors il faut passer une nouvelle commande aufournisseur adéquat. A la réception de la commande, la mise à jour de la base est faite par un employé. Dans le cas d'un paiement accepté et de stockdisponible, l'expédition est faite par un robot existant au quel il suffit depasser les coordonnées du client, et la liste des produits achetés. En cas d'indisponibilité, une lettre doit être envoyé au client.
59Correction
Supplément sur UC : User Story
Une User Story est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l'utilisateur.
Exemples de User stories: • En tant qu'utilisateur, je peux réserver des chambres d'hôtel• En tant que recruteur, je peux déposer des offres d'emploi.
Ron Jeffries utilise les 3 C pour la décrire:
•Card (l'histoire est courte et écrite sur une carte 8x13 cm)•Conversation (les détails de l'histoire sont discutés)•Confirmation (l'histoire est confirmée par des tests d'acceptation
rédigés au même moment que celle-ci, au dos de la carte).
Supplément sur UC (1)Un "Use case" modélise un service rendu par le système. Il représente un ensemble de séquences d'actions qu'un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système.
Exemples d'intitulés de Use cases: • S'authentifier, • Rechercher un livre.
Ces titres ne sont qu'une partie du "Use Case" qui comporte d'autres parties (Acteur, Résumé, Déclencheur, Scénario principal, Extensions...). Un "Use Case" est donc plus détaillé, et nécessite un travail approfondi d'analyse et de formalisation.
Supplément sur UC (2)
User Stories et Use Cases formalisent les besoins utilisateurs et sont orientés ButIls font facilement l'objet d'ateliers de travail avec les utilisateurs pour les découvrir, les expliciterIls vont être priorisés et vont ainsi guider les développementsIls mettent en avant les rôles, les différents profils d'utilisateursIls ne traitent que des exigences fonctionnelles (les aspects non fonctionnels sont décrits dans les spécifications supplémentaires(contexte UP) et dans les "Constraints Cards" (contexte XP))Ils sont textuels et obéissent à des règles de construction très précises Ils ne traitent pas des aspects interface et ergonomieIls aident à organiser le modèleIls facilitent le choix du contenu des itérationsIls peuvent être rédigés par les analystes (UC) ou le client (US)
Business use case
La première étape de la définition d’un système d’informationconsiste donc à s’interroger sur l’organisation (l’entreprise) pourlaquelle ce système d’information fonctionne, sur son identité, sur ce qui en fait partie et sur ce qui n’en fait pas partie
business actor1
business use-case realizationbusiness entity
business actor
business worker
business use case
63
Business use caseUne extension UML
business
actor1
business use-case realization
business entity
business
actor
business worker
business use case
Qui utilise l’entreprise
Qui est utilisé par l’entreprise(en externe)
Que fait l’entreprise
Comment fait l’entrepriseSur quoi travaillel’entreprise
Qui travaille dansl’entreprise 64
Business use case : Ex2
•De quelle entreprise s'agit-il? Trouver les business actor, business entité, business use case et les business worker
• Voyageur• Métro• Station• Couloir• Client• Inspecteur• Wagon
• Guichetier• Panneau publicitaire• Conducteur• Clochard• Commerciaux• Voyager• Acheter• Louer
65
La notation UML
Diagramme de classe
66
Diagramme de classe
• Statique :
– Ne pas utiliser de verbes d'action pour relier les classes
– Une classe isolée est une classe inutile
– Doit être vrai tout le temps
– Représente LE programme
– On ne peut pas tout montrer sur un seul schéma
Un diagramme de classe montre la structure statiquedu modèle, les choses qui existent, leur structureinterne et les relations aux autres choses.
67
Diagramme de classeLes classes
Personne
nom : Stringpoids : intsexetaille : intage : int = 0/ dateNaissance : String$ nbPersonne : int
Manger(calories : int, lipide : float)Dormir() : voidTravailler(duree : int) : int$GetNbPersonne() : int//FaireBonneAction()
Dentiste
adresseCabinet
Travailler()
Abstrait
Nom : type [= Initialisation]
Syntaxe libre
Attribut dérivé
Attribut de classe
Opération de classe
Responsabilité
{abstract}
68
Les classes : Génération de code
69
Diagramme de classeReprésentation des classes
Personne
nom : Stringpoids : intsexetaille : intage : int = 0/ dateNaissance : String$ nbPersonne : int
Manger(calories : int, lipide : float)Dormir() : voidTravailler(duree : int) : int$GetNbPersonne() : int//FaireBonneAction()
Personne
nom : Stringpoids : intsexetaille : intage : int = 0/ dateNaissance : String$ nbPersonne : int
Manger()Dormir()Travailler()$GetNbPersonne()//FaireBonneAction()
Personne
nom : Stringpoids : intsexetai lle : intage : int = 0/ dateNaissance : String$ nbPersonne : int
Personne
Manger()Dormir()Travai ller()$GetNbPersonne()//FaireBonneAction()
Personne
Manger()Dormir()Travailler()$GetNbPersonne()//FaireBonneAction()
Personne
70
Diagramme de classeHéritage et agrégation
Dentiste
Coeur
Personne
1
Dent0..32
1
0..32
1
1
1
0..320..32
Composition
Agrégation
Héritage Cardinalitémultiplicité
Héritage = Est unComposition et Agrégation = Est composé de
71
De quoi hérite -t-on ?
[PAM-97 p55] 72
Généralisation multiple (1)• La généralisation - sous sa forme dite multiple – existe également entre arbres de classes disjoints.
[PAM-00 p52] 73
Généralisation multiple (2)
• Pour que la généralisation multiple puisse être mise en œuvre, il faut que les langages de programmation « objets » supportent l’héritage multiple.
• Dans notre exemple, comment le compilateur peut-il garantir, lors de l’implémentation de la classe T, qu’il n’y ait pas d’effet de bord ou de conflit entre les propriétés pZ héritée de la classe Z et pY héritée de la classe Y?
• Par exemple, JAVA ne supporte pas l’héritage multiple.
74
Classification dynamique
[PAM-00 p58] 75
L’héritage
• L’héritage est une technique offerte par les langages de
programmation pour construire une classe à partir d’une ou de
plusieurs autres classes, en partageant des attributs, des opérations
et parfois des contraintes au sein d’une hiérarchie de classes.
• Les classes enfants héritent des caractéristiques de leurs classes
parents; les attributs et les opérations déclarés dans la classe
parent, sont accessibles dans la classe enfant, comme s’ils avaient
été déclarés localement.
76
Conflit de noms
[PAM-00 p60] 77
Les classes abstraites• Les classes abstraites ne sont pas instantiables directement; elles ne donnent pas naissance à des objets, mais servent de spécifications plus générales -de type- pour manipuler les objets instances (d’une) ou plusieurs de leurs sous-classes.
• La propriété abstraite peut également être appliquée à une opération afin d’indiquer que le corps de l’opération doit être défini explicitement dans les sous-classes.
[PAM-00 p146] 78
Les interfaces
79
Finalité des interfaces
[PAM-00 p120]
• Une interface décrit le comportement d’une classe, d’un composant, d’un sous-système, d’un paquetage ou de tout autre classificateur
80
Finalité et réalisation des interfaces
81
Finalité et réalisation des interfaces
• Une interface possède uniquement la spécification d’un comportement visible, sous forme d’un ensemble d’opérations (pas d’attributs et d’associations), et ne fournit aucune implémentation de ses services.
82
Le polymorphisme
[PAM-00 p63] 83
Les associations
Les associations représentent des relations structurelles entre classes d’objets. Une association symbolise une information dont la durée de vie n’est pas négligeable par rapport à la dynamique générale des objets instances des classes associées. La plupart des associations sont binaires, c’est-à-dire qu’elles connectent 2 classes.
84
Diagramme de classe : Associations Personne Societe
Est Employée par
Nom d'association
Personne SocieteEst Employée par
-employeur-employeNom de rôle
Personne
employeur : Societe
Societe
employe : Personne
SocietePersonne1..* 0..1
-employe -employeur
1..* 0..1
Cardinalité-Multiplicité
Personneemployeur : Societe
Societeemploye : ListeOfPersonne
NavigabilitéSocietePersonne1..*
-employes
1..*
Societeemployes : Personne
Personne
85
Association réflexive
86
Qualité des associations• Naturellement, toute personne a 2 parents. Nous modélisons des systèmes artificiels, une représentation de la réalité, pour lesquels un ou des utilisateurs devront enregistrer dans une base de données les objets instances des classes que nous avons identifiées.• Il n’est pas possible d’imposer dans un modèle que toute personne a 2 parents, car au moment de la saisie les utilisateurs devront remonter à Adam et Eve…• Il est juste qu’une personne a 2 parents et peut avoir plusieurs enfants. Toutefois, le rôle doit indiquer « le rôle » joué par une personne par rapport à une autre personne; ainsi une personne est parent ou enfant (au singulier) d’une autre personne.
87
Diagramme de classeClasse d'association
SocietePersonne 1..* 0..1
-employes
1..* 0..1Où mettre le salaire???
SocietePersonne 1..* 0..1
-employes
1..* 0..1
ContratTravail
Salaire : float
L'association et la classe ne forme qu'un élément
La classe ContratTravail est uneclasse normale qui peut hériter, êtreassociée à d'autres classes, ….
88
Diagramme de classeAssociations exclusives
Societe
Personne
1..*
0..1
1..*
0..1
ANPE1
0..*
1
0..*
{or} Contraintes
89
Les qualificateurs (1)
• Considérons le schéma suivant. Il décrit le fait qu’un avion contient plusieurs sièges qui ont chacun un numéro.
• Cependant, ce schéma ne nous permet pas de dire que chaque siège a un numéro qui est unique pour chaque avion. Cette notion proche de la clé primaire du modèle de bases de données relationnelles, nous permet de préciser la cardinalité des associations.
90
Les qualificateurs (2)
• En UML, l’analyste peut utiliser la notion de qualificateur pour représenter ce concept. Celui-ci est représenté par un rectangle contenant le qualificateur qui portera l’association entre Siege et la classe Avion qualifiée.
• Le diagramme se lit de la façon suivante: « un avion contient un siège pour un numéro donné ».
91
Les qualificateurs (3)
• Le diagramme ci-dessous indique que dans un avion, pour une rangée donnée, il y a 4 sièges.
92
Trouver un qualificateur?
93
qualificateur
94
Association : Génération du code
95
Diagramme de classeDépendance
Depenseri = Banque::GetInstance()->DonnerSolde();Acheter(i);Volerb = new Banque();i = b->DonnerSolde();Economiser (p : Banque)p->Deposer(10000);
Banque
Deposer(p : int)DonnerSolde() : int
Personne
Depenser()Voler()Economiser(p : Banque)
96
Les classes paramétrées
Collection
+Add(Element: T): void+Exist(Element: T): boolean+Remove(Element: T): T
Element :Tsize : int
Collection100String
bind(String,100)
97
Diagramme de classeExo3
98
Diagramme de packages
99
Diagramme de packages
Un package est un regroupement des éléments du model. Cela s’applique à tous les élémentsUML ainsi qu’aux différents diagrammes.Les packages sont la base de la gestion deconfiguration P.13
P0
On peut montrer ce qu’il y a à l’intérieur du packageUne classe appartient à un package et un seule, mais peutêtre utilisée dans d'autres package.
P1
+ C1C2C3
P2
global
100
Notion de package
• Un paquetage est un regroupement d’éléments de modélisation,
mais aussi une encapsulation de ces éléments. A l’image des
classes, les paquetages possèdent une interface et une réalisation.
• Chaque élément contenu par un paquetage possède un paramètre
qui signale si l’élément est visible ou non à l’extérieur du paquetage.
• Les valeurs prises par le paramètre sont : public ou implémentation (privé).
101
Packages et dépendances
Cela signifie que :
• Un élément de P0 au moins utilise un élément publique de P3 et de P1
• Un élément de P3 au moins utilise un élément publique de P1
• P0, P3 et P1 peuvent utiliser les éléments publiques de p2
P2
global
P1
+ C1C2C3
P0
P3
102
Packages et dépendances(1)
103
Organisation des packages
C
A B
D
P-AB P-CD
P-AB1B2 P-CD
C
A B1
D
B2
RMQ : On peut rajouter des classes
104
Trouver trois packages et les relations
K
L
A B
I
E
J
G
D
H
C
F
105
K
L
A B
I
E
J
G
D
H
C
F
Trouver trois packages et les relations (suite)
106
K
L
A B
I
E
J
G
D
H
C
F
p1
P2P3Design Pattern Façade
Trouver trois packages et les relations (suite)
107
Dépendances circulaires (Pb)
A
Op1()Fqq()
(f rom PA)
B
Op2()Fqq()
(f rom PB)+monB+monAOp1{b.Fqq()}
Op2{a.Fqq()}
monA : A : Application : A monB : B
Op1( )
Fqq( )
Op2( )
Fqq( )
108
Dépendances circulaires (Solution)
A
Op1()Fqq()
(f rom PA)B
Op2()Fqq()
(f rom PB)
FqqAble
Fqq()
(f rom Interf ace)
<<Interface>>
+monB +monA
A
Op1()Fqq()
(f rom PA)
B
Op2()Fqq()
(f rom PB)+monB+monA
• A n'est intéressépar B que pour luifaire faire Fqq()
• B n'est intéressépar A que pour luifaire faire Fqq()
109
Dépendances circulaires (Solution)
A
Op1()Fqq()
(f rom PA)B
Op2()Fqq()
(f rom PB)
FqqAble
Fqq()
(f rom Interf ace)
<<Interface>>
+monB +monAPA
+ A
PB
+ B
Interface
+ FqqAble
Rmq : si il y a des méthodes différentes, alors faire plusieurs interfaces
110
Dépendances circulaires (RMQ 1)
PA
+ A
PB
+ B
Interface
+ FqqAble
Rmq1 : L'objet A ne doit pas créer l'objet B Rmq2 : L'objet B ne doit pas créer l'objet A Rmq3 : Si nécessaire, on peut laisser l'un des deux
PA
+ A
PB
+ B
Interface
+ FqqAble
Rmq1
Rmq2
111
Dépendances circulaires (RMQ 1)
FqqAble
Fqq()
(f rom Interf ace)
<<Interface>>
A
Op1()Fqq()AddmonB(p : FqqAble)
(from PA)
+monB
Application
B
Op2()Fqq()AddMonA(p : FqqAble)
(from PB)
+monA
L'application :• Crée un objet A• Crée un objet B• Présente B à A en tant
que FqqAble• Présente A à B en tant
que FqqAble
112
Dépendances circulaires (RMQ 1)
: Application a : A b : B
Creer
Creer
AddMonB(b )
AddMonA(a )
op1 fqq
fqq()
A::AddMonB(FqqAble p)
B::AddMonA(FqqAble p)
113
Conclusion sur les dépendances
• Regrouper les classes qui vont bien ensemble• Un package peut contenir 15 classes• Éviter les associations bi-directionnelles• Rajouter des classes• Utiliser les interfaces (ou des classes abstraites)
pour découpler• Utiliser les design pattern suivants:
• Singleton• Façade• Observeur• Commande
Simple
Luxueux
114
Notion de stéréotypesUn stéréotype est une nouvelle classe d’un élément de modélisation qui est introduit au moment de la modélisation. Cela représente une sous classe d’un élémentde modélisation existant avec la même forme, mais avecune intention différente.
• Exemple : un acteur est "comme" une classe, mais il ne fait paspartie du système. Un acteur pourrait être un stéréotype d'une classe
• On peut stéréotyper les classes, les associations, les packages, …..• On peut associer un nouvel icône pour chaque nouveau stéréotype.
Z<<nouveauStereotype>>
115
Notion de stéréotypes(2)
• Les stéréotypes font partie des mécanismes d’extensibilités, prévus par UML.
• Un stéréotype permet la métaclassification d’un élément d’UML. Il permet aux utilisateurs (méthodologistes, constructeurs d’outils, analystes et concepteurs) d’ajouter de nouvelles classes d’éléments de modélisation, en plus du noyau prédéfini par UML.
116
Diagramme de classeBoundary-Controleur-Entité (1)
Environnement
Métier
Fonctionnel
B
C
E
Control
Fonctionnel
Entite
Métier
Boundary
Environnement
117
Diagramme de classeBoundary-Contrôleur-Entité (2)
Aiguilleur
Pilote
Decoller
Atterrir
Aeroport
Voler
118
Diagramme de classeBoundary-Contrôleur-Entité (2)
Aiguilleur
Pilote
Decoller
Atterrir
Aeroport
VolerCtrlVoler
CtrlDecoller
CtrlAtterrir
DecollerForm
VolerForm
AtterrirForm
AeroportForm
AiguilleurForm
TrainAtterrissage
Reacteur
Frein
119
Diagramme de classeExo4
Immeuble
Famille
Appartement
Pièce
Cuisine
Salon
Gardemanger
Chien
Chat
Animal
Locataire
Proprietaire
Nourriture
Lapin
Whisky
Mariage
CompteBanquaire
Personne
120
Diagramme de classeExo4
Immeuble
Famille
Appartement
Pièce
Cuisine
Salon
Gardemanger
Chien
Chat
Animal
Locataire
Proprietaire
Nourriture
Lapin
Whisky
Mariage
CompteBanquaire
Personne
121
Diagramme de classeExo5
Schtroumpf<<singleton>>
+nom: String
+ChercherAzzerel()
Palseperaillable<<interface>>
+poids: int
+FairePalseperaille()
Schtroumpfette
+longueurCheveux
LeGrandSchtroumpf
Cheval<<Utility>> LuckyLuke
+ChasserDalton()
CapableChasserDalton
Whisky
HaddockDupontd Tintin
+sonMaitre+jollyJumper ne boit pas
boit
+sonCopain
122
La notation UML
Diagramme d'objets
123
Diagramme d'objets• Rappel : Un diagramme de classe représente le programme, il est vrai
tout le temps.• Un diagramme d'objets ou diagramme d'instances représente
une photo du programme à un moment donné. • Les diagrammes de classe doivent être validées par les diagrammesd'objets
A B
0..20..2
a : A
b1 : B
b2 : B
• Une classe -> Un Objet [avec un nom]Rmq : l'héritage ne se voit plus
• Une association -> Zéro, un ou plusieurs liens (cardinalité)
• Une dépendance -> Un lien
Rmq : aucune information sur les liens (cardinalité, rôle,navigation, ….)
124
Diagramme d'objetsExo5
• Famille : Tintin & Milou, locataire• Famille : Haddock qui boit du whisky est marié à la Castafiore
Haddock est propriétaire de Moulinsart• Tournesol est locataire d’une partie de Moulinsart
Reprendre le résultat de l'Exo4 et faireles diagrammes d'objets correspondantsModifier éventuellement le diagramme de classe
125
Locataire
proprio
La notation UML
Diagrammes dynamiques
126
Diagramme dynamique
• Diagrammes d'interaction (Séquence collaboration) servent à montrer comment les objets se parlent les une aux autres.Ils montrent le déroulement d'un ou d'une partie d'un Use case(cas nominal, cas des exceptions, …)
• Automates servent à montrer le comportement d'une classe qui réagit différemment selon son état.
• Activités montrent le déroulement d'une méthode d'une classe oucelui d'un Use case
127
Diagramme de Séquence
: Clienta : A b : B c1 : C : C
A2( )
A3( )
B2( )C2( )
C4( )
new
128
Diagramme de CommunicationCollaboration
129
Diagramme de communication
a : A
: Client
b : B
c1 : C
: C
1: A2( )
2: A3( )
3: B2( )
4: C2( )5: C4( )
130
Diag. de Séquence :Navigation
: departhaddock : Personne
: Appartement : Salon : GardeManger : Whisky
Boire( )GetSalon( )
GetGardeManger( )
GetMaBouteille( )
Consommer( )
Cuver( )
Personne
Boire()GetAppartement() : AppartementCuver()
Appartement
GetSalon() : Salon
-monAppart
Salon
name : type = initval
GetGardeManger() : GardeManger
-maPiece
Whisky
Consommer()
GardeManger
GetMaBouteille() : Whisky
-monGardeManger
-maBouteille
131
Diagramme de communication Génération de code
132
Diagramme de Séquence (UML2.0)
133
Diagramme d'interactionExo6
Mariage
Propriétaire
Personne
0..1
0..1
+femme
+mari
Immeuble0..* 1
0..1
0..1
0..* 1
Hadock : Personne
Casta : Personne
Moulinsart : Immeuble
CH : Mariage
Hadock : Personne
Casta : Personne
Moulinsart : Immeuble
HM : Propriétaire
Avant
Après
• Faire le diagrammed'interaction correspondant aux changements.
• Mettre à jour le diagramme de classe
: ????
System
SeMarier
Acheter
134
Automate• Un automate est accroché à une classe et est composé d'états etde transitions. Les transitions permettent de passer d'un état àun autre …
Arret Marche
On
Off
Casse
Casse
135
AutomateÉtat & Transition
Etat
entry/ Action1exit/ Action2on Ev1/ Action2do/ Activité
E1 E2Ev1( a1,a2 )[ i == 0 ] / ActionDeTransition ^Cible.SendEv2(a3, a4)
Événement qui déclenche la transitionGarde
Action effectuée sur la transition
Envoie de Ev2 à un objet Cible
Action en entrant dans l'état
Action en sortant de l'état
Action déclenchée sur réception de Ev1
Activité
136
Automate imbriqué
Arret
Marche
Lavage
Rinçage
Essorage
H
On
Lavage
Rinçage
Essorage
After15After10
After5
PorteOuverte
HFermer
Off
Ouvrir[ cuve vide ]
Représentation d'un automate imbriqué
Automate:état historique profond
Automate :point de Jonction(1)
Automate :point de Jonction(2)
Automate :point de décision
Automate Parallèle
• C'est un mélange d'automate et de diagramme d'activité
143
Automate : exo7
E1
ST1
entry: i = 0exit: i++
ST2
entry: i++exit: i++on E4: i ++
E1 / i++
ST3ST4
on E2: i = i - 2
E3[ i == 5 ]
E2
E1
E1
E3
E3
E1E3E1E3E1E2E1E2
E3
144
Diagramme d'activité(1)
SeMarier
Acheter
SetMari SetFemme
AddPropriétées
Prix
SetProprio
[ Trop cher ]
[ OK ]
NewSwimlane3 : ImmeubleNewSwimlane2 : PersonneNewSwimlane : ????
145
Diagramme d'activité(2)
146
Diagramme d'activité : nœud d'objetavec état
La notation UML
Les autres diagrammes
148
Diagramme de composants (1)
Objet
Objet
Faca
List
C1C2
c1 c2
List
Faca
Iterat
Iterat
Elem.
Elem.
149
Diagramme de composants (2)
150
Diagramme de composants (3)
151
Diagramme de déploiement(1)
IMPR
IBM de course
Gestion des déclarations
Stockage
PC
SaisieJava
Mac
SaisieJava
152
Diagramme de déploiement(2)
153
Structure Composite :le problème
154
Structure Composite : exemple
Courant
Voiture
A6: Batterie
RAR: RoueMotrice[2]: Moteur
: Recepteur
RAV: RoueDirectrice[2] : ElectroAimant
ondesjus A6: Batterie
RAR: RoueMotrice[2]: Moteur
: Recepteur
RAV: RoueDirectrice[2] : ElectroAimant
ondesjus
Charge Telecommande
-A3: Batterie-DG: Bouton[4]-: Emeteur
jus A3: BatterieDG: Bouton[4]
: Emeteur ondesjus A3: BatterieDG: Bouton[4]
: Emeteur ondes
Vitesse
Tourner
Voiture
-A6: Batterie-RAR: RoueMotrice[2]-RAV: RoueDirectrice[2]-: Moteur-: Recepteur-: ElectroAimant
+plusVite()+moinsVite()+TourneADroite()+TourneAGauche()+Charger()
155
Diagramme de temps
156
Vue d'ensemble des interactions
• Les diagrammes d’interaction générale fusionnent les diagrammes d’activité et de séquence en autorisant l’utilisation de fragments (diagrammes de séquence) avec des points de décision et des flots de contrôle (diagrammes d’activité).
157
La notation UML
Utilisation des diagrammes
158
Importance des diagrammes
Type de diagramme Importance/utilisationLes diagrammes packages moyenneLes diagrammes de classe hauteLes diagrammes objet faibleLes diagrammes de structure composite moyenneLes diagrammes de composant moyenneLes diagrammes de déploiement faibleLes diagrammes de cas d’utilisation moyenneLes diagrammes d’activité hauteLes diagrammes d’état moyenneLes diagrammes de communication faibleLes diagrammes de séquence hauteLes diagrammes de temps faibleLes diagrammes d’interaction générale haute
159
La notation UMLLes diagrammes (1)
Diagramme de UC==> Les fonctionnalités vues de l'extérieure du
système
Personne Coeur
Diagramme de classe==> Les choses qui existent à l'intérieure du
système
Diagramme d'interaction==> Distribution des fonctionnalités aux
choses qui existent. Découverte desopérations des classes, de nouvelles classes, ….
Diagramme d'activité ==> Description des opérations complexes
160
La notation UMLLes diagrammes (2)
Ouvert Fermé
Battre
Battre
Diagramme Automate
==> Comportement des classes complexes
Diagramme d'instanceHaddock :
CoeurCasta : Coeur
==> Validation des diagrammesde classe
==> Description des fichiers contenant l'application (source, exe, …)
Diagramme de composants
Coeur Exe
==> Les machines supportantl'application
Diagramme de déploiementPC
Exe 161
Interaction Diagram
Requirements
Sequence
Collaboration
Use Cases
GUI
Class diagram
State Activity
Implementation
Component
Deployment
Code
Code
Code
Code
Tests
Cinématique des diagrammes UML
162
La démarche
ProcessQuiQuoiQuand
MéthodeComment
Langage Avec quoi
163
Process Outils
Hommes
UP
XP:BinômeTD
Scrum
Processus en V
Winston Royce
Addison Wesley
164
165
Processus en Y
Conceptualisation Analyse Architecture Conception Implémentation
Y
5 Phases Classiques :
166
Un processus itératif et incrémental (I)
• Guidé par les cas d'utilisation
Conceptualisation
Analyse Architecture
Définition des incréments
Conception
Implémentation167
Processus en YLes phases
• Le but de la conceptualisation est de définir ce que l’on veut (doit) faire (Affinement du cahier des charges)
• Le but de l’analyse est de trouver toutes les propriétés d’un système donné indépendamment de toutes implémentations
• Les objets du métier
• Le but de l’architecture est de trouver toutes les solutions techniques et ceci indépendamment du problème à traiter.
• Les objets des informaticiens
• Le but de la conception est le mapping d ’une analyse donnée sur une architecture donnée.
• Les objets du métier + objets des informaticiens
• L’implémentation doit être presque rien168
Conceptualisation (1)
ExpertMetier ExpertObjet
TrainOméoplasmose
Sténotype
ClassePolymorphisme
Relinker
Langagecommun
• Décrire ce que l’on doit faire(UC) => langage commun• Langage commun => Glossaire• Glossaire => Tout ce qui est mis dans un modèle doit avoir
une définition associée
169
Conceptualisation (2)
Les UC :• Décrire les acteurs et ce qu’ils attendent du système• Décrire l’ensemble des messages entrant et sortant du système• Ne pas décrire comment on fait• Décrire l’ensemble des contraintes
• Réutilisation d’un autre système• Problème de capacité-volume (des chiffres)• Problème de temps de réponse (des chiffres)• Choix technique quelconque imposé
RMQ : Ne pas se vautrer dans la PatateOide
170
Architecture• Faire des choix techniques correspondant aux contraintes
• Distribution (Obligatoire ou pour des problèmes de performance)• Fiabilité• Persistance
• Faire ces choix sans s’occuper de l’application• Valider ces choix par des protos• Découpe du système en sous-système• Simplifier la vie des utilisateurs
• Exemple des classes <<Role>>• Customisation des générateurs de code• Customiser et apprendre les outils aux utilisateurs• Production des Make File• Choix et mise en œuvre des design patterns utilisés pour le projet• Normes de programmation et de modélisation• Réutilisation par le principe de la réduction-expansion
171
Analyse
• Partir des diagrammes de UC• Trouver les classes d’analyse (Boundary et Control)
• Partir de la description des UC• Trouver les classes entity• Faire tourner le programme
• Diagramme de séquence• Cas nominal• Les cas d’exception
• Affiner le diagramme statique (attributs, opérations, nouvelles classes)
• Refaire des sous-systèmes• Affiner les classes complexes : Automate
RMQ : Ne pas se vautrer dans l’héritage172
Conception
A partir des résultats de l’analyse et de l’architecture:• Modifier les diagrammes d’analyse pour prendre en compte
les choix techniques de l’architecte• Application des design patterns• Persistance• Distribution• Les classes boundaryForm deviennent des sous systèmes• Certains contrôleurs peuvent disparaître, mais ceux qui restent
doivent rester simple• Utiliser l’héritage pour des problèmes de performance
• Refaire des diagrammes statiques et des diagrammes dynamiques
RMQ : Ne pas refaire ce qu’a fait l’architecte
173
Processus : le RUP : Historique
174
Processus : le RUP
Unify Process (Énorme process pour tous)
RUP Rational Unify Process Process customisé à partir du UPC'est un outil (site web, customisable)
Custom
AirFranceUP
Le RUP est :• Itératif• Basé sur une architecture à base de composants• Dirigé par les UC
175
Processus : le RUPLes phases
176
Processus : le RUPAnalyse et conception
Concepteur BD
Concepteur
Analyste
ArchitecteArchitecte
Architecte
Trouver et spécifier avecdes responsabilités lesclasses Boundary-Controlet entité
Mettre en place les mécanismes de persistance
Trouver les abstractions clés
Faire le mapping objet BDR
Méthode177
MéthodeC'est un ensemble de trucs et de règles :• Analyse :
• ne donner que des responsabilités• ne pas se vautrer dans l'héritage• trouver les classes B-C-E
• Architecture• Persistance, Distribution, Réutilisation d'ancien système, Fiabilité,
Capacité, performances, …..• Conception
• Modifier les (grosses) classes persistantes• Garder les contrôleurs pour mettre les transactions• Transformer les boundary en sous système
• Organisation du modèle• Utiliser les Use Case réalisation pour documenter le modèle
178
MéthodePersistance (1)
T_Ba c T_B_IDb
50 Raymonde 0155 Casta 1145 Simone 21
T_Aa c T_A_IDb
55 Robert 0060 Haddock 1035 0 Tintin 2
T_0T_A_ID T_B_ID
0
1
011
0
0 2
Mapping objet vers Table relationnellefait automatiquement par les outils(choix de l'architecte)
179
MéthodePersistance (2)
Data Modeler
180
Processus Light
XP
Process Agile
RAD
Programmation visuelle
TV4IT : Pourquoi le poste de développeur est déconsidéré en FranceEric Groise
181
Design patterns
182
Classification des patterns
Création
Comportement
Structure
183
Les Design patterns de comportement (1)
• State : un objet réagit selon son humeur• Stratégie : Faire une chose de différentes manières• Template Methode : Faire une chose de différentes manières
(avec une recette de base)• Observer : certains sont intéresses par ce que je fais, mais pas tout le
temps• Visiteur : Rajouter une responsabilité à une classe avec des sous
traitements identiques• Memento : sauvegarder un objet• Iterateur : Balayer une collection• Chaîne de responsabilité : un élément est attendu par un grand nombre d'objets
184
Les Design patterns de comportement (2)
• Commande : encapsule une requête dans un objet, et permet les files d'attentes, les journalisassions , et retours en arrière (undo).
• Médiateur : définit un objet qui encapsule la manière dont un ensemble d'objets interagissent.
• Interpréteur : définit un langage ainsi que sa grammaire, et fournit un interpréteur pour utiliser la représentation du langage.
185
State : UML
Client
Etat
+Op1(Context)+Op2(Context)+Op3(Context)
*
Etat1
+Op1(Context)+Op2(Context)
Etat2
+Op2(Context)+Op3(Context)
Context
+Op1()+Op2()+Op3()~SetEtat(Etat)
Client
Context
+Op1()+Op2()+Op3()-SetEtat(Etat)
Etat
+Op1(): Etat+Op2(): Etat+Op3(): Etat
*
Etat1
+Op1(): Etat+Op2(): Etat
Etat2
+Op2(): Etat+Op3(): Etat
186
State + SingletonE1
E2E3
C1
C2
C3
C2
C1
C2
C3
C1() {monEtat->C1(this)}
E1
$ instance : *E1
$GetInstance() : *E1C1(p : *Objet)C2(p : *Objet)
<<Singleton>>E2
$ instance : *E2
$GetInstance() : *E2C1(p : *Objet)C2(p : *Objet)C3(p : *Objet)
<<Singleton>>
E3
$ instance : *E3
$GetInstance() : *E3C2(p : *Objet)C3(p : *Objet)
<<Singleton>>
Etat
C1(p : *Objet)C2(p : *Objet)C3(p : *Objet)
Objet
C1()C2()C3()SetState(p : *Etat)
+monEtat
C1(--) {"Erreur"}
C1() {"OK"}C2() {"OK";p->SetState (E2)}
187
Stratègie : UML
Context
+ContextInterface()
Strategie
+Algorithme()
ConcreteStrategieA
+Algorithme()
+maStrategie
ConcreteStrategieB
+Algorithme()
Client
Context
+Op1()+Op2()+Op3()-SetEtat(Etat)
Etat
+Op1(): Etat+Op2(): Etat+Op3(): Etat
*
Etat1
+Op1(): Etat+Op2(): Etat
Etat2
+Op2(): Etat+Op3(): Etat
188
Patron de méthode
AbstractClass
+fqq()+fqq2()+fqq1()
ConcreteClass1
+fqq1()+fqq3()+fqq2()
fqq =fqq1 + fqq2 + fqq3
ConcreteClass2
+fqq2()+fqq3()
189
l’Observer : UML
Observer<<Interface>>
+UpDate()
Sujet
+list<Observer> lesObserveurs
+add(Observer)+remove(Observer)+notify()
SujetConcret
+state
+getState(): state+setState(p): void
Observer1
+UpDate()
Observer2
+UpDate()
Réutilisable
Rmq : souvent UpDate contient des paramètres (evt, le sujet, l'état du sujet, …)
190
l ’Observer : la dynamique : Observer1 : SujetConcret : Observer2
add()
add()
setState()
notify()
UpDate()getState()
UpDate()remove()
setState()
notify()
UpDate()getState()
191
Visitor
• Rajouter une (ou plusieurs) méthode à un objet (sans la rajouter) !!!!
• A utiliser quand une classe ne sait pas ce qu’elle veut et qu’elle risque de vouloir beaucoup de choses.
• La classe fait déjà beaucoup de petites choses
• L'objet visité accepte le visiteur (Accept (Visitor v)) • Il dit alors à v de visiter (v.Visit())• v fait son travail
192
Visitor : UMLElement
<<interface>>
+Accept(Visiteur)
Visiteur<<interface>>
+Visit(Element)
ElementVisité
+Operation1()+Operation2()+Accept(Visiteur v)
VisiteurConcret1
+Visit(Element e)
Accept(Visiteur v){v.Visit(this);}
Visit (Element e){cast e->ElementVisitée.OPeration1()+ e.OPeration2();}
v1 : VisiteurConcret1 e : ElementVisité
<<create>>
<<create>>
Accept(v1): void
Visit(Element e): voida=Operation1()
b=Operation2()
a+b()
193
Mémento : UML
UnDo-ReDo
La classe à surveiller-----La mémoire----Le programme client (main)
Originator
-state
+SaveMemento(): Memento+RestoreMemento(m: Memento): void
Memento
-state
+GetState()+SetState()
Caretaker
+SetMemento(p Memento)+GetMemento(): Memento
-monMenento
1
RestoreMemento(m){state = m.GetState();}
SaveMemento(){m = new Memento();m.SetState(state);return m;}
SetMemento(p ){moMemento = p;}
GetMemento() : Memento{return monMemento;}
Client
194
Itérateur: UML
Aggregate
+CreateIterator(): Iterator
Iterator
+First(): Object+Next(): Object+IsDone(): boolean+CurrentItem(): Object
ConcreteAggregate
+CreateIterator(): Iterator
ConcreteIterator
-position
~ConcreteIterator(ConcreteAggragate)-maCollection
CreateIterator():return new ConcreteIterator(this);
Client
195
Chain of Resp : Exemple
Président<100000
Vice-président<25000
Directeur<10000
Comité>=100000
Director grouillot = new Director(); VicePresident Sam = new VicePresident(); President Tammy = new President(); Grouillot.SetSuccessor(Sam); Sam.SetSuccessor(Tammy); Purchase p = new Purchase( 350.00, "Formation"); Grouillot.ProcessRequest(p); p = new Purchase( 24000, "Voiture"); Grouillot.ProcessRequest(p);p =new Purchase ( 99000, "Maison");Grouillot.ProcessRequest(p);p = new Purchase( 122100.00, "Usine"); Grouillot.ProcessRequest(p);
U
M
V
F Directeur
Acheter(p : Achat)
VicePresident
Acheter(p : Achat)
President
Acheter(p : Achat)
Approver
SetSuccesseur(p : *Approver)<<Abstract>> Acheter(p : Achat)
0..1+Chef
0..1
Achat
Prix : intlibelle : string
196
Command : UMLClient Invoker
Command
+Execute()
ConcreteCommand
+Execute()
Receiver
+Action() -receiver
receiver.Action()
: Client : ConcreteCommand a : Receiver : Command : Invoker
<<create>>
<<create>>
SetReceiver(a)
Execute
Execute(): voidAction(): void
Configurateur Utilisateur
197
Mediator : UMLMediator
ConcreteMediator
Colleague
+mediator
boutonbouton
listeliste
textAreatextArea
ControleurControleur
menumenu
Rmq :Façade-Observer
198
• Proxy : cacher la complexité d'un objet• Décorateur : Rajouter une responsabilité à une classe sans changer l'interface• Adaptateur : Adapter un objet à un autre• Composite : permet de traiter une structure d'objets de manière uniforme (Des feuilles et des nœuds)• Façade : Représenter, regrouper et diriger un ensemble d'objets • Poids mouche : Partager de nombreux minis objets• Pont : permet de différencier une abstraction de son
implémentation, permettant à chacune d'évoluer indépendamment.
Les Design patterns de Structure
199
Proxy : UML
Proxy.Operation1() {fait qqchose…..leSujet.Operation1();}
Proxy.Proxy(Sujet param){leSujet = param;}
Sujet
+Operation1()
SujetReel
+Operation1()
Proxy
+Operation1()+Proxy(p: Sujet)
+leSujet
Client
200
Decorator : UML
Decorateur.Operation():fait qq chosesuper.Operation()
Cela revient à rajouter une responsabilité à une classe mais sans en changer l'interface. Comparer avec le composite
Component
+Operation()
ComposantConcret
+Operation()+ComposantConcret()
Decorateur
+Operation()+Decorateur(Component)
-monComposant
1
Decorateur1
+Operation()+Decorateur1(Component)
Decorateur2
+Operation()+Decorateur2(Component)
ComposantConcret.Operation : fin de la chaîne
Decorateur.Operation() :monComposant.Operation()
201
l ’Adaptateur : Uml et Exemple
Dentiste
+Travailler()
Boulanger
+Travailler()
Travailleur<<interface>>
+Travailler()
Chomeur
+ChercherDuTravail()
SarkoChomeur
+Travailler() +monChomeur
monChomeur.ChercherDuTravail
Chomeur
+ChercherDuTravail()
super.ChercherDuTravail
Client Cible
+fqq()
Adapteur
+fqq()
Adapté
+fac()
Adapteur.fqq()=Adapté.fac()
202
Composite : Le contexte & UMLOn utilise le Composite lorsque on veut :• Représenter une hiérarchie d'objets• Ignorer la différence entre un composant simple et un composant
en contenant d'autres (interface uniforme) Client Component
+Operation()
Composite
+Operation()+Add(p: Component)+Remove(p: Component)+GetChild(index: int): Component
Leaf
+Operation()
+lesEnfants*
Operation()pour chaque enfant :Faire Operation()puis faire qq chose sibesoin pour le composite
Comparer avec le décorateur203
Façade : UML
204
Flyweight : Poids mouche :UML
Utilisation : beaucoup de petits objets à se partager à plusieurs.Exemple : les caractères d'un document
PluriGleton
FabriqueDePoidsMouche
+GetFlyweight(key)
PoidsMouche
+Operation()
Client
PoidsMoucheConcret PoidsMouchePartagé
+lesPoids
*
205
Bridge : UML
Rmq : ressemble au state
Abstraction
+Add(c: chose)+Remove(c: chose)
maCollection
Implementor
+Add(c: Chose)+Remove(c: Chose)
Vector
+Add(c: Chose)+Remove(c: Chose)
+imp
List
+Add(c: Chose)+Remove(c: Chose)
Pile
+Add(c: Chose)+Remove(c: Chose)
add:imp.Add(c)
206
• Singleton : un et un seul objet visible par tous• Fabrication : créer un objet en fonction d'un paramètre• Fabrique abstraite : créer une famille d'objets tous cohérents• Monteur : construire un objet en différentes étapes • Prototype : permet de spécifier le type d'objets à créer en utilisant une instance prototype. Le prototype sera copié pour créer les nouveaux objets.
Les Design patterns de Création
207
Le singleton uml
ClasseSingleton
<<static>> uniqueInstancedonnéeInstance
<<static>> Instance()OpérationSingleton()
Instance() { retourne uniqueInstance}
208
Fabrication : le Design pattern
Createur
+Fabrication(type: String): Produit+uneOperation()
CreateurConcret
+Fabrication(type: String): Produit
ProduitConcret1
+fqq()
ProduitConcret2
+fqq()
Produit
+fqq()
Client
209
Fabrication Abstraite : motivation
Application
IHMMotif
IHMwindows
Application IHM
IHMMotif
IHMwindows
L’application utilise IHM sans savoir si ils ’agit de Motif ou bien de Windows
210
Fabrication Abstraite : Structure
FabriqueAbstraite
CreerProduitA()CreerProduitB()
FabriqueConcrete1
CreerProduitA()CreerProduitB()
FabriqueConcrete2
CreerProduitA()CreerProduitB()
ProduitAbstraitA
ProduitAbstraitB
ProduitA1 ProduitA2
ProduitB1 ProduitB2
Application
<<instancie>>
211
Builder : UMLDirector
+Construct(Builder)
Builder
+BuildPart1()+BuildPart2()
ConcreteBuilder
+BuildPart1()+BuildPart2()+GetResultt(): Product
Product
+list<Parties> leProduct
+builder
BuildPart1()BuildPart2();GetResult();
: Director b1 : ConcreteBuilder
<<create>>
Construct(Builder): void
BuildPart1(): void
BuildPart2(): void
GetResultt(): void
212
Prototype
•Masque au client les complexités de la création de nouvelles instances (new, clone, deserialisation, …)
• Permet au client de générer des objets dont le type n’est pas connu.• Dans certaines circonstances, la copie d’un objet peut être plus efficace
que la création d’un objet (memberWiseClone du c#)
Client Prototype
+Clone()
ConcretePrototype1
+Clone(): Prototype
+prototype
ConcretePrototype2
+Clone(): Prototype
213
Etude de cas
214
• Sur le Web de rational : www.rational.com– UML Notation guide– UML Semantics– Object Constraint Language Specification– Le RUP
• Livres sur UML– Modélisation Objet avec UML (Muller/Eyrolles)– Visual modeling with rational Rose and UML
• Livres sur OMT (James Rumbaugh/Masson)
UML : Bibliographie
215
UML : Bibliographie (suite)
216
WWW
CETUS
217
Autres sites web
http://www.numbersix.com/http://www.m2tech.net/
218
Corrections des exercices
219
Use Case : Correction Ex1
Robot
ClientPoste
ClientInternet
Verifier StockFournisseur
Passer Commande Internet
include
Passer Commande Posteinclude
SystemBancaireVerifier Paiement
Include
Include
Expedier Commande
Extend
AdministrateurGérer Stocks et fournisseurs
220
Use Case : Correction Ex1
UC : Secrétaire
UC: Détails
UC:Suppléments
IHM : Secrétaire
UCWeb
UC : Requirements
Business use case : Correction Ex2 (1)
Business Actor
• Voyageur• Métro• Station• Couloir• Client• Inspecteur• Wagon
• Guichetier• Panneau publicitaire• Conducteur• Clochard• Commerciaux• Voyager• Acheter• Louer
Business Worker
• Voyageur• Métro• Station• Couloir• Client• Inspecteur• Wagon
• Guichetier• Panneau publicitaire• Conducteur• Clochard• Commerciaux• Voyager• Acheter• Louer 232
Business use case : Correction Ex2 (2)
Business use case
• Voyageur• Métro• Station• Couloir• Client• Inspecteur• Wagon
• Guichetier• Panneau publicitaire• Conducteur• Clochard• Commerciaux• Voyager• Acheter• Louer
• Voyageur• Métro• Station• Couloir• Client• Inspecteur• Wagon
• Guichetier• Panneau publicitaire• Conducteur• Clochard• Commerciaux• Voyager• Acheter• Louer
Business Entité
233
Diagramme de classeCorrection Exo3 (1)
Vehicule NewClass6
Voiture
Roue
Personne
Entreprise
{or}
Construction
Entreprise
Roue
Voiture
44
Piece
Jardin
Personne
Maison
44
0..10..11..2
0..*
{or}
Construction
ContratSimple
ContratDouble
Contrat
Vehicule
Maison
Couple
Roue
Personne
0..*0..*
22
Entreprise
Voiture
44
1..20..*
ActeNotarial
234
Diagramme de classeCorrection Exo3 (2)
{or}
Construction
ContratSimple
ContratDouble
Contrat
Vehicule
Maison
Couple
Roue
Personne
0..*0..*
22
Entreprise
Voiture
44
235
Diagramme de classeCorrection Exo4
236
Diagramme d'objets Correction Exo5 (1)
Famille : Tintin & Milou, locataire
Bruxelle : Appartement
Tintin : PersonneCL :
Locataire
TM : Famille
Milou : Chien
237
Diagramme d'objets Correction Exo5 (2)
Haddock qui boit du whisky est marié à la Castafiore et est propriétaire de Moulinsart
Haddock : Personne
Casta : PersonneMHC :
Mariage
HC : Famille
Moulinsart : Immeuble
????????
238
Diagramme d'objets Correction Exo5 (3)
Locataire
PersonneBienImmobilier
Proprietaire
Immeuble
Appartement
Haddock qui boit du whisky est marié à la Castafiore et est propriétaire de Moulinsart
Haddock : Personne
Casta : PersonneMHC :
Mariage
HC : Famille
Moulinsart : BienImmobilier HM :
Proprietaire239
Diagramme d'objets Correction Exo5 (4)
Tournesol est locataire d’une partie de Moulinsart
Locataire
PersonneBienImmobilier
Proprietaire
Immeuble
Appartement
Moulinsart : Immeuble
AT : Appartement
Tournesol : PersonneLT :
Locataire
240
Diagramme d'interactionCorrection Exo6 (1)
: ????
: Mariage Hadock : Personne
Casta : Personne
MH : Propriétaire
Moulinsart : Immeuble
SeMarier(m : Personne, f : Personne)
SetFemme(f : Personne)
SetMari(m : Personne)
Acheter(bi : BienImmobilier , p : Personne )
new
new
SetProprio(p : Personne)
AddPropriete(argname : BienImmobilier)
241
Diagramme d'interactionCorrection Exo6 (2)
Casta : Personne
: ????
: Mariage
Hadock : Personne
MH : Propriétaire
Moulinsart : Immeuble
1: SeMarier(m : Personne, f : Personne)
2: SetFemme(f : Personne)
3: SetMari(m : Personne)
4: Acheter(bi : BienImmobilier , p : Personne )
5: SetProprio(p : Personne)
6: AddPropriete(argname : BienImmobilier)
242
Diagramme d'interactionCorrection Exo6 (3)
Mariage
SeMarier(m : Personne, f : Personne)
Immeuble
SetProprio(p : Personne)
Personne
SetFemme(f : Personne)SetMari(m : Personne)AddPropriete(argname : BienImmobilier)
0..1
0..1
+femme 0..1 +mari
0..1+proprio
1
+proprietes
0..* 10..*
Propriétaire
Acheter(bi : BienImmobilier, p : Personne)BienImmobilier
243
Les développeurs Français
Comment revaloriser le métier d'informaticien et d'ingénieur ?Je crois qu'il est important de mieux expliquer ce qu'est le logiciel. Car c'est encore trop abstrait pour beaucoup de monde. Il faut expliquer que c'est une véritable industrie (qui demande donc des investissements et une approche industrielle..) mais également en quelque sorte un art (car les talents sont clés).
Ensuite il faut rappeler qu'il y aura plus d'innovation dans les 30 ans qui viennent que dans les 30 ans passés - et que nous sommes donc au cœur d'une industrie qui va générer de la croissance et des emplois.
Enfin il faudrait refaire rêver sur les perspectives d'une carrière dans l'informatique et revaloriser les filières techniques. Nous avons chez Microsoft des architectes logiciels qui sont à des niveaux hiérarchiques supérieurs à des managers de grandes divisions. Cette révolution "culturelle" n'a pas encore eu lieu en France mais nous sommes optimistes.
Supplément sur UC : User Story
Une User Story est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l'utilisateur.
Exemples de User stories: • En tant qu'utilisateur, je peux réserver des chambres d'hôtel• En tant que recruteur, je peux déposer des offres d'emploi.
Ron Jeffries utilise les 3 C pour la décrire:
•Card (l'histoire est courte et écrite sur une carte 8x13 cm)•Conversation (les détails de l'histoire sont discutés)•Confirmation (l'histoire est confirmée par des tests d'acceptation
rédigés au même moment que celle-ci, au dos de la carte).
Supplément sur UC (1)Un "Use case" modélise un service rendu par le système. Il représente un ensemble de séquences d'actions qu'un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système.
Exemples d'intitulés de Use cases: • S'authentifier, • Rechercher un livre.
Ces titres ne sont qu'une partie du "Use Case" qui comporte d'autres parties (Acteur, Résumé, Déclencheur, Scénario principal, Extensions...). Un "Use Case" est donc plus détaillé, et nécessite un travail approfondi d'analyse et de formalisation.
Supplément sur UC (2)
User Stories et Use Cases formalisent les besoins utilisateurs et sont orientés ButIls font facilement l'objet d'ateliers de travail avec les utilisateurs pour les découvrir, les expliciterIls vont être priorisés et vont ainsi guider les développementsIls mettent en avant les rôles, les différents profils d'utilisateursIls ne traitent que des exigences fonctionnelles (les aspects non fonctionnels sont décrits dans les spécifications supplémentaires(contexte UP) et dans les "Constraints Cards" (contexte XP))Ils sont textuels et obéissent à des règles de construction très précises Ils ne traitent pas des aspects interface et ergonomieIls aident à organiser le modèleIls facilitent le choix du contenu des itérationsIls peuvent être rédigés par les analystes (UC) ou le client (US)
Supplément sur UC (3)
Le robot
Correction
Le robot correction : les UC
Le robot correction : les UC : jouer(1)
Le robot correction : les UC : jouer(2)
Le robot correction : les UC : Deplacer
Le robot correction : les UC : Prendre
Le robot correction : les UC : Deposer
Le robot correction : les UC : Attaquer
Le robot correction : les UC : IHM
top related