C’est avec OCL (Object Constraint Language) qu’UML formalise l’expression des contraintes . Il s’agit donc d’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.
OCL peut s’appliquer sur la plupart des diagrammes d’UML et permet de spécifier des contraintes sur l’état d’un objet ou d’un ensemble d’objets comme :
Nous avons dit que les contraintes pouvaient être écrites en langage naturel, alors pourquoi s’embarrasser du langage OCL ? L’intérêt du langage naturel est qu’il est simple à mettre en œuvre et compréhensible par tous. Par contre (et comme toujours), il est ambigu et imprécis, il rend difficile l’expression des contraintes complexes et ne facilite pas les références à d’autres éléments (autres que celui sur lequel porte la contrainte) du modèle.
OCL est un langage formel volontairement simple d’accès. Il possède une grammaire élémentaire (OCL peut être interprété par des outils) que nous décrirons dans les sections 4.3 à 4.6. OCL représente, en fait, un juste milieu entre le langage naturel et un langage très technique (langage mathématique, informatique, …). Il permet ainsi de limiter les ambiguïtés, tout en restant accessible.
Plaçons-nous dans le contexte d’une application bancaire. Il nous faut donc gérer :
De plus, on aimerait intégrer les contraintes suivantes dans notre modèle :
La figure 4.3 montre un diagramme de classes correspondant à la problématique que nous venons de décrire.
Figure 4.4: Ajout d’une contrainte sur le diagramme de la figure 4.3.
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.
Figure 4.5: Diagramme d’objets cohérent avec le diagramme de classes de la figure 4.4.
Figure 4.6: Diagramme d’objets cohérent avec le diagramme de classes de la figure 4.4, mais représentant une situation inacceptable.
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.