UML 2

Nous avons déjà vu comment exprimer certaines formes de contraintes avec UML :

• les attributs dans les classes, les différents types de relations entre classes (généralisation, association, agrégation, composition, dépendance), la cardinalité et la navigabilité des propriétés structurelles, etc. ;

• typage des propriétés, etc. ;

• les contraintes de visibilité, les méthodes et classes abstraites (contrainte abstract), etc.

Dans la pratique, toutes ces contraintes sont très utiles, mais se révèlent insuffisantes. Toutefois, UML permet de spécifier explicitement des contraintes particulières sur des éléments de modèle.

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.

On représente une contrainte sous la forme d'une chaîne de texte placée entre accolades ({}). La chaîne constitue le corps écrit dans un langage de contrainte qui peut être :

• naturel ;
• dédié, comme OCL ;
• ou encore directement issu d'un langage de programmation.

Si une contrainte possède un nom, on présente celui-ci sous forme d'une chaîne suivie d'un double point (:), le tout précédant le texte de la contrainte.

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.

UML permet d'associer une contrainte à un, ou plusieurs, élément(s) de modèle de différentes façons (cf. figure 4.1) :

• en plaçant directement la contrainte à côté d'une propriété ou d'une opération dans un classeur ;
• en ajoutant une note associée à l'élément à contraindre ;
• en plaçant la contrainte à proximité de l'élément à contraindre, comme une extrémité d'association par exemple ;
• en plaçant la contrainte sur une flèche en pointillés joignant les deux éléments de modèle à contraindre ensemble, la direction de la flèche constituant une information pertinente au sein de la contrainte ;
• en plaçant la contrainte sur un trait en pointillés joignant les deux éléments de modèle à contraindre ensemble dans le cas où la contrainte est bijective ;
• en utilisant une note reliée, par des traits en pointillés, à chacun des éléments de modèle, subissant la contrainte commune, quand cette contrainte s'applique sur plus de deux éléments de modèle.

Nous venons de voir, au travers des exemples de la figure 4.1, quelques contraintes prédéfinies ({frozen}, {subset} et {xor}). Le diagramme de la figure 4.2 en introduit deux nouvelles : {ordered} et {addOnly}. La liste est encore longue, mais le pouvoir expressif de ces contraintes reste insuffisant comme nous le verrons dans la section 4.2.2Illustration par l'exemple . Le langage de contraintes objet OCL apporte une solution élégante à cette insuffisance.

4-2-1-a. QuesacOCL ?▲

4-2-1-b. Pourquoi OCL ?▲

4-2-2-a. Mise en situation▲

4-2-2-b. Diagramme de classes▲

La figure 4.3 montre un diagramme de classes correspondant à la problématique que nous venons de décrire.

Un premier problème apparaît immédiatement : rien ne spécifie, dans ce diagramme, que le solde du client doit toujours être positif. Pour résoudre le problème, on peut simplement ajouter une note précisant cette contrainte ({solde > 0}), comme le montre la figure 4.4.

Cependant, d'autres problèmes subsistent. La figure 4.5 montre un diagramme d'objets valide vis-à-vis du diagramme de classes de la figure 4.4 et également valide vis-à-vis de la spécification du problème. Par contre, la figure 4.6 montre un diagramme d'objets valide vis-à-vis du diagramme de classes de la figure 4.4 mais ne respectant pas la spécification du problème. En effet, ce diagramme d'objets montre une personne (P1) ayant un compte dans une banque sans en être client. Ce diagramme montre également un client (P2) d'une banque n'y possédant pas de compte.

• 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 langage OCL est particulièrement adapté à la spécification de ce type de contrainte. La figure 4.7 montre le diagramme de classes de notre application bancaire accompagné des contraintes OCL adaptées à la spécification du problème.

Faites bien attention au fait qu'une expression OCL décrit une contrainte à respecter et ne décrit absolument pas l'implémentation d'une méthode.

Le diagramme de la figure 4.8 modélise des personnes, leurs liens de parenté (enfant/parent et mari/femme) et le poste éventuel de ces personnes dans une société. Ce diagramme nous servira de support aux différents exemples de contraintes que nous donnerons, à titre d'illustration, dans les sections qui suivent (4.3Typologie des contraintes OCL à 4.7Exemples de contraintes).

Ce diagramme introduit un nouveau type de classeur, stéréotypé « enumeration », permettant de définir une énumération. Une énumération est un type de donnée UML, possédant un nom, et utilisé pour énumérer un ensemble de littéraux correspondant à toutes les valeurs possibles que peut prendre une expression de ce type. Un type énuméré est défini par un classeur possédant le stéréotype « enumeration » comme représenté sur la figure 4.9.

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 (comme nous l'avons fait sur la figure 4.4). 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 (comme nous l'avons fait sur la figure 4.7).

4-3-2-a. Syntaxe▲

context <élément>

4-3-2-b. Exemple▲

Un invariant exprime une contrainte prédicative sur un objet, ou un groupe d'objets, qui doit être respectée en permanence.

4-3-3-a. Syntaxe▲

inv : <expression_logique>

4-3-3-b. Exemple▲

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.

4-3-4-a. Syntaxe▲

4-3-4-b. Exemple▲

Ce type de contrainte permet de définir directement le résultat d'une opération.

4-3-5-a. Syntaxe▲

body : <requête>

4-3-5-b. Exemple▲

Parfois, une sous-expression est utilisée plusieurs fois dans une expression. let permet de déclarer et de définir la valeur (i.e. initialiser) d'un attribut qui pourra être utilisé dans l'expression qui suit le in.

def est un type de contrainte qui permet de déclarer et de définir la valeur d'attributs comme la séquence let…in. def permet également de déclarer et de définir la valeur retournée par une opération interne à la contrainte.

4-3-6-a. Syntaxe de let…in▲

let <déclaration> = <requête> in <expression>

4-3-6-b. Syntaxe de def▲

def : <déclaration> = <requête>

4-3-6-c. Exemple▲

Le type de contrainte init permet de préciser la valeur initiale d'un attribut ou d'une terminaison d'association.

Les diagrammes d'UML définissent parfois des attributs ou des associations dérivées. La valeur de tels éléments est toujours déterminée en fonctions d'autres éléments du diagramme. Le type de contrainte derive permet de préciser comment la valeur de ce type d'élément évolue.

Notez bien la différence entre ces deux types de contraintes. La contrainte derive impose une contrainte perpétuelle : l'élément dérivé doit toujours avoir la valeur imposée par l'expression de la contrainte derive. D'un autre côté, la contrainte init ne s'applique qu'au moment de la création d'une instance précisée par le contexte de la contrainte. Ensuite, la valeur de l'élément peut fluctuer indépendamment de la contrainte init.

4-3-7-a. Syntaxe▲

init : <requête>
derive : <requête>

4-3-7-b. Exemple▲

Le langage OCL possède un certain nombre de types prédéfinis et d'opérations prédéfinies sur ces types. Ces types et ces opérations sont utilisables dans n'importe quelle contrainte et sont indépendants du modèle auquel sont rattachées ces contraintes.

Le tableau 4.1 donne un aperçu des types et opérations prédéfinis dans les contraintes OCL. Les tableaux 4.2 et 4.3 rappellent les conventions d'interprétation des opérateurs logiques.

L'opérateur logique if-then-else-endif est un peu particulier. Sa syntaxe est la suivante :

if <expression_logique_0>
then <expression_logique_1>
else <expression_logique_2>
endif

Cet opérateur s'interprète de la façon suivante : si <expression_logique_0> est vrai, alors la valeur de vérité de l'expression est celle de <expression_logique_1>, sinon, c'est celle de <expression_logique_2>. 

Toute expression OCL est écrite dans le contexte d'un modèle UML donné. Bien entendu, tous les classeurs de ce modèle sont des types dans les expressions OCL attachées à ce modèle.

Dans la section 4.3.1Diagramme support des exemples illustratifs, nous avons introduit le type énuméré. Une contrainte OCL peut référencer une valeur de ce type de la manière suivante :

<nom_type_enuméré>::valeur

Par exemple, la classe Personne possède un attribut genre de type Genre. On peut donc écrire la contrainte :

context Personne
inv : genre = Genre::femme

Dans ce cas, toutes les personnes doivent être des femmes.

OCL est un langage typé dont les types sont organisés sous forme de hiérarchie. Cette hiérarchie détermine comment différents types peuvent être combinés. Par exemple, il est impossible de comparer un booléen (Boolean) avec un entier (Integer) ou une chaîne de caractères (String). Par contre, il est possible de comparer un entier (Integer) et un réel (Real), car le type entier est un sous-type du type réel dans la hiérarchie des types OCL. Bien entendu, la hiérarchie des types du modèle UML est donnée par la relation de généralisation entre les classeurs du modèle UML.

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.

Jusqu'à UML 2.0 exclu, 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.

Pour faire référence à un attribut ou une opération de l'objet désigné par le contexte, il suffit d'utiliser le nom de cet élément. L'objet désigné par le contexte est également accessible par l'expression self. On peut donc également utiliser la notation pointée : self.<propriété>.

Une opération peut avoir des paramètres, il faut alors les préciser entre les parenthèses de l'opération.

Lorsque la multiplicité d'un attribut, de type T, n'est pas 1 (donc s'il s'agit d'un tableau), la référence à cet attribut est du type ensemble (i.e. Set(T)).

Par exemple, dans le contexte de la classe Compte, on peut utiliser les expressions suivantes :

• solde ;
• self.solde ;
• getSolde() ;
• self.getSolde() ;
• débiter(1000) ;
• self.débiter(1000).

Dans l'exemple précédent, le résultat de l'expression self.débiter(1000) est un singleton du type Real. Mais une opération peut comporter des paramètres définis en sortie ou en entrée/sortie. Dans ce cas, le résultat sera un tuple contenant tous les paramètres définis en sortie ou en entrée/sortie. Par exemple, imaginons une opération dont la déclaration serait operation(out param_out : Integer):Real possédant un paramètre défini en sortie param_out. Dans ce cas, le résultat de l'expression operation(paramètre) est un tuple de la forme (param_out : Integer, result : Real). On peut accéder aux valeurs de ce tuple de la façon suivante :

operation(paramètre).param_out 
operation(paramètre).result

Pour faire référence à un objet, ou un groupe d'objets, en association avec l'objet désigné par le contexte, il suffit d'utiliser le nom de la classe associée (en minuscules) ou le nom du rôle d'association du côté de cette classe. Quand c'est possible, il est préférable d'utiliser le nom de rôle de l'association du côté de l'objet auquel on désire faire référence. C'est indispensable s'il existe plusieurs associations entre l'objet désigné par le contexte et l'objet auquel on désire accéder, ou si l'association empruntée est réflexive.

Le type du résultat dépend de la propriété structurelle empruntée pour accéder à l'objet référencé, et plus précisément de la multiplicité du côté de l'objet référencé, et du type de l'objet référencé proprement dit. Si on appelle X la classe de l'objet référencé, dans le cas d'une multiplicité de :

• 1, le type du résultat est X (ex. : ) ;

• * ou 0..n…, le type du résultat est Set(X) (ex. : ) ;

• * ou 0..n…, et s'il y a en plus une contrainte {ordered}, le type du résultat est OrderedSet(X) (ex. : ).

Emprunter une seule propriété structurelle peut produire un résultat du type Set (ou OrderedSet). Emprunter plusieurs propriétés structurelles peut produire un résultat du type Bag (ou Sequence).

Par exemple, dans le contexte de la classe Société (context Société) :

• directeur désigne le directeur de la société (résultat de type Personne) ;
• employé désigne l'ensemble des employés de la société (résultat de type Set(Personne)) ;
• employé.compte désigne l'ensemble des comptes de tous les employés de la société (résultat de type Bag(Compte)) ;
• employé.date_de_naissance désigne l'ensemble des dates de naissance des employés de la société (résultat de type Bag(Date)).

Une association qualifiée (cf. section3.3.6Qualification) utilise un ou plusieurs qualificatifs pour sélectionner des instances de la classe cible de l'association. Pour emprunter une telle association, il est possible de spécifier les valeurs, ou les instances, des qualificatifs en utilisant des crochets ([]).

Plaçons-nous dans le cadre du diagramme de la figure 4.10. Dans le contexte de banque (context Banque), pour faire référence au nom des clients dont le compte porte le numéro 19503800 il faut écrire :

self.client[19503800].nom

Dans le cas où il y a plusieurs qualificatifs, il faut séparer chacune des valeurs par une virgule en respectant l'ordre des qualificatifs du diagramme UML. Il n'est pas possible de ne préciser la valeur que de certains qualificatifs en en laissant d'autres non définis. Par contre, il est possible de ne préciser aucune valeur de qualificatif :

self.client.nom

Dans ce cas, le résultat sera l'ensemble des noms de tous les clients de la banque.

Ainsi, si on ne précise pas la valeur des qualificatifs en empruntant une association qualifiée, tout se passe comme si l'association n'était pas qualifiée. Dans ce cas, faites attention à la cardinalité de la cible qui change quand l'association n'est plus qualifiée (cf. section 3.3.6Qualification).

Pour naviguer vers une classe association, il faut utiliser la notation pointée classique en précisant le nom de la classe association en minuscules. Par exemple, dans le contexte de la classe Société (context Société), pour accéder au salaire de tous les employés, il faut écrire :

self.poste.salaire

Cependant, dans le cas où l'association est réflexive (c'est le cas de la classe association Mariage), il faut en plus préciser par quelle extrémité il faut emprunter l'association. Pour cela, on précise le nom de rôle de l'une des extrémités de l'association entre crochets ([]) derrière le nom de la classe association. Par exemple, dans le contexte de la classe Personne (context Personne), pour accéder à la date de mariage de toutes les femmes, il faut écrire :

self.mariage[femme].date

Il est tout à fait possible de naviguer directement depuis une classe association vers une classe participante.

Exemple :

context Poste
inv : self.employé.age > 21

Par définition même d'une classe association, naviguer depuis une classe association vers une classe participante produit toujours comme résultat un objet unique. Par exemple, l'expression self.employé.age de l'exemple précédant produit bien un singleton.

Quand une caractéristique définie dans une classe parente est redéfinie dans une sous-classe associée, la caractéristique de la classe parente reste accessible dans la sous-classe en utilisant l'expression oclAsType().

Supposons une classe B héritant d'une classe A et une propriété p1 définie dans les deux classes. Dans le contexte de la classe B (context B), pour accéder à la propriété p1 de B, on écrit simplement :

self.p1

et pour accéder à la propriété p1 de A (toujours dans le contexte de B), il faut écrire :

self.oclAsType(A).p1

L'opération oclAsType, que nous venons de décrire (section 4.5.6Accéder à une caractéristique redéfinie (oclAsType())), est une opération prédéfinie dans le langage OCL qui peut être appliquée à tout objet. Le langage OCL en propose plusieurs :

• oclIsTypeOf (t : OclType) : Boolean
• oclIsKindOf (t : OclType) : Boolean
• oclInState (s : OclState) : Boolean
• oclIsNew () : Boolean
• oclAsType (t : OclType) : instance of OclType

4-5-7-a. Opération oclIsTypeOf▲

4-5-7-b. Opération oclIsKindOf▲

4-5-7-c. Opération oclIsNew▲

4-5-7-d. Opération oclInState▲

Toutes les opérations que nous avons décrites jusqu'ici s'appliquaient sur des instances de classe. Cependant, OCL permet également d'accéder à des caractéristiques de classe (celles qui sont soulignées dans un diagramme de classes). Pour cela, on utilise le nom qualifié de la classe suivi d'un point puis du nom de la propriété ou de l'opération : <nom_qualifié>.<propriété>.

Le langage OCL dispose également d'une opération prédéfinie sur les classes, les interfaces et les énumérations (allInstances) qui retourne l'ensemble (Set) de toutes les instances du type au titre duquel elle est invoquée, au moment où l'expression est évaluée. Par exemple, pour désigner l'ensemble des instances de la classe personne (type set(Personne)) on écrit :

Personne.allInstances()

Comme nous l'avons vu dans la section précédente (4.5Accès aux caractéristiques et aux objets), pour accéder aux caractéristiques (attributs, terminaisons d'associations, opérations) d'un objet, OCL utilise la notation pointée : <objet>.<propriété>. Cependant, de nombreuses expressions ne produisent pas comme résultat un objet, mais une collection. Le langage OCL propose plusieurs opérations de base sur les collections. Pour accéder ce type d'opération, il faut, utiliser non pas un point, mais une flèche : <collection>-><opération>. Enfin, rappelons que pour désigner un élément dans un élément englobant on utilise les «::» (cf. Section 4.3.2Contexte (context) et 4.5.7Opérations prédéfinies sur tous les objets par exemple). En résumé :

• permet de désigner un élément (comme une opération) dans un élément englobant (comme un classeur ou un paquetage) ;

• permet d'accéder à une caractéristique (attributs, terminaisons d'associations, opérations) d'un objet ;

• permet d'accéder à une caractéristique d'une collection.

Nous avons dit dans la section 4.5.1Accès aux attributs et aux opérations (self) que l'objet désigné par le contexte est également accessible par l'expression self. self n'est pas uniquement utilisé pour désigner le contexte d'une contrainte dans une expression, mais également pour désigner le contexte d'une sous-expression dans le texte (en langage naturel). Ainsi, lorsque l'on utilise self pour une opération <opération>, c'est pour désigner l'objet (comme une collection par exemple) sur lequel porte l'opération. Cet objet peut être le résultat d'une opération intermédiaire comme l'évaluation de l'expression <expression> précédant l'opération <opération> dans l'expression complète : <expression>.<opération>.

Nous ne décrirons pas toutes les opérations sur les collections et ses sous-types (ensemble…) dans cette section. Référez-vous à la documentation officielle [19] pour plus d'exhaustivité.

4-6-2-a. Opérations de base sur les collections▲

4-6-2-b. Opérations de base sur les ensembles (Set)▲

4-6-2-c. Exemples▲

4-6-3-a. Syntaxe générale▲

<collection> -> <opération>( <expression> )

<collection> -> <opération>( <élément> | <expression> )

<collection> -> <opération>( <élément> : <Type> | <expression> )

<collection> -> <opération>( [ <élément> [ : <Type> ] | ] <expression> )

4-6-3-b. Opération select et reject▲

select( [ <élément> [ : <Type> ] | ] <expression_logique> )
reject( [ <élément> [ : <Type> ] | ] <expression_logique> )

4-6-3-c. Opération forAll et exists▲

forAll( [ <élément> [ : <Type> ] | ] <expression_logique> )
exists( [ <élément> [ : <Type> ] | ] <expression_logique> )

4-6-3-d. Opération collect▲

collect( [ <élément> [ : <Type> ] | ] <expression> )

self.employé->collect(date_de_naissance)

Ordre de précédence pour les opérateurs par ordre de priorité décroissante :

1. @pre
2. «.» et «->»
3. not et «-» (opérateur unaire)
4. «*» et «/»
5. «+» et «-»(opérateur binaire)
6. if-then-else-endif
7. «<», «>», «<=» et «>=»
8. «=» et «<>»
9. and, or et xor
10. implies

Les parenthèses, « ( » et « ) », permettent de changer cet ordre.