Base d’énoncés, de documents,
de cas,...
Modèle empirique
Modèle informatique
Implémentation
Système à base deConnaissances
Modèle
« cognitif »
Extraction, Codage :
Prototypage Incrémental
Conception de Systèmes Experts
Approche directe
Dès que le développeur a acquis un élément de connaissance il l’implémente.
Avantages :
Montrer rapidement quelque chose,
En phase d’étude de faisabilité, permet de cerner des points tels que la communicabilité de la connaissance, les besoins des utilisateurs, … Inconvénients :
Manque de vision d’ensemble, d’abstraction, de fiabilité (tests a posteriori)
C. de Résolution
Données, Pb Solution
Prototypage Incrémental
Diagnostic bilan comptable Approche indirecte
Elève le niveau d’abstraction;
Ouvre la voie à la réutilisabilité - de modèles de Domaines
Informatique Economie
Mécanique Médecine
Permet un contrôle a priori;
- de méthodes de Résolution
Planification Diagnostic Identification Maintenance
Diagnostic médical
Maintenance logiciel
C. de Domaine
C. de
Résolution Tâche Générique
indépendante du Domaine Q : Peut-on bâtir un modèle d’un domaine susceptible de couvrir tous les usages
i.e. à la fois neutre vis à vis de toute tâche et réutilisable ? Où s’arrête un Domaine ?
Q : Dispose t-on de méthodes génériques pour tout type de tâche ? Granularité optimale des méthodes génériques ?
(généricité versus réutilisabilité)
Sait-on discriminer (pour sélectionner) les tâches génériques ?
Schéma de Résolution
Objets de Raisonnement
+ =
Ontologie de Domaine Une vue consensuelle sur un Domaine
indépendante de la Tâche
=
Q : Fusion ?
« is a »
« is a »
1) Approche ‘ontologique’ (analytique) par sélection
1) Approche ‘ontologique’ (analytique) par sélection
Task
System
Analysis Design
Planification
Modeling Configuration
Structure Distribution
Sélection
parmi … Construction à
partir de …
Modeling
‘par sélection’
(KADS 1)
Catégorie
Prediction
Classification
Identification
Diagnosis
Défaillance Etat
SingleFault Diagnosis
MultipleFault Diagnosis
2) Approche constructiviste
Construction et/ou
Adaptation, Raffinement, …
& Combinaison de « Design Pattern »
Modèle de Domaine adapté au pb
Image du Domaine
Schéma de
Résolution générique Domaine
Résolution
Objets de Raisonnement
(un point de vue sur tout Domaine)
intègre des
se concrétise en
Modèle de Résolution
'client'
+ ‘customization’ ‘instanciation’
‘extraction’
(Design Patterns) K. de résolution
K. Domaine
(Ontologies)
Composant en panne en marche
Fonction assurée nécessaire pour
dépend
nécessaire pour(C, F) ∧ C. en marche = faux => F. assurée=faux dépend (F1, F2) ∧ F2 . assurée = faux => F1. assurée = faux F. assurée = faux ∧ influence (F, C) => C . en marche = faux C . en panne = vrai => C . en marche = faux
Exemple de Pattern : (structure,
influence
Méthodes :
m1 : { A partir de dysfonctions,déterminer les composants défectueux } m2 : { Evaluer l’influence d’un défaut sur composant }
schémas causaux, méthode(s))
T M
~
Observation Dysfonction constaté
partie de
Description de(s) la méthode(s) (flux des connaissances, enchaînement de pas inférentiels) associée(s) au Design Pattern
K. entrée
K. ressources
K. sortie inférence
{observation}
schéma causal 1
{fonction}
inf1
composant . coût composant inf3 {composant}
inf2
schéma causal 2
…
…
inf4
Une classification des pas inférentiels
inférer entrée : E1 ressource : E2
sortie : E3
<< signature >>
transformer entrée : E1 ressource : E2
sortie : E3
re-décrire entrée : E1 ressource : E2
sortie : E1
déduire entrée : E1 ressource : E2
sortie : E3
<< E2 = modèle causal >>
extraire entrée :{ei} ressource : E2
sortie : ei
<< E2 = critère >>
distribuer entrée : {ei} ressource : E2 sortie : {ek}*{el}*…
<< E2 = fonctions d’appartenance >>
ordonner entrée : :{ ei} ressource : E2
sortie : :{ ei}o
<< E2 = relation d’ordre >>
évaluer entrée : ei ressource : E2
sortie : ei
<< E2 = fonction >>
Composant en panne en marche
Fonction assurée nécessaire pour
dépend
nécessaire pour(C, F) ∧ C. en marche = faux => F. assurée=faux dépend (F1, F2) ∧ F2 . assurée = faux => F1. assurée = faux F. assurée = faux ∧ influence (F, C) => C . en marche = faux C . en panne = vrai => C . en marche = faux
1) Sélection de Pattern, (structure, 2) Instanciation
influence
(alim moteur, moteur)
(alim transfo, transfo) (alim moteur, alim transfo)
(alim transfo, alim secteur) (plombs, alim transfo)
schémas causaux, méthode(s))
T M
~
Observation Dysfonction constaté
partie de
(bobine, transfo)
alim. moteur alim. secteur alim. transfo
plombs moteur transfo bobine
Méthodes :
m1 : un Flux Inférentiel
Organe défaillant en marche
Fonction assurée nécessaire pour
dépend
nécessaire pour(C, F) ∧ C. en marche = faux => F. assurée=faux dépend (F1, F2) ∧ F2 . assurée = faux => F1. assurée = faux F. assurée = faux ∧ influence (F, C) => C . en marche = faux C . défaillant = vrai => C . en marche = faux
1) Customisation de Pattern 2) Instanciation
influence
(respiration, coeur)
(respiration, inspiration) (respiration, expiration) (poumon, respiration)
Méthode : ...
Symptôme constaté
partie de respiration
inspiration expiration
poumon coeur
Service ....
Fonction ....
en charge de
contrôle, ...
...
1) Modification, Fusion, … de Pattern 2) Instanciation
Méthode :
…
Indicateur ....
Agent ....
role
production avant-vente
marketing
1) Construction du Modèle de Résolution = set of Patterns 2) Instanciation ( → Modèle ‘client’)
3) Test du Modèle ‘client’ (bruit, silence)
Défaut diagnostiquée
Traitement prescrit entraîne
incompatible Exemples
Règle InstanciationIncohérente 1 (bruit)
∀ t1, t2 ∈ Traitement : t1 . prescrit ∧ t2 . prescrit ∧ incompatible(t1, t2) ⇒ Pb d'Instanciation
n n
Action
incompatible
Règle InstanciationIncomplète 1 (silence)
∀ m ∈ Défaut : ¬ ∃ entraîne(m, t) ⇒ Pb d'Instanciation (m1, t1)
(m1, t2) (m2, t2)
( t1, t2)
m1 m2 m3
t1 t2
Ces règles découlent de la sémantique des objets de raisonnement et de leurs relations ( ∈∈∈∈ pattern) et sont à appliquer aux K. de domaine
Dès la conception du Modèle de Résolution,
on élabore le protocole de test du Modèle ‘client’
1) Construction du Modèle de Résolution = set of Patterns 2) Instanciation ( → Modèle ‘client’)
3) Test du Modèle ‘client’ (bruit, silence)
C. de Résolution
Pb Solution
Approche par modèle
Meta C.
C. en Modélisation de Domaine & Résolution de Pb
+ {Règles et guide d’usages } { Design Pattern }
1) Construction du Schéma de Résolution, 2) Instanciation ( → Modèle ‘client’)
3) Test du modèle ‘client’
Un modèle est une réalisation d'un méta-modèle.
(une instanciation)
L'étape 1 est une étape 2 ! qui s’appuie sur une étape 1 :
Construction du Schéma de Résolution de
« Conception de Modèles »
« Conception de Modèles » contient, par définition, une structure (les notions de méta-modélisation),
des schémas causaux, une méthode (méthodologie de modélisation) +
les règles permettant de tester la validité de ses instanciations (et donc de réaliser l’étape 3 )
