Informatique et architecture : développement du système MARS et synthèse théorique

HAL Id: hal-01901173

https://hal.archives-ouvertes.fr/hal-01901173 Submitted on 22 Oct 2018

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Informatique et architecture : développement du

système MARS et synthèse théorique

Brigitte David, Didier Berger, Colette Bernanose

To cite this version:

Brigitte David, Didier Berger, Colette Bernanose. Informatique et architecture : développement du système MARS et synthèse théorique. [Rapport de recherche] 400/86, Ministère de l’urbanisme, du lo-gement et des transports / Secrétariat de la recherche architecturale (SRA); Ecole nationale supérieure d’architecture de Grenoble / Association grenobloise pour la recherche architecturale (AGRA). 1986. �hal-01901173�

Ministère de l'Urbanisme, du logement et du transport

Secrétariat de la Recherche Architecturale

Uoo

Ecole d'Architecture de Grenoble

Association Grenobloise de Recherche Architecturale

10 galerie des Baladins 38100 Grenoble

In fo rm a tiqu e et A rc h ite c tu re :

Développement du Système M.A.R.S. e t sunthèse théorique.

RAPPORT FINAL.

B. DAVID. D. BERGER. C. BERNANOSE

Plan

I. Avant-propos

II. Introduction

III. Systèmes Intelligents

Il 1.1 Stratégies de coopération Il 1.2 Supports de coopération

IV. Systèmes Intelligents en CAO IV. 1 Stratégies de coopération

IV .I.a Modélisations du processus de conception

IV. 1.b Modèle Généralisé de Processus de Conception (M6PC)

IV.2 Supports de coopération

IV.2.a Différentes réprésentations de connaissances

IV.2.5 Système de Gestion de Connaissances

V. Application à la Programmation Architecturale

VI. Conclusion

I - AVANT-PROPOS

Depuis trois ans, nous menons des recherches sur différents aspects de la programmation architecturale et plus particulièrement sur des possibilités d'assister la programmation architecturale par ordinateur.

Le premier travail théorique ( contrat MULT 1984) nous a permis de dégager une démarche de programmation architecturale ayant l'avantage de pouvoir recevoir un support Informatique. La deuxième étape (contrat MULT

1985) avait pour but de réaliser un premier prototype d'un système Informatique pour la programmation architecturale appelé MARS (Modélisation Architecturale intégrant la Référence Spatiale). Ce prototype réalisé en Logo nous a permis de tester notre approche et de mettre en valeur des besoins supplémentaires que ce système devrait avoir.

La présente étude se veut le re fle t de la recherche de cet approfondissement qui nous a amené au fur et à mesure de son avancement, à préciser nos objectifs.

Tout d'abord, 11 faut préciser que nous considérons que la programmation architecturale se situe en amont de toute proposition spatialisée de solution architecturale, c'est à dire au niveau du Programme d'architecture, des souhaits, des contraintes (éventuellement contradictoires, exprimés ou suggérés) qu‘11 contient.

•

Notre premier prototype a permis d'étudier la façon de prendre en compte un certain nombre d'informations, et de lès faire évoluer soit du domaine le plus conceptuel au plus spatial et/ou réciproquement, en gardant en permanence la possibilité de retrouver l'historique de ces différentes manipulations. Cette première version a montré de façon claire d'une part le besoin d'améliorer l'interaction homme-machine, et d'autre part la possibilité d'exploiter autrement que de façon textuelle les informations acquises et transformées.

A la suite de cette étude, notre souhait était de poursuivre en utilisant non seulement notre expérience antérieure, mais en tentant d'interfacer notre programme avec les travaux effectuer par l'équipe de recherche du

Laboratoire d’informatique de l’Fcole d’Architecture de Toulouse, c’est à dire les programmes PADAO et surtout TANGRAM, qui nous semblait contenir un certain nombre d’éléments susceptibles de compléter utilement notre système. Malheureusement, une étude détaillée nous a conduit à abandonner ce projet notamment pour deux raisons:

la ta ille du programme sous sa version complète P ADAO+TANGRAM+Interprète LOGO nécessitait une mémoire de 768 K dont nous ne disposions pas,

- l'Interprète LOGO alourdissait considérablement les temps de réponse et ne donnait donc pas de satisfaction,

Il n’était donc pas raisonnable de construire une autre couche au-dessus de ce logiciel comme nous l’envisagions Initialement (ta ille de mémoire disponible, temps de réponse).

Nous avions alors le choix entre recréer un logiciel adapté à notre contexte, travail routinier sans grand d’intérêt ou poursuivre nos recherches dans des directions novelles et donc plus enrichissantes. Nous avons opté pour la deuxième solution et nous nous sommes orienté vers l'étude d'un Système In telligent pour la Programmation Architecturale. En effet l'Impact des techniques d'intelligence A rtific ie lle est de plus en plus grand dans toutes les activités. Il nous a semblé utile d'explorer les possibilités d’introduction de ces techniques dans les activités de Programmation Architecturale.

Pour cela nous nous sommes d’abord Intéressé à l’évolution de la Conception Assistée par Ordinateur en général, pour prendre et adapter à la Conception Architecturale Assistée par Ordinateur toute entière, puis à la Programmation Architecturale Assistée par Ordinateur en particulier toutes les étapes d’évolution qui nous semblaient transposables. Dans les solutions étudiées et proposées nous avons voulu garder cette ouverture vers la CAO en général. C’est ainsi que notre étude dépasse largement le cadre restreint de la Programmation Architecturale pour s’appliquer à la CAAO voire la CAO en général. Toutefois les exemples traités dans ce document seront du domaine de la programmation architecturale.

Il - INTRODUCTION

Analysons Coût d'abord l'évolution de la Conception Asssltée par Ordinateur en général.

La CAO. tout en ayant un avenir prometteur a déjà une longue histoire derrière elle. En effet les premiers programmes de calculs ont vu Jour 11 y a déjà une vingtaine d'années. Cette première étape est caractérisée par des outils autonomes, le plus souvent des calculs et en tout cas des algorithmes.

La deuxième étape est caractérisée par un soucis de proposer une interface homme-machine plus agréable, elle a conduit d'abord aux sorties graphiques, dans un environnement de traitement par lot (batch), grâce aux premières tables traçantes; puis à l'utilisation Interactive grâce au traitement en temps partagé.

La troisième étape caractérisée par l'intégration de divers outils au sein d’un système CAO avait pour but d'exploiter toutes les possibilités de l'ordinateur (traitement, mémorisation et entrées-sorties) de façon la plus profitable pour l'utilisateur en l’occurrence le concepteur de produit.

La quatrième étape dans l'évolution de la CAO peut être caractérisée par l'Intégration de la conception et de la fabrication: création d'un système Intégré de CF AO, avec le soucis de meilleure coopération possible entre la conception et la fabrication.

La cinquième étape dans l'évolution de la CAO est celle que nous abordons actuellement et qui est caractérisée par une intégration encore plus importante, qui commence à être connue sous le vocable Tuslne intégrée par ordinateur" ou encore Computer integrated Manufacturlng. Il s'agit d'intégrer au sein d'un même système tous les aspects de conception, étude, développement, fabrication et gestion du processus

Industriel.

En parallèle de cette dernière évolution nous en vivons actuellement une autre au moins aussi Importante celle de l'Introduction des techniques d'intelligence a rtific ie lle dans le traitement des informations. Cette approche conduit vers les systèmes intelligents que nous discuterons de façon détaillée dans la chapitre suivant.

L'évolution de la CAAO est au moins en partie la même que celle de la CAO en général. En effet le passage des outils autonomes au système Intégré en passant par des améliorations des entrées-sorties a également été vécu en CAAO. L'Intégration CAO-FAO n’est pas encore tout à fa it à l'ordre du jour quant à l'usine Intégrée la question ne se pose pas et 11 ne faut surtout pas la poser.

L'évolution vers les systèmes Intelligents semble être le créneau privilégié de la CAAO car 11 n’existe pas de domaine dans lequel les connaissances et leur utilisation seraient plus subjectives.

La même analyse peut être appliquée à la Programmation Architecturale. L'approche "Système Intelligent" apparaît donc comme très prometteuse.

III. SYSTEMES INTELLIGENTS

L'introduction des techniques d'intelligence a rtific ie lle dans les systèmes CAO a pour but de les faire évoluer vers des systèmes Intelligents.

Cette évolution est tout à fa it naturelle. En effet, Jusqu’à présent la CAO ne prenait en compte que des traitements dont on était capable de fournir les algorithmes c'est à dire dont on a analysé et formalisé globalement (sous forme d'algorithme) le comportement. 11 n'était pas possible de prendre en compte des traitements plus complexes pour lesquels une vision globale, algorithmique, est Impossible de découvrir. De la même façon les Informations gérées par les systèmes CAO ont été limitées aux données sans la possibilité de prendre en compte des caractéristiques de ces données pour vé rifie r leur validité, assurer leur cohérence et procéder aux déductions et plus généralement prendre en compte des liens sémantiques, intelligents, entre les données. Il en était de même pour l'Interface homme-machine.

On était donc en présence d'un outil ou d’un système d'aide au concepteur tout à fa it passif dans lequel le concepteur non seulement pouvait mais devait penser à tout et demander explicitement toutes les évolutions.

Un système Intelligent devrait permettre de prendre en compte des traitements non-algorithmiques, exprimés de façon déclarative et incrémentale. Il devrait également gérer des connaissances, c’est à dire des données intelligentes avec leurs caractéristiques sémantiques, des règles de déduction et de cohérence. Il devrait en plus fournir une interface utilisateur appropriée, adaptable et évolutive pour prendre en compte la diversité des utilisateurs et de situations.

L'approche Système Expert ouvre la voie vers les systèmes intelligents. En effet cette approche permet une démarche Incrémentale dans la saisie de l'expertise et la constitution de la hase de connaissances. Elle permet également une gestion de la cohérence, des déductions et en général la manipulation de la sémantique des Informations.

constatation qu'ils ne sont performants que pour des problèmes ardus mais lim ités à un domaine bien précis. En plus Ils passent généralement d'un cahier des charqes directement à la solution qu'ils proposent.

En CAO, pour des produits complexes, on se trouve dans un contexte dans lequel d’une part le domaine de compétence est très vaste, nécessitant la participation de plusieurs concepteurs chacun compétent dans son domaine. D’autre part pour ces problèmes complexes, la solution fin ale est élaborée progressivement par la coopération de ces spécialistes (exemple: la conception d'un calculateur embarqué est faite par des spécialistes d'électronique, d’informatique (matériel et logiciel), de mécanique, etc...).

Nous pouvons envisager deux démarches pour u tilise r l’approche Système Expert en CAO:

- la construction d'un Super Système Expert (SSE), capable de prendre en compte tous les aspects de la Conception;

U tilis a te u r s

Figure il 1-2 Architecture d’un Super Système Expert.

- la construction d'un Système Multl-Expert (SME), comme une fédération d'un ensemble de Systèmes Experts, chacun compétent dans son domaine d'application (figure II 1-3 page suivante).

Il nous semble que la première approche n'est pas réaliste. En effet, 11 semble Illusoire de vouloir enfermer dans une seule base de connaissance toutes les Informations et de les prendre en compte en même temps. Ceci non seulement à cause du mécanisme d'inférence mais également et surtout à cause de la nature des Informations que l'on doit prendre en compte et donc modéliser.

Figure II 1-3 Architecture d’un système Multi-Expert.

C'est la raison pour laquelle, nous avons décidé de nous Intéresser à la deuxième démarche, celle d'un Système M ulti-Expert, en étudiant diverses stratégies de coopération entre les systèmes experts utilisant des Connaissances semblables ou différentes ainsi que leur modélisation et divers moteurs d'inférence.

En effet les deux problèmes majeurs posés par des Systèmes Multl-Experts sont:

- les stratégies de coopération, - le support de coopération

Examinons ces deux aspects de façon général.

111.1 Stratégies de Coopération des Systèmes Experts

Les différents S.E. évoluant au sein d'un Système Multi-Expert (S.M.E.) peuvent travailler de différentes façons. Les principales caractéristiques de leurs comportements mutuels sont les suivantes:

- la situation mutuelle dans le processus, qui caractérise la relation de deux S.E. au sein du processus d'élaboration. On peut identifier cinq cas:

a/ Indépendant (pas de relation), b/ séquentiel

c / parallèle

d/ en boucle fermée e/ en boucle ouverte

- l’utilisateur se servant des deux S.E. peut être soit le même, soit différent;

- l'expert élaborant la base de connaissances peut être soit le même, soit différent;

- la Base de Connaissances peut être soit la même, soit différente; - la Base de Faits peut être soit la même, soit différente: c'est à dire

plus ou moins détaillée;

- d'autres caractéristiques peuvent être prises en compte, en particulier la nature du moteur d'inférence et la modélisation des connaissances utilisée.

Nous avons étudié ces différentes situations et nous avons établi des configurations-type.

Pages suivantes: INDEPENDANTS

FIGURE II 1.4 Etude des

stratégies de coopération SERIE PARALLELE DOUCLE FERMEE

PROCESSUS UTILISATEUR EHPERT CONNAISSANCES FAITS COMMENTAIRES

m im e même même =r ?

même même même _> ?

même même _* = ? même même > ? même 4 : même ₌ ? même 4= même > ? même _{« « =} ? même * * > ?

* même même = concours entre plusieurs _équipes

* même même > ?

* même * =

étude Indépendante d'un p ro je t par différen tes équipes, pour d ifféren ts aspects

même _{4b >} ?

bÉ 4 : même ₌

étude indépendante d'un p ro je t par différentes équipes, pour d ifféren ts aspects, sur des con naissances communes.

45 4 : même > ?

4= 45 ₌

même opération: concepteurs d ifféren ts tra v a illa n t avec des systèm es experts différents au même niveau de résolution

PROCESSUS UTILISATEUR EHPERT CONNAISSANCES FAITS COMMENTAIRES

même même même tra vail inutile !

même même même _>

même même _&

même même > même =îfc même ₌ même même > même _* * ₌ même * * > même même = * même même > même _& s même > =Ê _* même * _* même > — ■

tra vail personnel par étape

pourquoi ? d ifféren tes appro ches du même problème tra vail personnel, d ifférentes étapes d'un p ro je t

tra vail personnel pour d iffé ­ ren ts aspects du même projet travail personnel, différentes étapes du p ro je t. Connaissan­ ces communes

tra v a il personnel sur d iffé ­ ren ts aspects du même problème

tra vail personnel dans les d ifféren tes étapes d'un p ro je t

tra v a il inutile ?

travail en équipe, approche classique

pourquoi ? D ifféren tes approches du même problèmt le même exp ert fo u rn it des connaissances différen tes poc des résolutions d ifféren tes étude de faisabilité

règlem entation

avant p ro je t - p ro je t, équipe; connaissances communes diverd aspects d'une étude de faisabilité

PROCESSUS U T ILIS A TE U R EHPERT C O N N A IS S A N C E S FA ITS C O M M E N T A IR E S

même même même =

même même même même m ême même même ^ même ÿ même ^ même =fc même même même travail personnel en parallèle

équipes tra v a illa n t sur d

if-* meme meme

féren tes p artie s du même p ro je t, élaboration de d iffé ­ rentes propositions

même même > 7■a

même ₌ d iffé re n ts aspects du

problèmes

même _{* >} ?■

élaboration de d ifférentes

* =Sfc même propositionsconnaissances communes

même > ?a

■

élaboration de d ifféren ts aspects d'une proposition

PROCESSUS UTILISATEUR même EHPERT même CONNAISSANCES même FAITS

même même même _>

COMMENTAIRES

tra v a il inutile

itératio n sur le niveau de résolution

même même prise en compte de nouveaux

outils

même même _> itératio n sur ie niveau de

résolution e t prise en compte de nouveaux aspects

meme meme meme

7= _meme

= validation par experts

d ifféren ts

nÉ même _> résolution e t apports des itératio n sur le niveau de experts d ifféren ts

- >

apports des experts d iffé ­ rents pour d ifféren ts aspects

apports des experts d iffé ­ rents pour d ifféren ts aspects à niveau de résolu­ tion croissant

même même as validation collective

même même _> apport de nouveaux _éléments

même ₌ d ifféren tes sensibilités

même _> nouveaux éléments et

nouveaux aspects

* même = validation collective

* même > connaissances communesniveau croissant sur des

• * = étude de d ifféren ts aspects e t leur in te rreiatio n

* >

étude de d ifféren ts aspects e t de d ifféren ts niveaux de résolution

PROCESSUS f B J * U TIL IS A T E U R m ê m e EHPERT m ê m e C O N N A IS S A N C E S m ê m e FA ITS C O M M E N T A IR E S

afflnam ent, vérificatio n

f f g T m ê m e m ê m e m ê m e > - f g r m ê m e m ê m e _* s s - f S r * m ê m e m ê m e _> 7 g 1 * m ê m e m ê m e ₌ m ê m e * m ê m e > 7 g 1 * m ê m e * * s s f e r m ê m e > affinem en t, vérificatio n + apports extérieurs 7 g 1 * m ê m e m ê m e f S r * m ê m e m ê m e > f B J ' m ê m e * •SS * m ê m e * > 7 g 1 * * * m ê m e ₌ 7 g r * * m ê m e > j e L * * s f S r 5 É 3* >

Il 1.2 Support de Coopération

Un autre problème Important est celui du choix du support de coopération. En effet, comme nous l'avons vu au paragraphe précédent le travail de différents S.E. n’est pas Indépendent. Il faut donc permettre aux différents systèmes d’échanger des Informations. Ceci peut être fa it principalement de deux façons différentes:

- par interfaces spécifiques entre différents S.E., ce qui conduit à un réseau de S.E. particulier dont on doit assurer la gestion coup par coup, c'est à dire pour chaque nouveau S.E. on doit réaliser les Interfaces avec tous les S.E. avec lesquels il doit coopérer;

- par un support unique: un Système de Gestion de Connaissances auquel tout S.E. du S.M.E. peut accéder soit en lecture, soit en écriture et avoir donc à sa disposition des informations souhaitées.

Cette deuxième approche semble plus Intéressante, car plus générale, même si elle est plus d iffic ile à mettre en oeuvre.

Dans ce qui suit nous allons étudier ces deux problèmes fondamentaux: stratégies de coopération et support de coopération dans le contexte de la CAO en général et nous Illustrerons notre démarche par un exemple Issu de la Programmation Architecturale.

Figure II 1-6 Support de coopération: approche support unique Système de gestion des connaissances

IV. SYSTEMES INTELLI6ENTS EN CAO

La réalisation d'un système intelligent en CAO basée sur l'approche de Système Multi Expert passe principalement par la solution des deux problèmes fondamentaux qui sont la définition des stratégies de coopération et le choix du support de coopération.

IV.1 Stratégies de coopération

Pour proposer différentes stratégies de coopération dans le contexte de la Conception Assistée par Ordinateur nous avons été conduit à étudier différentes modélisations du Processus de Conception pour en dégager une synthèse qui permettrait d'exprimer ces stratégies.

IV .I.a Modélisations du Processus de Conception

Le modèle de conception a pour but d'indiquer le ou les processus de conception selon lesquels la conception peut être effectuée. L'Importance du modèle de conception n'est pas la même selon qu'il s'agisse d'une conception individualiste ou collective. Dans le premier cas, le processus de conception n'a pas à être transmis, 11 peut donc rester uniquement dans la tête du concepteur et celui-ci peut le modifier dynamiquement sans problème majeur, étant seul responsable de ses actes. A partir du moment où on est en présence d'une conception collective, le problème de qui fa it quoi et quand se pose. Il s'agit donc de définir le déroulement du projet du point de vue des responsabilités d’une part, et du point de vue temporel d'autre part.

La CAO doit être considérée comme un cas particulier de la conception collective même si elle est utilisée par un seul concepteur, car il s'agit de partager le travail et les responsabilités entre l’homme et la machine.

Le modèle de conception doit mettre en évidence les concepts de base qui régissent la conception. Il doit avoir un champ de validité certain et remplir des conditions importantes d'adaptabilité, d'évolutivité et d'extensibilité.

Malheureusement les connaissances précises des règles qui régissent la conception sont encore très limitées, ce qui rend toute proposition discutable et constitue un obstacle que la CAO doit surmonter. Néanmoins pour pouvoir mettre en place des systèmes CAO 11 faut modéliser même provisoirement et partiellement ce processus. C'est ce qui est de toute façon fa it dans l'Industrie où on n'a pas attendu des résultats théoriques pour organiser des processus de conception qui doivent produire des résultats.

Les tentatives de modélisation du processus de conception ont été nombreux. Chacune correspond à une vision du processus en s'appuyant sur des techniques de modélisation Issues des mathématiques, de l'automatique, de l'optimisation, de la théorie d’information, etc... Nous pouvons en rappeler quelques unes:

- DEMARCHE IMPLICITE (boite noire) : on procède sans méthode apparente, sans justification, s'appuyant sur l'expérience et sur l'Intuition (on synthétise sans savoir quoi),

Cette démarche est couramment utilisée par les architectes, elle leur laisse une entière liberté de comportement, de jugement et de responsabilité. La subjectivité est la pièce maîtresse de cette méthode qui par contre ne permet que très difficilem ent la justification et la collaboration.

B o i t e M o ir e

FIGURE IV-1: BOITE NOIRE

formelle selon un cheminement pré-défini, basé sur un raisonnement logique et en ju s tifia n t toutes les étapes. Cette démarche s'appuie sur l'explicitation du déroulement du processus de conception, c'est à dire sur des schémas de comportement pré-définis selon lesquels le travail doit se dérouler.

Ainsi on rend ce travail plus systématique, ce qui fa cilite le partage du travail et la collaboration entre différentes personnes et permet d'avoir recours aux procédés pouvant assister le concepteur dans son travail.

Remarque: l'utilisation d'un système expert s'apparente pour l'utilisateur à une démarche de boite noire qui peut à postérlori dévenir transparente, car le système expert peut si l’on lui demande, exp liciter à postérlori son fonctionnement en expliquant et Justifiant ses choix.

B o ite tra n s p a re n te

FIGURE IV - 2: BOITE TRANSPARENTE

- ENCHAINEMENT: la conception d'un objet, notamment d’un objet complexe n'est jamais faite d'un coup. Il parait donc intéressant de mettre en évidence des étapes dans l’élaboration de l'objet. Ainsi on parle d'objet CONCEPTUEL, d'objet VIRTUEL, d'objet REEL ou de façon plus détaillée de MAQUETTE VIRTUELLE de l'objet, de la MAQUETTE REELLE, de PROTOTYPE d'objet réalisable, etc... En tout cas, il s'agit d'exprimer un découpage chronologique dans un déroulement du processus de conception ou de façon plus globale, du processus Conception - Etude - Développement (CED), si on ne se lim ite pas seulement à la conception mais si on prend en compte aussi la fabrication. A ces différents stades de l'objet correspondent des étapes appelées par exemple: avant-projet, projet, Industrialisation, fabrication.

Processus de conception

FIGURE IV - 3 : PHASES DE CONCEPTION

- BOUCLE: 11 semble aussi Important de modéliser le déroulement d'une étape de ce processus. On la représente généralement par la boucle: ANALYSE, SYNTHESE, EVALUATION, DECISION. On commence par analyser la partie concernée du cahier des charges puis on conçoit la solution. Cette solution doit être évaluée puis la décision de l'accepter ou pas doit être prise. Si elle est positive on passe à l'étape suivante si elle ne l'est pas on doit remettre en cause l'objet conçu et envisager une autre solution.

Cahier des charges

- OPTIMISATION: souvent on a essayé de modéliser le processus de conception comme un processus d’optimisation. Dans ce cas, 11 s'agit d’identifier:

♦ les variables sur lesquelles le concepteur peut agir, + les paramètres que le concepteur ne peut pas Influencer,

+ les contraintes permettant d’exprimer les liens entre les variables et les paramètres,

♦ la fonction-objectif qui exprime ce que l’on cherche.

L’Intérêt de ce type .de modélisation n’est pas aussi grand que l’on pourrait le croire. Il est très utile dans les ultimes étapes du processus où on peut véritablement parler d'optimisation, mais dans les étapes Initiales, où on crée réellement on ne dispose pas, malheureusement, ou peut-être heureusement, d'un tel modèle.

FIGURE IV - 5 : PROCESSUS DE CONCEPTION COMME UN PROBLEME D’OPTIMISATION

- PROBIFMF BIEN ET MAL DEFINI: la modélisation précédente met en évidence un aspect Important de la conception; si on connaît bien ce que l'on veut obtenir, 11 est possible d’u tilise r des techniques d'optimisation. On est en présence d'un problème bien défini, on peut donc u tilise r pour sa résolution un modèle bien défini. Dans ce cas 11 s'agit souvent d'ajustement

V -v o rla b le s

P -p o ra m è tre s

de valeurs, c'est à dire de ce que l’on appelle la conception paramétrique. Mais la véritable conception est la conception où on part d'un cahier des charges plus ou moins précis et on conçoit l'objet. Dans ce cas il s'agit d'une véritable création car on doit découvrir progressivement l'objet aussi bien du point de vue de sa structure que de sa sémantique. Dans ce cas 11 s’agit d'un processus de transformation dans lequel on élabore peu à peu des versions de plus en plus précises du cahier des charges de l'objet à concevoir et de l'objet conçu. Les techniques utilisées sont aussi bien heuristiques qu'analogiques. Pour les problèmes mal définis (et tout problème est d'une certaine façon mal défini car sinon on n'a plus besoin de concevoir), on procède par itération avec une reformulation de plus en plus précise.

FIGURF IV - 6 : PROBI FMF MAI DEFINI

- INTUITION, CRFATIVITE, INDUCTION, DEDUCTION, EXPERIENCE: pour bâtir une nouvelle version de l'objet à concevoir et de l'objet conçu on exploite alternativement diverses méthodes de résolution basées sur l'Intuition, la créativité, l'expérience, la compétence, l'Induction ou la déduction.

FIGURE IV - 7 : ACTIVITE DE CONCEPTION

Dans ces schémas d’organisation on joue en réalité sur la composante la plus adaptable Intervenant dans ce processus, l’homme, qui grâce ou malgré des schémas d'organisation, est capable de résoudre le problème qui lui est posé. On constate finalement en étudiant de près ces structures qu'elles ne permettent pas de réaliser quoi que ce soit mais délimitent le champ d’action laissé au concepteur.

Fn CAO le problème est différent, car 11 ne s’agit pas de délim iter mais d'assister le concepteur de façon Intime dans toutes les tâches qu'il effectue. Ceci implique une connaissance approfondie de son activité et dépasse donc largement l'aspect exprimé par un schéma d'organisation. I.'effort de modélisation doit être nettement plus grand. C’est la raison pour laquelle nous avons élaboré un modèle plus complet appelé "Modèle Généralisé du Processus de Conception" (MGPC), qui sera présenté dans la paragraphe suivant.

IV. 1 .b Modèle généralisé du processus de conception (MGPC)

Notre approche s'appuie sur une Idée originale exprimée 11 y a plusieurs années par (R1v.77), le modèle proposé trouve dans le nouveau contexte de systèmes CAO Intelligents un aboutissement Inespéré.

LA CONCEPTION est une activité, un processus qui produit un OBJET CONCU à partir d'un OBJET A CONCEVOIR. Elle comporte:

- un processeur: le concepteur (naturel ou a rtificie l),

- une méthode de conception, composée d’une séquence d'actions de conception,

- des objets manipulés par le concepteur.

l a conception s’effectue dans un domaine de conception au sein duquel nous pouvons caractériser séparément deux sous-domaines:

- le domaine des objets,

- le domaine des concepteurs.

Dans le domaine des objets, on décrit la procédure de conception comme le passage de l'objet à concevoir (OAC) à l’objet conçu (OC). A partir des différentes modélisations du processus de conception présentées dans le paragraphe précédent nous avons dégagé, en nous Inspirant des travaux de (R1v.77), quatre aspects des objets: leur morphologie, leur définition, leur structure et leur résolution. Ces aspects constituent des directions différentes dans le domaine des objets.

- DIRECTION MORPHOLOGIQUE: de la fonction vers la forme, vers la structure, c’est à dire de l'abstrait et qualitatif au concret et quantitatif, ou encore des notions conceptuelles aux notions relationnelles, aux notions dimensionnelles et finalement, aux notions matérielles.

- d ir e c t io n DF DEFINITION: on s'intéresse à la fonction de la conception

en tant que telle. Elle exprime qu'est-ce que l'on conçoit, pourquoi, et elle indique les objectifs sous forme de la définition de l’objet à concevoir, et donc, du problème de conception: le passage de l'objet à concevoir à l’objet conçu. Cette direction prend de l’Importance pour les problèmes mal définis où il faut d’abord élaborer la définition de l’OAC. Pour les problèmes bien définis, le déplacement dans cette direction n’a pratiquement pas Heu.

- DIRECTION STRUCTURELLE: étude de la structure des objets pour structurer leur conception (objet, sous-objet, l'articulation des sous-objets). Cette direction est donc liée à la méthode de conception, ascendante ou descendante, que l’on souhaite utiliser.

0 1 tn ui oc a> CD 3 zt cr C T (D H 3 ab C T o «CD o > O CL_OO Eo «a>_a> (D 3 C T C d é ta illé e schématique p ré lim in a ire MORPHOLOGIE 1er niveau "problème global" 2ème niveau "sous problèmes' 3ème niveau

S TR U TU R A TIO N

- DIRFCTION DF LA RFSOLUTION: on appelle résolution le degré de détail dans la représentation d*un objet. C'est la quantité et la finesse de l'information contenue dans le modèle de l’objet (définition en profondeur). Cette direction est associée à la notion courante de phase de conception, associée elle-même à la méthode descendante, ou par affinage successifs: conception préliminaire, conception schématique, conception détaillée.

Sur la Figure VI - 8 (tirée de R1v.77), nous montrons les différentes directions de conception pour une définition donnée. Un processus particulier dans cet espace de conception est défini par un cheminement dans cet espace.

On retrouve donc un graphe de conception avec les états de conception comme dans les autres modèles de conception. Mais par rapport à ces modèles, dans celui-ci nous pouvons caractériser très exactement les transitions entre états. Leur nature est définie par leur orientation dans l'espace et correspond à une transition (ou à une composition des transitions) appartenant à l'ensemble des transitions définies pour chaque direction. De cette façon, 11 est possible de gérer le changement d'état de façon cohérente et systématique.

Nous avons remarqué que le changement d'état s'effectue la plupart du temps dans une seule direction selon la règle "une chose à la fois". Par contre, à partir d’un état donné, 11 faut presque toujours pouvoir aller dans les quatre directions. On obtient donc un support de processus qui peut engendrer des processus très variés.

Dans le domaine des concepteurs, on décrit les trois caractéristiques des concepteurs, à savoir:

- la motivation (très d iffic ile à prendre en compte), la seule qui semble actuellement exploitable est la motivation fonctionnelle qui correspond à la notion de responsabilité,

- l’Intuition, qui agit dans le sens de la génération de variété pouvant faire appel aux méthodes de créativité,

- la compétence, qui agit dans le sens de la réduction de variété, et peut s'appuyer sur les méthodes rationnelles et l'acquis technique qui semble important de gérer. I e lien ou la relation qui existe entre le domaine des

concepteurs et le domaine des objets est la compréhension. On peut augmenter la compréhension d'un système-objet par la manipulation du système jusqu'à la détermination des relations de causalité et des lois de variation des différentes variables observées dans le système. C’est un processus d'apprentissage qui est lié aux notions d'analyse de système.

C'est la manipulation de l’objet conçu qui constitue la face visible du processus de conception proprement dit. A partir du cahier des charges, d'un champ de solutions possibles (l’acquis technique ou expérience du concepteur), le concepteur propose des solutions, puis les évalue. A chaque étape de conception, la définition du produit se précise et passe d'un concept à une réalité. L’ensemble des descriptions retenues constitue le dossier de définition du produit et il importe donc de gérer celui-ci en conséquence. Il existe fréquement plusieurs types de dossier concernant un même produit: dossier d’étude, de développement, de production, de maintenance....

Ce qui rend le. métier de concepteur d iffic ile est certainement la m ultiplication et l'hétérogénéité des objectifs ou performances que doit satisfaire l'objet conçu. Jusqu'alors, ces performances étalent acquises séquentiellement pendant les étapes successives de la conception. Mais aujourd'hui, leurs Interdépendances, ou leurs incompatibilités, Imposent de leur attribuer un poids re la tif et de les prendre en compte globalement. Cette tendance est amplifiée par la recherche de compétitivité et l'obligation plus rigoureuse du respect d'une politique Industrielle définie. Cette dernière se traduit notamment par un ensemble de contraintes Imposées ou discutées, qui sont à considérer par le concepteur comme autant d'objectifs ou de performances à saflsfalre. Il découle de ceci que le traditionnel "cahier des charges", généralement celui du client, se transforme en ce que l'on appellera "les objectifs et contraintes pondérés". Nous entendons par:

- OBJFCTIF: la définition du but à atteindre décrit de façon fonctionnelle,

- CONTRAINTF: la définition du moyen que l'on doit u tilise r dans l’élaboration de l'objet ou dans l'objet lui-même,

- PONDFRATION: un moyen d'exprimer le compromis entre l'ensemble des objectifs et des contraintes pouvant être contradictoires.

COP 1 COP 2 CO P 3 /

n+1 n+1 n+1

BASE DE

CONNAISSANCES

GESTION O B JEC TIFS ET C O N TR A INTES (Objet à Concevoir)

V A L ID A T IO N D'UNE ETAPE DE

CONCEPTION FIGURE IV - 9 : ETAPE DE CONCEPTION

OBJET CONCU

Une étape de conception aura pour entrée un ensemble d'objectifs et contraintes pondérés de niveau n et produira un ou plusieurs ensembles d’objectifs et contraintes pondérés du niveau n+1 (Fig. IV - 9).

I a gestion des objectifs et contraintes pondérés pose deux problèmes

Importants:

- il faut assurer la conformité et l’Intégrité des objectifs et contraintes pondérés à chaque étape de transform ation, problème d iffic ile car leur

expression doit être adaptée au "métier" du concepteur d'un niveau donné, mais doit aussi refléter exactement la décision du niveau supérieur formalisée dans un autre langage. Les notions de propriétés, associées aux entités conçues et reflétant leur aptitude à satisfaire un ensemble des objets et contraintes pondérés ainsi que leurs relations, devront pouvoir être manipulées et évaluées par des algorithmes logiques ou arithmétiques.

- la "traçabilité" du projet, ou suite cohérente des "pourquoi"et "comment", doit être mémorisée et exploitable. En effet, en cas d’impossibilité de satisfaire l'ensemble des objectifs et contraintes pondérés n au niveau n+1, il faut pouvoir remonter au niveau de décision supérieur pour redéfinir un nouvel ensemble. En plus, 11 est Important de pouvoir prévoir et gérer toutes les conséquences liées aux demandes de modifications. Afin de donner une solution à ces deux problèmes nous proposons de procéder de la façon suivante: pour assurer la conformité et l’Intégrité des ensembles d’objectifs et contraintes pondérés et des objets conçus nous définissons des opérations sémantiquement cohérentes qui assurent la sauvegarde de l'Intégrité. En plus nous les lions aux directions de l'espace de conception, c’est à dire que nous définissons par quelles opérations 11 est possible de passer d'un état à un autre selon la transition choisie et le sens du déplacement.

Ainsi nous pouvons préciser (voir le tableau Fig IV - 10) le comportement de l'objet à concevoir et de l'objet conçu lors du déplacement dans une direction. Nous pouvons aussi préciser la nature de l’opération à effectuer lors d'un tel changement (voir Fig. IV - 11).

Définition Etape - morphologie

| C OPI I I OBJ J I COP 1 | | OBJ J 1

- r

| OBJJ+1 |

Phase - Résolution Structure

FIGURE IV - 10 : OPERATIONS

Pour assurer la "traçabilité" du projet, nous proposons d'utiliser une RFI ATION DF CAUSE A EFFET (FIG.IV-12), que le système gère à chaque modification et permet ainsi de retracer le déroulement du projet et éventuellement de revenir en arrière lors des Impossibilités.

ESPACE DE CONCEPTION

4 DIRECTIONS _{MODIFIE CONCERNE NON MODIFIE} - DEFINITION - ETAPES (MORPHOLOGIE) - PHASE (REALISATION) OBJET A CONCEVOIR OBJET CONCU OBJET CONCU OBJET CONCU OBJET A CONCEVOIR FIGURE IV - I l : OPERATIONS ET DIRECTIONS

- STRUCTURE

OBJET CONCU

OBJET A CONCEVOIR OBJET A CONCEVOIR

FIGURE IV - 12 : RELATION DE CAUSE A EFFET

Le modèle MGPC constitue un moyen d’expression des coopérations possibles entre les S.F. En effet les déplacements élémentaires dans les directions de l'espace de conception constituent les stratégies

élémentaires de coopération, des stratégies plus sophistiquées peut être obtenues par la composition des stratégies élémentaires. La "traçabilité" du projet à l’aide de relations de cause à e ffet et l'expression du cahier des charges à l'aide des objectifs et contraintes pondérés complètent utilement le modèle et permettent la réversibilité du processus et son explication.

1V.2 SUPPORTS DE COOPERATION

IV.2.a D ifférentes réprésentations de connaissances

Pour modéliser des connaissances on trouve dans la littérature des modèles variés. Il ne s'agit pas Ici de les présenter mais seulement de les lis te r et de rappeler leurs propriétés principales.

IV.2.a.l la logique du premier ordre

Le logique formelle sert depuis longtemps à représenter des raisonnement, l e calcul des propositions n'est pas suffisant pour exprimer la plupart des problèmes, le calcul des prédicats en est une extension, mais l'expression correcte d'un problème devient vite complexe.

IV.2.a.2 les règles de production

l 'expression sous forme de règles de production du type SI condition ALORS action permet d'exprimer de façon déclarative des situations que l'on peut tester et appliquer à la demande. Les règles de productions sont surtout utiles pour exprimer des connaissances durables. Elles sont donc utilisées dans la Base de Connaissance.

IV.2.a.3 les f rames

Pour modéliser des connaissances stéréotypées on souhaite pouvoir exprimer le modèle des Informations à gérer. La notion de FRAME (cadre) a pour objectif de permettre de définir le squelette des objets à manipuler et de pouvoir

IV.2.a.4 les dépendances conceptuelles

Les dépendances conceptuelles sont utilisées pour représenter de façon spéreotypée des structures du problème à traiter.

IV.2.a.5 les scripts et plans

I es scripts servent à décrire des activités stéréotypées en s'appuyant sur les notions d'acteur, d'objet et d'événement, l es plans décrivent de

façon stéréotypée des Intentions fumalnes et des méthodes utilisées. IV.2.a.6 les réseaux sémantiques

Les réseaux sémantiques sont des ensembles de noeuds reliés entre eux par des arcs: chaque noeud symbolise les objets, concepts ou événements que l'on veut représenter, chaque arc relie deux noeuds et détermine le type de relation qui existe entre eux. Une notion d'héritage de propriétés permet de gérer la cohérence.

IV.2.b Système de Gestion de Connaissances d'un Système M ultl-Expert

Nous allons présenter le Système de Gestion de Connaissance, comme support homogène et unique de coopération de S.E. dans un Système Multl-Expert, que nous avons défini et que nous appelons KMS (Knowledge Management System). Nous allons d'abord rappeler les objectifs principaux d'un support de coopération.

Il semble que les contraintes les plus fortes soient celles de l’évolutivité et de l'extensibilité. En e ffet dans les applications classiques, 11 est possible de définir complètement au préalable l'univers dans lequel cette application va se dérouler. On peut donc figer la structure et la sémantique des Informations qui seront stockées et manipulées.

En CAO-SME ceci n’est possible ni pour la structure, ni pour la sémantique, car la structure est conçue pendant le processus de conception au même titre que les autres aspects de l'objet de la conception. Ceci est aussi vrai pour la sémantique que l'on veut prendre en compte, car celle-ci varie d'un projet à l'autre et dépend également des compétences du concepteur.

Nous définissons l'EVOLUTIVITE comme une possibilité de faire progresser dynamiquement la STRUCTURE de l’objet décrit et la SEMANTIQUE attachée à cette structure.

Nous définissons l'EXTENSIBILITE comme une possibilité de prendre en compte de nouvelles caractéristiques (propriétés sémantiques et relations), de nouvelles organisations structurelles.

A p a rtir du moment où on prend en compte l'évolutivité et l'extensibilité des données, 11 n'est plus possible de travailler avec des organisations de gestion basées 3ur des structures statiques et on doit u tilis e r des structures Interprétatives, c'est à dire des structures adaptables pouvant être facilement modifiées.

La démarche que nous avons choisie est la suivante: dégager un modèle abstrait, le formaliser et fournir des moyens et des outils pour construire sur celui-ci des modèles concrets liés aux applications traitées.

I e modèle abstrait ne peut plus être monolithique, et nous devons donc mettre en évidence des éléments à l'aide desquels 11 est possible de bâtir le squelette de l’organisation et du fonctionnement du KMS.

Ce modèle doit pouvoir respecter le but du processus de conception qui est d'élaborer l'objet conçu correspondant à la définition exprimée par l'objet-à-concevolr. Cette définition est représentée par les objectifs et les contraintes, et s'affine au fu r et à mesure de l'avancement du processus de conception. L'objet lui-même suit cette évolution. Pour faire face aux contraintes d’évolutivité et d'extensibilité nous avons mis en évidence quatre composants fondamentaux du modèle. Il s'agit de:

- LA STRUCTURE: ayant pour rôle d'exprimer l'organisation structurelle du projet,

- LA SEMANTIQUE: exprimant la signification des éléments organisés structurellement,

- LA COHERENCE: assurant l'évolution cohérente de l'objet pendant la conception,.

- I FS OPERATIONS : fournissant des outils à l'aide desquels on peut manipuler les Informations, et les faire évoluer pendant le processus.

IV.2.b.1 Structure

l a structure doit permettre de m atérialiser différentes méthodes de conception (descendante, ascendante, mixte), c'est pourquoi on se ramène la plupart du temps à une structure hiérarchique (ou arborescente). Elle doit aussi pouvoir exprimer les différents points de vue. Une telle structure a reçu dans la littérature le nom de hiérarchie abstraite. Cette structure multl-hlérarchique doit être construite et modifiée dynamiquement (Fig. IV -13). Elle ne peut donc pas être définie une fols pour toutes. Il faut p artir des éléments de la structure et des liens.

EVOLUTIVITE

A COTE

DESSOUS

FIGURE IV-13 : STRUCTURE MULTI-HIERARCHIQUE EVOLUTIVE

l a première notion de base de la description structurelle est la notion d’ENTITF. Une "ENTITE" est un contenant qui peut recevoir une description d"’objet" de complexité quelconque, mais qui est toujours un objet "à

concevoir" (cahier des charges), ou "conçu". Les "ENTITES" doivent pouvoir être composées entre elles et permettre ainsi une description hiérarchisée. Pour exprimer cette organisation il faut u tilis e r des liens. La deuxième notion de base de la description structurelle est la notion de RELATION. Une "RELATION" représente un lien entre entités. Nous faisons la distinction entre des relations verticales (de structuration) et des relations horizontales (de fonctionnement).

IV.2.b.2 Sémantique

La structure n'est qu'un aspect de la description, la signification (la sémantique) en est un autre. Pour exprimer cette signification nous introduisons la notion de "PROPRIETE". Les objets et les relations qui se trouvent dans la hiérarchie sont donc caractérisés par les propriétés. Ces propriétés doivent pouvoir évoluer dans le temps. Une entité est décrite par les "PROPRIETES" qui lui sont attachées. Ces propriétés permettent de qualifier et quantifier l'objet, avec un degré de définition évoluant au cours de la conception. Les propriétés peuvent être classées par familles (ex.: secteur d’activité, spécialité,...).

Ayant présenté comment on peut exprimer la structure et la sémantique, nous devons maintenant en décrire l'utilisation. Comme il n’est pas possible de figer des entités, des relations et des propriétés en les énumérant, nous devons introduire un moyen pour travailler de façon plus progressive. Ceci est réalisé grâce à la notion de GENERICITE connue aussi sous l’appellation de type ou de modèle. Le principe en est le suivant: on crée d’abord les modèles ou les types d'objet que l'on souhaite manipuler, puis à l’utilisation on choisit des valeurs précises et on crée ainsi des occurences particulières d'objets. De cette façon il est possible de prévoir les types d'objet que l'on veut manipuler et de les valuer à l’utilisation.

L'évolutivité structurelle est ainsi assurée, car l'utilisateur peut à l'aide de ces éléments bâtir une structure de son choix. Mais ceci n’est pas suffisant, car en CAO, il faut pouvoir prendre en compte de nouvelles caractéristiques de l'objet de façon tout à fa it dynamique. Il n'est donc pas toujours possible de prévoir, dans la phase de création du modèle conceptuel concret, toutes ses caractéristiques.

Il faut donc définir un moyen encore plus général et plus souple que la généricité classique, pour introduire de nouveaux types d'éléments dans la

phase d'utilisation du modèle conceptuel concret. Ceci est en effet nécessaire pour assurer l’évolutivité sémantique. Une solution consiste en l'u tilisa tio n d'une structure Interprétative. Pour cela on peut p a rtir d'une seule entité pour l'ensemble des objets traités. Cette entité est tout à fa it générale car elle est capable de recevoir des Informations de toutes natures. Cette entité doit pouvoir contenir toutes les informations nécessaires, c'est à dire le nom de l'entité, son contenu sémantique décrit par un ensemble de propriétés et son comportement structurel décrit par un ensemble de relations hiérarchiques et fonctionnelles.

Malheureusement cette définition est insuffisante, car nous n'avons aucun renseignement sur la nature des informations stockées dans l'entité. Afin d’y accéder et de les manipuler 11 nous faut avoir des caractéristiques plus précises tout en gardant la souplesse d'utilisation. Pour cela au lieu de figer des entités, nous allons commencer par figer les éléments constitutifs des entités. Nous allons d'abord définir des types de propriétés. Nous Indiquons de façon générique le comportement d'une propriété d’un type donné. Ce comportement se traduit par le type de valeur que la propriété peut prendre et par un ensemble d'opérations permettant de manipuler cette propriété. Pour fa c ilite r la mise en oeuvre de types de propriétés, 11 convient de permettre une construction de types de propriétés à p a rtir de types de base. Dans ce cas il est possible de définir dynamiquement des propriétés composées en composant des types de valeurs et des opérations pouvant les manipuler. Cette méthode de construction s'avère très utile pour assurer l'évolutivité et l’extensibilité.

l a mise en place d'une entité peut s’effectuer de différentes façons: - de façon DIRECTE : on prend l'entité générique et on définit en même temps les types de caractéristiques souhaitées et les valeurs associées. Cette entité n'est connue que par son nom propre,

- de façon INDIRECTE : on prend l'entité générique et on définit les types de caractéristiques que l'on souhaite prendre en compte, puis on sauvegarde ce modèle d'entité comme un modèle particularisé. Lors de l'utilisation on peut valuer directement ce modèle d'entité et créer des occurences,

- de façon PROGRESSIVE: on procède de façon Indirecte mais en plus 11 est possible de sauvegarder des modèles partiellement valués. L'utilisateur

peut définir dynamiquement une nouvelle entité en précisant l’ensemble de caractéristiques propres et des relations qui la définit. Cette entité peut être manipulée comme telle, ou bien elle peut être nommée et conservée comme un type d'entité. De cette façon 11 n'est plus nécessaire de la reconstruire entièrement lors de la prochaine utilisation, mais 11 s u ffit de la valuer. Aussi bien pour les entités typées que non typées, 11 faut supposer que la définition courante n'est que partielle, et que l’utilisateur voudra et devra pouvoir Introduire de nouvelles caractéristiques propres ou des relations, et modifier celles existantes.

IV.2.b.3 Cohérence

l e rôle du KMS n'est pas seulement de stocker des Informations du projet, 11 doit aussi assurer et garantir leur cohérence. Cela doit être fa it tout au long du déroulement du processus de conception. Il ne s'agit pas seulement de la cohérence physique (protection contre le malfonctionnement du système de gestion), mais surtout de la cohérence logique liée à un projet précis. Cette cohérence logique doit être maintenue pendant tout le déroulement du projet.

l ’évolution des Informations peut s'effectuer selon deux grandes classes de manipulations:

- manipulations locales: modifications ponctuelles, souvent interactives, d'une partie de la description,

- manipulations globales: changement global et systématique de la représentation. Il faut donc assurer la maintien de la cohérence dans ces deux types de manipulations. Pour assurer l'évolution de l’objet aussi bien du point de vue de sa structure que de ses caractéristiques, et pour garantir la cohérence de cette évolution, nous avons défini cinq types de contraintes de cohérence:

- les liens horizontaux entre les propriétés du même composant: nous parlerons de la dépendance des propriétés,

- les liens verticaux entre les propriétés de différents composants: nous parlerons de la correspondance des propriétés dans la hiérarchie,

dans le processus de conception: nous parlerons de transformations, (manipulations globales),

- les contraintes d’utilisation par rapport au déroulement du processus de conception: nous parlerons de l'utilisation,

- les contraintes d’accessibilité par rapport aux fonctions attribuées au sein de l'équipe de conception: nous parlerons d'accessibilités.

I es propriétés d'une entité peuvent être dépendantes. Dans ce cas, les relations de DEPENDANCE entre propriétés définissent ces liens (ex.: surface d'une pièce et son contour). Ces relations de dépendance entre propriétés (contraintes d'intégrité), sont des Invariants pendant la conception. (Fig. IV -14).

FIGURE IV-14 : RELATION DE DEPENDANCE

Pour chaque propriété 11 faut donc savoir si elle est liée dans une relation de DEPENDANCE et de quelle façon (source ou cible, relations symétrique ou assymétrlque, formule de dépendance calculable, inhibante ou spéciale). Les propriétés des entités dans la structure hiérarchique peuvent aussi être en relation (ex: la surface de l'appartement est la somme des surfaces des pièces qui le composent). On a donc une relation structurelle entre propriétés, que nous nommons CORRESPONDANCE des

propriétés. Ces attributs sont aussi des contraintes d'intégrité, et sont donc Invariants pendant la conception (Fig. IV -15). L'attribut de correspondance peut être:

- hérité - synthétisé - spécial

FIGURE IV -15 : RELATION DE CORRESPONDANCE

La description du déroulement du processus de conception fournit la règle d'utilisation, dans une étape donnée du processus, (accède, crée, modifie) des informations décrivant l'objet. On spécifie donc les différents filtre s d’accès aux données, par rapport à la phase de conception (contrainte d’utilisation). Cette description Indique aussi comment cette vision se modifie lors d’un changement d’étape. Les TRANSFORMATIONS qu'il faut effectuer concernent aussi bien des propriétés (sémantiques) que la structure. De plus on associe à l'objet des droits d’accès et d'utilisation, selon les responsabilités du concepteur dans le projet donné.

IV.?.b.4 Opérations

l es opérations sur la description de l'objet doivent permettre la manipulation de cette description: création d'entités, structuration de

l’objet, définition et mise à jour de propriétés et de relations.

l.es opérations sur la description du processus doivent permettre à l’utilisateur d'effectuer son projet, donc de parcourir le processus de conception de la façon qui lui semble utile (avec des retours en a rriè re ,...).

A p a rtir du moment où on veut assurer une cohérence sémantique, il n'est plus possible d'autoriser des opérations quelconques, 11 est indispensable de fournir des opérations sémantiques «garantissant par elles-mêmes la continuité de la cohérence.

I es contraintes d'évolutivité et d'extensibilité rendent ce maintien de cohérence plus d ifficile . C'est pourquoi 11 faut raisonner séparément sur la structure et sur la sémantique. Il est possible de définir un ensemble d'opérations structurelles:

- ajouter une entité dans la structure,

- supprimer une entité au niveau d'une feuille de la hiérarchie ou au niveau Intermédiaire,

- créer ou supprimer les liens fonctionnels, - contracter deux ou plusieurs entités, - éclater une entité en deux ou plusieurs, - etc....

Tout ce qui porte uniquement sur la structure peut être défini une fols pour toutes. La partie structurelle des entités dans la structure peut donc être manipulée quelque soit le contexte.

I a transformation structurelle de la partie de l'entité contenant des caractéristiques sémantiques dépend évidement de cette sémantique et varie donc selon la nature des Informations contenues.

Pour pouvoir effectuer les opérations structurelles sur cette partie sémantique, il faut définir le comportement structurel de ces caractéristiques.

Cela veut dire que lors de la définition de types (ou de modèles) de propriétés, on définit non seulement les types et les types de valeurs mais aussi l’ensemble d’opérations que l’on peut effectuer sur la propriété. De cette façon nous retrouvons la définition complète de type abstrait.

L’extensibilité, l'évolutivité et la cohérence sont ainsi proprement prises en compte et gérées.

IV.2.C Modèle conceptuel MARS

l.e modèle que nous avons présenté a été mis en oeuvre dans le prototype du système MARS que nous avons élaboré. Il assure l’évolution de l’ensemble des Informations (extension des données manipulées, du traitement, du processus de conception), tout en gardant la maîtrise de l'Intégrité du système.

Pour cela au lieu de p a rtir de la structure globale, nous avons Identifié l'ensemble des notions de base et des règles d’organisation.

Nous avons associé à chaque élément de base, l'ensemble d'opérations que l'on peut lui faire subir. De cette façon on assure la cohérence locale de chaque élément, l a cohérence globale est exprimée à l’aide des relations d'intégrité (Correspondance, Dépendance et Transformation).

l.e choix d'une structure Interprétative permet de manipuler des informations Incomplètes et de prendre en compte au fur et à mesure des compléments d'information.

Ces Informations peuvent être construites soit à p artir des types d'informations prédéfinis dans la phase de création du modèle conceptuel concret, soit directement à l’utilisation.

ELEMENTS DE BASE ENTITES

RELATIONS - STRUCTURELLES (HIERARCHIQUES) - FONCTIONNELLES (HORIZONTALES) PROPRIETES -DES ENTITES

-DE RELATION

STRUCTURE - MULTI-HIERARCHIE DES ENTITES

COHERENCE

- ACCESSIBILITE CONCEPTUELLE - ACCESSIBILITE ORGANISATIONNELLE OPERATIONS SEMANTIQUEMENT COHERENTES:

- SUR LA STRUCTURE - SUR LES PROPRIETES EXTENSIBILIT E ET EVOLUTIVITE

TYPE DE PROPRIETE TYPE DE RELATION TYPE D’ENTITE

TYPE DE BASE: EXTENSION PAR ADJONCTION

TYPE CONSTRUITS: EXTENSION PAR COMPOSITION DE TYPES (DE BASE OU CONSTRUITS)

NIVEAUX DISTANCIATION: - ENTITE GENERIQUE

• ENTITE TYPE NON VALUEE

- ENTITE TYPE PARTIELLEMENT VALUEE

- ENTITE COMPLETEMENT VALUEE ( OCCURRENCE) FIGURE IV -16: ELEMENTS FONDAMENTAUX DU MODELE

V. APPLICATION A LA PROGRAMMATION ARCHITECTURALE

Dans ce chapitre nous montrons un exemple de coopération entre les différents Systèmes Experts au sein du Système Multl-Experts de Programmation Architecturale.

L’exemple choisi concerne les possslbllltés d’implantation d'un batiment sur un terrain donné.

Nous examinerons les données connues au préalable (base de fa its) et les règles qui pourront être appliquées (base de connaissances), en distinguant par chapitres, des aspects différents qui pourraient donner lieu â l'utilisation de divers Systèmes (Experts ou simplement Algorithmiques).

Un des aspects fondamental de cette démarche, est qu’après toutes les manipulations, tous les traitements d’informations, 11 n’y aura pas de déchets d’informations, pas de données qui aura été oubliée.

En e ffet tout élément de la base de fa its sera soit utilisé, soit fera partie d’un ensemble de données non utilisées, mais dans tous les cas, le statut de cette information sera clairement connu de l’utilisateur.

BASE DE FAITS RE6LES

REGLEMENTATION - localisation du terrain - Implantation - matériaux souhaités - prospects - alignements - hauteur absolue -C.O.S, C.E.S,