Les profils UML

Le standards

UML 2.0

1

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

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

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

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

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

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

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

8

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

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

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

Exemple de profil UML

Actuellement, plusieurs profils sont standardisés par l’OMG.

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

Ce profil permet d’utiliser UML pour modéliser des tests.

Cet exemple montre comment sont utilisés les profils dans

MDA.

12

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

Modèle UML profilé pour les tests

14

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

La partie du métamodèle UML2.0 qui contient les métaclasses

relatives aux profils.

16

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

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

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

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

Les standards OCL et AS

22

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

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

•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

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

Exemple

context Compteinv : solde > 0

context Compte :: débiter(somme : int)pre : somme > 0post : solde = solde@pre - somme

context Compteinv : banque.clients -> includes (propriétaire)

27

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

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

Syntaxe :

context <élément>

<élément>: peut être une classe, une opération, etc.

Exemple :

context Compte

context Compte::getSolde()

30

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

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

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

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() : Realbody : solde

34

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

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

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

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

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

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

Liens entre les métamodèles UML et OCL

MétaMdèle

UML 2.0

MétaMdèle

OCL 2.0

41

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

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

Action

Semantics

Le standards AS

44

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

L’objectif d’AS est de permettre la spécification d’actions.

Une action, au sens AS 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

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