Le standards

UML 2.0

Les profils UML

Les profils UML

UML permet de modliser des applications orientes objet, mais

ses concepts sont suffisamment gnriques pour tre utiliss dans

dautres domaines.
Par exemple, les diagrammes de classes, qui permettent en
principe de ne modliser que la partie statique dune application
oriente objet, peuvent tre utiliss dautres fins:
notamment pour modliser
des mtamodles.

Ils peuvent mme tre employs (sans utiliser tous les concepts

quils proposent) pour modliser des structures de bases de

donnes.

 Le problme est : quil devient ds lors de plus en plus

difficile en regardant un modle de savoir sil modlise une

application objet, un mtamodle, une base de donnes ou
autre chose.

La solution
lOMG a standardis le concept de profil UML.
Un profil est un ensemble de techniques et de mcanismes

permettant dadapter UML un domaine particulier.

Cette adaptation est dynamique, cest--dire quelle ne modifie
en rien le mtamodle UML et quelle peut se faire sur
nimporte quel modle UML.

 Les profils UML mettent en jeu le concept central de

strotype.
Un strotype est une sorte dtiquette nomme que lon peut
coller sur nimporte quel lment dun modle UML.
Lorsquun strotype est coll sur un lment dun modle,
le nom du strotype dfinit la nouvelle signification de
llment.

Par exemple
coller un strotype nomm "Scuris" sur une classe UML

signifie que la classe en question nest plus une simple classe

UML mais quelle est une classe scurise, cest--dire dont les
accs sont restreints par mot de passe.
Utiliser un profil consiste donc coller sur un modle UML un
ensemble de strotypes.

 Dun point de vue graphique, un strotype se reprsente

sous la forme dune chane de caractres contenant le nom

du strotype encadr de guillemets.
Si le strotype est coll sur une classe, cette chane de
caractres doit apparatre au-dessus du nom de la classe

Utilisation dun strotype sur une classe

 le concept de profil ne peut fonctionner que si lensemble

des strotypes utiliss est partag par les diffrents

intervenants manipulant les modles.
Dans lexemple du strotype "Scuris", il faut que tous les
intervenants connaissent ce strotype ainsi que sa
signification.

 Pour faire face cela, lOMG a dfini des profils standards.

Ces profils dfinissent un ensemble de strotypes et

expliquent leur signification en langage naturel.

Dautres organismes de standardisation, tels que le JCP (Java
Community Process), proposent eux aussi des profils
standards.

10

 Lintrt principal des profils est quil est possible de leur

associer des traitements Spcifiques du domaine couvert par

le profil.
ces traitements permettent de rendre les modles UML
profils beaucoup plus productifs que les modles UML
simples, car ceux-ci disposent dinformations
supplmentaires grce aux strotypes.

11

Exemple de profil UML

Actuellement, plusieurs profils sont standardiss par lOMG.

Exemple : le profil pour les tests, UML Testing Profile.

Ce profil permet dutiliser UML pour modliser des tests.

Cet exemple montre comment sont utiliss les profils dans

MDA.

12

UML Testing Profile

Parmi les strotypes de ce profil, on trouve les strotypes :
"TestSuite " : Le strotype "TestSuite" sapplique des classes

UML. Lorsquil est utilis, la classe UML reprsente une suite de

tests effectuer.
"TestCase " : sapplique des oprations UML, Lorsquil est
utilis, lopration UML reprsente un cas de test effectuer.

13

Modle UML profil pour les tests

14

Dfinition de nouveaux profils

UML2.0 Superstructure facilite la cration de nouveaux profils

en simplifiant la dfinition des concepts de profils et de

strotypes dans le mtamodle.

15

La partie du mtamodle UML2.0 qui contient les mtaclasses

relatives aux profils.

16

 Dans ce mtamodle, la mtaclasse Profile hrite de la

mtaclasse Package.
Cela signifie que les dfinitions de nouveaux profils sont
maintenant considres comme tant des packages.
La mtaclasse Stereotype hrite de son ct de la mtaclasse
Class. Cela signifie que les dfinitions de strotypes sont
considres comme tant des classes UML.
Le nom de la classe correspond au nom du strotype.

17

 la mtaclasse Stereotype est relie la mtaclasse Class via la

mtaclasse Extension, qui hrite de la mtaclasse Association,

et la mtaclasse ExtensionEnd, qui hrite de la mtaclasse
Property.
Cela signifie quun strotype apporte une extension de
signification une classe.
les classes tendues par des strotypes doivent tre des
mtaclasses dun mtamodle,

18

 Si nous reprenons notre exemple de profil de test.

Nous constatons que les strotypes "TestSuite" et "TestCase

" sont lis non des classes normales mais des mtaclasses
(Class et Operation).

19

20

 Aprs ces prsentations, il est plus facile de comprendre

pourquoi lOMG prconise lutilisation dUML2.0

Superstructure pour laborer les PIM puisque :
les modles UML2.0 Superstructure permettent de modliser
les applications orientes objet indpendamment des platesformes sur lesquelles elles sexcutent.
Cest en cela que les modles UML2.0 Superstructure sont
prennes.
Grce aux profils, il est possible dappliquer UML2.0
Superstructure des domaines autres que la modlisation
dapplications orientes objet.

21

Les standards OCL et AS

22

Prennit des
Savoir-Faire
Les
Les standards UML
modles
OCL,AS
2.0
en XML

23

Modle et
niveaux mta
MOF

OCL (Object Constraint Language)

Une contrainte constitue une condition ou une restriction

smantique exprime sous forme dinstruction dans un langage

textuel qui peut tre naturel ou formel.
En gnral, une contrainte peut tre attache nimporte quel
lment de modle ou liste dlments de modle.
Une contrainte dsigne une restriction qui doit tre applique
par une implmentation correcte du systme.

24

Sur les deux diagrammes du haut, la contrainte porte sur un attribut qui doit tre positif.
En bas gauche, la contrainte {frozen} prcise que le nombre de roues dun vhicule ne
peut pas varier.
Au milieu, la contrainte {subset} prcise que le prsident est galement un membre du
comit.
Enfin, en bas droite, la contrainte {xor} (ou exclusif) prcise que les employs de lhtel
nont pas le droit de prendre une chambre dans ce mme htel.

25

 Cest un langage formel dexpression de contraintes bien adapt

aux diagrammes dUML, et en particulier au diagramme de

classes.
OCL existe depuis la version 1.1 dUML et est une contribution
dIBM.
OCL fait partie intgrante de la norme UML depuis la version
1.3 dUML.
Dans le cadre dUML 2.0, les spcifications du langage OCL
figurent dans un document indpendant de la norme dUML,
dcrivant en dtail la syntaxe formelle et la faon dutiliser ce
langage.
26

Exemple

context Compte

inv : solde > 0

context Compte :: dbiter(somme : int)

pre : somme > 0
post : solde = solde@pre - somme

context Compte
inv : banque.clients -> includes (propritaire)
27

 Le concept dexpression est au coeur du langage OCL. Une

28

expression est rattache un contexte, qui est un lment de

modle UML, et peut tre value afin de retourner une valeur.
Par exemple, une expression OCL dont le contexte serait la
classe Compte permettrait dobtenir la valeur de lattribut solde.
Une autre expression OCL, dont le contexte serait la classe
Personne, permettrait de vrifier quune personne dispose ou
non dun compte bancaire.
Les expressions OCL ne gnrent aucun effet de bord.
Il ne permet pas de construire de nouveaux lments ni mme
de modifier ou de supprimer des lments existants.

Les expressions OCL

Le contexte :
Pour tre value, une expression OCL doit tre rattache un

contexte.
Une contrainte est toujours associe un lment de modle.
Cest cet lment qui constitue le contexte de la contrainte. Il
existe deux manires pour spcifier le contexte dune contrainte
OCL :
En crivant la contrainte entre accolades ({}) dans une note

Llment point par la note est alors le contexte de la contrainte.

En utilisant le mot-clef context dans un document accompagnant le
diagramme.
29

 Syntaxe :

context <lment>
<lment>: peut tre une classe, une opration, etc.
Exemple :
context Compte
context Compte::getSolde()

30

 Invariants (inv): Un invariant exprime une contrainte

prdicative sur un objet, ou un groupe dobjets, qui doit tre

respecte en permanence.
Syntaxe
inv : <expression_logique> <expression_logique> est une
expression logique qui doit toujours tre vraie.
Exemple : Le solde dun compte doit toujours tre positif.
context Compte
inv : solde > 0

31

 Prconditions et postconditions (pre, post)

Une prcondition (respectivement une postcondition) permet de

spcifier une contrainte prdicative qui doit tre vrifie avant

(respectivement aprs) lappel dune opration.
Dans lexpression de la contrainte de la postcondition, deux
lments particuliers sont utilisables :
lattribut result qui dsigne la valeur retourne par lopration,
et <nom_attribut>@pre qui dsigne la valeur de lattribut

<nom_attribut> avant lappel de lopration.

32

 Syntaxe
Prcondition : pre : <expression_logique>
Postcondition : post : <expression_logique>
<expression_logique> est une expression logique qui doit toujours

tre vraie.
Exemle:

context Compte::dbiter(somme : Real)

pre : somme > 0
post : solde = solde@pre - somme
context Compte::getSolde() : Real
post : result = solde

33

 Rsultat dune mthode (body)

Ce type de contrainte permet de dfinir directement le rsultat

34

dune opration.
Syntaxe
body : <requte>
<requte> est une expression qui
retourne un rsultat dont le type doit tre compatible avec le
type du rsultat de lopration dsigne par le contexte.
Exemple
le rsultat de lappel de lopration getSolde doit tre gal
lattribut solde.
context Compte::getSolde() : Real
body : solde

Les oprations de slection

tant donn quOCL permet de dfinir des requtes sur des

lments de modle.
il est possible de lutiliser pour dfinir le corps doprations qui
ne font que slectionner des lments de modle. Nous utilisons
pour cela le mot-cl body:
Exemple : il est possible de spcifier en OCL le corps de lopration

permettant de slectionner tous les comptes bancaires positifs dune

personne :

context Personne::getComptePositif():Set
pre: self.cpts.notEmpty()
body: self.cpts->select(c | c.solde>0)
35

Collections
OCL dfinit galement la notion densemble sous le terme gnrique

36

de collection (collection en anglais). Il existe plusieurs sous-types du

type abstrait Collection :
Ensemble (Set) : collection non ordonne dlments uniques (i.e.
pas dlment en double).
Ensemble ordonn (OrderedSet) : collection ordonne dlments
uniques.
Sac (Bag) : collection non ordonne dlments identifiables (i.e.
comme un ensemble, mais pouvant comporter des doublons).
Squence (Sequence) : collection ordonne dlments identifiables.
les collections taient toujours plates : une collection ne pouvait pas
possder des collections comme lments. Cette restriction nexiste
plus partir dUML 2.0.

Manipulation des collections

OCL propose diffrentes fonctions pour manipuler les

collections, quel que soit leur type:

La fonction select() : permet de slectionner un sous-ensemble
dlments dune collection en fonction dune condition.

exemple :

context Personne
self.cpts->select(c | c.solde>0)

La fonction forAll() permet de vrifier si tous les lments dune

collection respectent une expression OCL.

Exemple : context Personne
self.cpts->forAll(c | c.solde>0)

37

 La fonction exist() : permet de vrifier si au moins un

lment respectant une expression OCL existe dans la

collection.
Exemple :
context Personne

self.cpts->exist(c | c.solde>0)

38

Le mtamodle OCL2.0
Lobjectif de la version 2.0 est principalement de spcifier OCL

grce un mtamodle afin que celui-ci soit facilement

intgrable dans MDA.
Depuis OCL2.0, les expressions OCL sont des modles
prennes, productifs et explicitement lis aux modles UML.
Cela offre un gain significatif dexpressivit aux modles UML.

39

OCL et UML
Les expressions OCL portent toutes sur des lments de modles

40

UML. Il y a donc un fort lien entre le mtamodle OCL et le

mtamodle UML.
Dans le mtamodle UML, la mtaclasse Constraint reprsente
nimporte quelle contrainte.
Cette mtaclasse est relie la mtaclasse ModelElement, qui joue le
rle de constrainedElement. Il est ainsi possible dattacher une
contrainte nimporte quel lment du modle.
La mtaclasse Constraint est aussi relie la mtaclasse Expression,
qui joue le rle de body. Le corps des contraintes UML est de la sorte
spcifi laide dune expression.
UML laisse le choix du langage dans lequel les expressions doivent
tre crites.

Liens entre les mtamodles UML et OCL

MtaMdle
UML 2.0

MtaMdle
OCL 2.0
41

 Le mtamodle OCL dfinit quant lui la mtaclasse

ExpressionInOcl, qui hrite de la mtaclasse Expression.

Grce cet hritage, cette mtaclasse reprsente des
contraintes UML crites avec OCL.
Cette mtaclasse est relie la mtaclasse OclExpression, qui
joue le rle de bodyExpression.
Cest cette dernire mtaclasse qui reprsente rellement la
spcification dune contrainte en OCL.

42

En rsum
OCL permet de prciser les modles UML tout en faisant en sorte quils

43

soient toujours indpendants des plates-formes de programmation.

Il est principalement utilis dans MDA pour llaboration des PIM
(Platform Independent Model).
Afin de clarifier lintgration du standard OCL dans MDA, lOMG a
dcid de le standardiser sous forme de mtamodle. Grce au
mtamodle OCL, les contraintes OCL sont dsormais reprsentes
sous forme de modles.
Le mtamodle OCL est reli au mtamodle UML de faon exprimer
la dpendance entre UML et OCL.
Grace ce lien, on peut dire que le mtamodle OCL a permis de
rendre les contraintes OCL productives.
Il est de la sorte envisageable dautomatiser lvaluation des contraintes
OCL.

Le standards AS
Action

Semantics

44

 AS peut tre vu comme une solution de rechange OCL du

fait des difficults dutilisation de ce dernier pour la majorit

des utilisateurs UML, plutt habitus crire des suites
dinstructions.
Grce AS, il est possible de modliser des constructions
dobjets, des affectations de variables, des suppressions, des
boucles for, des tests if, etc.

45

 Lobjectif dAS est de permettre la spcification dactions.

Une action, au sens AS du terme, est une opration sur un

modle qui fait changer ltat du modle.

Grce aux actions, il est possible de modifier les valeurs des
attributs, de crer ou de supprimer des objets, de crer de
nouveaux liens entre les objets, etc. Le concept daction
permet de spcifier pleinement le corps des oprations
UML.

46

 AS a tout dabord t standardis comme un langage part

entire, li au standard UML.

avant dtre inclus dans la version 1.5 dUML.
Dans UML2.0, il est enfin totalement intgr au mtamodle.

47