5.3 CRMA-1, un prototype en pilotage de programmes
5.3.2 Construction d’une base de connaissances en pilotage de pro-
La première étape de développement d’un système à base de connaissances est bien sûr la construction de la base de connaissances elle-même. Disposant par ailleurs d’ou- tils performants comme l’interpréteur du langage Y et le moteur d’inférence P- +, la construction de cette base de connaissances a constitué l’essentiel du travail de développement du prototype. La base de connaissances détaillée ici est construite suivant les contraintes associées au pilotage de programmes.
De conceptualisation en prototypage, et inversement
La construction de la base de connaissances dans le langage Y ne s’est pas ef- fectuée – loin de là – de manière linéaire. Plusieurs étapes ont nécessité des allers et retours pour parvenir à un résultat satisfaisant. On retrouve ici une méthode similaire à celle d’un expert hydraulicien chargé de caler manuellement un modèle numérique. Ces allers et retours se sont déroulés sur deux procédures.
Tout d’abord, la correspondance entre les connaissances initialement décrites dans le formalisme graphique UML et la base de connaissances en pilotage de programmes écrite dans le langage Y a nécessité des ajustements de la modélisation initiale pour une traduction cohérente dans le langage Y. Les principes de cette traduction sont présentés dans les paragraphes suivants. De même, l’implémentation de certains con- cepts présents dans le langage UML et nécessaires dans l’objectif fixé ont conduit à étendre la syntaxe du langage Y.
Ensuite, la concordance des résultats de l’exécution du système avec les objectifs fixés a été vérifiée sur les cas concrets de calage décrits dans les chapitres 6 et 7. Ces vérifications ont conduit à des raffinements dans la rédaction de la base Y.
Traduction UML–Y
Nous avons vu dans la section 5.2 au travers d’exemples comment les éléments – descriptifs et procéduraux – associés à des programmes se traduisaient naturellement
dans le langage Y, justement destiné à représenter ce type de connaissances pour le pilotage de programmes.
Nous avons ensuite utilisé le langage Y pour représenter l’ensemble des connais- sances décrites dans le chapitre précédent avec le formalisme graphique UML. Le prin- cipe de traduction des diagrammes de classes est présenté sur la figure 5.8. Chaque classe UML – attributs et méthodes compris – a été traduite par un type d’argument. Les méthodes – principalement les procédures de lecture et d’écriture des fichiers – ont été écrites enC++.
Nous avons enfin quelque peu détourné le langage Y de ses fonctions initiales pour représenter les diagrammes d’activités UML. Le principe de traduction de ces dia- grammes est présenté sur la figure 5.9. Chaque activité a été traduite par un opérateur, et les flots d’objets entrants et sortants par les arguments – Input Data et Output Data– de cet opérateur.
5.3 CRMA-1, CourbeSurSection HydrogrammeMesuré Débit Début : Date DébitsMesurés 0..1 2..* Fin : Date Section : SectionEnTravers compute_volume() volume : real Argument Type { name CourbeSurSection Attributes
Date name début Date name fin
SectionEnTravers name sectionDeMesure }
Argument Type { name Débit ... } Argument Type { name HydrogrammeMesuré Subtype of CourbeSurSection Attributes
Set of Débit name débitsMesurés
Float name volume
Methods
compute_volume() }
F. 5.8 –Exemple de traduction d’un diagramme de classes UML en types d’arguments
Y. La méthodecompute_volume()est écrite indépendamment enC++.
InitialisationDesParamètresHydrauliques
test_de_présence_d_ouvrages {Si des ouvrages sont présents sur la rivière, alors initialiser leurs coefficients de débit.} [paramètres définis] :ModèleHydraulique [paramètres initialisés] :ModèleHydraulique Composite Operator { name InitialisationDesParamètres Input Data
ModèleHydraulique name modèle_avec_paramètres_définis
Output Data
ModèleHydraulique name modèle_avec_paramètres_initialisés ... Body InitialisationCoeffRésistance - [ InitialisationCoeffDébit ] Optional Criteria Rule { name test_de_présence_d_ouvrages If modèle_avec_paramètres_définis.données.ouvrages <> nil
Then use_optional_operator InitialisationCoeffDébit } ... }
F. 5.9 –Exemple de traduction d’un diagramme d’activités UML en opérateurs Y. Les crochets entourant IntialisationCoeffDébit dans la partie Body indiquent un
opérateur-enfant optionnel, pris en compte suivant le critère d’optionalité représentée par la règle nommée test_de_présence_d_ouvrages. Cette règle consiste à tester la liste des
C 5 I ’
Évolution du langage Y
Comme évoqué précédemment, les besoins en modélisation ont nécessité une évo- lution du langage Y au travers de deux extensions principales :
– l’ajout d’opérateurs((locaux))(Local Operator) a permis de représenter des tâ-
ches terminales semblables à des opérateurs primitifs, mais au contenu entière- ment heuristique. Ce type d’opérateur a ainsi permis de représenter des activités non décomposables qui ne constituent pas une encapsulation de l’exécution d’un programme quelconque, comme par exemple laSélectionDUnEvénement;
– laprise en compte de collections d’éléments a quant à elle permis de représenter les
différents jeux de données, de paramètres et autres, présents dans notre modéli- sation. L’exemple de l’utilisation de ces collections pour définir un hydrogramme est donné sur la figure 5.8. Cette notion de collection est primordiale dans le cadre du calage, puisqu’un grand nombre d’objets utilisés sont présents sous cette forme : données de référence, paramètres, etc.
Structure de la base de connaissances et de la base de faits
Comme vu dans la section 5.2.2 (p. 130), la constitution d’un système à base de connaissances bâti autour du moteur P+ nécessite d’une part une base de connais- sances regroupant des fichiers textes écrits dans la syntaxe Y – selon les principes de traduction énoncés au-dessus – et d’autre part une base de faits, regroupant elle aussi des fichiers écrits dans la syntaxe Y, et formalisant les connaissances spécifiques au(x) système(s) étudié(s). La figure 5.10 présente la structure de la base de connaissances du système CRMA-1, et la figure 5.11 présente la structure actuelle de la base de faits de ce système.
Un point important est à noter dans la structure de la base de connaissances : nous nous sommes focalisés sur la spécialisation des connaissances pour l’hydraulique et nous avons de faitimmédiatement transposé les classes et activités génériques dans le domaine
de l’hydraulique. Quelques exemples permettent de prendre conscience de cette parti- cularité : aucun opérateur ne représente la tâche générique – c’est-à-dire indépendante du domaine – d’initialisation des paramètres. Un opérateur portant ce nom représente cette tâche directement dans le domaine de l’hydraulique fluviale (voir la figure 5.9). De la même façon, aucun type d’argument ne représente la classe génériquemodèle nu- mérique. Un type d’argument portant ce nom représente en fait le concept de modèle numérique en hydraulique fluviale. On ne peut donc pas dériver simplement cette base
de connaissances dans un autre domaine.
Cette particularité de la base de connaissances trouve son origine dans deux points différents. D’une part, des problèmes techniques se posent dans la gestion des types et des sous-types. La spécialisation explicite dans la base de connaissances de tâches
génériques nécessiterait ainsi la mise en place d’opérateurs d’interopérabilité tels que ceux décrits dans le chapitre précédent (section 4.5.4, p. 115) pour passer du niveau des connaissances hydrauliques au niveau des connaissances spécifiques au code M, c’est-à-dire pour passer des objets du domaine aux fichiers utilisés par le code. D’autre part, la base de connaissances s’est construite au fur et à mesure de nos travaux et l’identification d’un niveau générique de connaissances ne s’est pas imposée d’emblée. La lourdeur d’une implémentation systématiquea posteriori d’opérateurs d’interopéra-
5.3 CRMA-1, ConnaissancesCaRMA-1:BaseDeConnaissances :InitialisationDesParamètres:FichierYakl :DéterminationDesParamètres:FichierYakl :ConceptsHydrauliques:FichierYakl :ConceptsAssociésAMage:FichierYakl :RéalisationDUneSimulation:FichierYakl :RéalisationDUneSimulationAvecMage:FichierYakl :ComparaisonDesPrédictions:FichierYakl :ComparaisondesPrédictionsAvecMage:FichierYakl :AffectationDesDonnées:FichierYakl :AjustementDesParamètres:FichierYakl :QualificationDuModèleCalé:FichierYakl :ListeDesFichiers:FichierKb :MéthodesHydrauliques:FichierC++ :MéthodesAssociéesAMage:FichierC++ :CalageDeModèles:FichierYakl
F. 5.10 –Structure de la base de connaissances en pilotage de programmes pour CRMA-
1 – Diagramme de déploiement UML. Les fichiers représentés sur la droite regroupent les connaissances spécifiques au code M.
FaitsCaRMA1:BaseDeFaits
:FaitsSurLHogneau:FichierYakl
:FaitsSurLaLèze:FichierYakl
F. 5.11 – Structure de la base de faits en pilotage de programmes pour CRMA-1 – Diagramme de déploiement UML.
C 5 I ’
non-distinction de ces deux niveaux dans la base de connaissances. Nous reviendrons sur cet état de fait dans la section 5.4.
Le tableau 5.1 présente enfin quelques caractéristiques chiffrées de la base de con- naissances intégrée dans le système CRMA-1. Nous présentons dans la section sui- vante le mode de fonctionnement opérationnel de ce prototype.
Niveaux générique & hydraulique
Niveau du code M Total
Types d’attributs 75 22 97
Opérateurs 48 15 63
Règles 634 87 721
T. 5.1 – Quelques caractéristiques chiffrées de la base de connaissances en pilotage de
programmes.