Gestion des communications entre modules

Pour réaliser les requêtes entre les différents modules, il y a essentiellement trois possibilités.

les appels de fonctions se font par utilisation d’une interface de programmation ou API¹.

les appels se font à distance via un réseau

les appels sont faits soit à distance, soit localement en faisant éventuellement migrer les codes des fonctions d’un site à un autre.

La première solution offre l’avantage d’être performante car tous les appels se font en local.

Par contre cela ne permet pas de gérer les cas où l’AEM et le système de conception ne sont pas sur le même site.

1 API : Application Programming Interface

En fait une seule application est créée et les modules doivent connaître les API des autres modules :

la BAMGS appelle les fonctions de l’API du modeleur géométrique,

le module d’assemblage appelle les fonctions de l’API de la BAMGS,

l’AEM doit connaître l’API du module d’assemblage et éventuellement de la BAMGS.

Mais pour cela, il faut que les modules soient écrits dans des langages de programmation tel que l’accès aux API des autres modules soit possible et pas trop coûteuse. Par exemple l’interfaçage de C++ et Java est possible mais nécessite la conversion en profondeur de tous les objets, c’est-à-dire en tenant compte de l’imbrication des objets les uns dans les autres.

La deuxième solution permet de gérer des sites distants. Par contre, comme les appels se font systématiquement à distance lorsqu’il y a plusieurs sites, il est difficile d’assurer des performances temps réel.

Enfin la troisième solution semble la plus prometteuse puisqu’elle allie les avantages des deux solutions précédentes. Pour avoir des performances temps réel, le code de la fonction est téléchargé et exécuté en local. Pour émettre des requêtes sur un site distant, un appel de procédure distant est invoqué.

Dans tous les cas, pour remplacer tous les modules (modeleur géométrique, AEM, système de conception), par des logiciels existants, il est nécessaire d’accéder à leurs fonctionnalités via une API. De plus pour pouvoir faire des appels à distances, il faut un processus dédié à la communication dont le rôle est de scruter les requêtes qui arrivent et d’invoquer les méthodes de l’API correspondante.

Nous ne nous intéressons pas ici aux protocoles utilisés pour réaliser les appels à distance ou la migration dynamique du code. Notons cependant qu’il existe des outils pour réaliser les appels distants. Les plus connus sont Corba (Common Object Request Broker Architecture) de L’OMG ([OMG01a]), java RMI (Remote Method Invocation) de Sun, RPC (Remote Procedure Call) de Sun ([SUN03]), et DCOM (Distributed Component Object Model) de Microsoft. Mais seuls Corba et RPC sont indépendants de la plate-forme. Par ailleurs des travaux concernant la migration de code dans un environnement java sont proposés dans [DEN03] et font partie du projet DIJA.

Conclusion

Ce chapitre a recensé les défauts présents dans l’interfaçage des systèmes de conception et des AEM. Nous avons proposé une nouvelle architecture logicielle visant à réduire les interventions humaines dans les secteurs suivants : la spécification du maillage pour l’utilisation d’une AEM et la correction des erreurs présentes dans les modèles géométriques et les maillages.

L’architecture proposée tend à réduire les erreurs dans les modèles en évitant les interprétations multiples du modèle géométrique, qui sont la source de nombreuses erreurs.

Evidemment des erreurs subsistent, en particulier celles provenant d’utilisations maladroites des modeleurs et contre lesquelles, seule une bonne connaissance des représentations internes de la géométrie est efficace.

La préparation des données pour l’utilisation d’une AEM peut être en partie automatisée sous la condition que les informations fonctionnelles soient accessibles lors de la phase de construction du maillage. Nous avons vu avec le projet DIJA, que cette automatisation ne concerne pas seulement la conception routinière, mais aussi la conception innovante. En effet, la décomposition fonctionnelle par niveaux procède par traduction des termes de l’historique de construction d’un niveau, en termes du niveau inférieur (moins abstraits). L’architecture permet de manipuler des termes métiers, mais aussi des termes communs à différents métiers, et des termes désignant les entités géométriques. Ainsi l’utilisateur est réellement assisté dans sa tâche, en accord avec son niveau d’expertise dans les métiers et les connaissances déjà présentes dans le système de conception.

Cependant, l’utilisation de cette architecture avec des systèmes de conception et des AEM existants nécessite des efforts de programmation importants. Le module d’assemblage par les accès à la base de connaissance, est dépendant du système de conception et par conséquent, il faut développer un module d’assemblage pour chaque système de conception. Cependant, le développement du module d’assemblage est un travail qui peut être capitalisé puisque, par exemple, la phase dédiée purement à l’assemblage est à peu près le même pour tous les BRep.

Une interface virtuelle telle celles proposées dans [HAI98] et [TAU00], permettraient de factoriser cette partie du code. Les difficultés pour adapter le module d’assemblage d’un logiciel de conception à un autre viennent essentiellement de l’exploitation de l’information fonctionnelle, quand elle est disponible.

Un aspect nécessitant un développement important est la BAMGS. Une partie critique de cette architecture à laquelle nous nous sommes intéressés est l’intégration des algorithmes permettant de construire et modifier tous les types de maillages utilisés actuellement, au sein d’une architecture logicielle cohérente et extensible. La conception d’une telle bibliothèque nécessite une bonne connaissance des algorithmes de maillage qui ont été présentés dans le premier chapitre. Elle fait l’objet du chapitre 4.

Les opérations booléennes étant très présentes dans cette architecture, le chapitre suivant expose les problèmes algorithmiques qu’elles soulèvent

___________________________________________________________________________

Chapitre III : Approfondissement des opérateurs d’assemblage

___________________________________________________________________________