Vers une prise en compte des contraintes en UML grâce à Z

Vers une prise en compte des contraintes en UML grâce à Z
S. Dupuy
LSR-IMAG, BP 72, 38402 SAINT MARTIN D’HERES CEDEX
[e-mail], Tél : [phone], Fax : [phone]
[Catégorie Jeune Chercheur]
Résumé :
La prise en compte des relations statiques et dynamiques entre les acteurs et les objets du système est nécessaire à
une spécification correcte, mais il ne faut pas négliger celle des contraintes de domaine ou de gestion qui constituent
aussi des éléments de modélisation importants. Or les ateliers actuels supportent essentiellement la modélisation des
relations et assez faiblement les contraintes. Il serait pourtant bénéfique de disposer d’outils permettant de les
exprimer et de les valider. Pour permettre la validation des contraintes, nous proposons d’exploiter le potentiel de
raisonnement des langages formels.
Notre approche est basée sur l'expression des diagrammes UML et des contraintes dans un langage formel. Nous
présentons ici la traduction d’un sous-ensemble du diagrammes de classes d’UML et de ses contraintes, écrites en
OCL, vers Z. Les spécifications formelles ainsi obtenues peuvent être utilisées pour prouver la cohérence de
l’ensemble de contraintes. Mais la prise en compte des contraintes ne peut se faire efficacement que si des outils la
supportent. Pour la faciliter, nous proposons un outil intégrant l’expression des contraintes et automatisant la
génération des spécifications formelles Z. L’idée centrale de cet outil est que tout le travail de modélisation doit être
fait dans l’environnement UML. L’outil est basé sur un environnement industriel de modélisation UML complété par
des formulaires contenant les contraintes.
Mots-clé :
UML, contraintes, OCL, Z, support outil
Abstract :
The static and dynamic relationships between the system actors and objects, but also the domain and business
constraints must be taken into consideration in order to produce a consistent specification. Actual tools mainly
support relationships and forget constraints. It is nevertheless necessary to have tools which enable to express and to
validate them. In order to enable the validation of constraints, we propose to exploit the formal language power of
reasoning.
Our approach is based on the expression of the UML diagram and of its constraints in a formal language. We present
here the translation of a subset of the UML class diagram and of its constraints into Z. The formal specifications
obtained can be exploited to prove the consistency of the constraint set. But constraints can be taken into
consideration efficiently only if tools support them. To facilitate this, we propose a tool which integrates constraints
and automates the generation of Z formal specifications. The main point of this tool is that the whole modelling work
should be done in the UML environment. The formal specifications are seen only when it is necessary. The tool
could be based on an industrial UML modelling environment completed by forms containing the constraints.
Key word :
UML, constraints, OCL, Z, tool support

1 Introduction
En modélisation des systèmes d’information (SI), il n’est plus nécessaire aujourd’hui d’insister
sur l’importance de la prise en compte des relations statiques et dynamiques entre les acteurs et
les objets du système, mais aussi de celle des contraintes de domaine ou de gestion nécessaires à
une spécification correcte. Les ateliers de modélisation actuels insistent beaucoup sur l’apport de
l’outil comme moyen d’évaluer l’impact de l’évolution des systèmes afin de conserver une
spécification conforme aux applications développées. Cependant ils supportent essentiellement la
modélisation des relations et assez faiblement l’expression des contraintes et la validation des
cohérences que celles-ci sont sensées permettre.
Nous étudions ici la faisabilité d’un outil intégrant cette prise en compte des contraintes dans un
couplage fort à un environnement de spécification industriel. Nous proposons aussi un guidage
afin que la validation des contraintes et de la spécification du système puisse être mieux
maîtrisée. Nous avons fait le choix d’étudier nos propositions sur la notation UML [RATI97]
reconnue industriellement comme une évolution « standardisée » des méthodes d’analyse
orientées objet. Nous proposons qu’une modélisation UML et ses contraintes soient exprimées et
couplées à des spécifications formelles. Cette démarche est limitée à ce jour à la modélisation des
aspects statiques en vue d’aider à la validation de base de données (BD) traduisant la
modélisation du SI. L’outil Rational Rose sur lequel nous implantons cette démarche permet
effectivement la génération vers un certain nombre de systèmes de gestion de BD dont Oracle 8.
Comme les précédentes notations (OMT, OOSE, OOA…), UML ne permet pas d'exprimer toutes
les contraintes (comme par exemple, des clés sur les classes des objets). Plusieurs propositions
ont donc été faites pour permettre d'intégrer l'expression de contraintes de domaine à UML. La
première [OU98] propose d'étendre le méta-modèle d'UML pour ajouter à chaque classe une
partie textuelle exprimant des contraintes. La deuxième prévoit d'ajouter en commentaires aux
diagrammes, des contraintes exprimées dans un formalisme proche de la logique du premier
ordre. Avec la notation UML, est apparu un langage d'expression de contraintes OCL (Object
Constraints Language [WARM98]). Ce langage doit permettre d'exprimer les contraintes de
façon précise et non ambiguë. Contrairement à la première proposition, cette approche a
l’avantage de ne pas surcharger les notations graphiques. Mais OCL offre aujourd’hui une
sémantique pauvre et ne possède pas de support outil permettant d’exploiter les contraintes ; en
conséquence les contraintes exprimées peuvent être mutuellement incohérentes ou incohérentes
avec le diagramme qu’elles annotent. De plus, il n’existe pas de guide méthodologique pour
savoir où exprimer une contrainte afin de la rendre exploitable.
Or pour bénéficier pleinement de l’enrichissement apporté par les contraintes en détectant
d’éventuelles erreurs sans attendre l'implantation dans une base de données, il faut créer une
ingénierie qui les intègre réellement. Nous proposons d’exploiter ici le potentiel de raisonnement
des langages formels. Notre approche est basée sur l'expression concomitante des diagrammes
UML et des contraintes dans un langage formel. Les concepts d’UML traduits en squelettes de
spécifications formelles sont complétés par les contraintes.
Dans cet article, la traduction d'un sous-ensemble du diagramme de classes UML en Z
([SPIV95]) est présentée. Elle aide à localiser les limites d’expression du diagramme de classes
comme les « trous » des squelettes Z correspondant aux aspects qu’UML n’exprime pas.
L’identification de ces « trous » permet de classer les contraintes. Cette classification est utilisée
pour créer un guide méthodologique pour l’expression des contraintes sans connaissance des
aspects formels qui ont conduit à sa définition. Notre but n’est donc pas de proposer une n-ième

taxonomie de contraintes, mais de combiner des propriétés et des approches complémentaires :
UML pour son aspect structurel et ses qualités en terme de représentation graphique, Z dans le
cadre formel et les contraintes statiques selon les approches BD. Ces trois éléments combinés
sont pertinents pour obtenir des SI plus cohérents et plus rigoureux.
Mais la prise en compte de spécifications ou de contraintes ne peut se faire efficacement que si
des outils la supportent afin de permettre les adaptations et ré-évaluations qu’imposent les
évolutions de SI. Pour cela, nous proposons l’outil, RoZ, qui étend l’environnement Rational
Rose en offrant la possibilité d’annoter les diagrammes de classes UML avec des contraintes.
RoZ génère automatiquement les spécifications Z correspondant à un diagramme et à ses
contraintes afin de vérifier leur cohérence en utilisant les outils de Z. Ainsi l’impact des
évolutions sur la validation des contraintes est assuré grâce à une automatisation du processus de
génération de spécifications formelles et de vérification.
Nous décrivons au paragraphe 2 l'étude de cas qui illustre notre approche. Par facilité de
compréhension, celle-ci est davantage orientée système automatique, mais permet de montrer
l’impact des deux spécifications. Nous en proposons une modélisation en UML pour la partie
statique. Le paragraphe 3 présente, sur cette étude de cas, les règles de traduction du sous-
ensemble du diagramme de classes UML en Z. Il montre comment les contraintes du diagramme
sont intégrées aux squelettes de spécifications Z. Dans le paragraphe 4, nous décrivons l'outil
RoZ qui supporte à cette approche.
2 L'étude de cas du contrôleur d'accès
2.1 Description en langue naturelle
Notre étude de cas concerne un contrôleur d'accès à des bâtiments. Il s’agit avant tout d’un
exemple didactique illustrant chaque type de contraintes. Une description complète est donnée
dans [LEDR97]. Nous ne présentons ici qu'un résumé de ce document.
Un contrôleur d'accès doit être développé pour une entreprise. Chaque employé de l'entreprise a
accès à un ensemble de bâtiments de l'entreprise. Un accès, pour un employé donné et pour un
bâtiment donné, est autorisé sur la base de l'appartenance à un groupe. Chaque employé est
membre d'un seul groupe et un groupe peut accéder à un ensemble restreint de bâtiments.
Pour s'assurer que la politique d'accès décrite ci-dessus est respectée, chaque employé a une carte
magnétique unique et toutes les portes des bâtiments sont équipées de lecteurs de cartes. A
l'entrée ou à la sortie d'un bâtiment, l'employé doit insérer sa carte dans le lecteur. Si l'accès est
autorisé, la porte est débloquée et l'accès est enregistré dans une base de données.
2.2 Spécification du contrôleur d'accès en UML
Nous ne nous intéressons qu'à l'aspect statique du contrôleur d'accès. Nous utilisons donc un
diagramme de classes UML dont nous ne présentons ici qu’une version simplifiée (figure 1).
Quatre classes ont été identifiées :
• les employés (les personnes)
Une personne est caractérisée par son nom, son prénom, ses numéros de téléphone et le numéro
unique de sa carte d’accès.

• les groupes
Un groupe a un nom et un code.
• les bâtiments
Un bâtiment a une adresse physique et un code.
• les accès
La classe « ACCES » qui sert à enregistrer les accès de chaque employé aux bâtiments, devrait
en fait être un classe associative entre les classes « PERSONNE » et « BATIMENT ». Mais nous
simplifions le diagramme en faisant de « ACCES » une classe qui est en relation avec
« PERSONNE » et « BATIMENT ».
Les attributs d’« ACCES » correspondent aux instants d’entrée et de sortie d’une personne dans
un bâtiment.
En plus de la relation représentée par « ACCES », il existe deux autres relations. La première,
« Appartenir » entre « PERSONNE » et « GROUPE », est une association 1-n (une personne
appartient à un seul groupe et un groupe a pour membres plusieurs personnes). La deuxième,
« Acceder » entre « GROUPE » et « BATIMENT », est n-n : un groupe peut accéder à plusieurs
bâtiments et un bâtiment peut être accessible à plusieurs groupes.
A ce diagramme de classes, de nombreuses contraintes peuvent être ajoutées. Dans cet article,
nous nous intéresserons seulement aux contraintes suivantes :
1. les clés des classes sont : le numéro de carte pour « PERSONNE », le code ou le nom du
groupe pour « GROUPE », le code du bâtiment pour « BATIMENT » et la date d’entrée et la
personne pour « ACCES » ;
2. pour toute personne, on doit connaître au moins un numéro de téléphone ;
3. pour tout accès, on doit connaître la date d’entrée ;
4. quand elle est définie, la date de sortie d’un accès est postérieure à la date d’entrée ;
5. seule la date de sortie du dernier accès peut être inconnue ;
6. les personnes d'un même groupe ont le même préfixe téléphonique ;
7. un accès peut être enregistré dans la base de données seulement si la personne est autorisée à
entrer dans le bâtiment lié à l'accès.
BATIMENT
batimentcode
adresse
GROUPE
groupecode
groupenom
ACCES
dateentree
datesortie
PERSONNE
nom
prenom
tel
numcarte
Acceder AccesBatiment
AccesPersonneAppartenir
0..*
0..*
0..*
0..*
1..*
1
1
1
Les personnes d'un
même groupe ont le
même préfixe
téléphonique.
Figure 1 : Contrôleur d’accès - Diagramme de classes

En UML, ces contraintes peuvent être écrites en notes du diagramme de classes comme nous le
montrons pour la contrainte 6 (Figure 1). Quelle que soit la notation pour les exprimer (langue
naturelle, OCL …), cette solution surcharge le diagramme. De plus, il n'existe pas de guide
méthodologique pour savoir où une contrainte doit être ajoutée. Par exemple, on ne sait pas où
écrire la dernière contrainte (7) car elle porte sur tout le diagramme. C'est pourquoi nous
proposons un cadre permettant de considérer les contraintes de façon plus structurée. Il est basé
sur l'expression du diagramme de classes UML et de ses contraintes en une spécification formelle
Z.
3 Passage à une spécification formelle en Z
3.1 Démarche
L'approche proposée (figure 2) utilise la complémentarité des diagrammes UML et des
contraintes annotant ces diagrammes pour produire une spécification formelle :
1. Dans un premier temps, un diagramme de classes UML est décrit dans un éditeur de
diagrammes et complété par des annotations qui posent des contraintes sur les données. Les
annotations doivent être écrites dans un formalisme utilisant la logique du premier ordre et la
théorie des ensembles pour être exprimables en Z. En fait, elles peuvent être écrites en OCL.
2. Ce diagramme de classes est le point de départ d'un processus de traduction qui produit des
squelettes de spécifications formelles Z. La traduction garantit l'équivalence sémantique entre
le diagramme UML et la spécification formelle. Cette étape a déjà été beaucoup étudiée.
Actuellement la plupart des travaux s’intéressent à intégrer les modèles orientés objet et les
langages formels. Par exemple, des schémas de traduction ont été proposés pour la traduction
de modèles objet en VDM ([LALE95]) , en B ([FACO96, LANO96]) ou en Z ([FRAN97,
SHRO97]). Nous avons pour notre part déjà étudié l’intégration de spécifications formelles
exprimées en Object-Z dans des spécifications OMT ([DUPU98]). Mais nous sommes
revenus à une spécification en Z ([DUPU00]) afin de pouvoir intégrer des outils de preuve
qui ne sont pas disponibles en Object-Z.
3. Les squelettes de spécifications formelles sont complétés par les contraintes ajoutées au
diagramme de classes. Il existe de nombreuses classifications des contraintes d'intégrité qui
distinguent généralement les contraintes statiques des contraintes dynamiques. Dans ce
travail, nous ne nous intéressons qu'aux contraintes statiques. Des divers classifications
([AMGH94,DATE95,DELO82]), nous retiendrons qu'il existe trois types de contraintes
d'intégrité statiques: les conraintes intra-objet portant sur un ou plusieurs attributs d'un objet ;
les contraintes intra-classe qui portent sur plusieurs objets d’une classe et les contraintes
inter-classes portant sur plusieurs classes de la base de données. Nous pouvons prendre en
compte ces différents types de contraintes statiques, mais nous adoptons une classification
différente afin de pouvoir guider l'écriture des contraintes dans une démarche de
modélisation.
4. La spécification formelle est utilisée pour vérifier la cohérence des contraintes avec le
diagramme grâce à un prouveur Z. On peut, par exemple, vérifier que les opérations ne
violent pas les contraintes en calculant leur précondition ([LEDR98]).
5. Grâce au processus de traduction, les raisonnements effectués sur la spécification formelle
peuvent être reportés dans le diagramme de classes UML et ses annotations.