Interroger et vérifier des diagrammes de classes UML :

une approche fondée sur le modèle des graphes conceptuels

Interrogate and check UML class diagrams:

an approach based on the model of conceptual graphs

T. Raimbault D. Genest S. Loiseau

Laboratoire d’Étude et de Recherche d’Angers (LERIA)

2 boulevard Lavoisier 49045 ANGERS Cedex 01 - France

{thomas.raimbault, david.genest, stephane.loiseau}@info.univ-angers.fr

Résumé terrogation ou de vérification de ses diagrammes. Or, la

UML est le langage de modélisation objet de référence. Ce-
pendant, il ne fournit aucun moyen d’interrogation et de
vérification de ses diagrammes. Nous proposons une tra-
duction automatisable des diagrammes de classes UML
dans le modèle des graphes conceptuels. Ainsi, l’interro-
gation et la vérification de diagrammes de classes se fera
par l’utilisation d’opérateurs graphiques du modèle des
graphes conceptuels.
Mots Clef
UML, diagrammes de classes, graphes conceptuels, inter-
rogation, vérification.
Abstract
UML is the object modeling language of reference. Howe-
ver, it does not provide any means of interrogating and che-
cking its diagrams. We propose an automatizable transla-
tion from UML class diagrams into the model of concep-
tual graphs. Thus, interrogations and checkings of class
diagrams will be done by using graphic operators of the
model of conceptual graphs.
Keywords
UML, class diagrams, conceptual graphs, query, check.
1 Introduction
Unified Modeling Language [4] (UML) est le langage de
modélisation objet de référence. UML définit des nota-
tions, essentiellement graphiques, pour définir différents
types de diagrammes qui représentent différentes vues
et aspects d’un système à modéliser. Le diagramme de
classes est le plus important des diagrammes : il est le
cœur de la modélisation objet, il porte sur les classes et
leurs relations. Il faut bien noter qu’UML est un langage
et qu’à ce titre, il ne fournit pas un environnement d’in-
démarche de construction d’une modélisation nécessite de
la part du concepteur des consultations des parties de dia-
grammes déjà écrites pour avancer. De plus, pour valider
ses diagrammes, le concepteur devrait pouvoir préciser lui
même des spécifications sur ses diagrammes en vue d’une
vérification automatique.
Évidemment, il existe des outils commerciaux qui, tels
Rational Software Rose [13] ou Borland Together [5],
sont des éditeurs de diagrammes UML. Ils incluent des
outils d’interrogation et de vérification de diagrammes.
Cependant, d’une part les possibilités de questionnement
sur les diagrammes sont limitées à un cadre pré-formaté
de requêtes. D’autre part, les vérifications proposées sont
standard, c’est-à-dire uniquement liées à la sémantique du
modèle objet. Le but de cet article est de présenter une
méthode nouvelle et graphique pour interroger et vérifier
de manière plus complète des diagrammes de classes
UML. Cette méthode s’intègre au modèle des graphes
conceptuels qui est un modèle de représentation, de raison-
nement et de visualisation des connaissances.
Le modèle des graphes conceptuels (GCs) est un modèle
formel de représentation des connaissances, de la fa-
mille des réseaux sémantiques [16]. Sowa [20] a intro-
duit ce modèle muni d’une sémantique logique, et par
la suite de nombreuses extensions ont été proposées. De
façon générale, l’utilisation du modèle des GCs pour
modéliser un domaine se fait en deux étapes : d’abord la
définition d’un support qui spécifie et organise le vocabu-
laire représentant les connaissances du domaine, ensuite les
GCs qui modélisent les connaissances factuelles. Nous uti-
lisons dans cet article le modèle issu de [6, 17] et étendu
aux GCs emboı̂tés typés [7, 9], avec liens de coréférence
[8], règles [19, 3] et contraintes [1, 3]. L’article peut se lire
sans une connaissance précise de ce modèle, toutefois l’an-
nexe rappelle les définitions de ce modèle. Ce modèle for-
 F IG . 1 – Processus global de notre approche
mel de représentation est largement visuel et fournit des
opérations qui sont adéquates et complètes vis à vis de la
déduction en logique du premier ordre [20, 6, 9, 21, 15].
La Figure 1 présente le processus global de notre approche.
L’idée clef de notre travail est de coder les différentes no-
tations UML dans une ontologie, appelée ontologie UML,
qui est définie dans un support du modèle des GCs. Ainsi,
un diagramme de classes UML donné peut être automati-
quement traduit en un GC, défini sur l’ontologie UML, qui
lui est équivalent et que nous appelons GC-diagramme de
classes. On peut alors utiliser les outils de visualisation et
de raisonnement qu’offre le modèle des GCs pour interro-
ger et vérifier des diagrammes de classes.
En plus d’une intégration des diagrammes de classes UML
dans une modélisation GCs, ce travail fournit deux contri-
butions fondamentales. La première contribution est une
méthode graphique pour vérifier la validité de diagrammes
de classes. Deux approches complémentaires sont four-
nies pour cette vérification. D’une part, nous proposons de
définir et d’utiliser des spécifications orientées objet. Ces
spécifications sont utilisées pour vérifier la validité de dia-
grammes de classes selon les concepts objet. Par exemple,
une telle spécification peut préciser qu’il ne doit pas y
avoir de cycle de la relation d’héritage dans un diagramme
de classes. Par rapport aux outils UML existants, notre
méthode permet le même type de vérification, avec en plus
une présentation explicite et visuelle des spécifications : le
concepteur n’a pas à manipuler des boı̂tes noires dont il
n’a pas le contrôle. D’autre part, nous offrons la possibilité
au concepteur de créer ou d’adapter, par un langage visuel
et intuitif, des spécifications particulières au domaine qu’il
modélise. On les appelle des spécifications du domaine. Par
exemple, une telle spécification peut préciser que chaque
classe du diagramme de classes doit être nécessairement
associée à une autre classe. Notre processus de vérification
intègre ces deux catégories de spécifications sous forme de
contraintes exprimées dans le modèle des GCs. La seconde
contribution est la possibilité d’interroger interactivement
et visuellement le contenu de diagrammes de classes. Par
exemple, on peut interroger un diagramme de classes pour
savoir si la classe ‘FourWheelDrive’ hérite de la classe
‘Car’. Le concepteur dessine sa requête, de façon intuitive,
en s’appuyant sur l’ontologie UML : une requête est un
graphe conceptuel.
Nous proposons aussi une interface tout UML pour l’uti-
lisateur de notre méthode qui souhaite travailler uni-
quement avec les diagrammes de classes UML, et ne
souhaite pas connaı̂tre le modèle des GCs. Certaines
requêtes et spécifications peuvent être fournies dans une
représentation issue de UML. Le modèle des GCs est alors
transparent pour l’utilisateur.
Cet article est organisé comme suit. La Section 2 présente
l’ontologie UML qui définit et organise les notations
UML. La Section 3 présente notre solution pour traduire
un diagramme de classes UML en un GC-diagramme
de classes. La Section 4 indique comment interroger
un GC-diagramme de classes. La Section 5 présente les
spécifications orientées objets, les spécifications du do-
maine, et comment les vérifier. La Section 6 propose
une interface tout UML pour interroger et vérifier des
diagrammes de classes UML. La section 7 discute des
résultats et des perspectives de notre méthode.
2 Modélisation des notations UML
dans l’ontologie UML
Une description succincte sur les diagrammes de classes
UML et de leurs composants est rappelée en Section 2.1.
La Section 2.2 définit et organise les différentes notations
UML au sein d’un support de graphes conceptuels, que
nous appelons ontologie UML.
2.1 Courte description du diagramme de
classes UML
UML, Unified Modeling Language [4], définit plusieurs
types de diagrammes pour représenter différents aspects et
vues d’un système. Dans cet article, nous nous intéressons
au diagramme de classes qui est le cœur de la modélisation
objet. Il représente la structure statique d’un système,
c’est-à-dire les éléments du système, leurs caractéristiques
internes et leurs rapports avec d’autres éléments. Les
éléments du système sont modélisés en classes, et il existe
deux sortes de relations entre classes : la généralisation et
le lien d’association.
Nous présentons par un exemple volontairement simpliste
dans un souci de clarté, en Figure 2, les principaux
éléments d’un diagramme de classes. Sur cette figure, la
classe Car est modélisée par un rectangle qui contient le
nom de la classe dans le compartiment du haut, les at-
tributs band et makingDate dans le compartiment cen-
 F IG . 2 – Exemple de diagramme de classes
tral, et l’opération moveOff dans le compartiment du bas.
Cette opération a deux paramètres, le premier est une ins-
tance de la classe Driver et le second du type prédéfini
int, et retourne un bool. Une relation de généralisation
est représentée par une flèche à pointe blanche tracée
de la classe spécialisée vers la classe générale. Ainsi, la
classe FrontWheelDrive a pour généralisation la classe
TwoWheelDrive, et la classe Car a pour sous-classes les
classes FourWheelDrive, TwoWheelDrive et FrontWheel-
Drive. Une association entre les classes Driver et Car est
définie par la classe d’association Rental et par les pro-
priétés présentes aux extrémités de l’association, comme
la multiplicité 0..N. La classe d’association est représentée
comme une classe, qui est liée par une ligne pointillée à la
ligne pleine qui symbolise l’association.
2.2 Ontologie UML
Nous définissons et organisons le vocabulaire ontologique
de modélisation orienté objet en une structure que nous ap-
pelons ontologie UML. Cette dernière est basée sur [4].
Définition 1 (Ontologie UML). L’ontologie UML est un
support de GCs (Définition 8), où les notations UML sont
définies et organisées dans l’ensemble des types concepts
(Figure 3), les ensembles des types relations (Figure 4) et
l’ensemble des types d’emboı̂tements (Figure 5).
La Figure 3 présente les notations UML qui sont
hiérarchiquement ordonnées entre elles, par une relation
sorte-de. Par exemple class est une sorte-de type. La
Figure 4 présente les différentes associations possibles
entre les concepts. La Figure 5 donne les différents types
d’emboı̂tements où des graphes peuvent s’emboı̂ter au
sein d’un concept pour mieux le décrire. Cette ontolo-
gie UML a pour but de séparer d’un côté les notations
UML et d’un autre côté une modélisation particulière d’un
domaine. Ainsi, toute modélisation en un diagramme de
classes UML utilise - s’appuie sur - cette même ontologie
UML, et peut ensuite être traduite automatiquement en un
graphe conceptuel particulier, GC-diagramme de classes.
3 GC-diagramme de classes
Nous indiquons maintenant comment traduire un dia-
gramme de classes UML en un GC équivalent, noté GC-
diagramme de classes. Cette traduction est complètement
automatisable.
Définition 2 (GC-diagramme de classes). Un GC-
diagramme de classes est un GC (Définition 9) qui d’une
part est défini sur l’ontologie UML, conformément aux
Propositions 1, 2, 3, 4, 5 et 6, et qui d’autre part est en
forme normale locale (Définition 12).
Chaque classe, attribut, opération ou propriété (Section
3.1) est modélisé par un sommet concept du type ap-
proprié. Les différents éléments qui décrivent un même
sommet concept y sont emboı̂tés. Un emboı̂tement à
l’intérieur d’un sommet concept est une description par-
tielle de ce sommet concept. Notons qu’un même sommet
concept peut avoir différents types d’emboı̂tement. Chaque
relation entre les classes (Section 3.2) est modélisée, soit
par un sommet relation de type ‘généralisation’, soit par
un sommet relation de type ‘association’.
Nous nous contentons d’un exemple simple de GC en Fi-
gure 6 pour présenter ce qu’est un GC. Le GC de cette
figure, défini sur le support en Figures 3 et 4, peut être in-
tuitivement interprété par : “FourWheelDrive (qui est de
type class) a pour generalization la classe Car”. Un som-
met concept est représenté par un rectangle [typeConcept:
marqueurIndividuel], et un sommet relation par une ellipse
(typeRelation). Pour plus de détails, consulter les annexes
ainsi que [20, 17].
F IG . 6 – Exemple de graphe conceptuel
3.1 Caractéristiques internes des classes
Les propositions suivantes indiquent comment traduire une
classe, ses propriétés et ses membres 1 dans le formalisme
des graphes conceptuels.
1 Attributs et opérations d’une classe sont appelés membres de la
classe.
 F IG . 3 – Ensemble des types de concepts

F IG . 4 – Ensembles des types de relations

F IG . 5 – Ensemble des types d’emboı̂tements

Proposition 1 (Classe d’un GC-diagramme de classes).
Une classe est représentée par un sommet concept indivi-
duel c de type class dont le marqueur individuel est le nom
de la classe.
Les propriétés (Proposition 2) sont emboı̂tées au sein de c
dans un emboı̂tement de type propertiesDescription.
Les membres (Propositions 3 et 4) d’une classe sont
emboı̂tés dans un emboı̂tement de type membersDescrip-
tion de c.
Proposition 2 (Propriété et GC-diagramme de classes).
Une propriété d’une classe est représentée par un sommet
concept dont le type est un sous-type de classProperty ou
un sous-type de visibility.
Une propriété d’un attribut (resp. opération) d’une classe
est représentée par un sommet concept dont le type est un
sous-type de attributeProperty (resp. operationProperty) ou
un sous-type de visibility.
Les propriétés d’une classe ou d’un membre d’une classe
sont respectivement emboı̂tées dans l’emboı̂tement de type
propertiesDescription du sommet concept représentant la
classe ou le membre.
Proposition 3 (Attribut et GC-diagramme de classes).
Un attribut d’une classe est représenté par un sommet
concept individuel dont le type est attributeInstance si l’at-
tribut est instance d’une classe, attributeDataType si l’at-
tribut est de type prédéfini. Le marqueur individuel est le
nom de l’attribut préfixé par ‘attr ’.
Le type d’un attribut, au sens objet du terme, est un som-
met concept de la forme [class : nomclasse] si l’attribut
est instance d’une classe. Sinon il est de la forme [da-
taType : nomtype]. La multiplicité d’un attribut est un
sommet concept individuel dont le type est multiplicity et
le marqueur individuel est la valeur de multiplicité. Le
type de l’attribut et la multiplicité sont tous deux dans
un emboı̂tement de type attributeDescription du sommet
concept représentant l’attribut.
Proposition 4 (Opération, paramètre et GC-diagramme
de classes). Une opération d’une classe est représentée
par un sommet concept individuel dont le type est opera-
tion. Le marqueur individuel est formé de la signature 2 de
l’opération. Il est construit de la façon suivante : un préfixe
‘op ’, suivi du nom de l’opération, le caractère ‘ ’ et les
types de chaque paramètre séparés par ‘ ’.
Un paramètre est représenté par un sommet concept de
type instance ou dataType s’il s’agit de l’instance d’une
classe ou d’un type prédéfini. Il possède un marqueur indi-
viduel si le nom du paramètre existe. Dans ce cas, le mar-
queur individuel est le nom du paramètre préfixé par ‘pa-
ram ’. De même que pour un attribut, le type du paramètre
est un sommet concept de la forme [class : nomclasse] ou
[dataType : nomtype].
La direction du paramètre est représenté par un sommet
concept dont le type est un sous type de direction. Le
2 La signature d’une opération est un ensemble qui regroupe les types
des paramètres de l’opération, sauf le type retourné.
F IG . 7 – La classe Car du GC-diagramme de classes
représenté au format GC.
type du paramètre ainsi que sa direction sont dans un
emboı̂tement de type dataDescription du sommet concept
représentant le paramètre.
Les paramètres d’une opération sont associés par un som-
met relation parameterX, en respectant l’ordre d’appari-
tion des paramètres et où X indique le nombre de pa-
ramètres. Le paramètre de retour est associé à un sommet
relation unaire return.
La Figure 7 représente la classe Car de la Figure 2 tra-
duite au format GC. Cette classe est modélisée par un som-
met concept de type ‘class’ avec un marqueur individuel
‘Car’. Ce sommet possède deux emboı̂tements : un de type
‘propertiesDescription’ et l’autre de type ‘membersDes-
cription’. Les sommets concepts qui sont emboı̂tés dans
le premier emboı̂tement correspondent aux propriétés de
la classe. Par exemple, la classe Car est publique et non
abstraite. Les sommets concepts qui sont emboı̂tés dans
le second emboı̂tement correspondent aux membres de la
classe. L’attribut band est modélisé par un sommet concept
de type ‘attributeInstance’ avec un marqueur individuel
‘attr band’. Ce sommet concept a deux emboı̂tements. Le
premier de type ‘propertiesDescription’ regroupe les pro-
priétés de l’attribut. Le second de type ‘attributeDescrip-
tion’ regroupe le type et la multiplicité de l’attribut. Ainsi,
l’attribut band est une instance de la classe ‘String’ avec
une multiplicité de ‘1’. L’opération moveOff possède deux
paramètres : le premier, driver, est une instance de la
classe Driver, et le second une donnée sans nom de type
prédéfini ‘int’. En effet, le sommet concept individuel ‘pa-
ram driver’ de type ‘instance’ est lié par la première arête
du sommet relation de type ‘parameter2’, et le sommet
concept générique de type prédéfini ‘int’ à la seconde
arête de cette relation binaire. L’opération retourne un type
prédéfini ‘bool’. Le choix de préfixer le noms des attributs
par ‘attr ’ et ceux des opération par ‘op ’ rend possible la
modélisation par exemple d’un attribut et d’une opération,
d’une même classe, qui portent le même nom. Le choix
d’utiliser la signature d’une opération et pas uniquement
 F IG . 8 – Liens de généralisation et d’association de la Figure 2 représentée au format GC
son nom permet de représenter la surcharge d’opérations.
3.2 Relations entre les classes
Il existe deux sortes de relations entre les classes : la
généralisation et l’association. Les définitions suivantes in-
diquent comment traduire de telles relations dans le forma-
lisme des graphes conceptuels.
Proposition 5 (Généralisation et un GC-diagramme de
classes). Une relation de généralisation entre deux classes
est modélisée par un sommet relation de type generaliza-
tion. Le premier voisin de cette relation est la classe la plus
spécifique, le second est la classe la plus générale.
Une association spécifie les connexions existantes entre
plusieurs classes d’un système. Nous avons fait le choix
de toujours représenter une association dans sa forme la
plus complète, c’est-à-dire par l’intermédiaire d’une classe
d’association et en informant comment chaque classe
de l’association y participe. Ainsi, une association est
constituée d’un élément central : une classe d’association.
Les classes qui font partie de l’association sont appelées
classes d’extrémité.
Notons une limitation à notre travail de traduction entre
UML et GC. Cette limitation porte sur la notion de cardi-
nalité qui est absente dans le modèle des GCs. Toutefois
nous exploitons pour le moment les différentes valeurs de
multiplicité de façon symbolique.
Proposition 6 (Association et un GC-diagramme de
classes). Une classe d’association est modélisée par un
sommet concept de type associationClass.
Un sommet relation de type association a trois voisins :
le sommet concept de type associationClass, un sommet
concept qui correspond à une classe d’extrémité et un som-
met concept de type associationEnd.
Les propriétés qui caractérisent comment une classe
d’extrémité prend part à l’association sont représentés
par des sommets concepts de type multiplicity et de sous-
types de associationProperty. Ils sont tous regroupés dans
l’emboı̂tement de type propertiesDescription du sommet
concept de type associationEnd.
La Figure 8 montre les relations existantes entre les classes
du diagramme de classes de la Figure 2, lequel est traduit
en un GC-diagramme de classes. Pour des questions de li-
sibilité de la Figure 8, les propriétés et membres des classes
sont suggérées par ‘. . .’ dans les sommets concepts. Le lien
de généralisation entre les classes Car et FourWheeldrive
par exemple est représenté par un sommet relation de type
‘generalization’. On lit cette relation “la classe FourWheel-
drive a pour généralisation la classe Car”. L’association
entre les classe Car et Driver est centralisée par un sommet
concept de type ‘associationClass’ et de marqueur indivi-
duel ‘Rental’. Les sommets relation de type ‘association’
lient la classe d’association, les classes d’extrémité et les
détails qui caractérisent le rôle joué par ces dernières dans
l’association.
4 Interroger des GC-diagrammes de
classes
Le modèle des GCs fournit un ensemble d’opérateurs gra-
phiques qui sont adéquats et complets vis à vis de la
déduction en logique du premier ordre. Il est donc possible
de raisonner sur des GC-diagrammes de classes, contrai-
rement aux diagrammes de classes UML. Une première
forme de raisonnement est le fait de pouvoir interro-
ger des diagrammes de classes. Par exemple, il peut être
intéressant de connaı̂tre “les opérations publiques d’une
classe donnée” ou de chercher “les sous-classes non abs-
traites d’une certaine classe”.
Nous avons fait le choix d’exprimer explicitement toutes
les informations contenues dans un diagramme de classes.
Or, la transitivité du lien de généralisation, une notion im-
portante en modélisation objet, est implicite dans un dia-
gramme de classes UML. L’application de règles, au sens
graphe conceptuel du terme, permet de rendre explicite ce
genre de propriétés. Ainsi, la notion sous-classe peut alors
être ajoutée puis utilisée pour interroger un GC-diagramme
de classes.
La Section 4.1 fait l’état de ce que sont les règles dans
le modèle des GCs, et présentent deux règles pour expri-
mer la transitivité du lien de généralisation. La Section 4.2
présente comment interroger un GC-diagramme de classes.
4.1 Règles et GCs
Une règle [19, 3] permet d’ajouter de nouvelles connais-
sances à un GC. Elle est de la forme : “si G1 alors G2 ”, où
G1 et G2 sont des GCs. Une règle est donc composée d’une
hypothèse et d’une conclusion. Elle est utilisée de la façon
suivante : soit un GC G, si l’hypothèse de la règle peut être

F IG . 9 – La transitivité du lien de généralisation exprimée
explicitement par ces deux règles
F IG . 10 – Fermeture du GC-diagramme de classes par l’ap-
plication des règles de la Figure 9
trouvée dans G, alors les connaissances contenues dans la
conclusion de la règle sont ajoutées à G. Nous utilisons
ici les notations de [3] : la représentation d’une règle est
un graphe bicolore, que nous étendons aux GCs emboı̂tés
typés.
Définition 3 (Règle et fermeture de GC [19, 3]). Une
règle est un graphe conceptuel bicolore, repéré par ⇒ ,
où l’hypothèse est formée de l’ensemble des sommets sur
fond blanc, et la conclusion de l’ensemble des sommets sur
fond noir. Une règle R est dite applicable à un GC G si il
existe une projection (Définition 10), nommée Π, de l’hy-
pothèse de R dans G. Dans ce cas, le résultat de l’appli-
cation de R dans G selon Π est le GC GR obtenu à partir
de G auquel on a ajouté la conclusion de R et les arêtes
adéquates qui lient cette conclusion au graphe initial.
La fermeture d’un graphe G par un ensemble de règles est
obtenue lorsque toute information qui est ajoutée par une
règle est déjà présente dans G.
La Figure 9 montre deux règles R1 et R2 qui expriment
explicitement la transitivité du lien subClass, on parle alors
d’héritage et de sous-classe. L’hypothèse de R1 , sur fond
blanc, est constituée d’une classe qui a pour généralisation
une autre classe. La conclusion de R1 , sur fond noir, est que
la deuxième classe a pour sous-classe la première classe.
En d’autres termes, R1 exprime que “si la classe X a pour
généralisation Y, alors Y a pour sous-classe X”. La règle
R2 exprime que “si la classe X a pour sous-classe Y et Y a
pour sous-classe Z, alors X a pour sous-classe Z”.
L’application des deux règles en Figure 9 sur le diagramme
de classes en Figure 2, préalablement traduit dans le forma-
lisme de GCs, a pour résultat le GC de la Figure 10. Ainsi,
aux relations de généralisation créées par l’utilisateur, car
présentes en Figure 2, sont ajoutées par R1 et R2 les rela-
tions transitives sous-classes.
4.2 Interroger des GC-diagrammes de
classes
En s’appuyant sur l’ontologie UML, il est possible d’in-
terroger un diagramme de classes. Une requête s’exprime
simplement par un GC défini sur l’ontologie UML. L’idée
est de trouver si la requête pourrait coı̈ncider avec une par-
tie ou sous-partie du GC-diagramme de classes. Dans ce
cas, les réponses à la requête sont les sommets concepts
du GC-diagramme de classes pour lesquels les sommets
concepts génériques de la requête coı̈ncident.
Remarquons que la définition d’un GC-diagramme de
classes ainsi que la formulation d’une requête sont situées
sur un même niveau de représentation : celui du modèle
des GCs. Ainsi, une requête peut faire intervenir toute
connaissance présente dans tout l’environnement GC. Elle
n’est pas limitée aux travers de boı̂tes de dialogues qui
présupposent de la teneur des requêtes.
Définition 4 (Résultat d’une requête). Le résultat d’une
requête Q, définie sur l’ontologie UML, sur un GC-
diagramme de classes D est l’ensemble de projections de
Q sur D.
F IG . 11 – Exemple de requête et ses résultats
Supposons que nous voulions interroger le diagramme de
classes de la Figure 2 comme suit : “La classe Car a-t-elle
des sous-classes qui sont publiques ?”. Cette question est
représentée par la requête située à côté gauche de la Figure
11. En effet, cette requête montre la classe Car modélisée
par un sommet concept de type ‘class’ avec un marqueur
individuel ‘Car’. Cette classe possède une sous-classe qui
n’est pas identifiée. Cette dernière est donc représentée par
un sommet concept de type ‘class’ mais dont le marqueur
individuel n’est pas précisé (marqueur générique *). Cette
requête admet un premier résultat qui est : “oui, la classe
Car a des sous-classes” ; et donne les trois sous-classes so-
lutions : FourWheelDrive, TwoWheelDrive et FrontWheel-
Drive.
5 Vérifier des GC-diagrammes de
classes
Il y a deux catégories de vérifications, qui sont exprimées
par des spécifications orientées objet et des spécifications
du domaine. Les premières spécifications sont employées
pour effectuer des contrôles sur les diagrammes de classes
qui doivent être en accord avec les concepts orientés ob-
jet. Les secondes spécifications expriment les besoins de
l’utilisateur face aux caractéristiques et à des objectifs liés
au domaine à modéliser. Les spécifications orientées objet
et les spécifications du domaine sont représentées par des
contraintes dans le modèle des GCs.

Définition 5 (Validité d’un GC-diagramme de classes). F IG . 12 – Exemple de spécifications orientées objet

Un GC-diagramme de classes est valide si et seule-
ment si il satisfait les deux catégories de spécifications :
spécifications orientées objet et spécifications du domaine.

La Section 5.1 fait l’état de ce que sont les contraintes

dans le modèle des GCs. Les Section 5.2 et 5.3 présentent
respectivement les spécifications orientées objet et les
spécifications du domaine.
5.1 Contraintes et GCs
Nous employons deux types de contraintes : les contraintes
positives et les contraintes négatives, avec les notations de
[2, 3] que nous étendons aux GCs emboı̂tés typés.
Définition 6 (Contraintes et GCs emboı̂tés typés). Une
contrainte positive est un GC emboı̂té typé bicolore. La
condition de la contrainte est sur fond blanc et l’obligation
sur fond noir. Une contrainte négative est un GC emboı̂té
typé unicolore sur fond noir. Une contrainte positive et
négative sont respectivement repérées par + et − .
Définition 7 (Satisfaction de contrainte [2, 3]). Un GC G
satisfait une contrainte positive C, si toute projection de la
condition de C dans G peut être étendue à une projection
de C (condition et obligation) dans G. Un GC G satisfait
une contrainte négative C, s’il n’existe pas de projection
de C dans G.
5.2 Spécifications orientées objet
Pour être en accord avec les concepts orientés ob-
jet, un diagramme de classes doit satisfaire toutes les
spécifications appropriées. Ces spécifications, que nous ap-
pelons spécifications orientées objet, sont données dans le
formalisme des GCs en tant que contraintes positives et
négatives.
La Figure 12 montre une contrainte négative C1 et une
contrainte positive C2 . C1 exprime l’interdiction suivante :
“une classe X ne peut être une sous-classe de Y, qui est
une sous-classe de X”. Donc, cette contrainte vérifie qu’il
n’y a pas de cycle d’héritage. La condition de C2 est une
classe avec une opération abstraite, et cette classe a pour
sous-classe une autre classe qui n’est pas abstraite. L’obli-
gation de C2 est “si la sous-classe a une opération o qui
F IG . 13 – Exemple de spécifications du domaine
est la redéfinition d’une opération abstraite de la classe
plus générale, alors o doit être non abstraite”. Ainsi, cette
contrainte positive indique que si une classe X possède
des opérations abstraites, alors une sous-classe Y de X
est non abstraite seulement si les opérations abstraites de
X sont redéfinies comme non abstraites dans Y. Le lien
de coréférence (Définition 11) entre les deux sommets
concepts génériques de type ‘operation’ indique qu’il s’agit
du même individu.
5.3 Spécifications du domaine
Les spécifications du domaine permettent de modéliser,
en plus des spécifications orientées objet, des contraintes
que l’utilisateur aurait besoin selon des caractéristiques et
des objectifs propres à un projet donné. Ces spécifications
sont exprimées dans le formalisme des GCs en tant que
contraintes positives et négatives.
A titre d’exemple, la contrainte positive C3 dans la Figure
13 indique que toute classe doit être associée à une autre
classe. Rappelons que dans cet article, toute association est
modélisée dans sa forme la plus complète, c’est-à-dire par
l’intermédiaire d’une classe d’association. La contrainte
négative C4 représente le fait qu’aucune classe ne doit pas
être abstraite.
6 Interface tout UML
L’utilisation du modèle des GCs, par un ensemble d’outils
existants, nous permet une modélisation de la connaissance
qui dépasse les diagrammes de classes UML. L’utilisateur
de notre méthode peut souhaiter travailler uniquement sur
les diagrammes de classes, et pas forcément connaı̂tre le
modèle des GCs. C’est pourquoi nous proposons ici une
approche de raisonnement utilisant essentiellement des no-
tations UML pour décrire les requêtes et spécifications.
 mat XMI [18, 11] dans le formalisme des GCs emboı̂tés
typés au format BCGCT [12]. Cette traduction porte sur les
classes, attributs, opérations et leurs propriétés respectives,
ainsi que sur les relations de généralisation ou d’associa-
tion entre classes. D’autre part, règles et contraintes ont été
écrites pour vérifier des diagrammes de classes et satisfaire
aux concepts objet. La vérification tout comme l’interroga-
tion d’un GC-diagramme de classes, ont été testées sur la
plateforme CoGITaNT [10]. Les résultats obtenus sur des
F IG . 14 – Requête au format UML
exemples simples de diagrammes de classes sont tout à fait
satisfaisants. Ils fournissent les exigences souhaitées et ce
de façon quasi instantanée. Une interface permet à l’utili-
sateur de formuler ses requêtes et vérifications dans un for-
malisme UML. Ainsi, le modèle des GCs peut être trans-
parent pour l’utilisateur qui le désire.
Il serait intéressant de généraliser l’approche de notre
méthode graphique de modélisation, d’interrogations et de
vérifications aux différents types de diagrammes UML.
Cette extension, écrite en graphes conceptuels, offrira
ainsi un formalisme unique et visuel pour modéliser tous
types de diagrammes UML ainsi que des requêtes et des
vérifications à effectuer sur et entre ces derniers.

Références
F IG . 15 – Spécifications orientées objet et du domaine au
format UML
Pour cela, on a besoin de deux nouvelles notations : les va-
riables (pour les requêtes) et la bicoloration de diagrammes
(pour les spécifications). Cette extension du langage UML
a été adaptée par nos soins sur l’outil logiciel Poseidon SE
[11]. Elle est cependant limitée car on ne peut pas tout co-
lorier en UML, alors qu’en GC cela est possible puisque
nous avons fait le choix d’exprimer explicitement toutes
les informations contenues dans un diagramme de classes.
Nous nous contentons d’illustrer cette interface par un
exemple de requête, et en reprenant les spécifications des
figures 12 et 13. Prenons la requête présentée en Figure
14, demandant si “la classe FourWheelDrive a une classe
mère ?”. Elle est formulée par le diagramme requête à
gauche de la figure, où la classe FourWheelDrive a pour
généralisation une classe inconnue, repérée par ‘$’. La
réponse à cette requête est formée des éléments du dia-
gramme de classes en Figure 2 dans lesquels ceux de la
requêtes se sont projetés. Ainsi, la classe FourWheelDrive
a bien une classe mère qui est identifiée : la classe Car.
La Figure 15 présente respectivement la définition des
spécifications C1 à C4 des Figures 12 et 13, mais cette
fois-ci sous forme de notations UML. Remarquons que
pour les spécifications présentées Figure 15, le lien de
généralisation est considéré comme transitif.
7 Conclusion et travaux futurs
Un prototype a été développé pour d’une part réécrire
automatiquement un diagramme de classes UML au for-
[1] J.F. Baget, D. Genest, and M.L. Mugnier. Knowledge
acquisition with a pure graph-based knowledge re-
presentation model. In Proc. of KAW’99, volume 2,
pages 7.1.1–7.1.20, 1999.
[2] J.F. Baget, D. Genest, and M.L. Mugnier. A pure
graph-based solution to the SCG-1 initiative. In Proc.
of ICCS’99, volume 1640 of LNAI, pages 355–376.
Springer, 1999.
[3] J.F. Baget and M.L. Mugnier. Extensions of Simple
Conceptual Graphs : the Complexity of Rules and
Constraints. JAIR, 16(12) :425–465, 2002.
[4] G. Booch, C. Jacobson, and J. Rumbaugh. The Uni-
fied Modeling Language - a reference manual. Addi-
son Wesley, 1998.
[5] Borland. Together software, 2004.
http://www.borland.com/together/.
[6] M. Chein and M.L. Mugnier. Conceptual Graphs :
Fundamental Notions. Revue d’intelligence artifi-
cielle, 6(4) :365–406, 1992.
[7] M. Chein and M.L. Mugnier. Positive nested concep-
tual graphs. In ICCS’97 [14], pages 95–109.
[8] M. Chein and M.L. Mugnier. Concept types and
coreference in simple conceptual graphs. In Proc.
of ICCS’04, volume 3127 of LNAI, pages 303–318.
Springer, 2004.
[9] M. Chein, M.L. Mugnier, and G. Simonet. Nes-
ted graphs : A graph-based knowledge representation
model with FOL semantics. In Proc. of KR’98, pages
524–534. Morgan Kaufmann Publishers, 1998.
[10] D. Genest. CoGITaNT 5.1.6, 2005.
http://cogitant.sourceforge.net.
[11] Gentleware. Poseidon SE, 2004.
http://www.gentleware.com/.
[12] O. Haemmerlé. La plate-forme CoGITo : manuel
d’utilisation. Technical Report 95012, LIRMM,
1995.
[13] IBM. Rational rose, 2004. http://www-
306.ibm.com/software/rational/.
[14] ICCS’97, volume 1257 of LNAI. Springer, 1997.
[15] G. Kerdiles and É. Salvat. A sound and complete CG
proof procedure combining projection with analytic
tableaux. In ICCS’97 [14], pages 371–385.
[16] F. Lehmann. Semantic Networks in Artificial Intelli-
gence. Pergamon Press, 1992.
[17] M.L. Mugnier and M. Chein. Représenter des
connaissances et raisonner avec des graphes. Revue
d’intelligence artificielle, 10(1) :7–56, 1996.
[18] OMG. XML Metadata Interchange (XMI) Specifica-
tion, 2002. http://www.omg.org/technology/
documents/formal/xmi.htm.
[19] É. Salvat. Theorem proving using graph operations in
the conceptual graph formalism. In Proc. of ECAI’98,
1998.
[20] J.F. Sowa. Conceptual Structures : Information Pro-
cessing in Mind and Machine. Addison Wesley, 1984.
[21] M. Wermelinger. Conceptual graphs and first-order
logic. In Proc. of ICCS’95, volume 964 of LNAI,
pages 323–337. Springer, 1995.
Annexe
Définition 8 (Support [9]). Un support est un sextuplet
S = (TC , TR , TE , σ, I, τ ).
– TC , ensemble de types de concepts, est un ensemble
partiellement ordonné par une relation « sorte de »,
possédant un plus grand élément noté >.
– TR , ensemble de types de relations, est un ensemble par-
titionné TR = TRi1 ∪ · · · ∪ TRip où TRij est l’ensemble
des types de relations d’arité ij , ij > 0. Chaque TRij
est partiellement ordonné par une relation « sorte de »
et possède un plus grand élément noté >ij .
– TE , ensemble des types d’emboı̂tements, est un ensemble
partiellement ordonné par une relation « sorte de »,
possédant un plus grand élément noté Description.
– σ est une application associant à chaque type de rela-
tion une signature. La signature d’une relation spécifie
l’arité et le plus grand type possible pour chaque argu-
ment. Pour tout type r ∈ TRij , σ(r) ∈ (TC )ij . On note
σi (r) le ieme argument de σ(r).
– I est l’ensemble des marqueurs individuels. En plus de
cet ensemble, un marqueur particulier, noté ∗ et appelé
marqueur générique permet de représenter un individu
non spécifié. I ∪ {∗} est muni d’un ordre suivant : ∗ est
le plus grand élément et deux marqueurs individuels sont
deux à deux incomparables.
– τ , conformité, est une application de I dans TC qui as-
socie à chaque marqueur individuel son type.
Définition 9 (Graphe conceptuel emboı̂té typé[7, 9]). Un
graphe conceptuel emboı̂té typé (GCET) défini sur un sup-
port S, est un multigraphe non orienté, biparti et étiqueté
G = (R, C, U, etiq).
– R est l’ensemble de sommets relations et C l’ensemble
de sommets concepts.
– U est l’ensemble des arêtes. Les arêtes liées à un sommet
relation sont ordonnées, ce qui est représenté par une
numérotation des arêtes de 1 à l’arité de la relation. Le
ieme voisin d’une relation r est noté Gi (r).
– etiq associe à chaque sommet une étiquette telle que
∀r ∈ R, etiq(r) ∈ TR et ∀c ∈ C, etiq(c) =
(type(c), ref (c), desc(c)). L’étiquette d’un sommet
concept est formée d’un type, un référent et une des-
cription. type(c) ∈ TC . ref (c) ∈ I ∪ {∗}. Un sommet
concept tel que ref (c) ∈ I est appelé sommet concept
individuel, dans le cas contraire, il est appelé sommet
concept générique. La description d’un sommet concept
peut être vide, ce qui est représenté par un marqueur
particulier desc(c) = ∗∗, ou donnée sous la forme d’un
ensemble de couples (ei , Hi ) où ei ∈ TE et Hi est un
GCET défini sur S.
De plus, etiq obéit aux contraintes fixées par σ et τ :
∀r ∈ R, type(Gi (r)) ≤ σi (type(r)), et ∀c ∈ C si
ref (c) ∈ I alors τ (ref (c)) ≤ type(c).
Définition 10 (Projection [7, 9]). Une projection d’un
GCET H = (RH , CH , UH , etiqH ) dans un GCET G =
(RG , CG , UG , etiqG ) est un couple d’applications Π =
(f, g), avec f : RH → RG et g : CH → CG , tel que :
1. Π préserve les arêtes et l’ordre des arêtes : pour
chaque arête rc de UH , f (r)g(c) est une arête de UG ,
et si c = Hi (r) alors g(c) = Gi (f (r)).
2. Π peut restreindre les étiquettes des sommets : ∀r ∈
RH , etiqG (f (r)) ≤ etiqH (r) et ∀c ∈ CH , avec
etiqH (c) = (t, m, d) et etiqG (g(c)) = (t0 , m0 , d0 ),
etiqG (g(c)) satisfait :
– t0 ≤ t et m0 ≤ m
– Si d est un graphe, alors d0 est un graphe tel qu’il
existe une projection de d dans d0 . Si d = ∗∗, il n’y
a aucune contrainte sur d0 , qui peut être un graphe
ou ∗∗.
Définition 11 (Lien de coréférence [8]). Un lien de
coréférence entre deux sommets concepts génériques per-
met d’exprimer que les deux sommets concepts désignent le
même individu. Un lien de coreférence est représenté par
un lien en pointillés entre les deux sommets concepts.
Définition 12 (Forme normale locale [8]). Un GCET est
sous forme normale locale si et seulement si il n’existe pas
deux sommets concepts portant le même marqueur indivi-
duel dans un même emboı̂tement.