Académique Documents
Professionnel Documents
Culture Documents
UML
M.AFILAL
1
Objectif du cours
Objectif du cours:
la modlisation des logiciels, qui doivent rpondre un besoin dun client, en utilisant
UML
Cest pour cela, on commence par donner des dfinitions et certaines caractristiques
de ce que cest un logiciel.
Puis, de dfinir ce que cest la notion de gnie logiciel, ses problmatique et sa
relation avec la qualit de construction dun logiciel.
Puis, on parlera de cycle de vie dun logiciel avec ses diffrents types: traditionnel et
objet.
Et enfin, introduire la raison du choix de la modlisation en uml ainsi que ses
principaux diagrammes
qui permettent de capturer les caractristiques dun logiciel pour chaque phase de
son cycle de vie (son
cycle de dveloppement)
2
M.AFILAL
Logiciel ?
Dfinition :
Un logiciel (ou une application) est un ensemble de programmes, qui permet un
ordinateur ou un systme informatique d'assurer une tche ou une fonctionnalit
Physiquement, un logiciel est:
Une suite ditems ou dobjets
Une structure dinformations incluant programmes, donnes, documents,
Remarque:
Un logiciel nest pas seulement un ensemble de programmes, mais aussi de la
documentation pour :
linstallation,
lutilisation,
le dveloppement,
la maintenance.
M.AFILAL
Embarqus
Excutent dans du matriel lectronique isol
machine laver, tlvision, lecteur DVD, tlphone mobile,
magntoscope, four micro-ondes, rfrigrateur, joueur MP3, ...
Difficile modifier
M.AFILAL
La nature du logiciel
Le logiciel est facile reproduire (copier ou calquer)
Tout le cot se trouve dans son dveloppement
Pour dautres produits, la fabrication est souvent le processus le plus coteux
Le logiciel est intangible (impalpable, immatriel, invisible, abstrait )
Il est difficile d'estimer leffort de dveloppement
Le processus de dveloppement est difficile automatiser
Lindustrie du logiciel exige beaucoup de main doeuvre
Mme des informaticiens peu qualifis peuvent arriver bricoler quelque chose qui semble
fonctionner
La qualit dun logiciel nest pas apparente (validit, Robustesse, extensibilit,
rutilisabilit, portabilit, facilit dutilisation)
M.AFILAL
La nature du logiciel
Un logiciel semble facile modifier
La tentation est forte deffectuer des changements rapides sans vraiment en mesurer la
porte et les consquences
Un logiciel ne suse pas
Il se dtriore mesure que des changements sont effectus
en raison de lintroduction derreurs
ou par une complexification excessive
Remarque:
Beaucoup de logiciels sont mal conus et se dtriorent rapidement
La demande pour du logiciel est toujours croissante(donc croissance des difficults,
donc problmes dans les phases danalyse et de conception)
Un logiciel, comme le matriel, peut mourir (retrait de service) et devenir obsolte
(par exemple le passage lan 2000).
M.AFILAL
La nature du logiciel
Raisons pour lesquelles le logiciel vieillit :
Maintenance (bug fixes)
rosion architecturale (l'cart entre l'architecture prvue et son implmentation finale)
Des difficults techniques peuvent survenir pendant l'implmentation
Le dveloppeur se rend compte qu'un choix technologique , tablie au dbut pour
larchitecture prvue, ne parviendra pas atteindre les objectifs dsirs du projet.
Inflexibilit (rigide) ds le dbut
Documentation insuffisante ou inconsistante
Manque de modularit
Complexit croissante,
Un logiciel est fiable sil :
Rpond aux spcifications
La spcification tablit ce que le systme (ou logiciel) doit faire (le QUOI) et les contraintes
sous lesquelles il doit oprer
Ne produit jamais de rsultat erron
Ne jamais entrer dans un tat incohrent (Boucle infinie. Arrt brutale dun processus de calcul,
peut mener lutilisation de donnes non correctes, ce qui fait que les rsultats attendus par le
systme seront inexactes )
Ragir de faon sense et utile
en prsence dune situation inattendue 8
M.AFILAL
Le Gnie Logiciel ?
Art de produire du logiciel
Art de spcifier, concevoir, raliser, et de faire voluer, avec des moyens et dans des
dlais raisonnables, des programmes, des documentations, et des procdures de qualit
en vue dutiliser un ordinateur pour rsoudre certains problmes.
Art de bien faire de bons Logiciel
Art : technique, crativit, esthtique,
Bien faire : russite, rentabilit,
Bons : performance, fiabilit,
En gnie Logiciel, on parle de processus de dveloppement de logiciels et de gestion de
projets, dans les quels, on trouve:
Gestion du personnel :
Efforts ( travail fourni par les intervenants dans le projet)
Gestion des ressources :
Cots (cot associ au projet)
Aspects techniques :
Conception et Ralisation (des processus de dveloppement de logiciel)
Contraintes de ralisations :
9
M.AFILAL
Planification
Le Gnie Logiciel ?
Les points communs dans la construction des logiciels en Gnie Logiciel:
Travail de groupe et non dun individu isol
Besoins techniques et non-techniques
Connaissances informatiques.
Capacit de communication (non technique).
Gestion de projet.
Objectif du Gnie Logiciel
Dvelopper des logiciels considrs comme :
Logiciels fiables (srs).
Logiciels satisfaisant les besoins.
Logiciels maintenables (apte subir des modifications et des volutions
moindre cot ).
Logiciels exploitables dans diffrents environnement.
M.AFILAL
10
M.AFILAL
11
12
M.AFILAL
13
Quelques statistiques
tude du gouvernement amricain en 1979
Pays mais jamais livrs 45%
Livrs mais jamais utiliss 30%
Abandonns ou refaits 20%
Utiliss aprs modification 3%
Utiliss tel quel 2%
36%
erreurs de dfinition.
erreurs de codage
M.AFILAL
64%
14
Quelques statistiques
tude du gouvernement amricain sur 8380 projets de fabrication de logiciel en 1995
Succs: 16%
Problmatique: 53% (budget ou dlais non respects, dfaut de fonctionnalits)
chec: 31% (projets abandonns)
Remarque
Le taux de succs dcroit avec la taille des projets et la taille des entreprises
M.AFILAL
15
17
M.AFILAL
18
19
20
validation et vrification,
21
Dfinitions
Expression des besoins :
Tout ce quon dsire que le systme nous offre pour rpondre nos besoins du point de
vue de son utilisateur (humain ou autres systmes externes) .
Les donnes ou informations sont:
fournies par les experts/utilisateurs du domaine de lapplication, pour cela
Il faut tablir un dialogue entre les informaticiens et les experts/utilisateurs
du domaine
Rsultat:
Ensemble de document dcrivant lenvironnement du future systme,
ses principales fonctionnalits, ses frontires, son rle et sa future
utilisation (parfois un manuel dutilisation prliminaire, ou un dbut de
cahier des charges)
Permet davoir une ide de la faisabilit (lopportunit, le cot, la complexit
de lapplication) et de planification (dlais max de livraison) du systme
Remarque
Les besoins servent de rfrence pour lensemble des phases de fabrication
logicielle
22
M.AFILAL
Comprendre et structurer les besoins du client
Dfinitions
Spcification :
Ce que le systme doit tre, doit faire et comment il peut tre utilis (donne un manuel
dutilisation ):
Cest une description du future systme.
Les donnes:
Rsultat de lexpression des besoins + considrations
technique/faisabilit informatique
Rsultat:
Spcification technique des besoins (Exemple: l'environnement de
l'application, les cas d'utilisations de chaque fonctionnalits, la
normalisation des donnes, la modlisation du flux des donnes, les
maquettes d'crans ... etc...)
Point de dpart au dveloppement
Cest la version manuelle de rfrence + complment de manuel
dutilisation (voir partie dexpression des besoins)
Un cahier des charges finalis: sans ambigut et sans redondance
M.AFILAL
23
Dfinitions
Analyse ou < le quoi>:
Son objectif est de dterminer les lments intervenant dans le systme construire,
ainsi que leur structure et leurs relations.
Ce qui permet, lidentification des objets de gestion ou "objets Mtier".
Elle doit dcrire chaque objet selon trois axes :
Axe fonctionnel : le savoir-faire de lobjet.
Axe statique
: la structure de lobjet.
Axe dynamique : le cycle de vie de lobjet au cours de lapplication (tats et
messages de lobjet).
Ceci permet:
L'identification des objets
l'identification des structures
la dfinition des attributs
la dfinition des services
Remarque
En analyse, on ne tient pas compte de contraintes techniques et informatique.
M.AFILAL
24
Dfinitions
La conception : (ou < le comment>: prise en compte des contraintes techniques)
Permet didentifier la meilleur faon dimplmenter les exigences fonctionnelles du
systme tout en respectant les contraintes non fonctionnelles (budget, dlais, ..)
Elle consiste apporter des solutions techniques aux descriptions dfinies lors de
lanalyse :
Architecture technique (matriel et logiciel, ainsi que de l'organisation de ses
lments constitutifs), performances et optimisation, robustesse et stratgie de
programmation. (preuve de la qualit du logiciel)
On y dfinit les structures (les donnes, les classes), les algorithmes, les interfaces
(plus de dtailles que dans lanalyse).
Permet de revoir la notion de faisabilit du systme
Limplmentation :
Cest la ralisation de laM.AFILAL
programmation.
25
Dfinitions
Intgration :
Assembler tout ou une partie des composants logiciels afin dobtenir un systme
excutable.
Validation:
Permet de sassurer que le systme obtenu rpond lattente des utilisateurs et aux
contraintes de leur environnement.
Ceci via le rsultat de lanalyse des besoins effectue et linspection de la
spcification globale du systme
M.AFILAL
26
Dfinitions
Vrification
Permet de sassurer que le dveloppement est correcte via:
Des inspections des spcifications dfinies au dpart,
Des vrifications de programmes:
de preuve et de teste
Le Teste: consiste chercher des erreurs dans une spcification ou programme
par:
Examen ou analyse de texte (teste statique)
Par des excutions sur un sous-ensemble fini de donnes (teste dynamique):
Teste unitaire: tester des composants isols
Teste dintgration: tester un ensemble de composants venant dtre
assembls
Teste systme: tester le systme sur son future site dexploitation, dans
des conditions oprationnelles.
La preuve:
Porte sur une spcification dtaille ou programme et permet de prouver que
celui vrifie bien
la spcification de dpart
27
M.AFILAL
28
Expression des
besoins
validation
Spcifications
Correction
validation
Analyse
Correction
vrification
Conception
Correction
Teste unitaire
Implmentation
Teste Dacceptation
Teste de
vrification
Correction
Teste Systme
Validation
Correction
M.AFILAL
Maintenance
et
29
volution
30
M.AFILAL
31
M.AFILAL
32
M.AFILAL
33
Spcifications fonctionnelles
validation
Comprendre les
besoins, les dcrire
dans le systme
Validation fonctionnelle
vrification
Conception du systme
Tests du systme
(intgration)
vrification
Saccorder sur la
manire dont chaque
composant doit tre
construit
Le systme est il
Conforme lanalyse
Des fonctionnalits?
Implmentation
Phase de spcifications
et de conception
M.AFILAL
Phase de tests et de
validation
M.AFILAL
35
37
M.AFILAL
38
M.AFILAL
39
Rve
titi
123CDE91
garfield
mange
0605040302
grosminet
0102030405
parle
001-DF-YTR
poursuit
007BEJ06
Dupond
Dupont
poursuit
java 2
45BEJ91
milou
0203040506
M.AFILAL
40
Attribu
variable
compte001 : CompteBancaire
Attribu
constant
M.AFILAL
Identit
dobjet
M.Afilal
solde : 10
41
DebitAutorise : 1
CompteBancaire
Attributs
- solde
# numCompte
private
+ deposer()
+ retirer()
public
Oprations
M.AFILAL
protected
42
M.AFILAL
44
45
Tests de vrification
Implmentation
Spcifications fonctionnelles
Conception
M.AFILAL
Analyse
47
Itration: 1
Analyse
Conception
Itration: 2
Code+Test+Intgration
2 4 Semaines
Analyse
Conception
Code+Test+Intgration
2 4 Semaines
M.AFILAL
48
2
5
10
8
9
M.AFILAL
49
50
51
Le cycle de vie itratif et incrmental est en phase avec la ralit car il permet la
53
La solution UML
La solution est donc un langage qui permet denregistrer nos penses et communiquer en
utilisant des langages visuels et schmatiques:
Exemple: UML.
La raison du choix du langage visuels est quau moins 50% de notre cerveau est impliqu
dans le processus visuel.
Les langages visuels sont naturels et faciles pour notre cerveau.
Cest quoi et pourquoi UML ?.
M.AFILAL
54
La solution UML
UML (Unified Modeling Language) est un langage de construction de modle objet.
UML est un langage de modlisation (donc une notation) standard conu pour lcriture de
plans de construction de logiciels objet.
Il permet de capturer les caractristiques dun systme et de les exprimer laide de
notations prcises : des diagrammes.
Les mthodes objets OMT, Booch et OOSE (Objectory) sont lorigine de la cration du
langage UML en 1997
UML est adopt et standardis par le groupe Object Management Group.
UML n'est pas une mthodologie. Il ne prconise en effet aucune dmarche.
M.AFILAL
55
La solution UML
UML est une notation graphique conue pour:
reprsenter, spcifier, construire et documenter les systmes logiciels.
Ses deux principaux objectifs sont:
la modlisation de systmes en utilisant les techniques orientes objets, de la
conception jusqu la maintenance.
la cration dun langage abstrait comprhensible par lhomme et interprtable par les
machines.
Il permet de construire plusieurs modles dun systme, chacun mettra en valeur des aspects
diffrents:
fonctionnels, statiques, dynamiques et organisationnels
M.AFILAL
56
La solution UML
Les grandes qualits qui font que UML est un langage incontournable :
UML est un langage de modlisation objet.
UML est compos de modules (diagrammes) utilisables indpendamment les uns des
autres et qui expriment les caractristiques du systme au cours de son cycle de vie.
UML nest li aucune technologie ou aucun langage et peut donc tre utilis pour
nimporte quel type de dveloppement.
UML est dans le domaine public.
UML prend le meilleur de chacune des mthodes le prcdant :
OOSE (Jacobson) : cas dutilisation ;
OMT (Rumbaugh) : analyse ;
Booch : conception, architecture.
M.AFILAL
57
M.AFILAL
58
M.AFILAL
59
60
M.AFILAL
61
63
Diagrammes de UML
M.AFILAL
65
Classe strotype
<<Acteur>>
Nom Acteur
Remarque:
Du point de vue systme, il existe deux principaux catgories dacteurs:
les acteurs principaux : se sont les dclencheurs du cas dutilisation
les acteurs secondaires, se sont les autres acteurs
67
M.AFILAL
le matriel externe,
comme imprimante
les autres systmes.
M.AFILAL
68
Acte u r g n ra l
Acte u r sp ci a l i s
M.AFILAL
69
70
M.AFILAL
71
72
M.AFILAL
73
M.AFILAL
74
Exemple
Questions:
1- Reprsenter en UML les deux cas dutilisation : allumage ou extinction dune lampe
par un utilisateur.
2- Faites intervenir le rseau lectrique dans le cas dutilisation de lallumage de la
lampe
Rponse:
Le systme considr ou tudi est une lampe de chevet.
Les deux interactions lies aux fonctionnalits du systme sont lallumage de la lampe
et son extinction.
Lutilisateur de la lampe est un acteur primaire (ou principale).
Il est bien externe au systme qui est la lampe (lutilisateur ne fait pas partie
de la lampe).
Il interagit avec la lampe au travers de deux cas dutilisation : allumer et teindre
Il profite du service donn par les cas dutilisation car lallumage ou son
extinction de la lampe constituent bien des objectifs essentiels pour lui.
Lampe
Allumer
Utilisateur
M.AFILAL
teindre
76
Exemple
Le rseau lectrique est un acteur secondaire :
que lutilisateur de la lampe allume ou teigne cette dernire nest pas essentielle
pour le rseau lectrique,
Lampe
Allumer
teindre
Rseau
lectrique
Utilisateur
M.AFILAL
77
M.AFILAL
78
M.AFILAL
79
M.AFILAL
80
M.AFILAL
81
Sauthentifier
<<extend>>
M.AFILAL
Retenir carte
82
Exemple
Construire le diagramme des cas dutilisation et la description du cas dutilisation pour le
scnario suivant :
Un internaute ralise un virement entre 2 comptes via le guichet virtuel de sa
banque .
Application
Virement
Client
M.AFILAL
83
Systme
central
Rponse Exemple
tapes suivre:
Pour crer le diagramme des cas dutilisation, il faut commencer par:
Dfinir le systme tudi
Identifier les acteurs (principaux ou secondaires), puis
Les cas dutilisation associs pour chaque acteur, puis
Trouver les interactions qui puissent exister entre les cas dutilisation
et finir par
Donner une spcification ou description du cas dutilisation(avec les principaux
scnarios possibles).
Solution de lexemple:
Acteur(acteur principale): Un internaute.
Acteur (secondaire): Systme central.
Cas dutilisation: Virement
Description textuelle du cas dutilisation
M.AFILAL
84
Rponse Exemple
Cas dutilisation Virement
Titre : Virement
Rsum :
Ce cas dutilisation permet de faire un virement dune somme dargent dun
compte un deuxime compte via une liaison scurise et si la somme virer du
premier compte est valide par le systme central de la banque du client.
Acteurs : un internaute (principale), systme central (secondaire).
Date de cration : 29-12-2010
Date de mise jour : 14-10-2013
Version : 3.0
Responsable : Ahmed Ali
M.AFILAL
85
Rponse Exemple
Description des scnarios :
Prconditions :
Internaute se connecte au site Internet appropri.
Internaute clique sur le bouton Virement.
Client a fournit son nom dutilisateur
Client a fourni son code daccs
Le systme valide lidentification du client.
Scnario nominal (scnario le plus important)
On prsente ce scnario sous forme dun tableau, sparant les Actions des
acteurs et du systme (ou lapplication).
M.AFILAL
86
Rponse Exemple
Action Acteur
9-Affichage de la fentre
remercment
10-Affichage de la fentre
Identification Internaute
M.AFILAL
87
Rponse Exemple
Enchanements alternatifs et Enchanements des erreurs
3-a
7-a
Si lun des numros de compte est erron, en demande de ressaisir le numro erron puis la troisime
tentative le cas dutilisation se termine.
7-b
Si le compte dbiter est bloqu, on affiche un message puis on reprend le scnario 6 ou en sort du cas
dutilisation se termine.
7-c
Si la somme dpiter est trop lev ou impossible car le solde du compte dbiter ne le permet pas, on
avertie linternaute, puis on reprend le scnario 5 ou en sort du cas dutilisation se termine.
4-a
Le systme valide le scnario 4, puis demande si le virement va se faire en devise, Linternaute choisit le
type de la devise puis le montant dbiter doit avoir la proprit de la devise choisit
Postconditions
Une transaction de virement a t enregistre par le systme central avec toutes
les informations pertinentes (montant dbiter, numros du comptes dbiter
crditer, la date et lheure de la transaction, etc.).
M.AFILAL
88
Exemple
Avec la description textuelle, on peut ajouter dautre cas dutilisation, qui vont optimiser
ou gnraliser dautres cas dutilisation. (dcomposer un cas complexe en des sous cas
moins complexes)
Les cas dutilisation ajouts dans le systme prcdant sont :
Identification et Validation
Se sont des cas dutilisation interne au systme (dans Virement),
Elles sont ajoutes pour montrer les liaisons entre cas dutilisation storotypes
include et puis extend .
Virement en devise est un cas particulier de virement ou cest une extension des
proprits de Virement.
Le lien entre ses deux cas dutilisation se fait via des instances de chaque cas
dutilisation.
M.AFILAL
89
Exemple
Application
Virement
SI choix devise
<<extend>>
<<include>>
<<include>>
Virement en
devises
Identification
client
Validation
Systme
central
Client
M.AFILAL
90
Methodes
+ getCentre ( ) : Point
+ getRayon ( ) : float
+ $ surfaceTotale(list : Cercle2D[ ]) : float
Exceptions
rayonNonValideException
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:
son nom, la liste de ses attributs et de ses oprations (mthodes),
chaque attribut ou mthode peut tre qualifi avec des symboles : les modificateurs
daccs :
Remarque:
La dclaration dun attribut a la syntaxe suivante :
<modificateur daccs> [/]< Nom_Attribut >:< Type_attribut> ['['multiplicit ']']
[=valeur(s) initiale(s)] {proprit}
La dclaration dune opration a la syntaxe suivante :
<modificateur daccs>< NomDeLaMethode ([paramtres]) >:[<valeurRenvoye]
{proprit}
M.AFILAL
92
Classe et objet
Remarque
Multiplicit := (Intervalle | nombre)
Intervalle := Limite_Infrieure ..Limite_Suprieure
Limite_Infrieure:= entier_positif | 0
Limite_Suprieure := nombre
Proprit, dans le cas de la syntaxe dun mthode est donne par:
{abstrait}: indique une opration non implmente dans la classe. Le nom dune opration
abstraite peut galement tre rendu par une fonte en italique
{estFeuille}: Indique que lopration ne peut tre redfinie dans une sous classe (la proprit
de type boolen)
{estRacine}: indique que lopration est dfinie pour la premire fois dans une hirarchie de
classes (la proprit est de type boolen)
{requete}: indique que lopration naltre pas ltat de linstance concerne (la proprit est
de type boolen; la valeur vraie peut tre omise)
{concurrence = valeur}: o valeur est squentiellement gard (Lintgrit de lobjet est
garantie par un mcanisme de synchronisation externe) ou concurrent
valeur est lobjet
ou le champs ou le paramtre sur lequel on applique
la
93
M.AFILAL
synchronisation
<<interface>>
Forme2D
+ getCentre ( ) : Point
+ getRayon ( ) : float
+ $ surfaceTotale(list : Cercle2D[ ]) : float
Cercle{abstract}
- centre : Point
+ getCentre ( ) : Point
M.AFILAL
+ * surface
( ) : float
+ $ * surfaceTotale(list : Cercle2D[ ]) : float
94
<<interface>>
Forme2D
<<interface>>
Forme2D
Cercle
Cercle
Cercle
M.AFILAL
95
titi : Voiture
marque = Citroen
modele = DS 21
immatriculation = 19 AS 01
M.AFILAL
96
M.AFILAL
97
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 leurs interactions.
Ces classes peuvent tre relies de multiples manires :
La dfinition des relations est aussi importante que la dfinition de chaque classe.
Il y a plusieurs types de relation entre les classes :
Lassociation.
Lagrgation.
La composition.
La gnration.
La spcialisation.
La dpendance.
Remarque:
Les diagrammes de classes UML constituent un surensemble de diagrammes entitsassociations (E-A).
Alors que les digrammes E-A classiques sont centrs sur les donnes, les diagrammes
de classes vont un peu plus loin et permettent galement la modlisation de
comportements.
98
M.AFILAL
Lassociation
Une association est une relation entre classes.
Une association modlise la connexion entre deux classes dont lune a besoin de lautre
pour tre dfinie ou pour exister (liaison).
Exemple :
Une personne peut possder des voitures.
la relation possde est une association entre les classes Personne et Voiture
Un employ commercial est en relation avec ses clients.
La classe Client a un champ type commercial ou simplement un identifiant
idCommercial
La classe Employ a un champ de type Client[ ] ou simplement un vecteur
contenant les idClients
Une association dcrit une relation entre les objets de deux classes (ou plus).
Une des classes doit avoir connaissance de lautre pour accomplir son traitement.
En gnral les associations sont binaires, cest dire quelles connectent deux classes.
M.AFILAL
99
Lassociation
On reprsente une association en traant une ligne entre les classes associes.
Les associations peuvent tre nomme par une forme verbale.
Le sens de lecture est prcis par un symbole < ou > .
par dfaut de gauche vers la droite
L'extrmit d'une association est appele rle.
Le rle dcrit comment une classe voit une autre classe au travers d'une association.
Le rle est un pseudo attribut de la classe source (utilis comme un attribut).
Enfin, chaque rle d'une association porte une indication de cardinalit (multiplicit) qui
montre combien d'objets d'une classe peuvent tre lis un objet de lautre classe.
ValeurMultiplicit
Signification
n
exactement n instances
n..m
de n m, valeurs incluses
*
valeurs quelconque, quivaut 0 . . n ou 0 . .
n..*
au moins n
n . . m, p . . q
liste de valeurs ou dintervalles
Entreprise
1..1
Employeur
M.AFILAL
Emploie >
1..*
Intrimaire
Personne
100
{ordered}
Catalogue
1..*
Livre
1..*
contient >
M.AFILAL
101
M.AFILAL
102
Entreprise
private
{ XOR }
Etat
M.AFILAL
Employeur
public
Personne
Personne
Entreprise
{ Subset }
M.AFILAL
dlgu
104
Association rflexive
Association rflexive:
Deux objets de la mme classe sont impliqus dans la relation, il faut nommer les rles.
Cette relation permet de structurer les objets de la mme classe:
Crer une hirarchie entre objet, partitionner les objets, regrouper les objets en classe
dquivalence
Exemple
1- un manager dirige un plusieurs employs. Chaque employ est dirig par un seul manager
2- une personne a le mme age qua zro plusieurs personnes
3- une personne possde deux parents et de zro plusieurs enfants.
1
manager
Personne
Employ
1..*
<
dirige
Personne
Personne
0,*
Personne
0,*
< a le mme
age
0,*
2pare
nt
M.AFILAL
105
<
0,*
est amie
de
Association rflexive
Association symtrique non transitive
Permet de partitionner les instances de la mme classe
Association symtrique et transitive
Permet de regrouper les objets, de la mme classe, en classe dquivalence.
Association asymtrique
Permet de crer un hirarchie (sorte darbre) entre les objets.
Exemple:
Ami de: est une relation symtrique non transitive, permet de partitionner les objets.
A le mme age: est une relation symtrique transitive, permet de crer une relation
dquivalence.
Parent de: est une relation asymtrique(anti-Symetrique), elle permet de crer un arbre
(une hirarchie) entre les objets.
M.AFILAL
106
Association rflexive
Remarque:
Il est conseill dajouter les rles des extrmits dans le cas des relations asymtriques.
Une relation rflexive se traduit, dans la dfinition dune classe, simplement par une
rfrence sur un objet de la mme classe
Exemple (avec java)
class Personne{
Private Personne manager;
Private Vector<Personne> employes;
}
M.AFILAL
107
Intervenant
1
Salle
1M.AFILAL
2..*
108
Stagiaire
Classe association
Si une association contient des proprits, on construit alors une classe association:
Cette classe association peut participer dautres relations avec dautres classes.
La notation utilise une ligne pointille pour attacher cette classe lassociation.
Remarque:
La multiplicit sur le lien de chaque classe sapplique sur une instance du losange.
Intervenant
1
Salle
2..*
Stagiaire
Formation
M.AFILAL
date
sujet
109
Intervenant
1
Salle
1
association ternaire
1
1
Formation
2.. *
date
sujet
M.AFILAL
110
Stagiaire
Classe association
Une classe association peut tre remplace par une classe intermdiaire et qui sert de pivot
pour une paire dassociations.
Exemple: Transformation dune classe-association en une classe et en associations binaires.
A = tudiant; B = Travail et C classe association C avec attribut = note
Un tudiant ralise m travail et un Travail est ralis par n tudiant,
chaque travail fait par un tudiant lui est associ une note,
Le champ note ne peut tre dans la classe tudiant (un tudiant peut effectuer
plusieurs travaux et chaque travail une note)
Ni dansRalise
la classe Travail (dans un travail, il y a autant de note que dtudiants).
M.AFILAL
111
Banque
Compte
*
hberge
Banque
M.AFILAL
NumCpte:String
hberge
Compte
112
0..1
Qualificatif: Q
public class A{
private Map< Q, B> BObj = new HashMap< Q, B >;
Ou
private Map< Q, B > BObj = new HashTable< Q, B >;
.
}
Avec: Q = type de la cl utilise
dans le Map
M.AFILAL
113
M.AFILAL
114
M.AFILAL
115
Polygone
Point
0..*
3..*
116
Agrgation
L'agrgation est une association non symtrique
qui exprime lide quun objet fait partie dun autre objet.
qui exprime un couplage fort entre des classes, une des extrmits joue un rle
prdominant par rapport lautre extrmit.
Elle matrialise une relation de type:
compos et composant: "est-compos-de"
tout et parties: "est-une-partie-de"
matre-esclave: "appartient- "
Etc
Elle reprsente une relation dinclusion structurelle ou comportementale dun lment
dans un ensemble.
Le nom de la relation, en gnrale, est:
fait partie de ou contient ou compos de ou possde ou appartient , etc
Le compos(le tout) est lagrgat et les composants (les parties) sont les instances
agrges.
117
M.AFILAL
lagrgat joue le rle
dominant dans lassociation.
Agrgation
Remarque:
En pratique, l'identification d'une relation d'agrgation de celle d'association n'est pas
vidente.
Exemple : Un document est un ensemble de paragraphe.
Document
M.AFILAL
Paragraphe
118
Agrgation
Proprits de lagrgation:
Le tout est responsable de la gestion de ses parties.
Laction sur le compos(agrgat) entrane une action sur le composant(lagrg).
Un composant peut tre partag par plusieurs agrgats :
la multiplicit cot agrgat peut avoir une valeur suprieur 1.
Exemple:
une phrase peut tre dans plusieurs paragraphes.
La relation est transitive :
Exemple: 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 compos.
Les valeurs sont propages de lagrgat au composant :
Exemple:
la mise en italique du paragraphe entrane la mise en italique des phrase.
Remarque:
La dure de vie de lagrgat est indpendante des lments qui le constituent (cas o
un composant est partag par plusieurs agrgats)
M.AFILAL
119
Agrgation
Autres critres qui indiquent une agrgation:
Une classe fait partie dune autre classe,(classe interne)
Les valeurs dattributs dune classe se propagent dans les valeurs dattributs dune
autre classe
La modification dun attribut dun objet agrgat porte aussi sur les attributs des
objets agrgs.
Une action sur une classe implique une action sur une autre classe.
La suppression dun objet agrgat ferait disparatre les objets agrgs.
Les objets dune classe sont
Subordonns (secondaires, dpendants) aux objets dune autre classe,
contrls par les objets dune autre classe.
La dfinition dune mthode de lobjet agrgat repose sur celles des objets agrgs
M.AFILAL
120
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 ct du composant indique un attribut non renseign.
La suppression dun objet agrgat ferait disparatre les objets agrgs.
Une relation de composition est une agrgation qui vrifie de plus:
l'opration de destruction de lagrgat entrane la destruction de lagrg.
la multiplicit du ct agrgat est infrieur ou gale a 1.
Elle est reprsente en ajoutant un petit losange noire du ct de lagrgat.
M.AFILAL
121
Exemple de la composition
Universit
Facults
1,*
Dpartements
1,*
gre
Etudiants
M.AFILAL
122
possde
M.AFILAL
123
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
A moteur
A voile
M.AFILAL
124
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.
M.AFILAL
125
La gnralisation
Vehicule
{disjoint}
(milieu)
(motorisation)
A_Moteur
A_Voile
Terrestre
Maritime
{overlapping}
{overlapping}
Trimaran
Voiture
M.AFILAL
126
La dpendance
Cest une relation unidirectionnelle, exprimant une dpendance non structurelle, de la
classe source vers la classe cible.
Elle indique que la modification de la cible implique un changement de la source.
Exemple :
Un composant graphique a besoin dune couleur pour pouvoir safficher.(choix dune
nouvelle couleur entrane un changement de couleur du composant)
Le droulement des cours dpend de lemploi de temps
Elle reprsente une relation sur les classes uniquement, sans induire de liens sur les objets
instance de ces classes
La dpendance exprime la situation o une classe utilise une autre classe,
par exemple, en appelant une mthode de la 2me classe.
Remarque:
Lusage de telles relations est dconseill dans un diagramme car source dimprcision
et de couplage entre les classe (trop de classe)
M.AFILAL
127
La dpendance
Cible
Source
ComposantGraphique
Cours
Couleur
EmploiDeTemps
M.AFILAL
128
Interface et association
Quand une classe dpend dune interface pour raliser ses oprations, elle est dite classe
cliente de linterface .
Graphiquement, cela est reprsent par une relation de dpendance entre la classe et
linterface.
<<interface>>
NomInterface
NomClasse
M.AFILAL
129
Exemple de cas
Un microprocesseur est constitu de portes logiques. Ces portes logiques sont composes
de transistors qui fonctionnent comme des interrupteurs. On trouve deux sortes de portes
de base : les portes MOS et les portes CMOS.
Les microprocesseurs sont cadencs par une horloge caractrise par sa vitesse.
Les microprocesseurs sont bass sur deux mthodes doptimisation: la technologie CISC et
la technologie RISC
Tracez le diagramme de classe correspondant la description ci-dessus
M.AFILAL
130
Exemple de cas
La phrase un microprocesseur est constitu de portes logiques met en vidence deux notions
importantes ce qui permet davoir deux classes: Microprocesseur et PorteLogique
Les deux classes sont lies par une relation de composition, puisquune porte nappartient qua un seul
microprocesseur et son existence dpend de celui-ci
La seconde phrase met en vidence une nouvelle classe Transistor.
Chaque porte logique est compos de transistors , ce qui correspond une relation de composition.
La cardinalit * est ajoute aux extrmits des objets composant (les agrges)
Le diagramme initiale est donn par:
Microprocesseur
*
PorteLogique
M.AFILAL
Transistor
131
Exemple de cas
Les portes MOS et CMOS sont des spcialisations de la classe PorteLogique qui devient
une classe abstraite
Microprocesseur
*
*
PorteLogique
{abstract}
PorteMos
Transistor
PorteCMOS
M.AFILAL
132
Exemple de cas
La phrase Les microprocesseurs sont cadencs (rythms) par une horloges caractrise
par sa vitesse dcrit le lien existant entre la classe Microprocesseur et la classe Horloge,
lien est prsent par lassociation cadensPar.
La frquence est un attribut de la classe Horloge
Microprocesseur
Horloge
cadensPar >
1
M.AFILAL
- frquence:Integer
133
Exemple de cas
La dernire phrase Les microprocesseurs sont bass sur deux mthodes doptimisation: la
technologie CISC et la technologie RISC
Or, un microprocesseur ne peut tre modlis que sur lune des deux mthodes
La dernire phrase peut tre modlise de deux faon diffrentes
par deux associations qui sexcluent mutuellement:
Ou bien construire une classe abstraite qui gnralise les deux classes TechnologieCISC et
TechnolgieRISC
TechnologieCISC
< basSur
1
TechnologieRISC
{XOR}
Microprocesseur
*
*
TechnologieCISC
Technologie
{abstract}
1
TechnologieRISC
M.AFILAL
Microprocesseur
< basSur
*
134
Exemple de cas
Le diagramme complet est:
Technologie
{abstract}
< basSur
1
Horloge
cadensPar >
Microprocesseur
- frquence:Integer
TechnologieCISC
PorteLogique
{abstract}
TechnologieRISC
PorteMos
M.AFILAL
PorteCMOS
135
Transistor