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

Cycle de vie dun logiciel

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.

Cycle de vie dun logiciel

4

tapes ncessaires la ralisation dun logiciel:

Analyse
Conception
Codage (Implmentation)
Tests
Livraison
Maintenance

Cycle de vie dun logiciel

Modle en Cascade (WaterFall)
5

Analyse
Conception

Implmentation

Tests

Maintenance

Cycle de vie dun logiciel

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)

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

Spcification des besoins
9

La spcification gnrale consiste identifier :

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

Cycle de vie dun logiciel

Spcification des besoins
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

Cycle de vie dun logiciel

Spcification des besoins
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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Cycle de vie dun logiciel

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

Relation d'inclusion

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

Relation d'inclusion
Les cas d'utilisation "Dposer de
l'argent", "Retirer de l'argent",
"Effectuer des virements" et "Consulter
solde" incorporent de faon explicite le
cas d'utilisation "S'authentifier", un
endroit spcifi dans leurs
enchanements.

Retirer de l'argent

<<include>>
Dposer de l'argent
<<include>>
S'authentifier
<<include>>
Effectuer des virements
<<include>>

Consulter solde

53

Relation d'inclusion
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

Relation d'inclusion
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

Relation d'inclusion
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

Relation d'extension

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

Relation d'extension

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

Relation d'extension
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

Relation d'hritage : Exemple

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

Relation d'hritage : Exemple

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

Description des cas dutilisation

(description textuelle)
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

Description des cas dutilisation

(description textuelle)
Scnarios

1.

Scnario alternatif (exception)

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

73

Description des cas dutilisation

(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

Concept d'opration et
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

Concept d'opration et
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

Concept d'opration et
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

Concept de classes dobjets

Classe reprsente par un rectangle trois
parties :

Partie 1 : Nom de la classe

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

95

Concept de classes dobjets

Compte
- NCompte : String
- Solde
: float
# Client
: Personne

= 100

+ <<Constructor>> Compte ()
+
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

Gnralisation / Spcialisation
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

Gnralisation / Spcialisation
et hritage
Compte
- NCompte : String
- Solde
: float
+ <<Constructor>> Compte ()
+
Dposer (float Somme) : void
+
Retirer (float Somme) : float
+
AvoirSolde ()
: String

CompteEpargne
- Taux : float
+ AvoirSolde () : String

132

Gnralisation / Spcialisation
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

Gnralisation / Spcialisation
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

Gnralisation / Spcialisation
une classe peut hriter de plusieurs super-classes
= hritage multiple

135

Gnralisation / Spcialisation
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

Contraintes sur les associations

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

Contraintes sur les associations

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

Contraintes sur les associations

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

Contraintes sur les associations

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

Contraintes sur les associations

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

Contraintes sur les associations

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

Contraintes sur les associations

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

Diagramme de squences
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

Diagramme de squences

Un objet est reprsent par un rectangle et

une ligne verticale (ligne de vie de lobjet)
Les objets communiquent en changeant des
messages reprsents par des flches
orientes de lmetteur au rcepteur
Lordonnancement verticale des messages
indique la chronologie

156

Diagramme de squences

Un message reu par un objet dclenche

lexcution dun opration
Un message envoy par objet correspond :

Demander un service dun autre objet

Renvoyer le rsultat dun opration

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

Diagramme de squences
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

Diagrammes de collaboration

Reprsentation graphique de lvolution dun

ensemble dobjets pour effectuer une action
Diffrences avec diagrammes de squence

pas daxe temporel

temps modlis par numrotation

181

Diagrammes de collaboration
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

Diagrammes de collaboration

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

Diagrammes de collaboration

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

Diagrammes de collaboration

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

Diagrammes de collaboration

Les objets cres ou dtruits au cours dune

interaction peuvent respectivement porter
les contraintes :
{Nouveau}
{Dtruit}
<<{Dtruit}>>

<<{Nouveau}>>

Objet_1

Objet_2

186

Diagrammes de collaboration
Conclusion
Reprsentation spatiale

Aspect temporel plus difficile suivre que pour les

Diagramme de squence
Dure dexcution dune contrainte difficile valuer

Diagramme niveau instance

Limite : taille des diagrammes

Plus dinstances peuvent tre reprsentes sur un mme

diagramme que pour les diagrammes de squence

187

Exemple : Ascenseur
(Squence)

188

Exemple : Ascenseur
(Collaboration)

189

UML

Diagramme tat-transition

190

Diagramme tat-transition
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

Diagramme tat-transition
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

Transitions concurrentes

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

Transitions concurrentes

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

Exercice 2 : solution

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

Exercice 3 : solution

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

Exercice 4 : solution

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

Diagramme de composants

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

Diagramme de composants

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

Diagramme de composants
(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

Diagramme de dploiement
(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

Diagramme de dploiement

Serveur

Base <<utility>>
de Donnes
Base de
Donnes

Ordonnanceur

interface
TCP / IP

1
1..*

Client
IHM

256

Diagramme de dploiement

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

Traduction dune classe

class Personne{

Personne
}

260

Traduction dune classe

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

Traduction dune classe

abstract class Personne{
Personne
{abstract}

.
.
.

262

Traduction dune classe

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

Traduction dune classe

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

Traduction des relations

(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

Traduction des relations

(La gnralisation)
Class Personne{
Personne

Employe

}
Class Employe extends
Personne{

}
270

Traduction des relations

(La ralisation )

Une classe UML peut implmenter plusieurs

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

271

Traduction des relations

(Ralisation)
interface A{
A

}
interface B{

}
class C implements A, B {

}
272

Traduction des relations

(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

Traduction des relations

(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

Traduction des relations

(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

Traduction des relations

(Les associations)

276

Traduction des relations

(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

Traduction des relations

(Les associations)

278

Traduction des relations

(Les associations)

279

Traduction des relations

(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

Traduction des relations

(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

Gnralisation/spcialisation en
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

Gnralisation/spcialisation en
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

Associations en Relationnel
(Association un--un)

1re Solution

Pays(IdPays, NomP,#IdCapitale)
Capitales(IdCapitale, NomC, #IdPays)

2ime Solution

Pays(IdPays, NomP, NomC)

290

Associations en Relationnel
(Association un--un)

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

Associations en Relationnel
(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

Associations en Relationnel
(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

Associations en Relationnel
(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

context Compte::getSolde():Real
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

context Compte::getSolde():Real
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

Dfinition des attributs et de

mthodes
Syntaxes :
let <dclaration>=<requte> in <expression>

Lattribut dclar recevra le rsultat de la

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

315

Dfinition des attributs et de

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

Initialisation et volution des

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

Initialisation et volution des

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

Types et opration OCL

Type

oprateurs

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

Integer

+,-, *, /, abs(),

Real

+,-, *, /, abs(), floor(),

String

Concat(), size(), substring(),

321

Types et opration OCL

a

a and b

a or b

a xor b

a implies b

322

Types et opration OCL

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

Navigation travers une

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

Navigation travers une

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

Navigation travers une

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

Navigation travers une

association

Exemple : Type du rsultat

335

Navigation travers une

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