Le document traite des profils UML, qui permettent d'adapter UML à des domaines spécifiques grâce au concept de stéréotype, facilitant ainsi la modélisation d'applications variées. Il explique également les normes et les fonctionnalités de l'Object Constraint Language (OCL) pour spécifier des contraintes dans les modèles UML, ainsi que l'Action Semantics (AS) comme alternative pour modéliser des actions au sein de ces modèles. En résumé, il souligne l'importance de ces standards pour améliorer la productivité et la clarté des modèles UML dans des contextes personnalisés.

1. Les profils UML
Le standards
UML 2.0
1

2. Les profils UML
 UML permet de modéliser des applications orientées objet, mais
ses concepts sont suffisamment génériques pour être utilisés dans
d’autres domaines.
 Par exemple, les diagrammes de classes, qui permettent en
principe de ne modéliser que la partie statique d’une application
orientée objet, peuvent être utilisés à d’autres fins:
 notamment pour modéliser
 des métamodèles.
 Ils peuvent même être employés (sans utiliser tous les concepts
qu’ils proposent) pour modéliser des structures de bases de
données.
2

3.  Le problème est : qu’il devient dès lors de plus en plus
difficile en regardant un modèle de savoir s’il modélise une
application objet, un métamodèle, une base de données ou
autre chose.
3

4. La solution
 l’OMG a standardisé le concept de profil UML.
 Un profil est un ensemble de techniques et de mécanismes
permettant d’adapter UML à un domaine particulier.
 Cette adaptation est dynamique, c’est-à-dire qu’elle ne modifie
en rien le métamodèle UML et qu’elle peut se faire sur
n’importe quel modèle UML.
4

5.  Les profils UML mettent en jeu le concept central de
stéréotype.
 Un stéréotype est une sorte d’étiquette nommée que l’on peut
coller sur n’importe quel élément d’un modèle UML.
 Lorsqu’un stéréotype est collé sur un élément d’un modèle,
le nom du stéréotype définit la nouvelle signification de
l’élément.
5

6. Par exemple
 coller un stéréotype nommé "Sécurisé" sur une classe UML
signifie que la classe en question n’est plus une simple classe
UML mais qu’elle est une classe sécurisée, c’est-à-dire dont les
accès sont restreints par mot de passe.
 Utiliser un profil consiste donc à coller sur un modèle UML un
ensemble de stéréotypes.
6

7.  D’un point de vue graphique, un stéréotype se représente
sous la forme d’une chaîne de caractères contenant le nom
du stéréotype encadré de guillemets.
 Si le stéréotype est collé sur une classe, cette chaîne de
caractères doit apparaître au-dessus du nom de la classe
7

8. Utilisation d’un stéréotype sur une classe
8

9.  le concept de profil ne peut fonctionner que si l’ensemble
des stéréotypes utilisés est partagé par les différents
intervenants manipulant les modèles.
 Dans l’exemple du stéréotype "Sécurisé", il faut que tous les
intervenants connaissent ce stéréotype ainsi que sa
signification.
9

10.  Pour faire face à cela, l’OMG a défini des profils standards.
 Ces profils définissent un ensemble de stéréotypes et
expliquent leur signification en langage naturel.
 D’autres organismes de standardisation, tels que le JCP (Java
Community Process), proposent eux aussi des profils
standards.
10

11.  L’intérêt principal des profils est qu’il est possible de leur
associer des traitements Spécifiques du domaine couvert par
le profil.
 ces traitements permettent de rendre les modèles UML
profilés beaucoup plus productifs que les modèles UML
simples, car ceux-ci disposent d’informations
supplémentaires grâce aux stéréotypes.
11

12. Exemple de profil UML
 Actuellement, plusieurs profils sont standardisés par l’OMG.
 Exemple : le profil pour les tests, UMLTesting Profile.
 Ce profil permet d’utiliser UML pour modéliser des tests.
 Cet exemple montre comment sont utilisés les profils dans
MDA.
12

13. UML Testing Profile
 Parmi les stéréotypes de ce profil, on trouve les stéréotypes :
 "TestSuite " : Le stéréotype "TestSuite" s’applique à des classes
UML. Lorsqu’il est utilisé, la classe UML représente une suite de
tests à effectuer.
 "TestCase " : s’applique à des opérations UML, Lorsqu’il est
utilisé, l’opération UML représente un cas de test à effectuer.
13

14. Modèle UML profilé pour les tests
14

15. Définition de nouveaux profils
 UML2.0 Superstructure facilite la création de nouveaux profils
en simplifiant la définition des concepts de profils et de
stéréotypes dans le métamodèle.
15

16. La partie du métamodèle UML2.0 qui contient les métaclasses
relatives aux profils.
16

17.  Dans ce métamodèle, la métaclasse Profile hérite de la
métaclasse Package.
 Cela signifie que les définitions de nouveaux profils sont
maintenant considérées comme étant des packages.
 La métaclasse Stereotype hérite de son côté de la métaclasse
Class. Cela signifie que les définitions de stéréotypes sont
considérées comme étant des classes UML.
 Le nom de la classe correspond au nom du stéréotype.
17

18.  la métaclasse Stereotype est reliée à la métaclasse Class via la
métaclasse Extension,qui hérite de la métaclasse Association,
 et la métaclasse ExtensionEnd, qui hérite de la métaclasse
Property.
 Cela signifie qu’un stéréotype apporte une extension de
signification à une classe.
 les classes étendues par des stéréotypes doivent être des
métaclasses d’un métamodèle,
18

19.  Si nous reprenons notre exemple de profil de test.
 Nous constatons que les stéréotypes "TestSuite" et "TestCase
" sont liés non à des classes normales mais à des métaclasses
(Class et Operation).
19

20. 20

21.  Après ces présentations, il est plus facile de comprendre
pourquoi l’OMG préconise l’utilisation d’UML2.0
Superstructure pour élaborer les PIM puisque :
 les modèles UML2.0 Superstructure permettent de modéliser
les applications orientées objet indépendamment des plates-
formes sur lesquelles elles s’exécutent.
 C’est en cela que les modèles UML2.0 Superstructure sont
pérennes.
 Grâce aux profils, il est possible d’appliquer UML2.0
Superstructure à des domaines autres que la modélisation
d’applications orientées objet.
21

22. Les standards OCL et AS
22

23. Pérennité des
Savoir-Faire
Les
modèles
en XML
Les standards
OCL,AS
UML
2.0
Modèle et
niveaux méta
MOF
23

24. OCL (Object Constraint Language)
 Une contrainte constitue une condition ou une restriction
sémantique exprimée sous forme d’instruction dans un langage
textuel qui peut être naturel ou formel.
 En général, une contrainte peut être attachée à n’importe quel
élément de modèle ou liste d’éléments de modèle.
 Une contrainte désigne une restriction qui doit être appliquée
par une implémentation correcte du système.
24

25. •Sur les deux diagrammes du haut, la contrainte porte sur un attribut qui doit être positif.
• En bas à gauche, la contrainte {frozen} précise que le nombre de roues d’un véhicule ne
peut pas varier.
•Au milieu, la contrainte {subset} précise que le président est également un membre du
comité.
•Enfin, en bas à droite, la contrainte {xor} (ou exclusif) précise que les employés de l’hôtel
n’ont pas le droit de prendre une chambre dans ce même hôtel.
25

26.  C’est un langage formel d’expression de contraintes bien adapté
aux diagrammes d’UML, et en particulier au diagramme de
classes.
 OCL existe depuis la version 1.1 d’UML et est une contribution
d’IBM.
 OCL fait partie intégrante de la norme UML depuis la version
1.3 d’UML.
 Dans le cadre d’UML 2.0, les spécifications du langage OCL
figurent dans un document indépendant de la norme d’UML,
décrivant en détail la syntaxe formelle et la façon d’utiliser ce
langage.
26

27. Exemple
 context Compte
inv : solde > 0
context Compte :: débiter(somme : int)
pre : somme > 0
post : solde = solde@pre - somme
context Compte
inv : banque.clients -> includes (propriétaire)
27

28.  Le concept d’expression est au coeur du langage OCL. Une
expression est rattachée à un contexte, qui est un élément de
modèle UML, et peut être évaluée afin de retourner une valeur.
 Par exemple, une expression OCL dont le contexte serait la
classe Compte permettrait d’obtenir la valeur de l’attribut solde.
 Une autre expression OCL, dont le contexte serait la classe
Personne, permettrait de vérifier qu’une personne dispose ou
non d’un compte bancaire.
 Les expressions OCL ne génèrent aucun effet de bord.
 Il ne permet pas de construire de nouveaux éléments ni même
de modifier ou de supprimer des éléments existants.
28

29. Les expressions OCL
 Le contexte :
 Pour être évaluée, une expression OCL doit être rattachée à un
contexte.
 Une contrainte est toujours associée à un élément de modèle.
 C’est cet élément qui constitue le contexte de la contrainte. Il
existe deux manières pour spécifier le contexte d’une contrainte
OCL :
 En écrivant la contrainte entre accolades ({}) dans une note
L’élément pointé par la note est alors le contexte de la contrainte.
 En utilisant le mot-clef context dans un document accompagnant le
diagramme.
29

30.  Syntaxe :
context <élément>
 <élément>: peut être une classe, une opération, etc.
 Exemple :
 context Compte
 context Compte::getSolde()
30

31.  Invariants (inv): Un invariant exprime une contrainte
prédicative sur un objet, ou un groupe d’objets, qui doit être
respectée en permanence.
 Syntaxe
 inv : <expression_logique> <expression_logique> est une
expression logique qui doit toujours être vraie.
 Exemple : Le solde d’un compte doit toujours être positif.
context Compte
inv : solde > 0
31

32.  Préconditions et postconditions (pre, post)
 Une précondition (respectivement une postcondition) permet de
spécifier une contrainte prédicative qui doit être vérifiée avant
(respectivement après) l’appel d’une opération.
 Dans l’expression de la contrainte de la postcondition, deux
éléments particuliers sont utilisables :
 l’attribut result qui désigne la valeur retournée par l’opération,
 et <nom_attribut>@pre qui désigne la valeur de l’attribut
<nom_attribut> avant l’appel de l’opération.
32

33.  Syntaxe
 Précondition : pre : <expression_logique>
 Postcondition : post : <expression_logique>
 <expression_logique> est une expression logique qui doit toujours
être vraie.
 Exemle:
context Compte::débiter(somme : Real)
pre : somme > 0
post : solde = solde@pre - somme
context Compte::getSolde() : Real
post : result = solde
33

34.  Résultat d’une méthode (body)
 Ce type de contrainte permet de définir directement le résultat
d’une opération.
 Syntaxe
 body : <requête> <requête> est une expression qui
retourne un résultat dont le type doit être compatible avec le
type du résultat de l’opération désignée par le contexte.
 Exemple
 le résultat de l’appel de l’opération getSolde doit être égal à
l’attribut solde.
context Compte::getSolde() : Real
body : solde
34

35. Les opérations de sélection
 Étant donné qu’OCL permet de définir des requêtes sur des
éléments de modèle.
 il est possible de l’utiliser pour définir le corps d’opérations qui
ne font que sélectionner des éléments de modèle. Nous utilisons
pour cela le mot-clé body:
 Exemple : il est possible de spécifier en OCL le corps de l’opération
permettant de sélectionner tous les comptes bancaires positifs d’une
personne :
context Personne::getComptePositif():Set
pre: self.cpts.notEmpty()
body: self.cpts->select(c | c.solde>0)
35

36. Collections
 OCL définit également la notion d’ensemble sous le terme générique
de collection (collection en anglais). Il existe plusieurs sous-types du
type abstrait Collection :
 Ensemble (Set) : collection non ordonnée d’éléments uniques (i.e.
pas d’élément en double).
 Ensemble ordonné (OrderedSet) : collection ordonnée d’éléments
uniques.
 Sac (Bag) : collection non ordonnée d’éléments identifiables (i.e.
comme un ensemble, mais pouvant comporter des doublons).
 Séquence (Sequence) : collection ordonnée d’éléments identifiables.
 les collections étaient toujours plates : une collection ne pouvait pas
posséder des collections comme éléments. Cette restriction n’existe
plus à partir d’UML 2.0.
36

37. Manipulation des collections
 OCL propose différentes fonctions pour manipuler les
collections, quel que soit leur type:
 La fonction select() : permet de sélectionner un sous-ensemble
d’éléments d’une collection en fonction d’une condition.
exemple : context Personne
self.cpts->select(c | c.solde>0)
 La fonction forAll() permet de vérifier si tous les éléments d’une
collection respectent une expression OCL.
Exemple : context Personne
self.cpts->forAll(c | c.solde>0)
37

38.  La fonction exist() : permet de vérifier si au moins un
élément respectant une expression OCL existe dans la
collection.
Exemple : context Personne
self.cpts->exist(c | c.solde>0)
38

39. Le métamodèle OCL2.0
 L’objectif de la version 2.0 est principalement de spécifier OCL
grâce à un métamodèle afin que celui-ci soit facilement
intégrable dans MDA.
 Depuis OCL2.0, les expressions OCL sont des modèles
pérennes, productifs et explicitement liés aux modèles UML.
 Cela offre un gain significatif d’expressivité aux modèles UML.
39

40. OCL et UML
 Les expressions OCL portent toutes sur des éléments de modèles
UML. Il y a donc un fort lien entre le métamodèle OCL et le
métamodèle UML.
 Dans le métamodèle UML, la métaclasse Constraint représente
n’importe quelle contrainte.
 Cette métaclasse est reliée à la métaclasse ModelElement, qui joue le
rôle de constrainedElement. Il est ainsi possible d’attacher une
contrainte à n’importe quel élément du modèle.
 La métaclasse Constraint est aussi reliée à la métaclasse Expression,
qui joue le rôle de body. Le corps des contraintes UML est de la sorte
spécifié à l’aide d’une expression.
 UML laisse le choix du langage dans lequel les expressions doivent
être écrites.
40

41. Liens entre les métamodèles UML et OCL
MétaMdèle
UML 2.0
MétaMdèle
OCL 2.0
41

42.  Le métamodèle OCL définit quant à lui la métaclasse
ExpressionInOcl, qui hérite de la métaclasse Expression.
 Grâce à cet héritage, cette métaclasse représente des
contraintes UML écrites avec OCL.
 Cette métaclasse est reliée à la métaclasse OclExpression, qui
joue le rôle de bodyExpression.
 C’est cette dernière métaclasse qui représente réellement la
spécification d’une contrainte en OCL.
42

43. En résumé
 OCL permet de préciser les modèles UML tout en faisant en sorte qu’ils
soient toujours indépendants des plates-formes de programmation.
 Il est principalement utilisé dans MDA pour l’élaboration des PIM
(Platform Independent Model).
 Afin de clarifier l’intégration du standard OCL dans MDA, l’OMG a
décidé de le standardiser sous forme de métamodèle. Grâce au
métamodèle OCL, les contraintes OCL sont désormais représentées
sous forme de modèles.
 Le métamodèle OCL est relié au métamodèle UML de façon à exprimer
la dépendance entre UML et OCL.
 Grace à ce lien, on peut dire que le métamodèle OCL a permis de
rendre les contraintes OCL productives.
 Il est de la sorte envisageable d’automatiser l’évaluation des contraintes
OCL.
43

44. Action
Semantics
Le standards AS
44

45.  AS peut être vu comme une solution de rechange à OCL du
fait des difficultés d’utilisation de ce dernier pour la majorité
des utilisateurs UML, plutôt habitués à écrire des suites
d’instructions.
 Grâce à AS, il est possible de modéliser des constructions
d’objets, des affectations de variables, des suppressions, des
boucles for, des tests if, etc.
45

46.  L’objectif d’AS est de permettre la spécification d’actions.
 Une action, au sensAS du terme, est une opération sur un
modèle qui fait changer l’état du modèle.
 Grâce aux actions, il est possible de modifier les valeurs des
attributs, de créer ou de supprimer des objets, de créer de
nouveaux liens entre les objets, etc. Le concept d’action
permet de spécifier pleinement le corps des opérations
UML.
46

47.  AS a tout d’abord été standardisé comme un langage à part
entière, lié au standard UML.
 avant d’être inclus dans la version 1.5 d’UML.
 Dans UML2.0, il est enfin totalement intégré au métamodèle.
47