Vous êtes sur la page 1sur 125

UNIVERSITE ABDELMALEK ESSAADI

FACULTE DES SCIENCES ET TECHNIQUES


TANGER

Dpartement de Gnie Informatique

Module : Gnie logiciel Mthode UML


Master Mathmatiques Appliques et Informatique
Encadr par :

Professeur Chakkor Saad


E-mail : saadchakkor@gmail.com Anne Universitaire : 2011-2012
21/11/2012

Programme
Introduction Besoin de modles Diagrammes de classes Reverse Engineering Rtro conception et patrons de conception Gnration de code Diagrammes de squence Diagrammes de cas dutilisation

21/11/2012

Le gnie logiciel
Le gnie logiciel est lensemble des rgles quil faut respecter pour avoir une chance de dvelopper un programme sans trop de bug et que lon pourra facilement faire voluer ultrieurement. Un bug dsigne une faute du programme lors de son excution ou une erreur dcriture qui fait quil ne fait pas exactement ce quil devrait.

21/11/2012

LE CYCLE DE VIE DUN LOGICIEL


Le cycle de vie dun logiciel, cest lensemble des tapes quun programmeur doit suivre pour crer un logiciel. Il existe de nombreux cycles de vie,

21/11/2012

Introduction

UML (Unified Modeling Language) UML est un langage de modlisation trs complet, qui couvre de nombreux aspects du dveloppement des logiciels, comme : Les exigences, larchitecture, les structures et les comportements.

21/11/2012

besoin de modles
Construction dapplications : la construction dune application informatique se rsume raliser du code pour rpondre au besoin dun utilisateur

la ralisation du code nest pas la seule activit effectuer lorsque nous souhaitons construire une application.

besoin de modles
Parmi les autres activits non moins indispensables effectuer : Sassurer davoir bien compris le besoin de lutilisateur afin de raliser un code qui le satisfasse. Sassurer davoir ralis un code facilement modifiable, permettant de prendre en compte des volutions futures. Dfinir larchitecture de lapplication (dfinition de ses diffrents composants, indpendamment du langage de programmation) afin de bien comprendre les relations entre les composants de lapplication.
7 21/11/2012

besoin de modles
Raliser une batterie de tests afin de mesurer, dune certaine manire, la qualit du code. Effectuer un suivi des besoins de lutilisateur afin dintgrer des amliorations. Effectuer des corrections de erreurs. La prsence de erreurs tant invitable, il faut la grer plutt que la subir. crire la documentation utilisateur. crire la documentation dinstallation de lapplication. crire la documentation de lapplication afin quune autre quipe de dveloppeurs puisse reprendre le dveloppement.
8 21/11/2012

besoin de modles
Pour faire face cette complexit de construction des applications informatiques, lingnierie logicielle propose des mthodes et des techniques permettant de rpondre aux questions suivantes :

Objectif : montrer en quoi les diffrentes techniques de modlisation UML (quoi et comment) permettent dobtenir rapidement un gain de productivit.

besoin de modles
Le code : Le code occupe donc une place particulire dans la construction dune application informatique, mais laquelle exactement ? 1. Question : Comment le code peut-il tre utilis pour faciliter la maintenance des applications informatiques ? 2. Question. Comment pouvons-nous retrouver les fonctionnalits dune application en lisant le code ? 3. Question. Comment pouvons-nous dcrire la faon de mettre en production une application ? 4. Question. Comment pouvons-nous dcrire la faon dutiliser une application ?

besoin de modles
Documentation un ensemble de documents ncessaires raliser pour complter le code. Ces documents sont changs entre les clients de lapplication et les diffrents membres de lquipe de dveloppement. larchitecte, concevait les composants principaux de lapplication, le dveloppeur, dveloppe les composants de lapplication, et ladministrateur, installe lapplication afin quelle puisse tre utilise par lutilisateur.

besoin de modles

12

21/11/2012

besoin de modles
Ces documentations soient comprhensibles et quelles soient cohrentes entre elles. Ce problme peut tre rsum : Comment rdiger les documentations afin quelles soient intelligibles de manire non ambigu ? Comment sassurer que les documentations ne contiennent pas dincohrences ? Pour rpondre ces questions il faut que les modles soient utiliss.

13

21/11/2012

besoin de modles
Les modles Dfinition :

Un modle contient donc plusieurs informations sur une application informatique : vue des donnes, vue des utilisateurs (fonctionnalits), vue technique.

14

21/11/2012

besoin de modles

15

21/11/2012

besoin de modles
Modles et code : le code est diffrent du modle. Cest la matrialisation de la solution. Le code nest pas plus dtaill que les modles. le modle devant contenir toute linformation permettant la production du code, un modle doit tre au moins aussi dtaill que le code. Faire un modle nest pas plus facile qucrire du code. le modle contient des informations fortement diversifies se doivent dtre cohrentes.

16

21/11/2012

besoin de modles
Ne pas confondre niveau dabstraction et niveau de prcision. Abstraction : le fait de pouvoir masquer dans une vue certaines informations inutiles par rapport lobjectif bien dfini de cette vue.

Par exemple, il nest pas intressant de montrer les dtails techniques Java dans la vue des donnes. Toutes les informations de chaque vue doivent tre prcises.

17

21/11/2012

besoin de modles
Les modles doivent tre productifs plutt que dclaratifs. Lobjectif des modles est de contenir linformation ncessaire la production et lvolution du code. Les informations contenues dans les modles doivent donc tre synchronises avec le code. Nous considrons les modles comme des lments de production plutt que comme des lments de documentation.

18

21/11/2012

besoin de modles

19

21/11/2012

besoin de modles
Le concept de modle tel quil sera tudi dans ce cours, selon les vues structurelle , comportementale et fonctionnelle , sur trois niveaux dabstraction. Nous prsenterons de plus les relations de cohrence entre ces lments de modles ainsi que la relation de synchronisation avec le code.

20

21/11/2012

Diagrammes de classes

La vue structurelle du modle UML est la vue la plus utilise pour spcifier une application. Objectif de vue : modliser la structure des diffrentes classes dune application oriente objet ainsi que leurs relations. UML dfinit sa propre smantique OO, laquelle ressemble la smantique des langages de programmation objet Java ou C++. Il est donc important de considrer UML comme un langage part entire, et non pas comme une couche graphique permettant de dessiner des applications Java ou C++.
21 21/11/2012

Diagrammes de classes
Concepts lmentaires : Classe : Smantique En UML, une classe dfinit la structure commune dun ensemble dobjets et permet la construction dobjets instances de cette classe. Une classe est identifie par son nom. Graphique Une classe se reprsente laide dun rectangle, qui contient le nom de la classe.
22 21/11/2012

Diagrammes de classes
la classe nomme Personne. Interface Smantique En UML, une interface dfinit un contrat que doivent respecter les classes qui ralisent linterface. Une interface est identifie par son nom. Les objets instances des classes qui ralisent des interfaces sont aussi des instances des interfaces. Une classe peut raliser plusieurs interfaces, et une interface peut tre ralise par plusieurs classes.
23 21/11/2012

Diagrammes de classes
Graphique Une interface se reprsente de deux faons : soit laide dun rectangle contenant le nom de linterface, au-dessus duquel se trouve la chane de caractres interface, soit laide dun cercle, au-dessous duquel se trouve le nom de linterface.

24

21/11/2012

Diagrammes de classes
La relation de ralisation entre une classe et une interface est reprsente par une flche pointille la tte en forme de triangle blanc.

25

21/11/2012

Diagrammes de classes
Proprit (appele attribut) dune classe ou dune interface Smantique Les classes et les interfaces peuvent possder plusieurs proprits. Une proprit a un nom et un type. Le type peut tre soit une classe UML, soit un type de base (integer, string, boolean, char, real). Un objet instance de la classe ou de linterface doit porter les valeurs des proprits de sa classe.

26

21/11/2012

Diagrammes de classes
Graphique Les proprits dune classe ou dune interface se reprsentent dans le rectangle reprsentant la classe ou linterface. Chaque proprit est reprsente par son nom et son type. la classe Personne, avec sa proprit nom de type string.

27

21/11/2012

Diagrammes de classes
Opration dune classe ou dune interface Smantique Les classes et les interfaces peuvent possder plusieurs oprations. Une opration a un nom et des paramtres et peut lever des exceptions. Les paramtres sont typs et ont un sens (in, out, inout, return). Un objet instance de la classe ou de linterface est responsable de la ralisation des oprations dfinies dans la classe ou dans linterface.
28 21/11/2012

Diagrammes de classes
Si le sens dun paramtre de lopration est in, lobjet appelant lopration doit fournir la valeur du paramtre. Si le sens dun paramtre de lopration est out, lobjet responsable de lopration doit fournir la valeur du paramtre. Si le sens dun paramtre de lopration est inout, lobjet appelant lopration doit fournir la valeur du paramtre, mais celle-ci peut tre modifie par lobjet responsable de lopration.

29

21/11/2012

Diagrammes de classes
Si une opration possde un paramtre dont le sens est return, cela signifie que lobjet responsable de lopration rend cette valeur comme rsultat de lopration. Lapport de la direction return par rapport la direction out est de faciliter la combinaison de fonction. Il est important de souligner que les oprations UML ne dfinissent pas le comportement qui sera ralis lors de traitement de lopration.

30

21/11/2012

Diagrammes de classes
Graphique Les oprations dune classe ou dune interface se reprsentent dans le rectangle reprsentant la classe ou linterface. Chaque opration est reprsente par son nom et ses paramtres. Il est aussi possible de masquer les paramtres de lopration. prsente la classe Personne avec son opration getNom.

31

21/11/2012

Diagrammes de classes
Hritage entre classes Smantique En UML, une classe peut hriter dautres classes. Lhritage entre classes UML doit tre considr comme une inclusion entre les ensembles des objets instances des classes. Graphique La relation dhritage entre deux classes est reprsente par une flche la tte en forme de triangle blanc.
Classe Personne, qui hrite de la classe EtreVivant.
32 21/11/2012

Diagrammes de classes
Package Smantique Un package permet de regrouper des classes, des interfaces et des packages. Ils ne peuvent avoir quun seul package dans lequel ils sont regroups. La possibilit dtablir un lien entre des classes et des interfaces dpend du lien qui existe entre les packages qui les contiennent.

33

21/11/2012

Diagrammes de classes
Graphique Les packages se reprsentent laide dun rectangle possdant un onglet dans lequel est inscrit le nom du package. Les lments contenus se reprsentent dans le rectangle. La taille du rectangle sadapte la taille de son contenu. le package nomm personnel, qui contient la classe Personne.

34

21/11/2012

Diagrammes de classes
Import de package Smantique Afin que les classes dun package puissent hriter des classes dun autre package ou y tre associes , il faut prciser une relation dimport entre ces deux packages. La relation dimport est monodirectionnelle, cest--dire quelle comporte un package source et un package cible. Les classes du package source peuvent avoir accs aux classes du package cible.

35

21/11/2012

Diagrammes de classes
Graphique La relation dimport entre deux packages sexprime laide dune flche en pointill. La chane de caractres access element inscrite au-dessus de cette flche peut tre optionnellement positionne. Relation dimport entre deux packages P1 et P2 contenant resp. les classes A et B. La classe A a besoin daccder la classe B.

36

21/11/2012

Diagrammes de classes
Note Smantique Une note UML est un paragraphe de texte qui peut tre attach nimporte quel lment du modle UML (package, classe, proprit, opration, association). Le texte contenu dans la note permet de commenter llment cibl par la note.

37

21/11/2012

Diagrammes de classes
Graphique Les notes se reprsentent laide dun rectangle contenant le texte et dont un des coins est corn. Une ligne discontinue permet de relier la note llment du modle quelle cible. une note attache lopration nomme getNom().

38

21/11/2012

Diagrammes de classes
Associations entre classes UML dfinit le concept dassociation entre deux classes permet de prciser les relations qui peuvent exister entre plusieurs objets. une association se fait entre deux classes a un nom et deux extrmits, qui permettent de la connecter chacune des classes associes. Les objets instances de ces deux classes peuvent tre relis entre eux. lassociation nomme habite, qui associe les classes Personne et Adresse.
39 21/11/2012

Diagrammes de classes
Chaque extrmit de lassociation a un nom de rle, qui permet didentifier chacune des classes lies dans le contexte de lassociation. mme association en prcisant le nom des rles de chaque classe lie. Dans le contexte de cette association, la classe Personne reprsente lhabitant alors que la classe Adresse reprsente la rsidence.

il est possible de spcifier chaque extrmit les nombres minimal et maximal dobjets devant tre relis.
40 21/11/2012

Diagrammes de classes
rsidence 1 : pour 1 habitant, il y a au minimum 1 rsidence et au maximum 1 rsidence. habitant * : pour 1 rsidence, il y a au minimum 0 habitant et au maximum une infinit dhabitants. Il est possible de rendre chacune des extrmits navigable ou non. Si une extrmit est navigable, cela signifie que lobjet peut naviguer vers lautre objet auquel il est reli et ainsi obtenir les valeurs de ses proprits ou invoquer les oprations dont il est responsable.

41

21/11/2012

Diagrammes de classes
les habitants peuvent naviguer vers leurs rsidences (et pas linverse), ce qui permet dobtenir, par exemple, le numro de rue.

42

21/11/2012

Diagrammes de classes
UML propose deux smantiques de contenance : une smantique de contenance faible, dite dagrgation : permet de prciser que les lments contenus peuvent tre partags entre plusieurs conteneurs, Graphique

43

21/11/2012

Diagrammes de classes
une smantique de contenance forte, dite composition, qui permet de prciser que les lments contenus ne peuvent tre partags entre plusieurs conteneurs. Graphique

44

21/11/2012

Diagrammes de classes
la classe Personne joue un rle de conteneur pour la classe Compte Bancaire dans le cadre de lassociation moyens de paiement, ce qui signifie quun compte bancaire ne peut tre le moyen de paiement que dune seule personne.

45

21/11/2012

Diagrammes de classes
Concepts avancs Classe abstraite Smantique Une classe UML peut tre abstraite. Dans ce cas, elle ne peut pas directement instancier un objet car certaines proprits et certaines oprations sont abstraites. Graphique Pas de reprsentation graphique particulire pour les classes abstraites, il fallait mettre le nom de la classe en italique.
46 21/11/2012

Diagrammes de classes
Multiplicit des proprits et des paramtres Smantique Une proprit ou un paramtre peut porter plusieurs valeurs. UML permet de prciser les nombres minimal et maximal de ces valeurs. Graphique Pour les proprits et les paramtres, les nombres minimal et maximal des valeurs apparaissent entre crochets. Le caractre * est utilis pour prciser que le nombre maximal de valeurs est infini.
47 21/11/2012

Diagrammes de classes
diffrentes proprits en prcisant des nombres minimal et maximal de valeurs.

48

21/11/2012

Diagrammes de classes
Visibilit des classes, des proprits et des oprations Smantique On dit quune classe A accde la proprit dune classe B si le traitement associ une opration de A utilise la proprit de B. On dit quune classe A accde lopration dune classe B si le traitement associ une opration de A fait un appel lopration de B.

49

21/11/2012

Diagrammes de classes
Les visibilits proposes par UML 2.0 sont les suivantes :
Public : la proprit ou lopration peuvent tre accdes par nimporte quelle autre classe. Private : la proprit ou lopration ne peuvent tre accdes que par la classe elle mme. Protected : la proprit ou lopration ne peuvent tre accdes que par des classes qui hritent directement ou indirectement de la classe qui dfinit la proprit ou lopration.

50

21/11/2012

Diagrammes de classes
Graphique Le caractre + est utilis pour prciser la visibilit public. Le caractre - est utilis pour prciser la visibilit protected. Le caractre # est utilis pour prciser la visibilit private.

51

21/11/2012

Diagrammes de classes
Proprits et oprations de classe Smantique la valeur dune proprit dfinie par une classe est porte directement par la classe elle-mme pas par objet Il est possible de prciser quune classe est directement responsable dune opration quelle dfinit. On appelle ces proprits et ces oprations des lments de niveau classe .

52

21/11/2012

Diagrammes de classes
Graphique Dans la reprsentation graphique de la classe, les proprits et les oprations de niveau classe sont soulignes.

53

21/11/2012

Reverse Engineering

Concepts UML inexistants dans les langages de programmation : Association UML permet de dfinir une proprit de type B dans une classe A. Il est aussi possible dutiliser les multiplicits de cette proprit pour rfrencer plusieurs objets. En Java, il nest pas possible de prciser que deux rfrences appartenant deux classes correspondent la mme association et que lune est loppose de lautre.
54 21/11/2012

Reverse Engineering
Import entre packages En UML, la notion de package existe indpendamment de la notion de classe. Il est possible de dfinir des relations dimport directement entre les packages. Direction des paramtres En UML, les paramtres dune opration ont une direction (in, out, inout, return), qui prcise la faon dont les valeurs doivent tre transmises. Java ne supporte que les directions in et return dUML.

55

21/11/2012

Reverse Engineering
Concepts des langages de programmation inexistants en UML Corps des mthodes Les langages de programmation permettent tous de coder le traitement associ chaque opration. UML ne permet pas de dfinir le traitement associ aux oprations des classes.

56

21/11/2012

Reverse Engineering

Smantique dappel dopration Chaque langage de programmation dfinit sa propre smantique dappel dopration. En UML, aucune smantique dappel dopration nest impose Il est possible de modliser diffrentes smantiques dappel dopration dans la partie comportementale du modle.

57

21/11/2012

Reverse Engineering

API Chaque langage de programmation dispose de sa propre API (Application Programming Interface) : ce qui fait la richesse du langage de programmation. API permet dappliquer des oprations arithmtiques lmentaires, denvoyer des messages sur Internet, dcrire et de lire dans des fichiers et dafficher des composants graphiques.

58

21/11/2012

Reverse Engineering

UML ne propose aucune API. Il est impossible de modliser en UML lapplication Salut tout le monde, car il nexiste aucune API permettant dafficher une chane de caractres lcran (quivalant du System.out.println de Java).

59

21/11/2012

Reverse Engineering
Concepts communs UML et aux langages de programmation qui nont pas le mme sens Hritage En Java, seul lhritage simple entre classes est autoris. Il nest donc pas possible de faire quune classe hrite de plusieurs classes. En UML, lhritage multiple est autoris.

60

21/11/2012

Reverse Engineering
Types de base Comme tout langage de programmation, Java possde un ensemble de types de base (byte, short, int, long, float, double, boolean, char, String). UML ne propose que peu de types de base (Integer, String, Boolean, Char, Real). La raison est que UML a t conu pour tre un langage de modlisation.

61

21/11/2012

Reverse Engineering
Synthse entre UML et les langages de programmation

Similitudes et divergences des smantiques Java et UML,


62 21/11/2012

Reverse Engineering
Passage de code Java vers les diagrammes de classes Le code nest que la matrialisation de la solution. Objectif de lopration de Reverse Engineering : construire un diagramme de classes partir du code, est de construire le modle de la solution partir de sa matrialisation (la partie structurelle ). Lopration de Reverse Engineering permet de construire automatiquement la partie du modle de lapplication relative la vue structurelle et ciblant le niveau dabstraction le plus bas.
63 21/11/2012

Reverse Engineering
Code, modle et opration du Reverse Engineering

64

21/11/2012

Reverse Engineering
Intrt : tablir un lien entre le code et le modle. Le code est li au modle grce cette relation. Reverse Engineering ne permet en aucun cas de construire automatiquement lintgralit du modle.

65

21/11/2012

Reverse Engineering
Rgles de correspondance du Reverse Engineering Rgles de correspondance Java vers UML 1. toute classe Java doit correspondre une classe UML portant le mme nom que la classe Java. 2. toute interface Java doit correspondre une interface UML portant le mme nom que linterface Java.

66

21/11/2012

Reverse Engineering
3. tout attribut dune classe Java doit correspondre une proprit appartenant la classe UML correspondant la classe Java. Le nom de la proprit doit tre le mme que le nom de lattribut. Le type de la proprit doit tre une correspondance UML du type de lattribut Java. Si lattribut est un tableau, la proprit peut avoir plusieurs valeurs (en fonction de la taille du tableau).

67

21/11/2012

Reverse Engineering
4. toute opration dune classe Java doit correspondre une opration appartenant la classe UML correspondant la classe Java. Le nom de lopration UML doit tre le mme que celui de lopration Java. Pour chaque paramtre de lopration Java doit correspondre un paramtre UML de mme nom, dont la direction est in et dont le type est le type UML correspondant au type du paramtre Java.

68

21/11/2012

Reverse Engineering
5. Si une classe Java appartient un package Java, ce dernier doit correspondre un package UML correspondant au package Java qui doit contenir la classe UML correspondant la classe Java. 6. Si une classe Java importe un package Java, ce dernier doit correspondre une relation dimport entre le package UML de la classe UML correspondant la classe Java et le package UML correspondant au package Java import. 7. Si une classe Java hrite dune autre classe Java, les classes UML correspondantes doivent avoir elles aussi une relation dhritage.
69 21/11/2012

Reverse Engineering
8. Si une classe Java ralise une interface, la classe UML correspondante doit aussi raliser linterface UML correspondante. Ces rgles de correspondance ne prennent pas en considration le concept UML dassociation.

9. Si une opration Java possde un code de traitement, alors doit correspondre une note UML contenant ce code et qui doit tre attache lopration UML correspondant lopration Java.

70

21/11/2012

Reverse Engineering
Soulignons le fait quil existe plusieurs rgles de correspondance possibles : partir dun mme programme Java, il est possible dobtenir plusieurs modles UML diffrents.

71

21/11/2012

Reverse Engineering
Intrt et limites du Reverse Engineering UML fait la distinction entre modle UML et diagramme UML. Un diagramme nest quune reprsentation graphique dune partie dun modle. Il est possible de dfinir plusieurs diagrammes pour un mme modle.

72

21/11/2012

Reverse Engineering
Modle UML dune application informatique et ses diagrammes

73

21/11/2012

Les diagrammes reprsentent graphiquement linformation contenue dans un modle. Reverse Engineering ne construit donc pas de diagramme de classes mais une partie du modle. Reverse Engineering construit la partie structurelle du modle et la stocke dans une base de donnes ou dans un fichier. Grce aux informations contenues dans la base de donnes ou dans le fichier, il est possible de construire plusieurs diagrammes de classes.

74

21/11/2012

Reverse Engineering
Diagrammes faire aprs un Reverse Engineering Aprs avoir ralis une opration de Reverse Engineering, nous prconisons dlaborer les diagrammes suivants : un diagramme de classes reprsentant lintgralit des informations ; un diagramme de classes reprsentant uniquement lensemble des packages et leurs relations dimport sans montrer leur contenu ;

75

21/11/2012

Reverse Engineering
un diagramme par package montrant uniquement le contenu dun package ; un diagramme par classe permettant de montrer le contenu de la classe et les associations et les liens dhritage vers les autres classes.

76

21/11/2012

Reverse Engineering
Gains offerts par le Reverse Engineering premire opration de modlisation qui permette dobtenir un gain de productivit. permettant de gnrer automatiquement une des neuf parties du modle UML Possibilit de gnrer une documentation de la structure de lapplication laide des diagrammes de classes labors. Cette documentation a lavantage dtre faite dans un langage de modlisation standard trs largement diffus.

77

21/11/2012

Reverse Engineering
Possibilit dlaborer les autres parties du modle UML tout en gardant une cohrence avec le code.

78

21/11/2012

Rtro conception et patrons de conception


Quest-ce quune dpendance ? cela signifie quune classe A dpend dune classe B si elle est lie : soit organiquement (par lune de ses proprits ou lune de ses associations) ou fonctionnellement (par lune de ses oprations) un ensemble de classes ou une classe dun ensemble de classes. Dun point de vue technique, nous considrons dans le cadre de ce cours quune classe A dpend dune classe B si et seulement si :
79 21/11/2012

Rtro conception et patrons de conception


A hrite de B. A est associe B, et lassociation est au moins navigable de A vers B. A possde un attribut dont le type est B. A possde une opration dont le type de lun des paramtres est B. graphique

80

21/11/2012

Rtro conception et patrons de conception


Il est possible de faire apparatre sur un mme diagramme les relations de dpendance et les causes des relations de dpendance :

81

21/11/2012

Rtro conception et patrons de conception


Impact des cycles de dpendances Dpendances entre classes Si deux classes A et B dpendent mutuellement lune de lautre, cela signifie quil est impossible de les sparer. Il est parfois ncessaire, voire obligatoire, dtablir des dpendances mutuelles afin dassurer une navigation bidirectionnelle entre des lments lis.

82

21/11/2012

Rtro conception et patrons de conception


une association navigable dans les deux sens entre les classes Personne et CompteBancaire. Cette association est la cause dune dpendance mutuelle entre ces deux classes.

Il faut rduire autant que possible les dpendances mutuelles et les cycles de dpendances entre classes mais il nest pas ncessaire de les interdire.
83 21/11/2012

Rtro conception et patrons de conception


Dpendances entre packages Il est ncessaire dtablir une relation dimport entre deux packages lorsquil existe des associations ou des relations dhritage entre les classes quils contiennent. Les dpendances mutuelles et plus gnralement les cycles de dpendances entre classes sont interdits entre les classes de plusieurs packages.

84

21/11/2012

Rtro conception et patrons de conception


Une relation dimport entre P1 et P2, car A dpend de B, A appartient P1 et B appartient P2. Il est en outre ncessaire dtablir une relation dimport entre P2 et P3, car B dpend de C, B appartient P2 et C appartient P3.

85

21/11/2012

Rtro conception et patrons de conception


Casser les cycles de dpendances On a vu quil tait envisageable dtablir des cycles de dpendances tant que ceux-ci ne traversaient pas plusieurs packages. Il est possible de concevoir une application devant obligatoirement dfinir deux packages et dont les classes de ces deux packages ont des dpendances mutuelles.

86

21/11/2012

Rtro conception et patrons de conception


Ce problme de conception ncessite de casser le cycle des dpendances. Une dpendance mutuelle indique un besoin mutuel entre plusieurs classes. Ce besoin est rel et ne peut tre supprim. Casser un cycle de dpendances ne signifie donc pas changer les besoins entre les classes.

87

21/11/2012

Rtro conception et patrons de conception


Principe de base : Travailler sur une dpendance particulire et de changer cette dpendance en une indirection laide dune nouvelle classe et dune relation dhritage.

88

21/11/2012

Rtro conception et patrons de conception


La partie du haut prsente la dpendance initiale sur laquelle va seffectuer lindirection. La partie du bas prsente lindirection. Le besoin source de la dpendance na pas t supprim. Il a t isol et dplac dans la classe BSup.

89

21/11/2012

Rtro conception et patrons de conception


Grce ce principe, il nexiste plus de dpendance directe entre les classes A et B. Il est possible davoir deux packages P1 et P2 avec les classes A et B dans chacun des deux packages sans avoir dimport mutuel entre les packages P1 et P2.

90

21/11/2012

Pour pouvoir appliquer ce principe sur nimporte quel modle, il faut : 1. Identifier la dpendance sur laquelle peut se faire lindirection (cette dpendance ne peut avoir un hritage comme cause). 2. Isoler le besoin de la dpendance dans une superclasse afin de dplacer la dpendance. Par exemple, si A dpend de B car A utilise une opration de la classe B, il faut positionner cette opration dans la superclasse afin de pouvoir dplacer le lien de dpendance.
91 21/11/2012

3. tablir la relation dhritage. 4. Positionner les classes dans les packages et mettre les bonnes relations dimport. La difficult principale : est de pouvoir isoler dans une superclasse le besoin dune dpendance afin de permettre la cration dune indirection.

92

21/11/2012

Rtro conception et patrons de conception


Patron de conception Un patron de conception est une solution prouve qui permet de rsoudre un problme de conception trs bien identifi. Un patron de conception est un couple <problme/solution>. La solution dfinie par un patron de conception nest intressante que si nous faisons face au mme problme que celui trait par le patron. la solution dfinie par un patron est spcifie laide dun diagramme de classes.
93 21/11/2012

Rtro conception et patrons de conception


Appliquer la solution dfinie par un patron de conception sur une application consiste identifier parmi les classes de lapplication lesquelles doivent jouer les rles dfinis par la solution. Le patron de conception Observer Problme Crer un lien entre un objet source et plusieurs objets cibles permettant de notifier les objets cibles lorsque ltat de lobjet source change. Il faut pouvoir lier (ou dlier de) lobjet source autant dobjets cibles que nous le voulons.
94 21/11/2012

Rtro conception et patrons de conception


Solution

Ce diagramme fait apparatre les quatre rles suivants :


95 21/11/2012

Rtro conception et patrons de conception


Le rle Observer est un rle abstrait (la classe est abstraite) qui reprsente une abstraction de lobjet cible . Sa mthode update permet de lui envoyer un message de notification de changement dtat de lobjet source . Le rle Subject est un rle abstrait qui reprsente une abstraction de lobjet source . Lassociation entre les classes Subject et Observer exprime le fait quun objet source peut tre li plusieurs objets cibles .
96 21/11/2012

Rtro conception et patrons de conception


Grce aux oprations attach et detach, il est possible dynamiquement de lier et de dlier les objets cibles . Le rle ConcreteSubject est un rle concret qui hrite de Subject. Il reprsente lobjet source avec son tat. Le rle ConcreteObserver est un rle concret qui hrite de Observer. Lassociation entre les classes ConcreteObserver et ConcreteSubject exprime le fait quun objet cible est li lobjet source .

97

21/11/2012

Rtro conception et patrons de conception


Appliquer ce patron de conception sur une application ncessite didentifier dans le modle de lapplication les classes pouvant jouer les rles de Subject, Observer, ConcreteSubject et ConcreteObserver. Si aucune classe existante ne peut jouer un des rlesdu patron de conception, il est envisageable de construire une nouvelle classe dans le modle.

98

21/11/2012

Rtro conception et patrons de conception


Lapplication des patrons de conception est une opration de productivit qui est trs souvent employe sur les modles. Cela permet de fournir des solutions prouves aux problmes de conception qui ont dj t rencontrs par dautres personnes. Rutiliser les bonnes solutions permettant de rsoudre des problmes dj rencontrs.

99

21/11/2012

Diagramme de squence
Vue comportementale du modle UML Laspect comportemental dune application oriente objet est dfini par la faon dont interagissent les objets qui composent lapplication. Les objets qui composent une application pendant son excution et leurs changes de messages permettent lapplication de raliser les traitements. Cette vue (diagramme de squence) dfinit deux concepts principaux : celui dobjet et celui de message chang entre deux objets. Une interaction permet didentifier plusieurs objets et de reprsenter les messages quils schangent.
100 21/11/2012

Diagramme de squence
Concepts lmentaires Objet Smantique Dans une application, chaque objet peut envoyer et recevoir des messages des autres objets qui composent lapplication. En UML, les objets qui participent une interaction schangent des messages entre eux.

101

21/11/2012

Diagramme de squence
Graphique un carr contenant lidentifiant de lobjet (si lobjet nest pas anonyme), suivi du nom de la classe dont lobjet est instance (si lobjet est typ). Attach ce carr, une ligne verticale reprsente la vie de lobjet dans le temps (laxe du temps tant dirig vers le bas du diagramme).

102

un objet anonyme non typ, un objet anonyme typ, un objet identifi non typ et un objet identifi typ.

21/11/2012

Diagramme de squence
Message Smantique les objets communiquent par changes de messages. Le message le plus important est de demande de ralisation dopration, par lequel un objet demande un autre objet (ou lui-mme) de raliser une des oprations. En thorie, avec ce message seul, il est possible de dcrire compltement le comportement dune application.
103 21/11/2012

Diagramme de squence
Graphique Le premier message est un message de cration chang entre lobjet identifi id1 et lobjet identifi id2. Ce message signifie que lobjet id1 cre lobjet id2.

104

21/11/2012

Diagramme de squence
Le deuxime message est un message dappel synchrone dopration. Lobjet id1 demande lobjet id2 de raliser lopration nomme opration1. Lobjet id1 attend que lobjet id2 finisse de raliser cette opration avant de continuer son activit. Le message de fin de traitement est reprsent par une flche pointille. Le dernier message est un message de suppression. Lobjet id1 supprime lobjet id2.
105 21/11/2012

Diagramme de squence
Le temps dans les diagrammes de squence Une interaction spcifie une succession dchanges de messages entre les objets participant linteraction. Le temps est donc trs important puisquil prcise lordre dexcution entre tous les messages dune mme interaction.

106

21/11/2012

Diagramme de squence
le temps est gouvern par deux rgles principales. Ces rgles considrent les messages dappel synchrone dopration et de cration comme deux messages, un appel et un retour. Il y a donc une flche de lobjet metteur vers lobjet rcepteur (appel) et une autre de lobjet rcepteur vers lobjet metteur (retour).

107

21/11/2012

Diagramme de squence
Chaque message est ensuite dcompos en deux vnements, un vnement denvoi et un vnement correspondant la rception. Lenvoi est matrialis par lextrmit de dpart de la flche correspondant au message et la rception par lextrmit darrive de la flche. le temps est rgul par les rgles suivantes :

108

21/11/2012

Diagramme de squence
Sur laxe dun objet, tous les vnements sont ordonns du haut vers le bas. Cela entrane quun vnement arrive avant un autre vnement sil est positionn plus haut sur laxe dun mme objet. Pour un mme message, lenvoi se droule toujours avant la rception.

109

21/11/2012

Diagramme de squence

110

21/11/2012

Diagramme de squence
Liens avec la vue structurelle du modle Objet et classe Tout objet participant une interaction doit obligatoirement avoir son type dcrit sous forme de classe dans la partie structurelle. Nous dconseillons fortement lutilisation dobjets non typs.

111

21/11/2012

Diagramme de squence
Tout message dappel dopration (synchrone ou asynchrone) doit cibler une opration spcifie dans la vue structurelle. Cette opration doit appartenir la classe dont lobjet qui reoit le message est instance. Tout message dappel dopration (synchrone ou asynchrone) doit porter les valeurs des paramtres de lopration cible par le message.

112

21/11/2012

Diagramme de squence
Objets typs dans une interaction

Les rgles de cohrence entre parties de modles nous imposent davoir dans la partie structurelle la dfinition des classes A et B ainsi que la dfinition de lopration opration1
113 21/11/2012

Diagramme de squence
reprsente le diagramme de classes correspondant cette partie structurelle (les paramtres de lopration de la classe B sont masqus).

114

21/11/2012

Diagramme de squence
Diagramme et modle Un diagramme est une reprsentation graphique dun modle et qu un modle peuvent correspondre plusieurs diagrammes. Un diagramme de squence est la reprsentation graphique de la partie comportementale (interaction) dun modle UML. Toute les informations (objets, messages, etc.) sont contenues dans le modle et reprsentes graphiquement laide des diagrammes. Il est donc possible de reprsenter une mme information dans diffrents diagrammes.
115 21/11/2012

Diagramme de squence
Deux diagrammes partageant de mmes objets

116

21/11/2012

Diagramme de squence
deux interactions qui peuvent sexcuter dans une application de gestion de prts bancaires. Ces interactions font intervenir les mmes objets (le client c1 et la banque bk). La premire interaction reprsente un cas nominal : le prt est accord. La deuxime montre un cas soulevant une erreur : le prt est refus. Le fait quun objet appartienne plusieurs interactions na pas de consquence sur lordre entre les vnements des interactions.
117 21/11/2012

Diagramme de squence
Interactions et gnration de code Les interactions permettaient uniquement de spcifier des exemples dexcution dapplication Elles ne peuvent tre utilises pour spcifier intgralement des algorithmes et ainsi servir la gnration de code. Une interaction ne dfinit quune seule excution possible, alors quun algorithme dfinit lensemble des excutions possibles.

118

21/11/2012

Diagramme de squence
Exemple : lalgorithme correspondant la porte logique ET ralisant lopration boolenne ET Lensemble des excutions possibles est fini, que le rsultat ne dpend que de lentre et que ltat de lobjet ne change pas aprs excution de lalgorithme. Les quatre excutions possibles de lalgorithme sont illustres ici :

119

21/11/2012

Diagramme de squence
Diagrammes de squence spcifiant lalgorithme de la porte logique ET

120

21/11/2012

Diagramme de squence
Pour pouvoir tre totalement sr que ces interactions spcifient lintgralit des excutions de la porte ET, il faut savoir, que la porte ET a un comportement dterministe (le rsultat ne dpend que de lentre), Lexcution de la porte ET ne modifie par ltat de lobjet. si la porte ET avait un comportement indterministe ou si le comportement modifiait ltat de lobjet, il ne serait pas possible de gnrer le code.

121

21/11/2012

Diagramme de squence
il serait possible de gnrer le code suivant partir des diagrammes que nous venons de prsenter :

122

21/11/2012

Diagramme de squence
Limites des interactions Les interactions permettent uniquement de prsenter des changes de messages entre objets. Il nest donc pas possible de spcifier : Les accs aux proprits des objets. Les navigations sur les associations navigables. Les crations de liens entre objets. Les appels aux oprations de classes, car aucun objet nest directement responsable de la ralisation de lopration.
123 21/11/2012

Diagramme de cas dutilisation


Vue fonctionnelle du modle UML La partie fonctionnelle du modle UML dune application permet de spcifier les fonctionnalits offertes par lapplication sans spcifier la faon dont ces fonctionnalits sont ralises par les objets de lapplication. Le principe fondateur du paradigme objet est de runir en une seule et mme entit, lobjet, des donnes et des traitements.

124

21/11/2012

Rf rences Les R frences


UML pour le dveloppeur Xavier Blanc et Isabelle Mounier dition EYROLLES

125

21/11/2012