introduction - Université de technologie de Troyes

3e Conférence Francophone de MOdélisation et SIMulation “Conception, Analyse et Gestion des Systèmes Industriels”
MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)
UNE NOUVELLE APPROCHE POUR LE DEVELOPPEMENT D’OUTILS
D’ANALYSE ET D’AIDE A LA DECISION.
José-Luis PERPEN
Laboratoire d’Informatique Appliquée
Université de Pau et des Pays de l’Adour avenue de l’Université
BP 576
64012 Pau Cedex, France
Mél : [email protected]
RESUME : La maîtrise des phases de conception et d’exploitation de systèmes constitue un enjeu économique
important pour l’industrie. L’utilisation d’outils, faisant largement appel à la modélisation et à la simulation, est
devenue indispensable. Parce que les problèmes rencontrés ne sont jamais identiques et qu’il est constamment
nécessaire d’améliorer les méthodes de résolution, de nombreux outils spécifiques doivent encore être développés.
L’objectif de cet article est de présenter une nouvelle approche pour la construction rapide d’outils d’analyse et d’aide
à la décision, performants et évolutifs.
MOTS-CLES : Modélisation objet, points de vue, développement interactif, système de production.
1.
INTRODUCTION
Au cours des dernières décennies, la compétition entre
les industries manufacturières s'est considérablement
accrue, entraînant des exigences de plus en plus fortes
sur la qualité des produits, leur prix et leur délai de
fabrication.
Pour accélérer et fiabiliser les étapes du cycle de
développement de produits, de nombreux outils
d’analyse et d’aide à la décision ont été développés. La
diversité des systèmes existants ainsi que l’évolution
des techniques de production conduisent aux
développements répétés de nouveaux outils.
L’ingénierie simultanée impose de nouvelles
contraintes sur ces outils. Il devient maintenant
nécessaire de trouver des solutions, à un problème
donné, compatibles avec les contraintes issues de
domaines annexes. Les outils doivent par conséquent
coopérer.
De nombreux groupes pluridisciplinaires de recherche
se forment autour de l’étude d’une modélisation plus
précise et plus complète des systèmes de production.
Leur objectif est de fournir aux industries des outils
pour améliorer la production et mieux réagir face aux
perturbations. La complexité des systèmes étudiés rend
peu probable l’obtention directe d’une modélisation
fédératrice entièrement satisfaisante. Il est donc
indispensable de prévoir l’évolution des outils
développés.
2.
POSITIONNEMENT DE L’ETUDE
Le développement direct d’une application métier
intégrant une modélisation complète et précise d’un
système de production et pouvant résoudre l’ensemble
des problèmes rencontrés est irréaliste. Une des
solutions envisageable est de permettre la coopération
entre différentes applications autour d’un même
objectif. L’utilisation de technologies comme CORBA,
COM, EJB ou autre peut être une solution intéressante
pour la connexion entre différentes applications
existantes. Cette solution est avantageuse lorsqu’il
s’agit de réutiliser les fonctionnalités de composants
complexes comme un outil de CFAO, un tableur, etc..
Cependant, cette approche ne constitue pas une
solution entièrement satisfaisante dans la mesure où
elle n’offre pas une modélisation globale des
connaissances et limite considérablement les
possibilités d’adaptation et d’évolution des outils
produits. Les méthodes de résolution de problèmes
ainsi que les modèles utilisés doivent pouvoir évoluer
au cours du temps, au fur et à mesure que de nouveaux
besoins se précisent.
L’objectif de nos travaux de recherche est de définir
une nouvelle approche pour la construction rapide
d’outils d’analyse et d’aide à la décision, performants,
évolutifs et coopérants. Cette approche s’appuie sur le
développement d’un nouveau type de système
(Système de Gestion des Connaissances Techniques)
facilitant la modélisation et la résolution de problèmes.
Notre approche peut être placée à la frontière du génie
logiciel et de l’ingénierie des connaissances. Comme
pour ces deux approches, elle consiste à fournir un
modèle pour la représentation des connaissances à
partir duquel les méthodes de résolution de problèmes
pourront être programmées. Le modèle utilisé, nommé
OMT-K (Perpen, 2000), s’apparente aux modèles
OMT et UML (Fowler, 1997) utilisés en génie logiciel.
Cependant, il intègre, en outre, un certain nombre de
MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)
concepts existants dans des modèles issus des
recherches en ingénierie des connaissances comme les
modèles terminologiques, KL-one (Brachman et
Schmoltze, 1985) ou à base de frames, KRL (Bobrow
et Winograd, 1977), FRL (Roberts, 1977) et SHIRKA
(Rechenmann, 1989).
Un premier aspect différencie clairement notre
approche des approches existantes. Le travail de
programmation ne s’effectue pas avec un éditeur de
texte mais avec un outil graphique, le S.G.C.T.. Il
existe de nombreux outils de développement utilisant
une interface graphique pour la construction du modèle
d’une application. Rational Rose (Quantrani, 1998) est
un environnement graphique de modélisation
permettant la construction de modèles UML. Le
principe est de générer à partir de la description UML
le squelette de l’application. Le logiciel O2 (Cattell,
1994) utilise le même dispositif pour la construction
des schémas de bases de données orientées objets. En
ingénierie des connaissances, les systèmes tel que
Ontolingua (Farquhar, 1997), WebMap (Gaines et
Shaw, 1995), KSSO/NEXTRA (Einstadt , 1991),
WebOnto (Domingue, 1998) offrent un ensemble
d’outils pour la visualisation et le partage de modèles
sur Internet. Le principal objectif de ces outils est de
faciliter la visualisation et l’édition des ontologies d’un
domaine. KSSO (Gaines, 1993), dispose d’un
environnement hypermédia et utilise des techniques
d’exploitation de grille et un algorithme d’induction
ID3 et C4.5 pour la formalisation de connaissances à
partir d’interviews et d’articles.
Contrairement à ces outils, le rôle du S. G.C.T. n’est
pas uniquement la construction graphique du modèle
de connaissances pour préparer le code du programme
ou pour tester le modèle de représentation. L’interface
fournie par le S.G.C.T. participe activement à la
construction du modèle de connaissances en gérant les
contraintes
implicites
du
modèle
OMT-K.
Actuellement, notre approche ne permet pas la
formalisation de connaissances à partir de documents
informels. Cependant, nous avons pu vérifier que la
construction dynamique d’application métier facilite le
travail de modélisation jusqu'à favoriser les
développements par des experts non informaticiens.
Le projet PROTEGE (Eriksson, 1999), développé
actuellement à l’université de Stanford, offre une
approche similaire pour la modélisation de
connaissances. Le logiciel PROTEGE 2000 fourni un
environnement graphique convivial, permettant la
modélisation du domaine en utilisant la notion de
classes/instances. Cependant, cet environnement
n’intègre pas de contrôle sur la cohérence des modèles
saisis, ce qui est le cas avec notre S.G.C.T.. De plus,
l’approche utilisée pour le développement dans
PROTEGE 2000 est une approche par composants. Le
principe retenu pour l’évaluation de paramètres est
d’établir des liens entre les données du modèle et des
composants génériques pour le calcul (PSM, ProblemSolving Methods). Les classes ainsi que les attributs de
ces classes (nommé slots) n’intègrent pas la notion de
méthodes pour l’évaluation, ce qui limite les
possibilités tant au niveau de la représentation des
connaissances qu’au niveau de la résolution de
problèmes.
Le deuxième aspect original de notre approche est lié
aux fonctionnalités incluses dans les applications
construites.
• Un environnement graphique qui permet
l’évaluation des méthodes liées aux objets modélisés.
• Un système d’aide à la définition des besoins
interactif qui utilise des techniques basées sur la
propagation de contraintes et le raisonnement à base de
cas pour la construction d’objets complexes.
• Des interfaces graphiques qui s’adaptent
automatiquement au domaine de compétence de
l’utilisateur pour la visualisation et la manipulation des
objets modélisés.
• Pour finir, un générateur de documentation en
ligne (HTML) qui présente les descriptions associées à
l’ensemble des connaissances modélisées.
Dans les paragraphes suivants, nous présentons les
différents concepts utilisés dans notre approche pour la
modélisation des connaissances et pour leur mise en
œuvre, puis différents domaines d’application étudiés.
3.
MODELISATION PROPOSEE
Pour modéliser les connaissances utilisées dans les
différents domaines de la productique, il est
indispensable de disposer d’un modèle de
représentation à la fois puissant et facile d’accès aux
experts des domaines considérés.
Notre approche est basée sur un nouveau modèle
baptisé OMT-K (Perpen, 2000). Ce modèle reprend les
principes des modèles OMT et UML, qui sont parmi
les plus utilisés actuellement. Nous présentons, dans les
paragraphes suivants, l’ensemble des concepts utilisés
dans OMT-K.
3.1
Définition d’une classe
Plusieurs concepts sont utilisés pour la définition d’une
classe. L’utilisateur doit saisir pour chaque classe :
• Un nom
• Une liste de classes
parentes
• Une liste d’attributs
• Une description HTML
• Une liste de méthodes
• Une liste d’attributs
associés
MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)
Comme tout élément de modélisation, une classe
dispose d’un identifiant interne, défini à sa création.
Remarque : Les attributs associés permettent la
définition de “ Classes Associations ”. Contrairement
aux modèles objets ou Entité/Relation, l’association ne
se limite pas à relier uniquement les identifiants de
classes ou d’entités. Nous généralisons la notion
d’association en autorisant la liaison de tout attribut de
la base de connaissances.
3.2
Définition d’un attribut
La définition d’un attribut prend une place importante
dans notre approche. Tous les attributs d’une classe
sont définis de la manière suivante :
•
Un nom
• Une description
HTML
• Un type
Standard
(Texte, Entier,..)
Défini dans la base
(Matière, Machine,..)
• Un format
(instance ou classe)
•
Un modèle
• Une ou plusieurs sources
de valeurs
•
Un attribut parent
3.2.1
Définition d’un modèle
L’environnement PROTEGE 2000 se limite à un
nombre de valeurs égale à 1 ou infini. Cela nous
semble trop restrictif pour la modélisation de
connaissances, notamment dans le domaine de la
mécanique où de nombreuses matrices sont utilisées
pour stocker les caractéristiques de matériaux. Nous
proposons maintenant une vision plus large, en
définissant la notion de modèle pour un attribut.
• “ 1 ” correspond à une valeur unique pour
l’attribut.
• “ (N) ” correspond à une liste de N valeurs. Si N =
-1 alors la liste est infinie.
• “ {N} ” correspond à un ensemble de N valeurs ne
contenant donc pas de doublons.
• “ [N1,N2,N3,..,Nn] correspond à la description de
matrice de n dimensions. “ [5] ” est par exemple une
liste triée de 5 éléments. “ [5, 2] ” correspond à une
matrice 5x2. “ [-1, -1] ” affichera un tableau de taille
infinie.
3.2.2
Définition des sources de valeurs
Cinq types de sources peuvent être définis pour
identifier les valeurs admissibles pour l’attribut. Des
combinaisons de ces cinq types de sources sont
autorisées.
Une liste de valeurs figée ou non : L’utilisateur peut
créer ou choisir parmi les valeurs correspondantes au
type de l’attribut, celles qui sont acceptables (ex : pour
la forme d’une plaquette (attribut de type “ Texte ”), les
valeurs seront “ ronde ”, “ carrée ”, et..).
Un autre attribut : Les valeurs possibles seront alors les
valeurs définies pour cet attribut (ex : l’outil actif d’une
machine à commande numérique doit appartenir aux
outils du magasin).
Une liste de contraintes : Si aucune source n’est
définie, une ou plusieurs contraintes peuvent l’être
pour restreindre les choix possibles parmi l’ensemble
des valeurs compatibles avec le type de l’attribut. (Ex :
l’attribut “ Puissance Broche Maxi ” de type “ Réel ”
peut être contraint par “ > 0 ”)
Un attribut équivalent : Pour faciliter la modélisation et
aussi la gestion automatique des contraintes et des
calculs de similitude, il est possible de définir des
équivalences entre attributs (ex : la matière d’un outil à
plaquette est équivalente à la matière de la plaquette
utilisée). La valeur de cette attribut sera alors celle de
l’attribut.
Une méthode d’évaluation : Pour finir, la valeur d’un
attribut peut directement être fournie à l’aide de la
définition d’une méthode de calcul (voir définition
d’une méthode §3.3).
3.2.3
Définition d’un attribut parent
Un attribut peut surcharger un autre attribut
appartenant à la même classe ou à l’une des classes
mères de celle-ci. Deux types de surcharges sont
possibles :
La définition d’un attribut parent permet de surcharger
les restrictions sur la ou les valeurs de cet attribut. (Ex :
la matière de la partie active, pour un outil à plaquette,
est équivalente à la matière de la plaquette utilisée.
Pour modéliser un outil nous pouvons définir, dans un
premier temps, une classe “ Outil ” possédant un
attribut de type “ Matière ”, nommé “ Matière partie
active ”. Sur la classe “ Outil à plaquette ” héritant de
la classe “ Outil ”, il est alors possible de définir un
nouvel attribut surchargeant l’attribut “ Matière partie
active ”. Nous pouvons, ensuite, utiliser la notion
d’attribut équivalent afin que la valeur de cet attribut
soit celle de la matière de la plaquette utilisée par
l’outil.
Pour améliorer la gestion des points de vue utilisateurs
ainsi que la visibilité des modélisations construites,
nous avons mis en place un autre mécanisme de
surcharge, celui-ci moins commun. Le principe est
d’utiliser la notion d’attribut parent pour la
décomposition et le raffinement des concepts
modélisés. Prenons, cette fois, le cas d’une classe
“ Activité ” ayant comme attribut une liste de
ressources. Pour une activité d’usinage, ces ressources
peuvent être précisées. L’attribut “ Ressources ” peut
MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)
être surchargé dans la classe “ Opération d’usinage ” en
trois attributs l’un contenant une “ Machine ”, l’autre
un “ Outil ” et le dernier une “ Pièce ” ; chacun de ses
trois éléments étant bien entendu défini comme des
ressources pour la cohérence globale de la
modélisation.
3.3
Définition d’une méthode
Contrairement à l’environnement PROTEGE 2000, il
est possible de définir des méthodes pour les classes,
l’évaluation d’attribut, et l’évaluation de contraintes.
Une méthode est définie par :
Un nom
•
•
Une description HTML
• Une contrainte
d’utilisation
•
MISE EN ŒUVRE DES MODELES
Pour la mise en œuvre des modèles, nous avons
travaillé sur l’étude de solutions techniques permettant
de passer directement de la modélisation des
connaissances à une application exploitable. Nous
décrivons ici les moyens utilisés pour l’implémentation
des modèles OMT-K, leur utilisation ainsi que les
aspects liés à la gestion des points de vue utilisateurs.
L’implémentation des modèles
Une méthode parente
Un code C++
3.3.1
Définition d’une méthode parente
Comme pour un attribut, une méthode d’une classe
peut avoir une méthode parente dont elle sera une
surdéfinition ; la méthode parente désignée jouant ici le
rôle de méthode virtuelle.
3.3.2
Définition d’une méthode parente
Bien qu’il soit possible de récupérer l’identifiant d’un
attribut et d’accéder par le programme à ses propriétés,
en règle générale, les utilisateurs veilleront à prendre
comme attributs en entrée les attributs strictement
nécessaires au calcul. Si une méthode nécessite
l’attribut “ Puissance Broche Maxi ”, défini dans la
classe “ Machine ”, il est inutile de récupérer un
attribut désignant la classe “ Machine ”. En effet, cette
classe peut être amenée à évoluer et il serait alors
nécessaire de modifier la méthode programmée.
3.4
4.
4.1
•
• Une liste d’attributs en
entrée et en sortie
classe association : par exemple, pour imposer la prise
en compte de l’attachement entre l’outil et la machine.
Définition d’une contrainte
Notre avons montré qu’il était possible de définir des
contraintes sur la valeur d’un attribut. Les contraintes,
que nous définissons ici, sont plus des contraintes liées
à la résolution de problèmes qu’à la modélisation des
connaissances, bien qu’elles fassent partie intégrante de
la modélisation. Ces contraintes supplémentaires
pourront être activées ou désactivées en fonction des
problèmes à résoudre et de la qualité des solutions
recherchées. Deux types de contraintes peuvent être
utilisés avec OMT-K.
Le premier concerne l’application de contraintes sur les
attributs de la base de connaissances. Par exemple :
puissance de broche maximale d’une machine
inférieure de 10% à la puissance de coupe nécessaire à
une opération.
Le deuxième type de contraintes est lié à l’existence
d’une instance dans une classe et notamment dans une
Le S.G.C.T. dispose d’une interface graphique
permettant la saisie des modèles OMT-K décrivant le
système étudié. Les interfaces graphiques nécessaires à
la gestion des instances issues de la modélisation sont
générées dynamiquement par le S.G.C.T, intégrées à
celui-ci et directement utilisables.
Contrairement aux approches utilisées en ingénierie
des connaissances, nous n’effectuons pas une analyse
de cohérence sur la modélisation finale avec une
analyse du code obtenu. Le S.G.C.T. est basé sur une
approche préventive qui consiste à guider l’utilisateur
afin d’éviter le choix de valeurs incohérentes vis à vis
de la modélisation en cours de construction. Cette
cohérence est aussi vérifiée lors de chaque
modification. Des menus déroulants contextuels
montrent les valeurs acceptables en fonction des
opérations effectuées. Le système peut interagir avec
l’utilisateur lorsqu’une modification du modèle ou des
données conduit à des incohérences.
La sauvegarde des modèles et des données saisies
s’appuie sur un système de base de données classique.
Les tables peuvent donc être facilement partagées sur
le réseau avec d’autres S.G.C.T. ou des outils existants.
4.2
L’utilisation des modèles
Nous avons étudié un certain nombre de modules
génériques afin de fournir directement à partir des
modèles saisis une aide efficace à la résolution de
problèmes.
4.2.1
Evaluation des méthodes
Dans un premier temps nous avons travaillé sur un
module dédié à l’évaluation des méthodes définies dans
les objets modélisés. L’approche utilisée est
sensiblement la même que pour les systèmes experts à
base de règles. Le module développé est basé sur un
moteur d’inférences chargé de retrouver les paramètres
nécessaires à l’évaluation d’une méthode. Il utilise
comme base de fait un contexte contenant les objets
étudiés. Les règles sont les méthodes de calcul liées
aux attributs. Les entrées de la méthode sont les
prémisses d’une règle et les sorties sont les
MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)
conclusions. Ce module interagit avec l’utilisateur pour
renseigner les valeurs manquantes dans le contexte
initial. L’utilisateur peut choisir de renseigner la valeur
manquante et enrichir la base de connaissances ou
prendre une valeur temporaire pour effectuer ces
calculs. Si la valeur manquante est liée à un objet
absent du contexte, l’utilisateur peut choisir d’ajouter
un objet complet au contexte. Dans ce cas, l’utilisateur
pourra faire appel à deux modules spécialement étudiés
pour l’aide à la configuration de solutions.
4.2.2
Recherche d’objets existants
Le premier offre la possibilité de rechercher, dans la
base, les objets correspondants à un objet partiellement
renseigné. Le principe est basé sur une mesure de
similarité utilisant la logique floue. Dans l’exemple
suivant, nous décrivons une méthode pour mesurer la
similarité entre la rugosité d’une pièce et celle
souhaitée.
ressemblance par deux critères qui sont les degrés de
possibilité et de nécessité.
Une mesure globale de ressemblance sur plusieurs
caractéristiques peut être obtenue en effectuant le
calcul d’une similitude globale. Le calcul a été étudié
sur la base des travaux de Dubois et Prade (Dubois et
Prade, 1988). Plutôt que l’utilisation d’un poids décrit
par un réel appartenant à l’intervalle [0,1], nous avons
mis en place la notion de rang que l’utilisateur pourra
affecter à chaque caractéristique recherchée. Le poids
utilisé pour le calcul de la similarité globale est
déterminé de la façon suivante :
Soit rangPi le rang de la ième caractéristique de l’objet,
alors le poids wi, de la ième caractéristique, est tel que :
wi =1−
(rang P −1)
i
max(rangP )
i
i =1,...,n
L’utilisation de la notion de rang, en lieu et place du
poids, nous semble permettre un classement plus rapide
et plus intuitif des attributs en fonction de leur
importance dans la recherche d’un objet similaire.
1
µ
π
Rugosité
en µm
0
2
4
Deux nouvelles distances sont alors définies pour la
similarité globale d1 et d2. Elles correspondent
respectivement à la nécessité et à la possibilité globales
de similarité.
supu∈U min(µ(u),π (u) )
N = infu∈U max(µ(u),1−π(u))
d1 = min max(1−wi,si)
i =1,...,n
Figure 1. Similarité entre deux rugosités.
d 2 = min max(1− wi,s'i )
i =1,...,n
Π=
Nous définissons la fonction d’appartenance µ qui
traduit l’appartenance au critère “ est proche de ” et
une distribution de possibilité π traduisant la différence
entre les deux rugosités. Π et N donnent les degrés de
possibilité et de nécessité de similitude entre la rugosité
de la pièce testée et la rugosité demandée.
La logique floue permet d’affiner la notion de
similitude deux caractéristiques. Dans cet exemple, la
fonction d’appartenance µ choisie, traduit que la
similarité est grande, si la différence entre les deux
rugosités est inférieure à 1 µm, et qu’elle diminue
jusqu'à être nulle pour une différence dépassant les 5
µm. Il est aussi possible pour la rugosité demandée de
prendre un intervalle de valeur ou une variable floue.
Dans ce cas, la distribution de possibilité π prendra la
forme d’un créneau ou d’un trapèze.
La logique floue permet aussi d’homogénéiser la
mesure de ressemblance sur un ensemble de
caractéristiques différentes, en résumant cette
Avec S’j et Si les degrés de possibilité et de nécessité
de similarité locale pour la ième caractéristique.
Une étude antérieure sur cette même mesure de
similarité a permis de tester la fiabilité des résultats
obtenus (Perpen, 1996). L’utilisation de cette technique
sur des objets complexes modélisés avec OMT-K a
conduit à l’élaboration d’un premier algorithme
prenant en compte la structure objet de notre
modélisation (Ruet, 1999).
Il semble important de noter que l’utilisation de ce
module de recherche d’objets similaires impose
toutefois, pour chaque classe élémentaire (c.-à-d. celles
représentant des concepts de base), la définition d’une
méthode fournissant les degrés de possibilité
correspondant à une mesure locale de similitude.
4.2.3
Génération et/ou validation d’objets
L’intérêt de ce module est d’assurer une coopération
dynamique entre les différentes connaissances issues
de domaines divers. La construction, par exemple, d’un
MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)
objet de type opération d’usinage pour la fabrication
d’une pièce donnée impose la sélection d’un outil et
d’une machine adaptés. Le rôle du module, défini ici,
est de proposer directement aux utilisateurs les
composants adéquats à placer dans l’opération, en
tenant compte de toutes les contraintes liées à ceux-ci.
La complexité des composants à construire et des
calculs dépendra des contraintes imposées, au départ,
par l’utilisateur du système. L’approche utilisée pour
identifier les composants acceptables est issue
d’importants travaux de recherche sur les méthodes de
résolution de problème par satisfaction de contraintes
(Monteiro, 1999).
Un problème de satisfaction de contraintes (CSP) est
composé d'un ensemble X de n variables X1, X2,…, Xn
et d'un ensemble de m contraintes C1, C2,…, Cm.
Chaque variable prend sa valeur dans son domaine
respectif dom(X1), dom(X2),… Chaque contrainte est
composée d'un sous-ensemble {Xi, …,Xq} de X et
d’un sous-ensemble du produit cartésien dom(Xi) x…x
dom(Xq), qui spécifie (en extension ou en intention)
quelles valeurs des variables Xi, …,Xq sont
compatibles avec la contrainte. Sur la figure 2, nous
présentons un exemple de CSP contenant quatre
variables et trois contraintes.
X1
X2
V1
V2
V3
V4
X3
C2
C1
C3
V13
V14
V15
V16
C2
X1 X3
V1 V9
V1 V10
V3 V11
Pour résoudre le CSP ainsi obtenu, nous nous sommes
basés sur l’algorithme DnGAC4 (Bessière, 1991). Cet
algorithme, efficace sur des contraintes discrètes, doit
être perfectionné pour permettre, aussi, la prise en
compte de contraintes continues.
Le module dédié à la recherche d’objets existants et le
module pour la génération, ou la validation, d’objets
pourront, à terme, être utilisés consécutivement. Le
premier pour rechercher rapidement une première
solution sous la forme d’un objet déjà existant dans la
base, et le second pour vérifier la cohérence entre les
valeurs des attributs récupérés avec l’objet et le
contexte global de l’étude. La correction d’éventuelles
erreurs pourrait alors être effectuée par le module de
satisfaction de contraintes, après l’élimination des
attributs incriminés. La réévaluation de ces attributs
fournira alors une solution adaptée au contexte de
travail. A terme, le couplage entre ces deux modules
doit pouvoir conduire à l’obtention d’un module
fournissant
un
mécanisme
presque
complet
d’apprentissage par le raisonnement à partir de cas.
Si les différents algorithmes étudiés ont fait l’objet de
nombreux tests très prometteurs, un travail important
de développement est encore à effectuer pour mettre en
place toutes les interfaces graphiques nécessaires à une
mise en œuvre concrète des solutions proposées.
4.3
X4
V9
V10
V11
V12
C1
X1 X2
V1 V5
V2 V5
V3 V7
V5
V6
V7
V8
entre les attributs d’une même classe et par les liens
entre différentes classes par le biais de contraintes sur
leurs attributs ou d’association entre ces attributs.
C3
X2 X3 X4
V5 V9 V13
V7 V11 V14
V8 V12 V14
Figure 2. Description d’un CSP
La résolution d’un CSP consiste à restreindre les
domaines de chaque variable en appliquant
successivement les contraintes définies. La même
méthode peut être employée pour vérifier la validité
d’une solution chaque domaine ne contenant cette fois
qu’une valeur.
Notre approche est basée sur l’assimilation d’une
modélisation OMT-K à un problème de satisfaction de
contraintes. Les classes élémentaires, ne comportant
qu’un attribut, jouent le rôle de domaine. Les
contraintes sont matérialisées par les liens intrinsèques
La gestion des points de vue
La coopération de plusieurs experts, de domaines
différents, impose une modélisation répondant aux
besoins de chaque acteur métier. Suivant son domaine
de compétence et sa fonction, chacun possède une vue
propre des objets liés au système à modéliser. Le
modèle OMT-K, à travers des concepts comme
l’héritage multiple et la surcharge d’attributs et de
méthodes, permet de réaliser une modélisation
regroupant ces différents points de vue.
La fédération des différents points de vue au niveau des
modèles construits est nécessaire mais non suffisante
pour une coopération efficace des différents acteurs. Le
S.G.C.T. qui sert à capitaliser les connaissances métiers
doit aussi permettre une gestion efficace de l’accès à
l’information.
Chaque expert ayant participé à l’élaboration d’une
modélisation globale des connaissances doit pouvoir
retrouver dans l’application réalisée une représentation
claire des objets associés à son domaine de
compétence. Cette représentation doit masquer toutes
les caractéristiques liées à des domaines annexes et
n’appartenant pas au domaine en cours.
MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)
Dans un même domaine, plusieurs utilisateurs peuvent
avoir des fonctions ou des niveaux de compétences
différents. Des erreurs de manipulation ou la saisie de
valeurs incorrectes pour les attributs d’un objet peuvent
fausser les futurs résultats fournis par le système. Le
repérage de ces erreurs peut être très tardif. La
possibilité, offerte par le système, de sauvegarder
plusieurs versions de la base de connaissances n’est pas
suffisante dans ce cas. Pour fiabiliser le système il est
indispensable de contrôler l’accès aux informations
contenues dans la base.
Pour permettre une gestion efficace des différents
points de vue, nous avons défini deux classes par
défaut, la classe “ Domaine ” et la classe
“ Utilisateur ”. La classe “ Utilisateur ” dispose
d’attributs représentants les droits d’accès en lecture,
écriture et exécution. Ces attributs ont pour valeur, une
ou plusieurs classes “ Domaine ”. Des hiérarchies de
domaines et d’utilisateurs peuvent être mises en place à
partir des classe “ Domaine ” et Utilisateur ”. Chaque
concept modélisé peut alors être associé à un ou
plusieurs domaines. Lors de la génération des
interfaces graphiques, le S.G.C.T. prendra en compte
ces différents éléments pour fournir à chaque utilisateur
un accès adapté aux modèles, aux données et aux
méthodes développées.
5.
DOMAINES D’APPLICATION
Un des premiers domaines d’application de notre
approche de développement a été la résolution de
problèmes de configuration d’usinages. Les
informations nécessaires à la résolution de ce type de
problèmes sont de natures diverses et font intervenir
plusieurs domaines de compétence. Un modèle OMTK comportant une vingtaine de classes a été défini en
collaboration avec des experts en méthode de
fabrication (Perpen, 1999b). Ce modèle contient la
description d’une opération d’usinage, des types de
machines et d’outils utilisés et intègre les contraintes
liant ces différents paramètres.
Contrairement à une approche classique de
développement, la réalisation de l’application basée sur
cette modélisation a été effectuée en un temps record.
Le temps passé entre la fin de la première modélisation
et la version finale de l’outil n’a pas dépassé trois
semaines. L’implémentation du modèle étudié a été
réalisée par un non informaticien à l’aide d’un premier
prototype de S.G.C.T. développé avec l’A.G.L.
CAS.CADE en partenariat avec la société MATRADATAVISION (Perpen, 1999a). Bien que notre
modélisation ne soit pas exhaustive, elle pourra être
complétée sans remise en cause de l’ensemble des
connaissances saisies.
Dans le but d’élargir les champs d’application de notre
S.G.C.T., nous travaillons actuellement sur un nouveau
prototype développé pour les plates-formes Windows
NT et Linux. Celui-ci intègre les différents concepts de
modélisation présentés dans cet article et, pour certains,
absents dans le premier prototype. Basé sur un MétaModèle C++ plus élaboré, il devrait intégrer une
gestion automatique des mécanismes de réservation de
ressources et un module pour la construction et
l’analyse automatique de réseaux d’activités
modélisées avec OMT-K. L’objectif de ces travaux
étant de permettre la modélisation de systèmes de
production complexes mais surtout d’en simuler le
fonctionnement. L’intérêt étant grâce à notre approche
de disposer d’une application utilisant des objets
pouvant progressivement évoluer pour être plus proche
des modèles réels.
6.
CONCLUSION
A travers différents concepts liés à la modélisation, à
l’opérationnalisation, et à la gestion des points de vue,
nous avons décrit les différents aspects de notre
approche. Notre objectif est de favoriser une meilleure
coopération des divers domaines de compétence autour
d’une modélisation unique pouvant rapidement être
enrichie. Le développement interactif d’applications
métier évolutives est un axe de recherche important
pour l’industrie comme pour les laboratoires de
recherche. Cette approche représente une solution
efficace pour la capitalisation des connaissances
métier. Des travaux importants de recherche et de
développement doivent encore être menés pour
permettre une simulation directe de systèmes de
production complets. Les études menées et les travaux
en cours montrent des résultats très encourageants.
REFERENCES
Bessière C., 1991. Arc-consistency in dynamic
constraint satisfaction problems. Proceedings of the
10th AAAI, California, p. 221-226.
Bobrow D. G., Winograd T. W., 1977. An Overview of
KRL, a Knowledge Representation Language.
Cognitive Science, 1(1), pp. 3-46.
Brachman R. J., Schmoltze J. G., 1985. An overview of
the KL-ONE knowledge representation language.
Cognitive science, 9, p. 171-216.
Cattell R. G. G., 1994. Object Data Management.
Addison Wesley.
Domingue J., 1998. Tadzebao and WebOnto:
Discussing, Browsing, and Editing Ontologies on
the Web. 11th Knowledge Acquisition for
Knowledge-Based Systems Workshop, Banff,
Canada.
Dubois D. et Prade H., 1988. Théorie des possibilités.
2ème éd. Paris : Masson.
Eisenstadt M., 1991. Review of the KSSO/NEXTRA
Knowledge Aquisition Tool for the VITAL Project.
HCRL Technical Report.
MOSIM’01 – du 25 au 27 avril 2001 – Troyes (France)
Eriksson H., Fergerson R., W., Shahar Y., Musen M.,
A., 1999. Automatic Generation of Ontology
Editors. Twelfth Banff Knowledge Acquisition for
Knowledge-based systems Workshop, Banff,
Alberta, Canada.
Farquhar A., Fikes R., Rice J., 1997. The ontolingua
server : a tool for collaborative ontology
construction. International Journal of HumanComputer Studies, 46, p. 707-728.
Fowler, M., Scott, K., Biich, G., 1997. Uml Distilled:
Applying the Standard Object Modeling Language,
Addison-Wesley Pub Co.
Gaines B. R, Shaw M. L. G., 1993. Eliciting
Knowledge and Transferring It Effectively to a
Knowledge-Based System. IEEE Transactions on
Knowledge and Data Engineering, 5(1), p. 4-14.
Gaines B., and Shaw M., 1995. WebMap: Concept
Mapping on the Web. Proc. 4th WWW conference,
Boston (MA US).
Monteiro T., Perpen J.L. et Geneste L., 1999.
Configuring a machining operation as a constraint
satisfaction problem. In International Conference on
Computational Intelligence for Modelling Control
and Automation, Vienne : Austria.
Perpen J.-L., Le Raisonnement A Partir de Cas et la
résolution de problèmes en Productique. Etat de l'art
et propositions, Mémoire de DEA, laboratoire
GRAI, université de Bordeaux I, 1996.
------------------------------------------------------------------
Perpen J.-L., Geneste L., Noyes D.,1999a. KASKOO :
un système d'aide à l'acquisition et à la manipulation
de connaissances orientées objets. 3ème Congrès
International de Génie Industriel, Montréal :
Canada, 1, pp. 639-648.
Perpen J.-L., Garnier F., Dessein G., 1999b.
Formalisation de la connaissance pour le choix des
configurations d'usinage. 14ième Congrès Français de
Mécanique, CDROM, ISBN 2-84088-040-7,
Toulouse.
Perpen J.-L., 2000. Définition et réalisation d’une
application orientée objets pour la maîtrise du
processus de coupe. Thèse à l’ENIT Université de
Bordeaux I, spécialité en Mécanique, 10 Janvier
2000.
Quantrani T., 1998. Visual Modeling with Rational
Rose and UML. Reading, MA : Addison-Wesley.
Rechenmann F., 1989. SHIRKA : un modèle de
connaissance centré- objets, rapport interne,
laboratoire ARTEMIS/IMAG, Grenoble, France.
Ruet M., Geneste L., Perpen J.-L., 2000. Raisonnement
à partir de cas dans une structure de capitalisation
des connaissances orientée objet. Atelier de
Raisonnement à Partir de Cas (RàPC 2000),
Toulouse.