Cours UML Kounaidi

UML : Unified Modeling Language
Gnie Logiciel
UML
Introduction
Cycle de vie dun logiciel
Historique dUML
Diagrammes UML
Diagrammes de classes et d'objets
Diagrammes des cas d'utilisation
Autres diagrammes
Passage vers le code
De UML vers Java
UML et les bases de donnes
Langage de contraintes : OCL
tudes de cas
De lanalyse des besoins au code
2

3
Processus (ensemble dactivits) ncessaire

au dveloppement et la maintenance dun
logiciel
Compos de plusieurs phases autonomes
mais dpendantes (interdpendantes).
Chaque tape se termine par la remise de un
ou plusieurs documents valid conjointement
par lutilisateur et le dveloppeur.

4
tapes ncessaires la ralisation dun logiciel:
Analyse
Conception
Codage (Implmentation)
Tests
Livraison
Maintenance

Modle en Cascade (WaterFall)
5
Analyse
Conception
Implmentation
Tests
Maintenance

Analyse
6
Elle a pour but de dgager le problme

tudier.
Le rsultat de l'analyse est le cahier de
charges (exprim dans une langue naturelle)
contenant les besoins du futur systme.
Cette spcification est informelle.
3 phases:(Faisabilit, Spcifications des
besoins, Organisation du projet)

Faisabilit
7
Premire tape du cycle de vie dun logiciel

Rpondre deux questions :
Est-ce que le logiciel est ralisable ?
Est-ce que le dveloppement propos vaut la
peine dtre mis en uvre ?
tudier le march pour dterminer sil

existe un march potentiel pour le produit.
7

Spcification des besoins
8
Permet de dfinir ce que doit faire le logiciel et

non comment il le fait
Quatre types de spcifications
Spcifications gnrales
Spcifications fonctionnelles
Spcifications dinterface
Spcifications techniques

9
La spcification gnrale consiste identifier :

Objectifs atteindre
Contraintes (utilisation du matriel et outils
existants)
Rgles de gestion respecter

10
Spcification fonctionnelles est la description des

fonctionnalits du futur logiciel de manire
dtaille que possible
Spcification dinterface dcrit les interfaces du
logiciel avec le monde extrieur : homme
(IHM), autres logiciel (Middleware), machines
10

11
Spcification technique :(tude de lexistant)

Moyens daccs (local, distant, Internet, )
Temps de rponse acceptable (gestion des GAB,
gestion des emplois de temps, )
Plateforme (Windows, Unix, )
Quantit dinformations stocker (choix du
SGBDR, )
11

Organisation du projet
12
Appele aussi Planification et gestion de projet

Permet de dterminer la manire de dvelopper le
logiciel
La phase de planification permet de :
dcouper le projet en tches

dcrire leur enchanement dans le temps,
affecter chacune une dure et un effort
12

Organisation du projet
13
Plusieurs tapes :
Analyse des cots: estimation du prix du projet
Planification: calendrier pour le dveloppement
(jours ouvrables, jours fris, nombre dheures de
travail par jours, )
Rpartition des tches: distribuer les tches et les
sous tches (affectation des ressources aux
tches)
13

Conception
14
Permet de fournir une description fonctionnelle

(formelle) du systme en utilisant une
mthode.
Les mthodes proposent des formalismes
(dans la plupart des temps graphiques) pour
concevoir le systme.
Deux types de conception :
Conception gnrale
Conception dtaille
14

Conception gnrale
15
Appele aussi : Conception architecturale

Se focaliser sur larchitecture gnrale du
systme : dcomposition du systme en sous
systme
Exemple, pour la gestion scolaire :
Estudiantine (tudiants, notes, prof, filires, )

Administrative (personnel administratif, )
Bibliothque (Ouvrages, auteurs, adhrents, )
15

Conception dtaille
16
Produire une description externe de chacune

des procdures, fonctions et des structures de
donnes (conception classique)
Produire de manire prcise les contenus des
objets en terme de proprits et de mthodes
(conception Oriente Objet)
16

implmentation (Ralisation)
17
Des programmes seront labors afin de

mettre en uvre des solutions techniques
prcdemment retenues
Plusieurs types langages sont utiliss:
Langages classiques (C, Pascal, Fortran, )
Langages orients objets (C++, Java, C#, )
17

Codage et Tests
18
On distingue plusieurs types de tests :
Test unitaire: tester les parties du logiciel par les dveloppeurs

Test dintgration: tester pendant lintgration des modules
Test systme: tester dans un environnement proche celui de
production
Test alpha: tests faits par le client sur le site de dveloppement
Test bta: tests faits par le client sur le site de production
Test de rgression: enregistrer les rsultats des tests et les
comparer avec ceux des anciens versions pour dterminer si la
nouvelle na pas apport de dgradation de performance.
18

Livraison
19
Fournir au client une solution logiciel qui

fonctionne correctement.
Plusieurs tches :
Installation: rendre le logiciel oprationnel sur le
site du client
Formation: enseigner aux utilisateurs se servir
de ce logiciel
Assistance: rpondre aux questions de lutilisateur
19

Maintenance
20
Mettre jour et amliorer le logiciel

La maintenance comprend :
Corrective : correction des erreurs et anomalies
Adaptative : adaptation de nouveaux
environnements
volutive ou Perfective : ajout de nouvelles
fonctionnalits
20

Documents
21
Cahier des charges : description des fonctionnalits

dsires (dcrites par lutilisateur)
Spcifications : dcrit ce que doit remplir le logiciel
(dcrites par le dveloppeurs) :
Modle Objet : Classes et objets

Scnarios des cas dutilisation : diffrents enchanements
possibles du point de vue de lutilisateur
IHM : propositions des interfaces homme-machines
21

Documents
22
Calendrier du projet: indique les tches, les

dlais et les ressources
Plan de test: indique les procdures de tests
appliquer
Manuel dutilisateur: mode demploi du logiciel
dans sa version finale
22

Documents
23
Code source: code complet du produit fini

Rapport des tests: dcrit les tests effectus et
les ractions du systme
Rapport des dfauts: dcrit les comportements
du systme qui nont pas satisfait le client.
23
Historique
Dans le cadre de la modlisation des SI, on
distingue Deux approches
Approche fonctionnelle
1960 fin 1970

l'important c'est les traitements
Sparation nette des donnes et traitements
(MCD et MCT dans Merise, par exemple)
Approche objet
1980 dbut 1990 : premires gnration

L'important c'est l'objet
Objet = donnes + traitements
24
Historique
la fin des annes 90, il yavait une prolifration des
mthodes : 1984 1994, le nombre de mthodes OO a pass
de 10 plus de 50 (guerre de mthodes). Chaque mthode
met laccent sur un aspect diffrent (OMT est oriente vers
lanalyse, OOD est plus oriente vers la conception, OOSE
insiste sur la spcification des besoins). Dautre part, chaque
mthode propose ses propres concepts et sa propre notation.
ceci est la source dune grande confusion dune part, et la
difficult de passage dune mthode une autre
mthode OOD de Grady Booch (1991)

mthode OMT de James Rumbaugh (1991)
mthode OOSE de Ivar Jacobson (1991)
mthode OOA/OOD de Coad and Yourdon (1992)
mthode de Schlaer and Mellor (1992)
Etc.
25
Historique
Fin 1994
J. Rumbaugh rejoint G. Booch chez Rational Software
OMT + OOD Unified Method (oct 1995)

Fin 1995
I. Jacobson les rejoint chez Rational Software
Unified Method + OOSE UML 0.9 (juin 1996)
Dbut 1997
Partenaires divers : Microsoft, Oracle, IBM, HP et autres leaders
collaborent
UML 1.0 (jan 1997)

Fin 1997
lOMG (Object Management Group) retient UML 1.1 comme
norme de modlisation
26
Historique
Les versions se succdent :
Dbut 1998
UML 1.2
En 1998
UML 1.3
En 2001
UML1.4
En 2003
UML 1.5
En 2005
UML 2.0
27
Quest ce que UML ?

UML(Unified Modeling Language) un
langage de modlisation unifi
Langage = syntaxe + smantique :
syntaxe : notations graphiques consistant

essentiellement en des reprsentations
conceptuelles d'un systme
smantique : sens prcis pour chaque notation
28
Quest ce que UML ?
UML est caractris par :
un travail d'expert
utilise lapproche oriente objet
normalis, riche
Formel : sa notation limite les ambigut et les
incomprhensions
langage ouvert
INDPENDANT du langage de programmation

Domaine d'application : permet de modliser n'importe quel
systme
Support par plusieurs outils (AGL) : Objecteering, Open

tools, Rational Rose, PowerAMC, WinDesign,
29
Quest ce que UML ?

Attention
UML est un langage (et non pas une mthode)
qui :
permet de reprsenter les modles
ne dfinit pas le processus d'laboration des
modles.
30
Diagrammes d'UML
UML1.1 comprend 9 de diagrammes :
Diagramme
Est sorte de
Cas
utilisation
Cas
d dutilisation
Collaboration
Composants
Classes
Classes
EtatsTransitions
Transitions
tats
Dploiement
Activit
Squence
Squence
Objets
31
Diagrammes d'UML
UML dfinit deux types de diagrammes, structurels (statiques)
et comportementaux (dynamiques)
Modlisation de la structure (ce que le systme EST)
diagramme de classes: reprsente la partie statique du systme en

intgrant dans chaque classe la partie ddie aux donnes et celles
consacre aux traitements. Cest le diagramme pivot de la modlisation
du systme.
diagramme dobjets: reprsente les instances des classes du
diagramme de classes
diagramme de composants: reprsente les diffrents constituants
logiciel dun systme en terme de modules : fichiers source, librairies,
excutables, etc.
diagramme de dploiement: montre la disposition physique des
matriels qui composent le systme et la rpartition des composants
sur ces matriels
32
Modlisation du comportement: (comment le systme
EVOLUE)
diagramme de cas d'utilisation: destin reprsenter les

besoins des utilisateurs par rapport au systme. Point de vue de
lutilisateur
diagramme dtats/transitions : montre les diffrents tats par
lesquels passe un objet en ractions aux vnements.
diagramme dactivits: donn une vision des enchanements des
activits propres une opration ou un cas dutilisation.
diagramme de collaboration: une autre reprsentation des
scnarios des cas dutilisation qui met laccent sur les objets et les
messages changs.
diagramme de squence: permet de dcrire les scnarios de
chaque cas dutilisation en mettant laccent sur la chronologie des
interactions entre objets.
33
Diagramme dUML
Les diagramme dUML peuvent tre utiliss pour
reprsenter diffrents points de vues :
Vue externe : vue du systme par ses utilisateurs
finaux
Vue logique statique : structure des objets et leurs
relations
Vue logique dynamique : comportement du systme
Vue dimplmentation : composants logiciels
Vue de dploiement : rpartition des composants
34
UML
Diagrammes de cas
d'utilisation
35
Diagramme des cas

dutilisation
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.
36
Diagramme de cas
d'utilisation
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
37
Diagrammes des cas

d'utilisation
Comportent plusieurs lments :
Acteurs
Cas d'utilisation
Relations de dpendances, de
gnralisations et d'associations
38
Acteurs
UML nemploi pas le terme dutilisateur mais

dacteur.
Le terme acteur ne dsigne pas seulement
des utilisateurs humains mais galement les
autres systmes (machines, programmes, )
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)
39
Acteurs
Remarques
La mme personne physique peut jouer le
rle de plusieurs acteurs (Chef dagence est
un client de la banque).
Dautres part, plusieurs personnes peuvent
jouer le mme rle, et donc agir comme un
mme acteur (plusieurs personnes peuvent
jouer le rle dadministrateur).
40
Acteurs
Peut tre reprsent de deux manires
diffrentes :
Petit personnage (stick man)

Nom Acteur
Classe strotype
<<Acteur>>
Nom Acteur
41
Acteurs
Les acteurs peuvent tre de trois types :
Humains : utilisateurs du logiciel travers
son interface graphique, par exemple.
Logiciels : disponibles qui communiquent
avec le systme grce une interface
logicielle (API, ODBC, )
Matriels : exploitant les donnes du systme
ou qui sont pilots par le systme
(Imprimante, robots, automates, )
42
Acteurs
<<acteur>>
Site Web de l'tablissement
Secrtaire
Systme de Gestion
Scolaire
Etudiant
<<acteur>>
Imprimante
43
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.
44
Acteurs
Un acteur peut tre une
spcialisation d'un autre
acteur dj dfini.
Acteur gnral
Dans ce cas, on utilise la

relation de
gnralisation/spcialisation.
Acteur spcialis
45
Cas d'utilisation
Introduit par Ivar Jacobson en 1992 dans sa

mthode Object-Oriented Software
Engineering (OOSE).
Technique de description du systme tudi
privilgiant le point de vue de l'utilisateur.
Repris par UML dans la but de :
Effectuer une bonne dlimitation du systme

Amliorer la comprhension de son
fonctionnement interne
46
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.
47
Cas d'utilisation
Un cas d'utilisation est reprsent par une
ellipse en trait plein, contenant son nom.
Nom Cas Utilisation
48
Structuration des cas

d'utilisation
Aprs avoir identifi les acteurs et les cas
d'utilisation, il est utile de restructurer
l'ensemble des cas d'utilisation que l'on a fait
apparatre afin de rechercher les :
Comportements partags
Cas particuliers, exceptions, variantes
Gnralisations/spcialisations.
49
Structuration des cas

d'utilisation
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
50
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.
51
A inclut B : le cas A inclut obligatoirement le

comportement dfinit par le cas B; permet de
factoriser des fonctionnalits partages
Le cas d'utilisation point par la flche (dans
notre cas B) est une sous partie de l'autre
cas d'utilisation (A, dans notre exemple).
B
<<include>>
52
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
<<include>>
Dposer de l'argent
<<include>>
S'authentifier
<<include>>
Effectuer des virements
<<include>>
Consulter solde
53
On utilise cette relation pour viter de dcrire
plusieurs fois un mme enchanement
d'actions. Ainsi, on est amen factoriser un
comportement commun plusieurs cas
d'utilisation dans un cas d'utilisation part.
54
Remarques
La relation include na pour seul objectif que de
factoriser une partie de la description dun cas
dutilisation qui serait commune dautres cas
dutilisation.
Le cas dutilisation inclus dans les autres cas
dutilisation nest pas proprement parl un vrai cas
dutilisation car il na pas dacteur dclencheur ou
receveur dvnement. Il est juste un artifice pour
faire de la rutilisation dune portion de texte.
55
Rsum
Une instance du cas source inclut
obligatoirement le comportement dcrit par le
cas dutilisation destination
Permet de dcomposer des comportements
et de dfinir les comportements partages
entre plusieurs cas dutilisation
Factoriser
56
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.
57
Le CU source (B) ajoute, sous certaines conditions,

son comportement au CU destination (A)
En dautres termes, le CU B peut tre appel au
cours de lexcution du CU A
A
B
<<extend>>
Point d'insertion
Le comportement ajout sinsre au niveau dun

point dextension dfinit dans le CU destination
58
Le cas d'utilisation de destination peut

fonctionner tout seul, mais il peut galement
tre complt par un autre cas d'utilisation,
sous certaines conditions.
On utilise principalement cette relation pour
sparer le comportement optionnel (les
variantes) du comportement obligatoire.
59
Exemple :
Au moment de l'authentification, il se peut que
le guichet retient la carte.
S'authentifier
Retenir la carte
<<extend>>
60
Relations dinclusion VS
d'extension
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.
61
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.
62
Relation d'hritage : Exemple

Dans un systme d'agence de voyage, un acteur
"Touriste" peut participer un cas d'utilisation
de base qui est "Rserver voyage", qui
suppose par exemple, des interactions
basiques au comptoir de l'agence. Une
rservation peut tre ralise par tlphone ou
par Internet.
63
On voit qu'il ne s'agit pas d'une relation "extend", car

la rservation par Internet n'tend pas les interactions
ni les fonctionnalits du cas d'utilisation "Rserver
voyage".
Les deux cas d'utilisation "Rservation voyage" et
"Rserver voyage par Internet" sont lis : la
rservation par Internet est un cas particulier de
rservation.
De faon gnrale en objet, une situation de cas
particulier se traduit par une relation de
gnralisation/spcialisation.
64
Reserver voyage
Rserver voyage par tlphone
Rserver voyage par Internet
65
Structuration entre cas

dutilisation
Rsum
Les cas peuvent tre structures par des relations :
A inclut B : le cas A inclut obligatoirement le
comportement dfinit par le cas B; permet de
factoriser des fonctionnalits partages
A tend B : le cas A est une extension optionnelle du
cas B un certain point de son excution.
A gnralise B : le cas B est un cas particulier du
cas A.
66
Relations entre cas

dutilisation : Exemple
Un client peut effectuer un retrait bancaire. Le
retrait peut tre effectu sur place ou par
Internet. Le client doit tre identifi (en
fournissant son code daccs) pour effectuer
un retrait, mais si le montant dpasse
500DH, la vrification du solde de son
compte est ralise.
67
Relations entre cas

dutilisation
Virement
<<extend>>
Vrification solde compte
Montant > 500 DH
<<include>>
Virement par Internet
Virement sur place

Identification
Client distant
Client local
68
Description des cas

dutilisation
Le diagramme de cas dutilisation dcrit les

grandes fonctions dun systme du point de
vue des acteurs.
Mais il nexpose pas de faon dtaille le
dialogue entre les acteurs et les cas
dutilisation.
ncessit de dcrire ce dialogue
69
Description des cas

dutilisation
Deux faons sont couramment utilises pour
dcrire les cas dutilisation :
Description textuelle
Description laide dun diagramme de
squence (voir chapitre suivant)
70
Description des cas dutilisation

(description textuelle)
Identification
Nom du cas : retrait dargent

Objectif : dtaille les tapes permettant un
guichetier deffectuer des oprations de retrait par
un client
Acteurs : Guichetier (Principal), Systme central
(Secondaire)
71

Scnarios
1.
2.
3.
4.
5.
6.
7.
Scnario nominal
Le Guichetier saisit le numro de compte client
Lapplication valide le compte auprs du SC
Lapplication demande le type dopration au Guichetier
Le Guichetier slectionne un retrait de 200 DH
Le systme interroge le SC pour sassurer que le compte
est suffisamment approvisionn.
Le SC effectue le dbit du compte
Le systme notifie au guichetier quil peut dlivrer le
montant demand
72

Scnarios
1.
Scnario alternatif (exception)

En (5) : si le compte nest pas suffisamment
approvisionn .
73

(description par diagramme de
squence)
Systme
Guichetier
Saisie du numro de compte client
Systme Central
Demande de validit de compte

OK
Vrfification
Demande type opration

Retrait(somme)
Compte suffisamment approviosionn
Compte dbit
Dbiter le compte
Autorisation de dlivrer somme
74
Intrts des cas dutilisation

Les CU obligent les utilisateurs :
Dfinir la manire dont ils voudraient interagir
avec le systme
Prciser quelles informations ils entendent
changer avec le systme
Dcrire ce qui doit tre fait pour obtenir le
rsultat escompt
75
Diagramme des cas

d'utilisation
Le diagramme des cas d'utilisation regroupe dans

un mme schma les acteurs et les cas d'utilisation
en les reliant par des relations. Le systme tant
dlimit par un cadre rectangulaire.
La reprsentation de base d'un cas d'utilisation est
une ellipse contenant le nom du cas. L'interaction
entre un acteur et un cas d'utilisation se reprsente
comme une association. Elle peut comporter des
multiplicits comme toute association entre classes.
76
Diagramme des cas

d'utilisation
Dposer de l 'argent
Reteni r l a carte
Cl i ent
<<i nclude>>
Reti rer de l 'argent
<<extend>>
<<i ncl ude>>
Consul ter l e sol de
<<i ncl ude>>
S'authenti fi er
<<i ncl ude>>
Effectuer des vi rements entre comptes
Fourni r un l ogi n et un mot

de passe
Agent
Ravi tai l l er
T echni cien
Rparer
77
tapes de construction du
diagramme des cas
Pour modliser le diagramme des cas d'utilisation, il faut :
d'utilisation
Identifier les acteurs qui entourent le systme. Certains acteurs
utilisent le systme pour accomplir des tches (acteurs

principaux), d'autres effectuent des tches de maintenance ou
d'administration (acteurs secondaires).
Organiser les acteurs selon une hirarchisation de
gnralisation/spcialisation
Intgrer les acteurs au diagramme en spcifiant les cas
d'utilisation auxquels ils se rapportent
Structurer les cas d'utilisation pour faire apparatre les
comportement partags (relation d'inclusion), les cas particuliers
(gnralisation/spcialisation) ou options (relation d'extension)
78
Diagramme dUML
Cas dutilisation
Composants
Objets
Classes
Squence
Collaboration
Vue logique statique

(Structure des objets)
Vue Implmentation
(composants logiciels)
Vue externe
(fonctions systme)
Vue dploiement
Vue logique dynamique
(Environnement
(Comportement)
dimplantation)
tats transitions
Activits
Dploiement
79
UML
Diagrammes de classes et
dobjets
80
Diagramme de classes
Permet de donner une vue statique du systme en

terme de :
Classes d'objets
Relations entre classes
Associations
agrgation/composition
hritage
La description du diagramme de classes est centre

sur trois concepts :
Le concept dobjets
Le concept de classes dobjets comprenant des attributs et
des oprations
Les diffrents types de relations entre classes.
81
Concept d'objet
Objet = un concept, abstraction ou une chose
autonome qui a un sens dans le contexte du
systme modliser
une personne : le client El Alami M.

un objet concret : le livre intitul Initiation
un objet abstrait : le compte bancaire n
1915233C
82
Concept d'objet
Remarque
Un objet doit :
tre autonome
Avoir une signification dans le systme
En relation avec d'autres objets
Ne pas confondre "autonomie" avec

"indpendance"!!
Exemples
Gestion de stock : Clients, Commandes, Articles,

Gestion scolaire : tudiants, Modules, Filires,
83
Concept d'attribut
Un attribut est une proprit, caractristique

dun objet. Par exemple :
un client a un nom, un prnom, une adresse, un

code client,
un compte bancaire a un numro, un solde,
Un attribut doit (gnralement) avoir une

valeur atomique
84
Concept d'attribut
La description dun attribut comporte :
Visibilit attribut:type[= valeur initiale]
O :
Visibilit :
+ (publique, public) : visible par tous

- (prive, private) : visible seulement dans la classe
# (protge, protected) : visible seulement dans la classe et
dans les sous-classes de la classe.
Nom dattribut
Type de lattribut
Valeur initiale (facultative)
85
Concept d'attribut
Le type dun attribut peut tre :
Un type de base : entier, rel,

Une expression complexe : tableaux,
enregistrements,
Une classe
Exemples dattributs :
- couleur : enum{Rouge, Vert, Bleu}

# b : boolean = vrai
- Client : Personne
86
Concept d'attribut
Lorsquun attribut peut tre driv ou calcul
partir d'autres attributs, il est prcd dun /.
Par exemple, une classe Rectangle peut
contenir les attributs suivants :
longueur : rel,
largeur : rel,
/surface : rel.
Rectangles
- Largeur
: float
- Longueur : float
- /Surface : float
= 10
87
Concept d'attribut
On distingue deux types d'attributs :
Attribut d'instance :
Chaque instance de la classe possde une valeur

particulire pour cet attribut
Notation : Visibilit attribut:type[= valeur initiale]
Attribut de classe
Toutes les instances de la classe possde la mme valeur

pour cet attribut
Notation : Visibilit attribut:type[= valeur initiale]
quivalent en C++, Java : static
88
Concept d'attribut
Window
-
taille
visibilit
taille_defaut
taille_max
:
:
:
:
Rectangle
boolean
Rectangle
Rectangle
= (100,100)
= true
+ <<Constructor>> Window ()
+
afficher ()
+
cacher ()
+
getTaille_max ()
+
getTaille_defaut ()
Attributs d'instances
Attributs de classes
:
:
:
:
void
void
Rectangle
Rectangle
Oprations d'instances
Oprations de classes
89
Concept d'opration et
mthode
Une opration est :
un service offert par la classe
une fonction ou une transformation qui peut
tre applique aux objets dune classe.
permet de dcrire le comportement dun
objet. Par exemple, Embaucher ,
Licencier et Payer sont des
oprations de la classe Socit .
90
mthode
Une mthode est
limplmentation dun service offert par la
classe (opration).
de diffrents types :
accesseurs (get...): renvoie une information sur

l'tat d'un objet (fonction)
modifieurs (set...): modifie l'tat de l'objet
(procdure)
constructeurs: initialise une nouvelle instance
91
mthode
La description dune opration comporte :
Visibilit opration([arguments:type[=valeur
initiale]]):type de rsultat
Visibilit de lopration (-, +, #)

Nom de lopration
Liste des arguments avec leurs types et
ventuellement leurs valeurs par dfaut
Le type du rsultat retourn
92
mthode
Exemples d'oprations :
Compte
- NCompte : String
- Solde
: float
- Client
: Personne
+ <<Constructor>> Compte ()
+
Deposer (float somme) : void
+
Retirer (float somme) : float
+
AvoirSolde ()
: String
93
Concept de classes dobjets
Classe = ensemble dobjets ayant les mmes

proprits (attributs) et le mme comportement
(oprations)
tous les clients sont dcrits par un nom, un prnom, et

peuvent marcher, parler,courir,
tous les comptes bancaires ont un numro, un solde,
et sur lesquels on peut dposer ou retirer l'argent, ou les
consulter
Un objet est instance dune classe, et le fait de

crer un objet d'une classe est dite instanciation.
94

Classe reprsente par un rectangle trois
parties :
Partie 1 : Nom de la classe

Partie 2 : Attributs (proprits, champs)
Partie 3 : Mthodes (fonctions, oprations)
95

Compte
- NCompte : String
- Solde
: float
# Client
: Personne
= 100
+
Deposer (float somme) : void
+
Retirer (float somme) : float
+
AvoirSolde ()
: String
96
Concept de classe d'objets

On peut ne pas visualiser les attributs et/ou les
oprations, afin de ne pas alourdir
inutilement le schma.
Nom de la classe
Nom de la classe
Nom de la classe
Attributs
Attributs
Oprations
Nom de la classe
Oprations
97
Encapsulation, visibilit et
interface
Encapsulation est le mcanisme de

regrouper les attributs et les oprations au
sein dune mme entit (classe)
Ce regroupant permet dempcher daccder
directement aux donnes par un autre moyen
que les services proposs (oprations)
Ces services offerts aux utilisateurs
dfinissent ce que lon appelle linterface de
la classe.
98
Encapsulation, visibilit et
interface
Donnes
Traitement
Partie statique, passive

Partie cache, prive
Partie dynamique, comportementale
Partie visible, publique
Interface avec lextrieur
User
99
Mthodes et classes
abstraites
Une mthode est dite abstraite si on connat

son entte, mais pas la manire dont elle
peut tre ralise
Une classe est dite abstraite lorsquelle
dfinit au moins une mthode abstraite
FormeGomtrique
{abstract}
- abs : int
- ord : int
+
+
+
+
{abstract}surface () : double
getAbs ()
: int
getOrd ()
: int
... ()
100
Classe Interface
Une interface est une classe spciale dont

toutes les mthodes sont abstraites
Une interface se note en UML avec le
strotype <<interface>> ou symbole
Forme
101
Package
Un package permet de regrouper des

classes, des interfaces et des packages.
Les classes, les interfaces et les packages
ne peuvent quun seul package dans lequel
ils sont regroups
102
Package
Un package est reprsent par un rectangle

possdant un onglet dans lequel est inscrit le
nom du package
103
Import des packages
La relation dimport permet une classe dun

package dutiliser les classes dun autre
package.
La relation est monodirectionnelle : elle
comporte un package source et un package
cible.
104
Import de packages
La relation dimport sexprime avec une

flche en pointill
Dans lexemple, la classe Afficheur a besoin
des classes du package Dessin
105
Associations
Relation existant entre une, deux ou

plusieurs classes.
Une association porte un nom (signification)
Reprsente par une ligne rectiligne
106
Associations
Remarques
une association fonctionne (gnralement)
dans les 2 sens (bidirectionnelle)
termes associs : Nom, Sens de lecture,
degr (arit), Multiplicit, Rle, navigabilit et
le qualificateur
107
Associations
Nom et sens de lecture
Dcrit la nature (signification) de lassociation

Montre la direction de lecture de lassociation
108
Associations
Rle dune association
Dcrit le rle dune classe dans une association
109
Associations
Rle dune association
Utile surtout dans deux cas :
Avion
Lorsquon a plusieurs associations entre deux

classes avec des rles diffrents
une relation rflexive : relation entre deux
instances dune mme classe
Pilote
Personne
Personne
0..4
femme
Passager
0..1
mari
110
Associations
Classe association
Une association peut avoir des attributs = classe-association
111
Associations
Classe association
Les classes association sont utiles quand il y

a des attributs qui sont pertinents
lassociation, mais aucune des classes
impliques.
Personne
Entreprise
1..*
0..1
Emploi
- Priode : int
- Salaire : float
112
Associations
degr dune association = nombre de classes participantes
Association unaire : relie 2 instances d'une classe
association binaire : relie 2 classes
association ternaire : relie 3 classes

association n-aire : relie n classes
113
Associations
Multiplicit = nombre de participations dune classe dans une
association
indique chaque extrmit dune association
sous la forme min..max
min, max = 0, 1, *
Exemple gnral
Exemple concret
114
Associations
Exemple ternaire
Pour un couple dinstances de la classe A et de la classe B,

il y a au min. r1 instances de la classe C et au max. r2 instances,
115
Associations
Notation abrge des multiplicits :
1
1..1 (exactement 1)
0..* (0 ou plusieurs)
n .. n (exactement n)
1..* 1 ou plusieurs (1 ou plus)

0..1 0 ou 1 (au plus un)
1..100 entre 1 et 100
2,4,5 2, 4 ou 5
116
Association
Navigabilit
Une association est par dfaut

bidirectionnelle.
Commandes
Clients
1..*
1
Cependant, il peut tre utile de se limiter

une seule direction association navigable
117
Association
Navigabilit (Exemple)
Spcification : on doit tre en mesure de savoir le

client qui a fait la commande et non toutes les
commandes dun client
Conception :
Commandes
Clients
1..*
1
Implmentation : la classe commande doit avoir un

champ faisant rfrence la classe client
118
Association
Navigabilit (Exercice)
Un tudiant peut avoir jusqu 5 copies
dexamens. un tudiant sont associes ses
copies dexamens, mais on ne doit pas
autoriser laccs lauteur de la copie
(notamment avant la correction des copies)
119
Qualification d'une
association
La qualification dune association permet de

restreindre la multiplicit dune association.
La qualification se reprsente par un
rectangle plac au niveau de la classe
source du qualificatif.
120
Qualification d'une
association
Exemple : une banque contient plusieurs
comptes, d'o le diagramme :
Banque
Compte
1..*
Par contre, si on connat le NCompte, il y a un

et un seul compte, on obtient alors :
Compte
Banque
NCompte
1
121
Qualification d'une
association
Exercice
Un avion est compos de plusieurs siges,
mais dans une range il y a seulement
quatre siges.
122
Agrgation
Type particulier dassociation dans laquelle :
Classe agrgat (compos), classes agrge

(composant)
Entre les deux, il existe une relation de type est
compos de
Agrgat
Agrge
123
Agrgation
Les parties (les composants) sont sparables

de Lagrgat (le tout)
La suppression dune quipe nimplique pas
la suppression des personnes qui la
composent
124
Agrgation
Titre
0..1
Un agrgat (compos) peut tre multiple.
1..1
Destinataire
1..*
E-Mail
0..*
Fichier
0..*
Ici, on exprime qu'un fichier peut tre attach un email (ou a
plusieurs, ou mme aucun) et qu'un email peut (ou non)
attacher (contenir une copie) une ou plusieurs fichiers.
1..1
0..1
Texte
125
Composition
La composition est un cas particulier dune

agrgation dans laquelle la vie des
composants (lment) est lie celle de
lagrgat (compos) : si lagrgat est dtruit
(ou dplac), ses composants le sont aussi.
Dun autre ct, et contrairement
lagrgation, une instance de composant ne
peut tre lie qua un seul agrgat.
La composition se reprsente par un losange
noir (plein).
126
Composition
la suppression dun objet agrgat entrane la suppression des

objets agrgs
127
Composition
Un document est compos de plusieurs

paragraphes, qui, son tour, est compos de
plusieurs phrases
Remarquer la propagation des oprations
(copie, suppression,)
128
Gnralisation / Spcialisation
et hritage
La gnralisation est la relation entre une

classe et une ou plusieurs de ses versions
raffines.
On appelle la classe dont on tire les
prcisions la super-classe et les autres
classes les sous-classes.
Cest une relation de type est un (is a) ou
est une sorte de .
La notation utilise pour la gnralisation est
le triangle
129
Gnralisation / Spcialisation et
hritage
gnraliser = mettre en facteur des classes super-classe
spcialiser = dcrire de nouveaux dtails
sous-classes
comparable une association de type est un, is a, kind of

une sous-classe hrite des attributs et oprations de sa super-classe
(classe mre)
130
et hritage
La classe spcialise (sous-classe)
hrite les mthodes et les attributs de la
classe gnrale (super-classe)
peut ajouter ses propres attributs et
mthodes.
peut redfinir le comportement dune
mthode.
131
et hritage
Compte
- NCompte : String
- Solde
: float
+
Dposer (float Somme) : void
+
Retirer (float Somme) : float
+
AvoirSolde ()
: String
CompteEpargne
- Taux : float
+ AvoirSolde () : String
132
et hritage
Remarques
La gnralisation et la spcialisation sont
deux faons pour voir la mme relation, topdown (spcialisation) ou bottom-up
(gnralisation).
L'hritage est limplmentation de la relation
de la gnralisation/spcialisation.
Une classe peut hriter de plusieurs classes,
on parle alors dun hritage multiple.
133
et hritage
Personnes
- Code : int
- Nom : String
+ <<Constructor>> Personnes (int Code, String Nom)
+
getNom ()
: String
+
getInf ()
: String
Spcialisation
Super classe, classe mre
Gnralisation
Etudiants
- Salaire : float
+ <<Constructor>> Etudiants (int Code, String Nom, float Salaire)
+
getInf ()
: String
+
getSalaire ()
: float
Sous classes
Classes filles
Classes drives
Employes
- Filiere : String
+ <<Constructor>> Employes (int Code, String Nom, String Filiere)
+
getInf ()
: String
+
getFiliere ()
: String
134
une classe peut hriter de plusieurs super-classes
= hritage multiple
135
polymorphisme = oprations de mme nom, polymorphisme
= comportement spcifique
136
Contraintes sur les

associations
Concepts avancs des associations

Permettent dimposer des rgles respecter
lors du passage limplmentation
Il est possible dattribuer toutes sortes de
contraintes une association
Les contraintes sont reprsentes entre
accolades et peuvent tre exprimes dans
nimporte quel langage (y compris OCL)
137
Contraintes sur les

associations
Les contraintes (prdfinies) souvent utilises :
{ordonn}
{sous ensemble}
{xor}
{addOnly}
{frozen}
138
Contraintes sur les associations

contrainte {ordonn}
Indique que les objets seront ordonns
chaque opration de cration, modification,
suppression,
Personne
1
0..*
{Ordonn}
Compte
Les comptes dune personne sont ordonns
139

contrainte {sous-ensemble}
Indique quune collection est incluse dans

une autre
Ncessite la prsence dau moins deux
relations
Ecole
Parent dlve
1..*
{sous-ensemble}
Personnes
Dlgu
1..*
Les personnes qui jouent le rle de dlgu font partie des personnes
qui jouent le rle de parents dlves
140

contrainte {xor}
Indique que parmi un groupe dassociations,
une seule est valide la fois
Batterie
1
PC Portable
1
{xor}
1
Un PC Portable est aliment soit partir

dune batterie, soit partir dun secteur
1
Secteur
141

contrainte {addOnly}
La contrainte prdfinie {addOnly} autorise
lajout de nouveaux objets, mais pas leur
suppression ni leur mise jour.
Personne
1..*
Liste
1
0..*
{addOnly}
Enfants
142

contrainte {frozen}
La contrainte prdfinie {frozen} interdit lajout,
la suppression ou la mise jour des liens
dun objet vers les objets de la classe
associe, aprs linitialisation du premier.
Personne
{frozen}
2
parent
0..*
enfant
143

Exercices
Modliser sous forme de diagrammes de
classes :
1. Le prsident dun comit doit tre membre
du comit
2. Une personne qui soumit un article un
journal ne peut pas valuer son propre
article
144

Exercices
Modliser sous forme de diagrammes de
classes :
1. Un vhicule est compos dau moins 2
roues. Le nombre de roues dun vhicule ne
peut pas varier
2. Les employs de lhtel nont pas le droit de
prendre une chambre dans le mme htel.
145

Exercices
Une personne
Est ne dans un pays (ce pays ne peut tre
modifie)
A visit un certain nombre de pays, dans un
ordre donn, et que le nombre de pays
visits ne peut que crotre
Aimerait encore visiter toute une liste de
pays, et que cette liste est ordonne.
146
Exemple de diagramme de
classes
(Distributeur Automatique de Banque : DAB)
147
Diagramme dobjets
Reprsente les objets (instances de classes)

et les liens (instances de relations) un
instant donn
Peut tre utilis pour :
Illustrer le modle de classes en montrant un

exemple qui explique le modle
Prciser certains aspects du systme
Exprimer une exception en modlisant des cas
particuliers
Etc.
148
Diagramme dobjets
Le nom dun objet est soulign
Nom : Classe
Nom
:Classe
149
Diagramme dobjets
Exemple :
Une entreprise emploie au moins deux
personnes
Une personne travaille dans au plus deux
entreprises
150
Diagramme dobjets
Exemple
Entreprise
:Entreprise
e1:Entreprise
0..2
2..*
Personne
:Personne
p1:Personne
p2:Personne
p3:Personne
p4:Personne
151
Etapes pour tablir un

diagramme
A partir dune description du systme :
1. Identifier un premier ensemble de classes candidates
2. Identifier les associations et les attributs
3. Identifier les gnralisations
4. Lister les traitements, choisir les oprations
5. Vrifier le modle obtenu
a.
Supprimer les transitivits
b.
Sassurer que le schma rpond la demande
6. Itrer jusqu satisfaction
152
UML
Diagrammes de squences
153
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
154
Obj et_1
Obj et_2
Obj et_3
M essage_1
M essage_2
Li gne de vi e de
l 'obj et
155
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
156
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
157
Diagramme de squences :
Exemple
Compte
- NCompte : String
- Solde
: float
+ <<Constructor>> Compte (int n, float s)
+
dposer (float somme) : void
+
retirer (float somme) : float
+
consulter ()
: float
Le client demande un service (dposer de largent) lobjet Compte

Le compte reoit le message et dclenche lopration de mme nom
Le compte retourne le rsultat (le solde actuel)
158
Plusieurs concepts additionnels :
Priode dactivit
Types de messages
Cration et destruction dobjets
Structures de contrles
159
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
160
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
161
Message simple
Message pour lequel on ne spcifie aucune
information denvoi ou de rception
Objet_1
Objet_2
Message_1
162
Message minut (Timeout)
Bloque lexpditeur pendant un temps donn,

en attendant la prise en compte du message
par le rcepteur
Aprs le dlai, lexpditeur est libr et peut
envoyer
Objet_2
Objet_1
Message_1 (20 secondes)
163
Message minut (Timeout) :

Exemple
La porte dun ascenseur souvre pendant un
certain dlai avant dtre referme.
Ascenseur
Porte
ouvrir (2 secondes)
fermer
164
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)
Obj et_2
Objet_1
Message_1
165
Message synchrone (appel de

procdure) : Exemple
Communication client serveur : Sockets
Client
Serveur
Sollitation
Acceptation
Requte
Rponse
166
Message asynchrone
Ninterrompt pas lexcution de lexpditeur

Lexpditeur peut mettre sans attendre la
rponse du rcepteur
Obj et_2
Obj et_1
M essage_1
167
Message rcursif
Appel aussi message rflexive

Message envoy dun objet vers lui-mme.
Objet_1
Message_1
168
Message rcursif : Exemple

Lorsque le client introduit sa carte de guichet,
ce dernier vrifie la validit de la carte avant
de demander le code daccs
Client
GAB
Introduire carte
Vrification validit
Demande code accs
169
Cration et destruction
dobjets
Un message peut crer ou dtruire un objet
Objet_1
Objet_3
Message_1
Cration dobjet
Objet_2
Message_2
Objet cr au cours de lexcution du scnario
Destruction dobjet
Objet dtruit dans un scnario

170
Traduction des messages
Envoyer un message cest demander un

service dun autre objet (sauf le cas dun
message de retour).
Les messages sont traduits par des
oprations dans la classe de lobjet ayant
reu le message
171
Traduction des messages

class Voiture{
Voiture
Public void demarrer(){}
}
class Conducteur{
private Voiture voiture;
public void conduire(){
voiture.demarrer();
}
main(String[] arg){
conducteur.conduire();
172
Structures de contrle
Le diagramme de squences peut inclure un
certain nombre de structures
Branchements (tests)
Rptitions (itrations, boucles)
173
Les test (branchements)

La condition prcde le message et elle est
dlimite par des crochets
Objet_1
Objet_2
Objet_3
[condition]: Message
174
Les test (branchements) :

Exemple
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
Prsente son badge
Vrifier droit d'accs

[OK]voyant vert
ouvrir porte
175
Les boucles (rptitions)

La boucle se note comme le test, mais la
condition est prcde dun astrisque
Objet_1
Objet_2
Objet_3
* [condition]: Message
176
Fragments
Permet de dcomposer une interaction

complexe en fragments simples
Reprsent par un rectangle dont le coin
suprieur gauche contient un pentagone
Dans le pentagone figure le type du fragment
loop : boucle
alt : alternative
ref : rfrence
177
Fragments
Tant que x>0 faire
Si x>0 alors
Si x<0 alors
178
UML
Diagrammes de collaboration
179
Diagramme de collaboration
Reprsente les interactions entre objets et

relations structurelles permettant celles-ci.
Permettent la description:
Du comportement collectif dun ensemble dobjets

Des connexions entre ces objets
Des messages changs par les objets
Interaction ralise par un groupe dobjets

qui collaborent en changeant des messages
180
Reprsentation graphique de lvolution dun

ensemble dobjets pour effectuer une action
Diffrences avec diagrammes de squence
pas daxe temporel

temps modlis par numrotation
181
lments dune interaction
Instances
liens
qui collaborent avec d'autres objets en changeant des

informations
:Classe
Objet:Classe
Reprsents par
qui sont des supports de messages
Reprsents comme des associations
messages
dclenchant les oprations

Indiqus par des flches
182
Exemple : Appel tlphonique
:Appelant
1. Dcrocher
:Ligne
2. Tonalit
3. Numrotation
4.1a. Tonalit sonnerie
6.1a. Arrt tonalit
4.1b. Sonnerie
5. Dcrocher
6.1b. Arrt sonnerie
:Appel
183
Aspect temporel
modlis par numrotation des messages
Type et Smantique des numrotations
1, 2, 3, 4 : Numrotation simple
1, 1.1, 1.2, 1.2.1, 1.2.2, 1.2.3 : Dot notation
squencement des messages

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
184
Mmes types contraintes que pour les

diagrammes de squence
Itration : *[condition]
Conditions : [condition]
Exemple : rservation darticles

1. commander(n, item)
:Client
:Vendeur
4. livrer(n, item)
2. vrifier(n, item)
:Stock
3. [disponible]rserver(n, item)
185
Les objets cres ou dtruits au cours dune

interaction peuvent respectivement porter
les contraintes :
{Nouveau}
{Dtruit}
<<{Dtruit}>>
<<{Nouveau}>>
Objet_1
Objet_2
186
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
187
Exemple : Ascenseur
(Squence)
188
Exemple : Ascenseur
(Collaboration)
189
UML
Diagramme tat-transition
190
Le diagramme tat-transition :
Fait partie des modles dynamiques
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
191
Le diagramme tat-transition manipule
plusieurs concepts :
tat
Transition
vnement
Garde

192
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
coins arrondis
Fentre
Affiche
- ID
: int
- Visible : boolean
= True
193
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
194
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
195
Exemple
Soit le diagramme dtats/transitions de lobjet Fentre
196
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
Etat1
Evnement [Condition]
Etat2
197
Formalisme et exemple
Etat1
Employ recrut
Evnement [Condition]
Prise fonction [Date embauche chue]
Etat2
Employ en activit
198
Actions et activits
Un objet qui reoit un vnement dclenche

une ou plusieurs oprations
On distingue deux types d'oprations :
Action : associe un tat ou une transition

Activit : associe un tat
199
Activit
Opration d'une certaine dure, qui est

excute tant que lobjet se trouve dans ltat
Associe un tat d'un objet
Reprsente dans l'tat prcde par la
notation "do/"
200
Action
Opration instantane non interrompue

Peut tre associe aussi bien l'tat d'un
objet qu'a une transition
Elle peut intervenir soit
En entre de l'tat (prfixe : "entry/")

En sortie de l'tat (prfixe : "exit/")
En rponse un vnement (prfixe :"evt/")
Au cours d'une transition (prfixe : "evt/")
201
Formalisme et exemple
Etat 2
Etat_1
entry / Action_1
do / Action_2
Evnement() / Action_3
exit / Action_4
Evnement [Cond]/ Action
entry / Act1
do / Act2
Evnement() / Act3
exit / Act4
Embauch
entry / Signer contrat
do / Assurer fonction
Arrive proposition() / Rponde la proposition
Mutation() / Changer d'affectation
exit / Rompre contrat de travail
202
Exercice
Modliser ltat de saisie dun mot de passe :
Au dbut, la zone de saisie est masque
chaque saisie dun caractre, il stock
La touche F1 permet dafficher laide
Le bouton dannuler permet de fermer la
fentre
la fin de la saisie (validation) le mot de
passe est test (valide ou invalide)
203
tat initial et tats finaux

Un diagramme tat-transition
Dbute toujours par un tat initial

Se termine par un ou plusieurs tats finaux (sauf
o le diagramme reprsente une boucle)
Etat_1
Etat_2
204
Exemple (Feu de
signalisation)
Feu
- ID
: int
- Couleur : {Vert, Orange, Rouge}
Orange
Vert
Rouge
205
Point de dcision
Permettent de reprsenter des partages de

transitions ou des alternatives pour le
franchissement dune transition
On utilise deux mcanismes :
Points de jonction (petit cercle plein) : pour

partager des segments de transition
Points de choix (losange) : pour choisir une ou
une autre transition
206
Point de jonction
207
Points de choix
208
tat composite
Un tat composite (#tat simple) est

dcompos en deux ou plusieurs sous tats
Cette dcomposition est rcursive
Un tat composite est reprsent comme un
tat simple, sauf que les sous tats sont
contenus dans le compartiment infrieur.
209
Exemple
210
Historique
On reprsente le pseudo tat historique par

un H cercl
Une transition ayant pour cible ltat
historique est quivalente une transition
ayant pour cible le dernier tat visit dans la
rgion contenant le H
H* (historique profond) est un tat valable
pour tous les niveaux
211
Concurrences
Pour reprsenter la concurrences dans un

diagramme dtats/transitions, on utilise :
tats concurrents
Transitions concurrentes
212
tats concurrents
tat composite pour reprsenter lexcution

de plusieurs automates sexcutant
indpendamment
On utilise un sparateur en pointills
Lobjet peut tre simultanment dans
plusieurs tats concurrents
213
tats concurrents
214
Deux transitions particulires : fork et join

La transition fork correspond la cration de
deux tats concurrents
La transition join permet de supprimer la
concurrences (barre de synchronisation)
Pour pouvoir franchir la barre de
synchronisation, toutes les tches
concurrentes doivent tre acheves
215
216
UML
Diagramme d'activits
217
Introduction
Variante des diagrammes d'tat-transition

Permet de dcrire le flot de contrle entre les
oprations :
Choix
Squences
Itrations
Paralllisme
Au niveau macroscopique : dcrit les

enchanements des oprations
Au niveau microscopique : dcrit l'algorithme d'une
action du diagramme d'tats
218
Concepts de base
Plusieurs concepts sont manipuls :
tat
Activit
Transition (squentielle, alternatives ou
conditionnelle)
Synchronisation (disjonction et conjonctions
dactivits)
Itration
Swimlanes
219
Comportement conditionnel
Appel aussi le branchement

Symbolise une transition entrante garde par
une condition et plusieurs transitions
sortantes mutuellement exclusives
220
Comportement conditionnel :
Exemple
Demander l'addition
[Prix<=Somme disponible]
Rgler la note
[Else]
Faire la vaisselle
221
Synchronisation
Fusion (conjonction) : plusieurs transitions

entrantes et une seule sortante
Comportement parallle :
La barre de synchronisation permet d'ouvrir et de

fermer les branches parallles au sein d'un flot
d'excution
Les transitions partantes d'une barre ont lieu en
mme temps
La barre n'est franchie qu'aprs ralisation de
toutes les transitions qui s'y rattachent
222
Synchronisation : Exemple
Dserrer le frein main
Barre de synchronisation
Fusion (conjonction)
Appuyer sur l'embrayage
Enclencher la 1re vitesse
Comportement parallle
Disjonction
Relcher l'embrayage
223
Itration : Exemple
Recevoir commande
Vri fier arti cl e
Commander arti cl e
[s'i l reste des articl es]
[pl us d'arti cl e]
224
Swimlanes
Extension des diagrammes d'activits

permettant de reprsenter l'organisation.
Reprsente le lieu, le responsable des
activits.
225
Rsum notation
226
Exemple rcapitulatif
227
Exemple rcapitulatif
Rcepti on commande
Annul er commande
Vri fi er carte crdi t
Vri fi er di sponi bi l i t produi t
[El se]
[El se]
[Di sponi bl e]
[Val i de]
Prparer commande
Expdi er commande
Dbi ter carte crdi t
Poster facture
228
Exercice 1
Reprsenter les tats suivants sous forme de
diagramme d'activit :
Vrification commande
Enregistrement commande
Rejet commande
Informer erreur au client
229
Exercice 1 : solution
Vrifier commande
Valide
[oui]
Enregistrement commande
[non]
Rejet commande
Informer erreur au client
230
Exercice 2
Dans le domaine de gestion de stock, on
considre les tats suivants indiquant le flot
de contrle de rception d'une livraison :
Rception livraison, contrle qualit, contrle
quantit et enregistrement livraison.
Proposez un diagramme d'activit reprsentant
ce flot d'information
231
232
Exercice 3
Construire un diagramme dactivit pour
modliser le processus de commander dun
produit. Le processus concerne les acteurs
suivants:
Comptable : enregistrement commande,
envoie la facture et enregistrement paiement
du client
Client : paiement de la facture
233
234
Exercice 4
Construire un diagramme dactivit pour modliser le
processus de commander dun produit. Le
processus concerne les acteurs suivants:
Client: qui commande un produit et qui paie la
facture
Caisse: qui encaisse largent du client
Vente: qui soccupe de traiter et de facturer la
commande du client
Entrept: qui est responsable de sortir les articles
et dexpdier la commande.
235
236
UML
Diagrammes de Composants et de
Dploiement
237
Diag de Composants/
Dploiement
Permettent de modliser les aspects physiques

dun systme orient-objet
Diagramme de Composants : se focalise sur
lorganisation et les dpendances entre un
ensemble de composants
Diagrammes de Dploiement : se focalise
sur la configuration en temps d'excution des
nuds de traitement et de composants qui
sont actifs
238
Diagramme de composants
Dans le monde de btiment, tout ce qui est

propos par larchitecte (plan) constitue une
vue logique : visualiser, spcifier, documenter
Lors de la construction, on utilise des
composants physiques du monde rel : murs,
fentres, portes,
239
De mme, tout ce que nous avons vu jusqu

prsent constitue le modle logique :
visualiser, spcifier et documenter la
structure et le comportement des objets
La construction va sappuyer sur les
composants du monde rel de lordinateur :
fichiers, tables, librairies,
240
Permet de dcrire l'architecture physique et statique d'une

application en terme de composants :
code source,
bibliothques,
excutables,
Il montre la mise en oeuvre physique des modles de la vue
logique dans l'environnement de dveloppement
Permet de spcifier :
Composants
Interfaces
Relations (dpendance, gnralisation, association, ralisation).
241
Composant
Un composant est une partie physique et

remplaable dun systme qui sait faire et
fournit la ralisation dun ensemble
dinterface
Les composants peuvent tre organiss en
paquetages
242
Composant
Nom du composant
Component1
Nom du composant :
Permet de distinguer un composant des autres composants
Il peut tre un nom simple ou un nom compos qui indique le paquetage

auquel appartient le composant
Strotypes : spcifient un composant qui dsigne:
executable : un programme pouvant sexcuter sur un nud
library : une bibliothque statique ou dynamique
table : une table de base de donnes
file : un fichier contenant du code source ou des donnes
document : un document
243
Concepts
Interface :
Est une collection doprations utilises pour

spcifier les services dune classe ou dun
composant
Relations avec les interfaces
Ralisation :
Dfinie entre linterface et le composant qui fournit les

services pour les autres composants
Cette interface est appele interface exporte
Dpendance :
Dfinie entre linterface et le composant qui utilise les

services fournis par un autre composant
Cette interface est appele interface importe .
244
Interface
Component1
Component2
Interface1
dpendance
ralisation
Interface
Interface1
Component1
Attributs
Component2
Oprations
245
Relations entre les

composants
Dpendance :
Cela signifie quun des lments dun composant

a besoin des services que les lment de lautre
composant ralisent
Notation UML
Component1
Component2
246
Relations entre les

composants
Contenance :
Un composant peut tre contenu dans un autre

composant
Notation UML
Component 1
Component 2
247
Systme Vente
(diagramme de classes)
Ligne de vente
enregistre
SpcificationProduit
-Description : string
-Prix : real
+getDescritption(In Item:undefined):string
+getPrix(In Item:undefined):real
-quantit : integer
+setQuantit(In quantit:integer)
1..*
contenu dans
Contient
1
1..*
Vente
-Date : undefined
-Heure : undefined
+initierPaiement(In montant:real)
1
est paye par
Magasin
+nom : string
+adresse : string
utilise
1
Catalogue
1
+ObtenirSpec(In Item:undefined):SpcificationProduit
Paiement
-montant : real
-mode : string
248
(Exemple)
Systme Vente
<<executable>>
IHM_Caisier
<<interface>>
InterfaceProduit
InterfacePaiement
<<library>>
JavaSwing
<<executable>>
Enregistrement-Produits
<<executable>>
GestionPaiement
InterfaceAutorisation
InterfaceImpts
<<executable>>
Gestion d'autorisation
Gestion d'Impts
InterfaceCatalogue
<<utility>>
CatalogueProduits
249
Diagramme de dploiement
Montre la configuration des nuds de excution et

des composants quy rsident
Montre les relations physiques entre les
composants logiciels et matriels dun systme
Permet de spcifier
Nuds
Relations : (dpendance, associations)
250
Nud
Est un lment physique qui existe pendant

lexcution et reprsente une ressource informatique
dans la plupart de cas il sagit dun lment matriel
En gnral un nud possde sa propre mmoire et
une capacit de traitement
Lensemble de composants qui est associ aux
nuds est appel unit de rpartition
Les nuds prennent en charge lexcution des
composants.
251
Nud
Nom du nud
Nom du nud :
Nud 1
Permet de distinguer un nud des autres nuds

Le nom peut tre compos du nom de paquetage qui contient
le nud
Strotypes : un nud peut possder un strotype qui permet de

le distinguer des autres types de ressources (permettant de
spcifier le types de ressources)
CPU : une unit de calcul

memory : une unit de stockage
device : un dispositif tel quun capteur
252
Relations entre nuds et

composants
Dpendance :
Montre la capacit dun nud de supporter un composant
Peut tre galement exprime entre les composants rsidant dans un mme nud
Notation UML
Nud 1
Client
IHM
Composant1
Composant 2
253
Relations entre deux nuds
Association
Indiquent une voie physique entre deux nuds

Exemple:
Une connexion Ethernet

Un bus de communication
TCP / IP
1
1..*
Notation UML
Nud 1
Nud 2
254
(Exemple)
Systme Vente
Serveur de Calcul
InterfaceAutorisation
<<executable>>
<<executable>>
Enregistrement-Produits
InterfaceImpts
<<executable>>
Gestion d'Impts
GestionPaiement
Gestion d'autorisation
InterfacePaiement
1
1
LAN
LAN
Serveur de Donnes
Ventes
<<executable>>
InterfaceCatalogue
1..*
IHM_Caisier
<<library>>
JavaSwing
<<utility>>
CatalogueProduits
255
Serveur
Base <<utility>>
de Donnes
Base de
Donnes
Ordonnanceur
interface
TCP / IP
1
1..*
Client
IHM
256
257
Correspondance UML
et Java
258
Traduction dune classe
La classe est le concept fondamental de

toute technologie objet.
Le mot-cl correspondant existe bien sr
galement en Java.
De plus, chaque classe UML devient par
dfaut un fichier .java.
259

class Personne{
Personne
}
260
Une classe abstraite est simplement une

classe qui ne sinstancie pas directement
mais qui reprsente une pure abstraction afin
de factoriser des proprits.
Elle se note avec {abstract} en UML et se
traduit par le mot-cl abstract en Java.
261

abstract class Personne{
Personne
{abstract}
.
.
.
262
Une interface est une classe spciale dont

toutes les mthodes sont abstraites
Une interface se note en UML avec le
symbole
En java, elle traduite par le mot cl interface
263

interface Forme {
Forme
}
264
Traduction des attributs
Les attributs UML deviennent simplement des

attributs en Java
Leur type est soit un type primitif (int, etc.),
soit une classe.
La visibilit des attributs est montre
graphiquement en UML en les faisant
prcder par + pour public, # pour protg
(protected), - pour priv (private).
Les attributs de classe en UML deviennent
des membres statiques en Java (static).
265
Traduction des oprations
Les oprations UML deviennent trs

directement des mthodes en Java.
Leur visibilit est dfinie graphiquement avec
les mmes conventions que les attributs.
Les oprations de classe deviennent des
mthodes statiques (static).
Les oprations abstraites (en italiques) se
traduisent par le mot-cl abstract en Java.
266
Traduction des oprations

class Personne {
private int code;
private String nom;
private static int nombre;
public Personne() {
}
public static int getNombre(){
}
public String getInf(){
}
}
267
Traduction des relations

Les relations UML entre concepts statiques
sont trs riches. On peut distinguer les
relations de :
Gnralisation (hritage)
Ralisation
Association, avec ses variantes : agrgation
et composition.
268

(La gnralisation)
Le concept UML de gnralisation se traduit

directement par le mcanisme de lhritage
dans les langages objets.
Java, contrairement C++ interdit lhritage
multiple entre classes.
269

(La gnralisation)
Class Personne{
Personne
Employe
}
Class Employe extends
Personne{
}
270

(La ralisation )
Une classe UML peut implmenter plusieurs

interfaces.
Contrairement C++, le langage Java
propose directement ce mcanisme.
271

(Ralisation)
interface A{
A
}
interface B{
}
class C implements A, B {
}
272

(Les associations)
Les associations navigables UML se

traduisent par du code Java qui dpend de :
la multiplicit de lextrmit concerne (pointe

par la flche)
mais aussi de lexistence ou pas dune contrainte
{ordered} ou dun qualificatif.
Nous allons voir tout cela du plus simple au

plus complexe :
Une association navigable avec une multiplicit 1

Une association navigable avec une multiplicit *
273

(Les associations)
Une association navigable avec une

multiplicit 1 se traduit par une variable
dinstance de type rfrence vers une
instance de classe.
Une multiplicit * va se traduire par un
attribut de type collection de rfrences
dobjets au lieu dune simple rfrence sur un
objet.
274

(Les associations)
La difficult consiste choisir la bonne collection
parmi les trs nombreuses classes de base que
propose Java.
Bien quil soit possible de crer des tableaux
dobjets, ce nest pas forcment la bonne solution.
En pratique, on prfre plutt recourir des
collections, parmi lesquelles les plus utilises sont :
ArrayList, SortedList et HashTable.
Utilisez ArrayList si vous devez respecter un ordre et

rcuprer les objets partir dun indice entier
Utilisez HashTable si vous souhaitez rcuprer les objets
partir dune cl arbitraire.
275

(Les associations)
276

(Les associations)
Une association bidirectionnelle se traduit

simplement par une paire de rfrences, une
dans chaque classe implique dans
lassociation.
Les noms des rles aux extrmits dune
association servent nommer les variables
de type rfrence.
277

(Les associations)
278

(Les associations)
279

(La classe association)
Elle possde tout la fois les caractristiques

dune association et dune classe et peut
donc porter des attributs qui se valorisent
pour chaque lien.
Ce concept UML avanc nexiste pas dans
les langages de programmation objet, il faut
donc le traduire en le transformant en classe
normale, et en ajoutant des variables de type
rfrence.
280

(La classe association)
281
UML
De UML vers le modle relationnel
282
De UML vers le modle

relationnel
Cette partie traite le passage de la

conception faite par UML vers le modle
relationnel
La traduction concerne
Classes, instances, attributs

Relations entres classes :
Associations,
Agrgation,
Composition,
Gnralisation spcialisation
r
283
Classe en Relationnel
Dans le cas gnral une classe est traduite

par une table
Chaque objet est conserv dans une ligne de
la table
Un champ jouant le rle de cl primaire est
ajout mme s'il n'existait pas dans la classe
284
Traduction d'une classe
En Relationnel
Compte(NCompte, Solde)
En SQL
Create table Compte(
Compte
- NCompte : int
- Solde
: float
+ <<Constructor>> Compte (int NCompte, float Solde)
+
deposer (float Solde)
: void
+
retirer (float Solde)
: float
+
avoirSolde ()
: String
NCompte smallint,
Solde decimal,
Primary key PK_Compte (NCompte)
285
Gnralisation/spcialisation en
Relationnel
Plusieurs mthodes de traduction en
Relationnel :
Reprsenter toutes les classes dune
arborescence dhritage par une seule table
relationnelle
Reprsenter chaque classe par une table
286
Relationnel
La solution la plus simple est de modliser

toute une hirarchie de classes dans une
mme table
Chaque classe ajoutant ses propres attributs
comme de nouveaux champs.
Il nous suffit alors dajouter un champ
contenant le type de linstance pour pouvoir
charger les champs correspondants.
287
Relationnel
288
Associations en Relationnel
(Association un--un)
Deux solutions sont possibles :
une cl trangre dans chacune des tables
associes
la fusion des deux tables dans une seule
289
1re Solution
Pays(IdPays, NomP,#IdCapitale)
Capitales(IdCapitale, NomC, #IdPays)
2ime Solution
Pays(IdPays, NomP, NomC)
290
1re Solution
create table Pays(IdPays integer primary key,
IdCapitale integer foreign key references capitales (IdCapitale))
et
create table Capitales(IdCapitale integer primary key,
,
IdPays integer foreign key refernces pays(IdPays))
2ime Solution
Pays(IdPays integer primary key,
NomP varchar(20),
NomC varchar(20))
291
(Association un--plusieurs)
Une seule solution est possible :
migration de la cl du ct de 1 vers la table
du ct de plusieurs
La cl migre jouera le rle de cl trangre
292
(Association un--plusieurs)
En Relationnel
Dept(IdDept, Nomdept)
Emp(IdEmp, NomEmp, #IdDept)
En SQL
Create table dept()

Create table emp(IdEmp integer primary key,
NomEmp varchar(20),
IdDept integer foreign key references Dept(IdDept)
)
r
293
(Association plusieurs-
plusieurs)
Lassociation est traduite par une table dont
la cl primaire est la concatnation des cls

primaires des tables associes
La table rsultante aura :
Une seule cl primaire

Deux cls trangres
294
Traduction des associations en

Relationnel
(Association
plusieurs-En Relationnel
plusieurs)
Articles(Ref, Des, PU)
Commandes(NBC, DateC, Client)

Dtails(#NBC, #Ref, Qt)
295
Traduction des associations en

Relationnel
(Association
plusieurs-En
SQL
1.
create table Article(Ref integer primary key, )
plusieurs)
2.
3.
create table Cde(NBC integer primary key, )

create table Detail(NBC integer, Ref integer,,
constraint PK primary key(NBC, Ref),

constraint FK1 foreign key(NBC) references cdes(NBC),
Constraint FK1 foreign key(NBC) references cdes(NBC))
296
OCL
297
Contraintes
Une contrainte est une condition ou une

restriction smantique exprime sous forme
dinstructions dans un langage textuel qui
peut tre naturel ou formel
Elle doit tre applique lors de
limplmentation
Reprsente sous forme dune chane place
entre accolades({})
298
Contraintes
Nous avons vu comment exprimer certaines

contraintes avec UML
{ordered}
{subset}
{frozen}
{xor}
299
Contraintes Exemple
Dans cet exemple, on exprime le fait quun

solde doit rester toujours positif (utilisation
dun langage formel).
300
Contraintes Exemple
Dans cet exemple, on exprime un contrainte

avec un langage textuel non formel
301
Introduction
OCL est un langage de contraintes associ

UML
Il peut tre utilis pour contraindre nimporte
quel diagramme
302
Contexte
Une contrainte est toujours associe un lment

du modle
Cet lment constitue le contexte de la contrainte
Deux manires pour exprimer le contexte dune
contrainte :
En crivant la contrainte entre {} dans une note (voir

exemple prcdent)
En utilisant le mot cl context dans un document
accompagnant le modle
303
Contexte
Syntaxe
context <lment>
O : <lment> : peut tre une classe, un attribut,
une opration, etc.
Pour faire rfrence un lment dune

classe, il faut utiliser les ::
304
Contexte
Le contexte de la classe Compte

context Compte
Le contexte de lopration getSolde() de la
classe Compte
context Compte::getSolde():Real
Le contexte de lopration deposer() de la
classe Compte
context Compte::deposer(somme:Real)
305
Invariants
Un invariant exprime une contraintes sur un

objet ou un groupe dobjets qui doit tre
respecte en permanence
Syntaxe :
inv : <expression_logique>
Lexpression logique doit tre toujours vraie
306
Invariants
Exemple :
Le solde dun compte doit tre toujours positif
context Compte
inv : solde>0
307
Prconditions et
postconditions
Une prcondition permet de spcifier une

condition qui doit tre vrifie avant lappel
dune opration.
Une postcondition permet de spcifier une
condition qui doit tre vrifie aprs lappel
dune opration.
308
Prconditions et
postconditions
Dans lexpression de la contrainte de la

postcondition, deux lments particuliers sont
utiliss :
result : la valeur retourne par lopration

<attribut>@pre : la valeur de lattribut avant
lappel de lopration
309
Prconditions et
postconditions
Syntaxe de la prcondition
pre : <expression logique>
Syntaxe de la postcondition
post : <expression logique>
310
Prconditions et
postconditions
Exemples :
context Compte::debiter(somme : Real)
pre : somme>0
post : solde=solde@pre-somme
post : result=solde
311
Rsultat dune opration

Lexpression de contrainte body permet
dfinir directement le rsultat dune
opration
Syntaxe :
body : <requte>
<requte> : expression qui retourne le rsultat
dont le type est compatible avec le type de
retour de lopration
312
Rsultat dune opration

Exemple
La mthode getSolde() de la classe Compte
retourne le solde actuel
body : solde
313
Dfinition des attributs et de

mthodes
Motivation :
une sous expression peut tre utilise plusieurs fois dans

une expression
Deux expressions de contraintes :
let : permet de dclarer et dinitialiser un attribut qui peut

tre utilis dans lexpression qui suit le mot cl in
def : fait la mme chose que let.
314

mthodes
Syntaxes :
let <dclaration>=<requte> in <expression>
Lattribut dclar recevra le rsultat de la

<requte> dans toute l<expression>
def : <dclaration>=<requte>
315

mthodes
1.
2.
3.
Exemples
context Personne
inv : let argent=compte.solde->sum() in
age>=18 implies argent>0
context Personne
def : argent : Real = compte.solde>sum()
context Personne
inv : age>=18 implies argent>0
316
Initialisation et volution des

attributs
Le type de contrainte init permet de prciser

la valeur initiale dun attribut ou dune
terminaison dassociation
La valeur dun attribut driv est dfinie par la
contrainte derive.
Syntaxes :
init : <requte>
derive : <requte>
317

attributs
Exemple
Quand on cre une personne, la valeur initiale
de lattribut mari est faux, et la personne ne
possde pas demployeur.
context Personne::mari:Boolean
init : false
context Personne::employeur:Set(Socit)
init : set{}
318

attributs
Exemple
Lge dune personne est la diffrence entre
la date courante et la date de naissance de la
personne.
context Personne::age:Integer
derive : Date::current() date_de_naissance
319
Types et opration OCL

Le langage OCL possde un certain nombre de
types prdfinis et doprations prdfinies
sur ces types :
Boolean
Integer
Real
String
320

Type
oprateurs
Boolean And, or, xor, not, implies, ifthenelseendif

Integer
+,-, *, /, abs(),
Real
+,-, *, /, abs(), floor(),
String
Concat(), size(), substring(),
321

a
a and b
a or b
a xor b
a implies b
322

not
If <exp_log0>
Then <exp_log1>
Else <exp_log2>
Endif
323
Collections
Le langage OCL manipule plusieurs

collections :
Set : collection non ordonne dlments uniques

orderedSet : collection ordonne dlments
uniques
Bag : collection non ordonne dlments
Sequence : collection ordonne dlments
324
Collections
Collection
lments ordonnes lments uniques
Set
Non
Oui
OrderedSet Oui
Oui
Bag
Non
Non
Sequence
Oui
Non
325
Quelques oprations sur les

collections
- Opration
de base La syntaxe : collection->operation()
size() : nombre dlments

count() : nombre doccurrences
sum() : somme des lments
isEmpty() : est vide
notEmpty() : non vide
includes(el) : appartenance
excludes(el) : non appartenance
includesAll(col) : inclusion
excludesAll(col) : exclusion
326
Quelques oprations sur les

collections
select(cond) : retient
- Filtrage
- les lments qui vrifient la condition
reject(cond) : limine les lments qui vrifient la condition
any(cond) : retourne lun des lments qui vrifie la

condition
forAll(cond) : true si tous les lments vrifient la

condition
exists(cond) : true si au moins un lment vrifie la

condition
isUnique(exp) : true si une et une seule valeur de la

collection qui vrifie la condition
327
Opration ensembliste
- Set ou OrederedSet
union(ens) : union
- : diffrence (ens1 ens2)
including(el) : ajoute un lment
excluding(el) : retire un lment
328
Accs aux donnes de lobjet

courant
Pour faire rfrence une donne (attribut
ou opration) dun objet dsign par le
contexte :
1.
2.
Utiliser le nom de llment

Faire prcder le nom de llment du mot cl
self
329
Accs aux donnes de lobjet

courant
Exemple
Dans le contexte de la classe Compte :
Context Compte
Inv : solde > 0
Context Compte::debiter(somme : Real)

Pre : somme > 0
Post : self.solde = self.solde@pre - somme
330
Navigation travers une

association
Pour faire rfrence un objet (ou un groupe

dobjets) associ via une association, On
utilise :
Le nom de la classe associe en minuscule

Le nom du rle ct de la classe associe
331

association
Dans le contexte de la classe Personne, on

fait rfrence la classe socit avec lune
des deux mthodes :
employeur
socit
De mme pour accder ladresse de la

socit :
employeur.adresse
socit.adresse
332

association
Lutilisation du rle est indispensable si :
1.
2.
Il existe plusieurs associations entre lobjet

dsign par le contexte et lobjet auquel on
dsire accder
Lassociation est rflexive
333

association
Le type du rsultat dpend de :
la multiplicit de lobjet rfrenc

type de lobjet rfrence proprement dit.
Si lobjet rfrenc est T, alors le rsultat est

de type :
T, si la multiplicit est 0..1 ou 1..1

Set(T), si la multiplicit est *
OrderedSet(T), si la multiplicit est * avec
{ordered}
334

association
Exemple : Type du rsultat
335

association qualifie
Dans une association qualifie, on utilise les
valeurs (les instances) des qualificatifs entre
crochets ([])
context Banque
inv : self.compte[8900].solde>0
336
Navigation vers une classe

association
Dans le contexte de Socit, self.poste.salaire:
salaire de tous les employs

Dans le contexte de Personne,
self.mariage[epouse].date : dates de mariages
des femmes
337
Navigation depuis une classe

association
context Poste
inv : self.employe.age>21
(ou aussi, self.personne.age>21)
338
Accs une mthode

redfinie
Une sous classe peut redfinir une mthode

de sa classe mre
Laccs la mthode de la classe parente est
toujours possible et se fait par : oclAsType()
339
Accs une mthode

redfinie
Dans le contexte de B :
Self.f() : accs f() de B
Self.oclAsType(f()) : accs la
mthode de A
340

Cours UML Kounaidi

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Cours UML Kounaidi

Hochgeladen von

Copyright:

Verfügbare Formate

UML : Unified Modeling Language

Cycle de vie dun logiciel

Processus (ensemble dactivits) ncessaire

Cycle de vie dun logiciel

tapes ncessaires la ralisation dun logiciel:

Cycle de vie dun logiciel

Cycle de vie dun logiciel

Elle a pour but de dgager le problme

Cycle de vie dun logiciel

Premire tape du cycle de vie dun logiciel

tudier le march pour dterminer sil

Cycle de vie dun logiciel

Permet de dfinir ce que doit faire le logiciel et

Cycle de vie dun logiciel

La spcification gnrale consiste identifier :

Cycle de vie dun logiciel

Spcification fonctionnelles est la description des

Cycle de vie dun logiciel

Spcification technique :(tude de lexistant)

Cycle de vie dun logiciel

Appele aussi Planification et gestion de projet

dcouper le projet en tches

Cycle de vie dun logiciel

Cycle de vie dun logiciel

Permet de fournir une description fonctionnelle

Cycle de vie dun logiciel

Appele aussi : Conception architecturale

Estudiantine (tudiants, notes, prof, filires, )

Cycle de vie dun logiciel

Produire une description externe de chacune

Cycle de vie dun logiciel

Des programmes seront labors afin de

Cycle de vie dun logiciel

On distingue plusieurs types de tests :

Test unitaire: tester les parties du logiciel par les dveloppeurs

Cycle de vie dun logiciel

Fournir au client une solution logiciel qui

Cycle de vie dun logiciel

Mettre jour et amliorer le logiciel

Cycle de vie dun logiciel

Cahier des charges : description des fonctionnalits

Modle Objet : Classes et objets

Cycle de vie dun logiciel

Calendrier du projet: indique les tches, les

Cycle de vie dun logiciel

Code source: code complet du produit fini

1960 fin 1970

1980 dbut 1990 : premires gnration

mthode OOD de Grady Booch (1991)

OMT + OOD Unified Method (oct 1995)

UML 1.0 (jan 1997)

Quest ce que UML ?

syntaxe : notations graphiques consistant

Quest ce que UML ?

UML est caractris par :

INDPENDANT du langage de programmation

Support par plusieurs outils (AGL) : Objecteering, Open

Quest ce que UML ?

diagramme de classes: reprsente la partie statique du systme en

Modlisation du comportement: (comment le systme

diagramme de cas d'utilisation: destin reprsenter les

Diagramme des cas

Dcrit, sous forme dactions et de ractions,