Le standards UML2.0-Les profils UML

Plan

Les standards OCL et AS

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.

Les contraintes UML

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
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.
Exemple:
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)
```
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.

Les expressions OCL

Le 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.
Syntaxe :
context <élément>
<
élément>: peut être une classe, une opération, etc.
Exemple :
- context Compte
- context Compte::getSolde()
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 : est une expression logique qui doit toujours être vraie.
Exemple : Le solde d’un compte doit toujours être positif.
context Compte

inv : solde > 0
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 @pre qui désigne la valeur de l’attribut avant l’appel de l’opération.
Syntaxe:
Précondition : pre :
Postcondition : post :

est une expression logique qui doit toujours être vraie.

Exemple

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

context Compte::getSolde() : Real
post : result = solde

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 : ou 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.
Exemple
```
		
context Compte::getSolde() : Real
   		body : solde
```
É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 :
Exemple
```
		
context Personne::getComptePositif():Set
		pre: self.cpts.notEmpty()
		body: self.cpts->select(c | c.solde>0)
```

Les 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.

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)
```
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)
```

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.

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.
Liens entre les métamodèles UML et OCL:
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.

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.

[ Sommaire ]

Le standards AS(Action Semantics)

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.
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.
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.

[ Sommaire ]