A propos des choix de mod´ ` elisation

2.2.1 Comment notre mod`ele a-t-il ´et´e ´elabor´e ?

´

Elaborer un mod`ele, c’est faire une succession de choix. Dans notre cas, la m´ethode de concep-tion sciemment suivie a ´et´e principalement ascendante. L’´etat de l’art ayant abouti `a la d´ecision de cr´eer notre propre mod`ele de m´etadonn´ees, nous sommes partis de l’examen des traitements `a d´ecrire. Cela a fourni le premier squelette du mod`ele (fig. 2.18 p. 96). Nous avons s´electionn´e des exemples de traitements – pour la majeure partie des traitements de g´en´eralisation d´evelopp´es au COGIT – et avons commenc´e `a les d´ecrire. Les ´el´ements de description sont ainsi apparus pro-gressivement. Des entretiens avec les utilisateurs ont ´et´e men´es, des questionnaires diffus´es (cf. p. 231). Chaque besoin d’information nouvellement identifi´e impliquait la cr´eation d’un ´el´ement de description suppl´ementaire du mod`ele.

Occasionnellement, nous avons proc´ed´e de fa¸con descendante. Il n’avait ainsi pas ´et´e envi-sag´e, initialement, de d´ecrire l’environnement mat´eriel des ordinateurs ex´ecutant les traitements. C’est en songeant `a ce th`eme g´en´eral que nous avons introduit plusieurs ´el´ements de description particuliers, ´el´ements dont la pr´esentation aux auteurs de traitements a r´etrospectivement permis d’identifier de nouveaux exemples de besoins (cf. exemple p. 123).

S’il est difficile de d´egager une r´ef´erence particuli`ere de l’´etat de l’art qui ait notablement influ´e sur le choix des ´el´ements de description de base du mod`ele, on peut en revanche citer OWL-S comme source d’inspiration dans la fa¸con de les organiser. Nous reprenons et ´etendons en effet l’id´ee des trois facettes de descriptions des traitements (ce que fait le traitement, comment il fonctionne, comment y acc´eder). Les classes qui r´eifient ces facettes sont d’un niveau d’abstraction sup´erieur `a celui des classes correspondant aux ressources plus ´evidentes, “concr`etes” pourrait-on dire, comme les algorithmes ou les formats de donn´ees.

On peut subodorer que, pour des besoins tels que les nˆotres, l’int´erˆet et l’originalit´e d’un mod`ele r´esident surtout dans la pr´esence de classes abstraites permettant une appr´ehension et des manipulations efficaces des m´etadonn´ees. De ce point de vue, l’´etat de l’art pertinent n’est pas tant celui des descriptions de traitements que celui des principes de repr´esentation des connaissances. Les notions d’orient´e-objet et de frames ont ´et´e sommairement ´evoqu´ees dans les pages pr´ec´edentes ; celles plus sp´ecifiques aux syst`emes `a base de connaissances sont pr´esent´ees au chapitre 3. La volont´e d’exploiter informatiquement les connaissances d’expert a ´emerg´e `a la fin de la premi`ere ann´ee de travail, notamment lorsque sont apparues les difficult´es `

a r´epondre aux utilisateurs demandant une adaptation des modes d’emploi. La prise en compte de ce nouveau point de vue a alors rejailli sur le mod`ele, en particulier sur les classes pr´esent´ees au chapitre 3.

Mod`ele conceptuel, mod`ele d’impl´ementation et application d’acc`es aux m´etadonn´ees

Un mod`ele conceptuel est une repr´esentation d’un domaine exprim´ee dans un formalisme autant que possible neutre vis-`a-vis des soucis d’impl´ementation. Un mod`ele d’impl´ementation est la traduction formelle d’un mod`ele conceptuel dans un langage informatique.

D`es le d´ebut de notre travail un langage d’impl´ementation a ´et´e choisi. En permanence, toute ´evolution du mod`ele conceptuel se traduisait imm´ediatement dans le mod`ele d’impl´ementation. Une application Web permettant de consulter la base de m´etadonn´ees naissante a ´et´e d´evelopp´ee d`es la premi`ere ann´ee de th`ese. Cela a permis de recueillir tr`es tˆot les commentaires d’utilisateurs cobayes non seulement sur le mod`ele mais aussi sur l’interface de consultation. Ces deux types d’enseignements ont ´et´e mutuellement profitables. Nous verrons par exemple p. 104 comment le besoin de voir illustr´ees dans l’interface les donn´ees avant et apr`es traitement a amen´e `a enrichir

le mod`ele.

Le d´eveloppement parall`ele de l’application et du mod`ele a donc ´et´e profitable. Notre d´emarche a ´et´e incr´ementale. En effet la succession de phases “analyse – conception – impl´ementation – tests – validation” [LJP98] a permis l’´elaboration progressive d’un mod`ele dont la base de m´etadonn´ees instance supportait un nombre croissant de besoins d’information. Ce faisant, la faisabilit´e du projet r´epondant aux objectifs initialement d´efinis a ´et´e contrˆol´ee. Notamment, de fa¸con r´ecurrente, les utilisateurs cobayes nous ont mis en garde contre une complexit´e excessive du mod`ele.

Si construire tˆot un mod`ele d’impl´ementation pr´esente l’avantage de permettre des exp´eri-mentations pr´ecoces, cette d´emarche comporte n´eanmoins un risque, celui que la prise en compte des propri´et´es du langage adopt´e biaise notre fa¸con d’appr´ehender le probl`eme et parasite le mod`ele conceptuel. Soucieux d’´eviter un tel travers, nous avons tent´e de garder constamment claire la s´eparation entre les deux mod`eles, conceptuel et d’impl´ementation. La r´ealit´e de l’acti-vit´e de mod´elisation n’est cependant pas si simple. D’abord parce que le formalisme du mod`ele conceptuel n’est pas neutre, ensuite parce que les caract´eristiques des langages informatiques peuvent jouer le rˆole de masque ou au contraire d’aide selon ce que l’on souhaite repr´esenter.

2.2.2 Notre mod`ele de m´etadonn´ees est-il orient´e objet ?

Parmi les sp´ecifications qui accompagnaient notre sujet de th`ese lors de notre arriv´ee au laboratoire COGIT, il figurait une demande particuli`ere : le mod`ele conceptuel de m´etadonn´ees `

a d´efinir devait ˆetre exprim´e sous forme de diagramme de classes UML. Compte tenu de cet imp´eratif, il nous parait utile de pr´eciser notre position vis-`a-vis des notions de l’orient´e objet.

Une des raisons de la demande d’utilisation du formalisme UML ´etait l’objectif d’in-terop´erabilit´e avec une future plateforme58 de m´etadonn´ees. L’id´ee qui pr´esidait au sein de l’action de recherche Consul ´etait que les diff´erents mod`eles (de tˆaches, de m´etadonn´ees des traitements et de m´etadonn´ees des donn´ees) soient instanci´es sous forme de classes Java.

Par ailleurs, et de fa¸con li´ee, l’usage au sein du laboratoire COGIT est d’utiliser la notation UML comme support de communication59. Quant au langage Java, il est utilis´e pour GeOxygene, l’une des deux plateformes de d´eveloppement du COGIT.

Ce contexte ´etant pos´e, on peut se demander si notre mod`ele doit forc´ement ˆetre orient´e objet, et si par cons´equent UML est bien la notation la plus adapt´ee `a ce que l’on souhaite exprimer (ind´ependamment du fait que le besoin d’un langage commun de communication est une raison suffisante pour l’adopter).

Il existe parfois une confusion entre l’id´ee de repr´esentation orient´ee objet et celle de program-mation orient´ee objet. Clairement, nous consid´erons que notre mod`ele rel`eve de repr´esentation OO mais non de la programmation OO. Nous allons voir que notre mod`ele fait appel `a deux principes :

– celui de classe et d’instance, – celui d’h´eritage.

Ces deux principes sont caract´eristiques des langages de repr´esentation OO. Mais pr´etendre faire de la programmation OO suppose de mettre en œuvre, en plus de ces principes, ceux d’encapsulation des propri´et´es et des m´ethodes, d’abstraction (visibilit´e variable des propri´et´es et des attributs entre les objets), de polymorphisme (m´ecanisme pour invoquer des m´ethodes

58Ensemble de structures de donn´ees, de logiciels et de librairies facilitant le d´eveloppement ou l’exploitation de programmes.

59N´eanmoins, au sein de l’IGN, il existe une tradition de formalisation en HBDS. Cette notation est en effet enseign´ee `a l’ENSG par Fran¸cois Bouill´e, qui en est le cr´eateur.

d´esign´ees par un mˆeme nom, mais diff´erentes selon le contexte) [LJP98]. Si l’on consid`ere la pro-grammation OO comme reposant avant tout sur l’encapsulation des propri´et´es et des m´ethodes, elle est un d´epassement de la programmation proc´edurale. Dans notre contexte au contraire, l’exploitation envisag´ee de notre mod`ele dissocie clairement les donn´ees et les traitements qui leurs sont appliqu´es. Cette dissociation est d’ailleurs un principe que l’on retrouve dans diverses m´ethodes de conception de syst`emes d’information : MERISE60, par exemple, mais aussi plus r´ecemment des m´ethodes utilis´ees notamment dans le domaine bancaire.

La notation UML est d´esormais le standard pour la mod´elisation en programmation OO. En revanche, elle n’est pas n´ecessairement la plus adapt´ee pour tous les mod`eles de repr´esentation OO. On pourra pr´ef´erer adopter d’autres notations pour certains mod`eles d’impl´ementation mettant en œuvre les notions de classes et d’h´eritage. On verra de plus qu’UML ne permet pas d’exprimer certaines contraintes de mod´elisation61.

2.2.3 R´eifier les familles de traitements

Les connaissances que nous voulons repr´esenter portent non seulement sur des traitements ou ensembles de traitements (Buffer.java, Arcview, etc.), mais aussi sur des familles de traitements (SIG, logiciels Windows, programmes Java, etc.).

Prenons un exemple. Supposons qu’une nouvelle plateforme de d´eveloppement G´eoEx bas´ee sur le langage Java doit ˆetre d´ecrite. Les programmes de cette plateforme partagent un certain nombre de propri´et´es : sur les pr´e-requis pour les lancer, sur leur compatibilit´e, sur le domaine des fonctionnalit´es qu’ils r´ealisent, etc. Cette connaissance doit pouvoir s’exprimer grˆace `a notre mod`ele. Certes, il serait possible de proposer `a l’expert de d´efinir un ensemble de r`egles "si appartientPlateforme( ?prg, G´eoEx) alors ...". Mais une telle solution n’est pas propice `a un recueillement syst´ematique et contrˆol´e des connaissances. L’abandon des premiers syst`emes expert pour des syst`emes bas´es sur les frames ou l’orient´e objet le montre. Il est plus ´el´egant de proposer `a l’expert de d´ecrire la famille de traitement programmeG´eoEx comme un programme poss´edant les caract´eristiques typiques attach´ees `a ladite plateforme. Cela implique qu’il existe dans notre mod`ele une classe FamilleTraitement.

Les FamilleTraitement h´eritent les unes des autres : dans notre exemple, on peut ainsi imaginer que programmeG´eoEx h´erite de programmeJava.

Si les instances de FamilleTraitement ´etaient elles-mˆemes des classes, FamilleTraitement serait une m´eta-classe. Ce n’est pas exactement le choix que nous faisons. En fait, notre mod`ele permet de dire, par exemple, qu’Arcview, instance de Logiciel, est li´e aux deux instances de FamilleTraitement SIG et LogicielWindows par la relation62 “type”. Si l’on consid`ere “type” comme une relation d’h´eritage, alors nous faisons l`a de l’h´eritage multiple.

“SIG” et “LogicielWindows”, pour des raisons d’extensibilit´e et parce que ce sont selon notre point de vue des ressources `a d´ecrire, doivent figurer dans la base de m´etadonn´ees en tant qu’instances de classe et non dans le mod`ele en tant que classes. Si de nouvelles familles de traitements apparaissent, leur prise en compte ne doit pas affecter le mod`ele. Nous reviendrons sur la question au moment de pr´esenter les diagrammes de classes.

60http://www.commentcamarche.net/merise/concintro.php3

61cf., entre autres, l’exemple sur l’association entre entr´ee et sortie p. 102, ou la restriction de propri´et´es fig. 2.16 et 2.17, p. 95. Pour permettre `a ces contraintes d’apparaˆıtre dans les diagrammes de classes UML, le langage OCL (Object Constraint Language) a dˆu ˆetre cr´e´e.

62relation est un terme employ´e notamment dans le langage UML. Nous parlerons ´egalement de propri´et´e des classes, qui sont des fa¸cons de repr´esenter les relations. Dans les logiques de description, sur lesquelles reposent les ontologies que nous verrons plus avant, les relations sont appel´ees rˆoles, et les propri´et´es attributs ou slots.

La s´emantique que nous attribuons `a la relation “type” permet simplement de transmettre des valeurs de propri´et´es. Par exemple Arcview est de type LogicielWindows, donc son syst`eme d’exploitation est Windows.

Restrictions de propri´et´es

Nous avons besoin de contrˆoler les valeurs des ´el´ements de nos descriptions. Cela commence par la restriction de l’ensemble des valeurs possibles pour une propri´et´e. Les figures 2.16 et 2.17 donnent deux exemples de nos souhaits en la mati`ere.

Un contrˆole plus fin consiste `a s’assurer de la coh´erence entre diff´erentes m´etadonn´ees. Par exemple, si un programme qui impl´emente un algorithme doit r´ealiser le mˆeme type de fonc-tionnalit´e que lui, les informations sur les types de donn´ees abstraits et impl´ement´es doivent ˆetre coh´erents. De mˆeme, les descriptions respectives d’une fonction et du logiciel `a qui elle appartient ne sont pas sans relations. Les r`egles de coh´erence ne pourront pas apparaˆıtre dans la d´efinition du mod`ele. Elles seront donc exprim´ees en tant que m´eta-connaissances et utilis´ees par l’application exploitant la base de m´etadonn´ees.

Fig. 2.16 –Restriction de l’ensemble des valeurs possibles pour la propri´et´e type donn´ee