Académique Documents
Professionnel Documents
Culture Documents
bousmah@gmail.com
Objectifs
Connatre les concepts du langage UML Mettre en uvre les diagrammes UML Illustrer les concepts et la modlisation avec lutilisation de Rational Rose, Power AMC , Star UML,
bousmah@gmail.com
1. Origine dUML
bousmah@gmail.com
bousmah@gmail.com
HISTORIQUE
2003
UML 2.0
1999 : Standardisation par lOMG (Object Management Group) 1997 : Soumission lOMG
OOPSLA96
OOPSLA95
Autres mthodes
Booch91
OMT-1
OOSE Jacobson92
(use cases)
Lunification
Les crateurs dUML insistent tout particulirement sur le fait que la notation UML est un langage de modlisation objet et non pas une mthode objet. UML nest pas une notation propritaire; elle est accessible tous et les fabricants doutils ainsi que les entreprises de formation peuvent librement en faire usage. En franais, UML pourrait se traduire par langage unifi pour la modlisation objet, mais il est plus probable quUML se traduise plutt par notation unifie, voire notation UML
bousmah@gmail.com
Mta-modle
Pour faciliter le travail de dfinition et pour formaliser UML, tous les diffrents concepts ont t eux-mmes modliss avec UML. Cette dfinition rcursive, appele mtamodlisation, prsente le double avantage de permettre de classer les concepts par niveau dabstraction, de complexit et de domaine dapplication, et aussi de faire la preuve de la puissance dexpression de la notation, capable entre autres de se reprsenter elle-mme.
bousmah@gmail.com
Modle et modlisation
[Guinier] La modlisation nest quune reprsentation dun systme rel quelle quen soit sa forme: physique, graphique, mathmatique, verbale ou mentale. Cette reprsentation intelligible est indispensable pour assurer la comprhension de systmes naturels complexes.
bousmah@gmail.com
bousmah@gmail.com
Modles dUML Le modle des classes qui capture la structure statique Le modle des tats qui exprime le comportement dynamique des objets Le modle des cas dutilisation qui dcrit les besoins des utilisateurs Le modle dinteraction qui reprsente les scnarios et les flots de messages Le modle de ralisation qui montre les units de travail Le modle de dploiement qui prcise la rpartition des processus
bousmah@gmail.com
10
Les modles sont regards et manipuls par les utilisateurs au moyen de vues graphiques, vritables projections au travers des lments de modlisation contenus par un ou plusieurs modles. De nombreuses vues peuvent tre construites partir des modles de base; elles peuvent montrer tout ou partie des modles. A chaque vue correspondent un ou plusieurs diagrammes.
bousmah@gmail.com
11
Technologogie objets
UML UML
Modlisation
Java Java
Prsentation
SGBD SGBD
Distribution
CORBA CORBA
bousmah@gmail.com
12
bousmah@gmail.com
13
Dans une organisation unifie, la distinction des composants va de pair avec leur intgration. La force de lapproche objet provient alors de sa double capacit dcomposer diffrencier et recomposer runir du fait de la richesse de ses mcanismes dintgration, qui concernent la fois les aspects statiques et dynamiques des logiciels. Lapproche objet tire sa force de sa capacit regrouper ce qui a t spar, construire le complexe partir de llmentaire, et surtout intgrer statiquement et dynamiquement les constituants dun systme.
bousmah@gmail.com
14
Les objets
Lobjet est une unit atomique forme de lunion dun tat et dun comportement. Il fournit une relation dencapsulation qui assure la fois une cohsion interne trs forte et un faible couplage avec lextrieur. Lobjet rvle son vrai rle et sa vraie responsabilit lorsque, par lintermdiaire de lenvoi de messages, il sinsre dans un scnario de communication. Un objet peut tre concret ou abstrait.
bousmah@gmail.com
15
Les objets informatiques dfinissent une reprsentation abstraite des entits dun monde rel ou virtuel, dans le but de les piloter ou de les simuler. Cette reprsentation abstraite peut tre vue comme une sorte de miroir informatique, qui renvoie une image simplifie dun objet qui existe dans le monde peru par lutilisateur. Les objets informatiques, que nous appellerons dsormais objets, encapsulent une partie de la connaissance du monde dans lequel ils voluent.
bousmah@gmail.com
16
Un objet doit apporter une valeur ajoute par rapport la simple juxtaposition dinformations ou (et) de code excutable. Un objet sans tat ou sans comportement peut exister marginalement, mais dans tous les cas, un objet possde une identit.
bousmah@gmail.com
17
Ltat
Ltat regroupe les valeurs instantanes de tous les attributs dun objet sachant quun attribut est une information qui qualifie lobjet qui le contient. Chaque attribut peut prendre une valeur dans un domaine de dfinition donn. Ltat dun objet, un instant donn, correspond une slection de valeurs, parmi toutes les valeurs possibles des diffrents attributs. Ltat dun objet un moment donn est la consquence des comportements passs.
bousmah@gmail.com
18
Le comportement
Le comportement regroupe toutes les comptences dun objet et dcrit les actions et les ractions de cet objet. Chaque atome de comportement est appel opration. Les oprations dun objet sont dclenches suite une stimulation externe, reprsente sous la forme dun message envoy par un autre objet.
bousmah@gmail.com
19
Lidentit
En plus de son tat, un objet possde une identit qui caractrise son existence propre. Lidentit permet de distinguer tout objet de faon non ambigu, et cela indpendamment de son tat. Cela permet, entre autres, de distinguer deux objets dont toutes les valeurs dattributs sont identiques. Lidentit est un concept, elle ne se reprsente pas de manire spcifique en modlisation. Chaque objet possde une identit de manire implicite.
bousmah@gmail.com
20
Contraintes de ralisation
Les notions dtat, de comportement et didentit sappliquent aux objets de manire gnrale, quel que soit lenvironnement de ralisation. Toutefois, les objets peuvent galement possder des caractristiques plus informatiques, lies aux contingences de ralisation comme la distribution des programmes, les bases de donnes ou les programmes multilangages.
bousmah@gmail.com
21
Les objets non persistants sont dits transitoires ou phmres. Par dfaut, les objets ne sont pas considrs comme persistants. Dans leur ensemble, les langages de programmation objet ne proposent pas de support direct pour assurer la persistance des objets. Cela est regrettable et oblige recourir des artifices extrieurs pour assurer la persistance des objets. Les constructeurs de bases de donnes fournissent des solutions pour la sauvegarde des objets, soit totalement objet, soit hybride.
bousmah@gmail.com
22
La persistance
[SOU-99 p31] La gestion de la persistance est une notion intrinsque des SGBD, elle permet le stockage des donnes et leur restitution la demande. Dans un contexte de bases de donnes, les objets mtier sont utiliss au niveau conceptuel et les objets dimplmentation au niveau physique. [SOU-99 p39] Bien que SGBD et langages de programmation aient des points communs, ils diffrent par un aspect fondamental. En effet, un programme est sens rsoudre un problme donn, alors quune base de donnes a pour objectif de rpondre un ensemble de problmes qui sont en partie inconnus au moment de la cration de la base.
bousmah@gmail.com
23
Ltude des formes de communication entre objets du domaine est de premire importance dans la modlisation objet et, dailleurs, la grande diffrence entre lapproche fonctionnelle et lapproche objet rside prcisment dans cette articulation qui rduit le couplage entre la structure et la fonction.
bousmah@gmail.com
24
Le concept de message
Lunit de communication entre objets sappelle le message. Le message est le support dune relation de communication qui relie, de faon dynamique, les objets qui ont t spars par le processus de dcomposition.
bousmah@gmail.com
25
Les formes de synchronisation des messages dcrivent la nature des mcanismes de communication qui permettent le passage de messages dun objet vers un autre objet. La notion de synchronisation prend tout son intrt lorsque plusieurs objets sont actifs simultanment et quil faut, par exemple, protger laccs des objets partags.
bousmah@gmail.com
26
Les objets interagissent pour raliser collectivement les services offerts par les applications. Les diagrammes dinteraction reprsentent les objets les uns par rapport aux autres et montrent comment ils communiquent au sein dune interaction. Chaque interaction possde un nom et un contexte de validit quil convient de prciser de manire textuelle. Il existe deux sortes de diagrammes dinteraction: les diagrammes de collaboration et les diagrammes de squence. [PAM-97 p32] Les diagrammes dinteraction montrent quelques objets dans une situation donne. Seule une petite interaction est reprsentable.
bousmah@gmail.com
27
UML
bousmah@gmail.com
28
Dcrit, sous forme dactions et de ractions, le comportement dun systme du point de vue dun utilisateur. Permet de dfinir les limites du systme et ses relations avec lenvironnement.
bousmah@gmail.com
29
Sert modliser les aspects dynamiques d'un systme (Contrairement aux diagrammes de classes). Fait ressortir les acteurs et les fonctions offertes par le systme. Utilis pour modliser les exigences (besoins) du client
bousmah@gmail.com
30
bousmah@gmail.com
31
Acteurs
UML nemploi pas le terme dutilisateur mais dacteur. Un acteur est un rle jou par une entit externe qui agit sur le systme (Comptabilit, service commercial, ), en changeant de linformation (en entre et en sortie) Le terme acteur ne dsigne pas seulement des utilisateurs humains mais galement les autres systmes (machines, programmes, ).
bousmah@gmail.com
32
Acteurs
Peut tre reprsent de deux manires diffrentes : Petit personnage (stick man)
Classe strotype
Nom Acteur
bousmah@gmail.com
33
Acteurs
Mais du point de vue systme on distingue deux types : Acteurs principaux : utilisent les fonctions principales du systme. Par exemple, le client pour un distributeur de billets. Acteurs secondaires : effectuent des tches administratives ou de maintenance. Par exemple, la personne qui recharge la caisse contenue dans le distributeur.
bousmah@gmail.com
34
Acteurs
Un acteur peut tre une spcialisation d'un autre acteur dj dfini. Dans ce cas, on utilise la relation de gnralisation/spcialisation.
Acteur gnral
Acteur spcialis
bousmah@gmail.com
35
Cas d'utilisation Les cas dutilisations Permettent de modliser les attentes (besoins) des utilisateurs Reprsentent les fonctionnalits du systme Suite dvnements, initie par des acteurs, qui correspond une utilisation particulire du systme Limage dune fonctionnalit du systme, dclenche en rponse la stimulation dun acteur externe.
Nom Cas Utilisation
bousmah@gmail.com
36
UML dfinit trois types de relations standardises entre cas d'utilisation : Une relation d'inclusion, formalise par la dpendance include Une relation d'extension, formalise par la dpendance extend Une relation de gnralisation/spcialisation
bousmah@gmail.com
37
Relation d'inclusion
Lors de la description des cas d'utilisation, il apparat qu'il existe des sous-ensembles communs plusieurs cas d'utilisation, il convient donc de factoriser ces fonctionnalits en crant de nouveaux cas d'utilisation qui sont utiliss par les cas d'utilisation qui les avaient en commun.
B
<<include>>
bousmah@gmail.com
38
Relation d'inclusion
Les cas d'utilisation "Dposer de l'argent", "Retirer de l'argent", "Effectuer des virements" et "Consulter solde" incorporent de faon explicite le cas d'utilisation "S'authentifier", un endroit spcifi dans leurs enchanements.
Retirer de l'argent
Consulter solde
bousmah@gmail.com
39
Relation d'extension
La relation strotype extend permet d'tendre les interactions et donc les fonctions dcrites dans les cas d'utilisation, mais sous certaines contraintes.
bousmah@gmail.com
40
Relation d'extension
bousmah@gmail.com
41
La relation extend" montre une possibilit d'excution d'interactions qui augmenteront les fonctionnalits du cas tendu, mais de faon optionnelle, non obligatoire, La relation "include" suppose une obligation d'excution des interactions dans le cas de base.
bousmah@gmail.com
42
Relation d'hritage
Il peut galement exister une relation d'hritage entre cas d'utilisation. Cette relation exprime une relation de spcialisation/gnralisation au sens classique.
Reserver voyage
bousmah@gmail.com
43
Dposer de l 'argent
Reteni r l a carte
Cl i ent
<<extend>>
S'authenti fi er
T echni ci en Rparer
bousmah@gmail.com
44
ex it
Co m pl
Co m pl ica
bousmah@gmail.com
tio n
45
UML
Diagrammes de classe
bousmah@gmail.com
46
Classe et objet
Une classe est une description dun ensemble dobjets ayant des attributs, des mthodes et des relations en communs. Un modle partir duquel seront construit les objets cres par le systme. Un objet est une instance dune classe. Une classe est reprsente, en UML, par la notation suivante avec: son nom, la liste de ses attributs et de ses oprations (mthodes).
Voiture
Exemple marque modele immatriculation Dmarrer() Acclrer() Freiner()
bousmah@gmail.com
47
bousmah@gmail.com
48
Problmes de dtermination des classes et objets La dtermination des classes lors de la phase danalyse nest pas vidente. Elle suit une mthode plutt intuitive, base sur lexprience de lanalyste qui a (ou na pas) lhabitude de reconnatre plus ou moins facilement: les classes, les objets , les associations, les attributs et les mthodes des classes. Lanalyste pourra se demander alors: quels sont les objets de gestion dans le problme tudi pour identifier les objets rels ainsi que leurs liens et les modliser sous formes de classes et dassociations. Utilisation des description textuelle des cas dutilisation afin de reprer les objets mtiers
bousmah@gmail.com
49
Diagramme de classes
Le diagramme de classe donne une vue densemble statique du systme en prsentant toutes les classes dfinies dans le systme, leurs cooprations et interactions. Ces classes peuvent tre relies de multiples manires : la dfinition des relations est aussi importante que le dfinition de chaque classe. Il y a plusieurs types de relation entre les classes : Lassociation Lagrgation La composition La gnration La spcialisation La dpendance
bousmah@gmail.com
50
Association Une association est une relation entre deux classes (association binaire) ou plus (association n-aire), qui dcrit les connexions structurelle entre leurs instances.
bousmah@gmail.com
51
Lassociation
Les associations peuvent tre nomme par une forme verbale. Le sens de lecture est prcis par un symbole < ou >. L'extrmit d'une association est appel rle. Le rle dcrit comment une classe voit une autre classe au travers d'une association. Enfin chaque rle d'une association porte une indication de cardinalit (multiplicit) qui montre combien d'objets d'une classe peuvent tre lis un autre objet.
Entreprise
Emploie >
Personne
1,1
Employeur
1,*
Employ
bousmah@gmail.com
52
Valeurs de cardinalit
bousmah@gmail.com
53
Catalogue
1..*
{ordered}
Livre
bousmah@gmail.com
54
Entreprise
{ XOR }
Personne
public
Etat
Employeur
bousmah@gmail.com
55
Entreprise
employ
Personne
{ Subset }
dlgu
bousmah@gmail.com
56
Classe-association
Si une association possde des proprits ou des oprations, il est possible de la qualifier laide dune classe-association. Une classe-association possde les mmes caractristiques que les associations et les classes.
Une classe-association qui ne participe pas dautres relations avec dautres classes peut ne pas porter de nom .
bousmah@gmail.com
57
Classe association
une classe association peut tre remplace par une classe intermdiaire et qui sert de pivot pour une paire dassociations. Transformation dune classe-association en une classe et en associations.
bousmah@gmail.com
58
bousmah@gmail.com
59
Agrgation
L'agrgation exprime une forme de couplage fort entre classes. Elle matrialise une relation de type: " Compos-Composant " ou "partie de" ou de type "matre-esclave". Exemples : Un document est un ensemble de paragraphe. Personne/immeuble
bousmah@gmail.com
60
Agrgation
Proprits de lagrgation Le tout est responsable de la gestion de ses parties. Laction sur le tout entrane une action sur le composant Un composant peut tre partag par plusieurs agrgats : la multiplicit cot agrgat peut avoir une valeur suprieur 1. une phrase peut tre dans plusieurs paragraphes. La relation est transitive : un paragraphe est compos de phrases, les phrases sont composes de mots et donc un paragraphe est compos de mots La relation ne peut tre symtrique : un composant ne peut contenir le tout ou le compos. Les valeurs sont propages de lagrgat au composant : la mise en italiques du paragraphe entrane la mise en italique des phrase.
bousmah@gmail.com
61
La composition
La composition est une agrgation pour laquelle les composants (partie) possdent une dure de vie incluse dans celle de lagrgat(ne peut exister sans lui.). Le composant ne peut exister sans lagrgat et ne peut appartenir qu un seul agrgat. La valeur de la multiplicit du cot de lagrgat ne peut prendre que les valeurs 0 ou 1 car le composant ne peut tre partag par plusieurs agrgat. La valeur 0 du cot du composant indique un attribut non renseign. La suppression dun objet agrgat ferait disparatre les objets agrgs. La distinction entre une relation de composition et d'agrgation est faite par l'opration de destruction. Si elle est transmise aux composants, la relation est une composition (prsente avec losange noir ).
bousmah@gmail.com
62
Exemple de la composition
Universit
Facults
Dpartements
1,*
gre
Etudiants
bousmah@gmail.com
63
Exemple
bousmah@gmail.com
64
La gnralisation
Elle exprime un lien dhritage reliant une classe enfant une classe parent La classe enfant possde les mmes attributs, opration, associations que sa classe parent. La classe enfant ajoute des descriptions spcifiques La spcialisation est la relation inverse. Une classe peut hriter de plusieurs classe
Vehicule
motorisation
A moteur
bousmah@gmail.com
A voile
65
La gnralisation
Contraints sur les gnralisations (disjoint) : une sous classe de la hirarchie ne possde quune seule classe parent (contraints par dfaut). (overlapping) : une classe peut possder plusieurs classe parent. (complete) : la gnralisation est complte. On ne peut ajouter dautres sous classes la hirarchie. (incomplete) : la gnralisation est incomplte. On peut ajouter dautres sous classes la hirarchie.
bousmah@gmail.com
66
Exemple
bousmah@gmail.com
67
Exemple
bousmah@gmail.com
68
La dpendance
La dpendance exprime la situation o une classe utilise une autre classe, par exemple, en appelant une mthode de la 2 eme classe Elle reprsente une relation sur les classes uniquement, sans induire de liens sur les objets instance de ces classes Cest une relation unidirectionnelle de la classe source vers la classe cible Exemple : Un composant graphique a besoin dune couleur pour pouvoir safficher. Lusage de telles relations est dconseill dans un diagramme car source dimprcision et de couplage entre les classe (trop de classe)
bousmah@gmail.com
69
Modificateurs
bousmah@gmail.com
70
Modificateurs
bousmah@gmail.com
71
Association Rflexive
bousmah@gmail.com
72
Interface
bousmah@gmail.com
73
UML
Diagrammes dobjets
bousmah@gmail.com
74
bousmah@gmail.com
75
:classe
Nom de lobjet
bousmah@gmail.com
76
Cas n1:
:Voiture
1 1
:Moteur
Voiture
1 4
Roue
:Voiture
:Moteur
:Roue
bousmah@gmail.com
77
Cas n2:
Exemple dun systme de scurit limitant les accs des parties dun difice laide de cartes magntiques. Le systme gre un seul btiment contenant trois portes. Le systme peut tre gr par une personne nomme SIMO. Deux utilisateurs peuvent accder au btiment : SALIM a accs la premire (8h-18h) et seconde porte (12h-24h) SALIMA a accs la troisime porte toute la journe.
T.A.F
bousmah@gmail.com
78
1 *
Personne nom
MotDePasse valeur
1 *
* * 1 *
Porte nom
Systme
Diagramme de classes 79
bousmah@gmail.com
:MotsDePasse
valeur:= "
:Badge :Badge
123 "
:Acces :Superviseur
nom:= SIMO debut:= 8h fin = 18h
:Acces
debut:= 12h fin = 24h
:Acces
debut:= 0h fin = 24h
:Systeme
Bat:Batiment
bousmah@gmail.com
P3:Porte
80
UML
Diagrammes de paquetage
bousmah@gmail.com
81
Diagramme de packages Objectif: Utiliss pour sparer le modle en conteneurs logiques, et dcrire leurs interactions un haut niveau. Paquetage = Collection dlments de modlisation UML (classes, use cases, etc.) groups ensemble car lis logiquement
bousmah@gmail.com
82
Diagramme de packages
bousmah@gmail.com
83
UML
Modles dynamiques
bousmah@gmail.com
84
Modle dynamique
Le modle dynamique contient les diagrammes reprsentant lvolution du systme selon des aspects particuliers. Chacun de ces diagrammes reprsente le comportement dun ou plusieurs objets et leurs interactions avec les autres objets. Par exemple, on y trouve un diagramme montrant les squences denvois de message entre les objets du systme. Le comportement dynamique du systme est reprsent par : Linteraction entre les objets, acteurs, cran durant lexcution via les diagrammes de collaboration et de squences (diagrammes dinteractions). La description de lactivit gnrale du systme. Les changements de ltat du systme durant lexcution.
bousmah@gmail.com
85
UML
Diagramme dactivit
bousmah@gmail.com
86
Diagramme dactivit
Les diagrammes dactivits permettent de reprsenter graphiquement le comportement dune mthode ou le droulement dun cas dutilisation.
bousmah@gmail.com
87
Exemple
bousmah@gmail.com
88
bousmah@gmail.com
89
UML
Diagramme de Squence
bousmah@gmail.com
90
Diagramme de squences
Reprsenter les interactions entre objets en prcisant la chronologie des changes de messages Reprsente une instance dun cas dutilisation (les scnarios possible dun cas dutilisation donn) Montre sous forme de scnarios, la chronologie des envoies de messages issus dun cas dutilisation Le diagramme de squence fait ressortir : Les acteurs Les objets Les messages
bousmah@gmail.com
91
Diagramme de squences
O b j e t_ 1
O b je t_ 2
O b j e t_ 3
M e ssa g e _ 1
M e ssa g e _ 2
L ig n e d e vie d e l 'o b j e t
bousmah@gmail.com
92
Diagramme de squences
Un objet est reprsent par un rectangle et une ligne verticale (ligne de vie de lobjet) Les objets communiquent en changeant des messages reprsents par des flches orientes de lmetteur au rcepteur Lordonnancement verticale des messages indique la chronologie
bousmah@gmail.com
93
Diagramme de squences
Un message reu par un objet dclenche lexcution dun opration Un message envoy par objet correspond :
Demander un service dun autre objet Renvoyer le rsultat dun opration
bousmah@gmail.com
94
Client
Compte
Compte - N Compte : String - Solde : float + <<Constructor>> Compte (int n, float s) dposer (float somme) : void + + retirer (float somme) : float + consulter () : float
dposer(somme)
1. Le client demande un service (dposer de largent) lobjet Compte 2. Le compte reoit le message et dclenche lopration de mme nom 3. Le compte retourne le rsultat (le solde actuel)
bousmah@gmail.com
95
Diagramme de squences
Plusieurs concepts additionnels : Priode dactivit Types de messages Cration et destruction dobjets Structures de contrles
bousmah@gmail.com
96
Priode dactivit
Correspond au temps pendant lequel un objet fait une action Reprsente par une bande rectangulaire superpose la ligne de vie de lobjet
Objet_2
Objet_1
Message_1
bousmah@gmail.com
97
Messages
Traduisent les interactions (change dinformations) entre objets Reprsents par des flches orientes de lmetteur au rcepteur Plusieurs types :
Message simple Message minut (Timeout) Message synchrone Message asynchrone Message rcursif
bousmah@gmail.com
98
Message simple
Message pour lequel on ne spcifie aucune information denvoi ou de rception
Objet_1
Objet_2
Message_1
bousmah@gmail.com
99
O b j e t_ 2
O b j e t_ 1
M e ssa g e _ 1 (2 0 se c o n d e s)
bousmah@gmail.com
100
ouvrir (2 secondes)
fermer
bousmah@gmail.com
101
Message synchrone (appel de procdure) Bloque lexpditeur jusqu la prise en compte du message par le rcepteur Le contrle est pass de lmetteur au rcepteur qui devient son tour metteur (actif)
O b j e t_ 2
O b j e t_ 1
M e ssa g e _ 1
bousmah@gmail.com
102
Client
Serveur
bousmah@gmail.com
103
Message asynchrone
Ninterrompt pas lexcution de lexpditeur Lexpditeur peut mettre sans attendre la rponse du rcepteur
O b j e t_ 2
O b je t_ 1
M e ssa g e _ 1
bousmah@gmail.com
104
Message rcursif
Appel aussi message rflexive Message envoy dun objet vers lui-mme.
Objet_1
Message_1
bousmah@gmail.com
105
Client
GAB
Introduire carte
bousmah@gmail.com
106
Objet_1 Message_1
Objet_3
Objet_2
Cration dobjet
Message_2
Destruction dobjet
107
Structures de contrle
Le diagramme de squences peut inclure un certain nombre de structures Branchements (tests) Rptitions (itrations, boucles)
bousmah@gmail.com
108
Objet_1
Objet_2
Objet_3
[condition]: Message
bousmah@gmail.com
109
Pour accder au centre de recherche, lutilisateur doit prsenter son badge. Sil a droit daccs, un voyant vert est allum et la porte souvre
Utilisteur Systme
bousmah@gmail.com
110
La boucle se note comme le test, mais la condition est prcde dun astrisque
Objet_1 Objet_2 Objet_3
* [condition]: Message
bousmah@gmail.com
111
C lie n t
V e n d e u r
C a ta lo g u e
d e m a n d e
d e
p ri x c o n su l te le c a ta lo g u e
d o n n e
le
p ri x d e
b a se
s' t o n n e
se
p la in t
p ro p o se
u n
a u tre
p ri x
r c u p re
le
p ro d u i t
bousmah@gmail.com
112
Conclusion
la modlisation objet ne se fait pas par les donnes, comme cest le cas de Merise (construction du MCD) mais par lobservation et la mise en vidence du comportement des objets. Observer un objet, cest mettre en vidence : ses caractristiques statiques ( couleur = rouge , poids= 5,5kg, etc.) ses comportements cest dire sa capacit entretenir des relations avec le reste du monde, cest dire dautres objets et ventuellement luimme.
bousmah@gmail.com
113
UML
Diagrammes de collaboration
bousmah@gmail.com
114
Diagramme de collaboration
Le diagramme de collaboration dcrit le comportement ou interaction collectif dun ensemble dobjets ou acteurs ralisant un traitement en illustrant leurs interactions par des envois de messages. Permet dtablir des responsabilits: qui coopre avec qui pour l'obtention d'un but ou un service La reprsentation se concentrant sur les squences des interactions dun point de vue spatial (lien entre objets avec des messages). La dimension temporelle est ajoute grce des numros de squence. Permet aussi la reprsentation dun acteur, lment externe au systme (le premier message est envoy par lacteur). Le diagramme contient : Des objets dont ltat est prcis. Des envois de message refltant linteraction entre les objets.
bousmah@gmail.com
115
Diagramme de collaboration
Reprsentation graphique de lvolution dun ensemble dobjets pour effectuer une action. Permet la description: Du comportement collectif dun ensemble dobjets Des connexions entre ces objets Des messages changs par les objets
bousmah@gmail.com
116
Diagrammes de collaboration
Diffrences avec diagrammes de squence pas daxe temporel temps modlis par numrotation
bousmah@gmail.com
117
Diagrammes de collaboration
lments dune interaction Instances qui collaborent avec d'autres objets en changeant des informations liens :Classe Objet:Classe qui sont des supports de messages Reprsents comme des associations messages dclenchant les oprations Indiqus par des flches
bousmah@gmail.com
118
Diagrammes de collaboration
:Appelant
1. Dcrocher :Ligne 2. Tonalit 3. Numrotation 4.1a. Tonalit sonnerie 6.1a. Arrt tonalit
:Appel
bousmah@gmail.com
119
Diagrammes de collaboration
Aspect temporel modlis par numrotation des messages Type et Smantique des numrotations 1, 2, 3, 4 : Numrotation simple squencement des messages 1, 1.1, 1.2, 1.2.1, 1.2.2, 1.2.3 : Dot notation squencement + un point : ne peut tre termin que si ses sous points le sont aussi 1, 1.1a, 1.1b, 1.2, 1.3 : Dot notation + concurrence idem dot notation, mais les points 1.1a et 1.1b peuvent tre effectus en parallle
bousmah@gmail.com
120
Diagrammes de collaboration Mmes types contraintes que pour les diagrammes de squence Itration : *[condition] Conditions : [condition] Exemple : rservation darticles
bousmah@gmail.com
121
Diagrammes de collaboration
Les objets cres ou dtruits au cours dune interaction peuvent respectivement porter les contraintes : {Nouveau} {Dtruit}
<<{Dtruit}>> Objet_1
<<{Nouveau}>> Objet_2
bousmah@gmail.com
122
Diagrammes de collaboration
Conclusion Reprsentation spatiale Aspect temporel plus difficile suivre que pour les Diagramme de squence Dure dexcution dune contrainte difficile valuer Diagramme niveau instance Limite : taille des diagrammes Plus dinstances peuvent tre reprsentes sur un mme diagramme que pour les diagrammes de squence
bousmah@gmail.com
123
bousmah@gmail.com
124
bousmah@gmail.com
125
bousmah@gmail.com
126
UML
Diagramme tat-transition
bousmah@gmail.com
127
Diagramme tat-transition
Objectif : Dcrit l'enchanement de tous les tats d'un objet Propre une classe donne. Il dcrit : Les tats des objets de cette classe Les vnements auxquels ils ragissent Les transitions qu'ils effectuent
bousmah@gmail.com
128
Diagramme tat-transition
Le diagramme tat-transition manipule plusieurs concepts : tat Transition vnement Garde Action/Activit
bousmah@gmail.com
129
tat
L'tat d'un objet est dfini par l'ensemble des valeurs de ses attributs (fentre affiche, fentre cache, ) Un tat dpend de l'tat prcdent et de l'vnement survenu Un tat est reprsent par un rectangle aux angles arrondis
Affiche
bousmah@gmail.com
130
Transition
C'est le passage d'un tat un autre Peut tre nomm par un vnement Reprsent par une flche oriente de l'tat source vers l'tat cible
Restaure Rduire
Rduite
bousmah@gmail.com
131
vnement
Fait (externe) survenu qui dclenche une transition (changement d'tats) Peut tre rflexif et conduire au mme tat Conduit l'appel d'une mthode de la classe de l'objet Peut possder des attributs : paramtres ports par des vnements Reprsents entre parenthses
bousmah@gmail.com
132
Gardiens
Conditions ou fonctions boolennes associes une transition Une transition garde ne peut tre effectue que si le gardien est vrifi Un gardien est reprsent entre crochets
Etat2
bousmah@gmail.com
133
Formalisme et exemple
Employ recrut
bousmah@gmail.com
134
Actions et activits
Un objet qui reoit un vnement dclenche une ou plusieurs oprations On distingue deux types d'oprations : Action :
associe un tat dun objet ou une transition Opration instantane non interrompue
Activit :
associe un tat dun objet
Opration d'une certaine dure, qui peut tre interrompue
bousmah@gmail.com
135
Etat_1
Etat_2
bousmah@gmail.com
136
Orange
Vert
Rouge
bousmah@gmail.com
137
Exemple
bousmah@gmail.com
138
UML
Autres Diagrammes
bousmah@gmail.com
139
Diagramme de composants Objectif: Offre une vue de haut niveau de larchitecture du systme Utilis pour dcrire le systme dun point de vue implmentation Permet de dcrire les composants dun systme et les interactions entre ceux-ci Illustre comment grouper concrtement et physiquement les lments (objets, interfaces, etc.) du systme au sein de modules quon appelle composants
bousmah@gmail.com
140
bousmah@gmail.com
141
Quest-ce quun composant? Chaque composant ralise une, et seulement une fonction au sein du systme, mais peut nanmoins exposer plusieurs mthodes. Typiquement, chaque composant est dfini par une ou plusieurs interfaces qui constituent son seul moyen dinteragir avec les autres composants Lutilisation dune interface pour communiquer avec les autres composants du systme facilite la maintenance puisquon peut alors en changer limplmentation sans affecter les autres composants (induit un couplage plus faible du composant avec le reste du systme)
bousmah@gmail.com
142
bousmah@gmail.com
143
Exemples
bousmah@gmail.com
144
tude de cas
bousmah@gmail.com
145
tude de cas
bousmah@gmail.com
146
Diagramme de dploiement
Objectif: Le diagramme de dploiement dcrit la disposition concrte des lments du modle dans le monde physique. En fait, il sert reprsenter les lments matriels (ordinateurs, priphriques, rseaux, systmes de stockage ... etc.) et la manire dont les composants du systme sont rpartis sur ces lments.
bousmah@gmail.com
147
dispositifs physiques (les noeuds), objets dimplantation attachs aux noeuds (les composants), liens reprsentants les moyens de communication entre les noeuds (les supports de communication).
bousmah@gmail.com
148
tude de cas
bousmah@gmail.com
149
tude de cas
bousmah@gmail.com
150
bousmah@gmail.com
151
bousmah@gmail.com
152
Diagramme de temps
bousmah@gmail.com
153
variante du diagramme d'activit o les nuds sont des interactions. Il permet d'associer les notations du diagramme de squence celle du diagramme d'activit, ce qui permet de dcrire une mthode complexe
bousmah@gmail.com
154
bousmah@gmail.com
155
Fin document
bousmah@gmail.com
156