U M L Analyse Et Conception Objet

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


Mere

Run

Bronzer

Enfant

Creer

JchaiPasQuoiFaire

FaisUnChateau

ChateauDeSable

Creer

Garnir

Casser

JchaiPasQuoiFaire

15


Mere

Run

Bronzer

Enfant

JchaiPasQuoiFaire

ChateauDeSable

PrendreBain

Delete

16


Mere

Run

Bronzer

Enfant

JchaiPasQuoiFaire

PrendreBain

Mer

Creer

AllerDans

FaireVagues

BoireTasse

Crier

17


Mere

Run

Bronzer

Enfant

MerCrier

Delete

18


Mere

Run

Bronzer

Mer

Fuite Mémoire

19


EnfantCollege

Lycée

Enfant

Enfant

EnfantUsine

20


EnfantCollege

Lycée

Enfant

Enfant

EnfantUsine

21


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



Dentiste

adresseCabinet

Chirurgien

specialite

Estun

29

Polymorphisme

Personne



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


Manger(calories : int, lipide : float)Dormir() : voidTravailler(duree : int) : int$GetNbPersonne() : int//FaireBonneAction()

Personne


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


• 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


• 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


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


: 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


Immeuble

Famille

Appartement

Pièce

Cuisine

Salon

Gardemanger

Chien

Chat

Animal

Locataire

Proprietaire

Nourriture

Lapin

Whisky

Mariage

CompteBanquaire

Personne

120


Immeuble

Famille

Appartement

Pièce

Cuisine

Salon

Gardemanger

Chien

Chat

Animal

Locataire

Proprietaire

Nourriture

Lapin

Whisky

Mariage

CompteBanquaire

Personne

121


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


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


150


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

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


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


Etat2


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

: qq

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

: qq

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


+imp

List


Pile


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


FabriqueConcrete2


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

: qq

: 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

UC : Requirements

Business use case : Correction Ex2 (1)

Business Actor



Business Worker


• Guichetier• Panneau publicitaire• Conducteur• Clochard• Commerciaux• Voyager• Acheter• Louer 232

Business use case : Correction Ex2 (2)

Business use case





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


Haddock qui boit du whisky est marié à la Castafiore et est propriétaire de Moulinsart

Haddock : Personne

Casta : PersonneMHC :

Mariage

HC : Famille


????????

238


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


Tournesol est locataire d’une partie de Moulinsart

Locataire

PersonneBienImmobilier

Proprietaire

Immeuble

Appartement


AT : Appartement

Tournesol : PersonneLT :

Locataire

240

Diagramme d'interactionCorrection Exo6 (1)

: ????

: Mariage Hadock : Personne

Casta : Personne

MH : Propriétaire


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


Casta : Personne

: ????

: Mariage

Hadock : Personne

MH : Propriétaire


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


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.


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)

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

U M L Analyse Et Conception Objet

Documents

Transcript of U M L Analyse Et Conception Objet