Objectifs de Motor-2

Un simulateur «idéal»

Compte tenu des problèmes mentionnés dans le chapitre précédent, on peut tenter d’imaginer un environnement de simulation idéal. Cet environnement devrait soutenir toutes les phases d’une étude de système comme nous les avons présentées. L’objectif d’un outil logiciel est d’alléger et rendre plus efficace le travail d’un ingénieur de simulation. Ce programme doit couvrir les deux phases principales, la modélisation et la simulation. Pour la phase de modélisation, l’environnement doit permettre de développer de nouveaux modèles et de gérer les modèles existants. Les modèles existants peuvent aider à la création de nouveaux modèles de deux manières. D’une part, ils peuvent servir comme patron pour le développement de modèles entièrement neufs. D’autre part, ils peuvent être des points de départ pour les modèles qui ne se distinguent que peu et qui sont dérivés des modèles existants. Sans trop restreindre la liberté de formuler l’algorithme pour le nouveau modèle, l’environnement peut proposer un cadre pour la représentation des modèles. Nous avions déjà mentionné les PROFORMAS qui poursuivent cet objectif. Des outils logiciels vérifient l’adhésion au cadre prescrit et la cohérence interne d’un modèle. À titre d’exemple, ils peuvent tester les unités des variables utilisées dans les équations (voir [7, chap. 2.7]). Quant à la deuxième phase, la simulation, c’est une application classique de l’ordinateur. Comme nous l’avons vu au chapitre précédent, il y a déjà beaucoup de logiciels qui traitent cette phase. Un bon environnement de simulation peut guider l’utilisateur dans son choix de modèles pour le problème donné. La description du système étudié doit être à la fois facile, pour garder une bonne vue d’ensemble, et souple, pour pouvoir facilement modifier une configuration en vue de comparaisons. Un mécanisme de contrôle peut vérifier les connexions entre les modules, la cohérence des modèles appliqués et la cohérence entre les modèles et les connexions. Pour la résolution numérique du système, on peut imaginer un logiciel qui prépare les modules et leurs connexions d’un manière à rendre les calculs qui Objectifs de Motor-2 36 Objectifs de Motor-2 suivent les plus efficaces possible. Ces calculs sont effectués pour résoudre le système. L’environnement doit donc proposer un algorithme de résolution qui soit rapide et adapté aux types de modèles. Beaucoup de difficultés numériques peuvent se présenter pendant la résolution. Un environnement idéal doit les reconnaître et aider à les surmonter. Le temps d’exécution d’une simulation reste toujours un problème ouvert. Un utilisateur veut toujours ses résultats le plus vite possible. Le programme idéal de simulation est portable sur différents types de machines et il est rapide. Aujourd’hui, les interfaces graphiques sont devenues indispensables. À toute phase d’interaction de l’utilisateur avec l’environnement logiciel, il faut une interface facilement compréhensible, que l’on peut piloter par des actions simples comme « cliquer» avec le bouton d’une «souris». Ceci concerne aussi bien le développement de nouveaux modèles, la saisie de la structure du système étudié et des paramètres des modules utilisés que le traitement des résultats comme la présentation des graphes et des courbes. Il y a quelques années, le projet SYMBOL a été formalisé et mis en chantier dans le groupe GISE. Parmi quelques autres objectifs, on y trouve aussi le développement d’un environnement de simulation destiné aux problèmes thermiques de bâtiment.

Cadre : le projet SYMBOL

Présentation générale

Les principales applications du projet SYMBOL concernent les systèmes complexes de grande taille, comme les bâtiments. Les objectifs de ces travaux sont premièrement l’amélioration de la connaissance des systèmes thermiques par la modélisation et l’analyse, et deuxièmement l’offre d’un ensemble modulaire et cohérent d’outils logiciels. SYMBOL est un acronyme qui signifie Synthèse Modale et Boîte à Outils Logiciels et évoque les deux axes principaux du projet. L »analyse et la synthèse modale reposent sur le fait qu’un système thermique linéaire peut être représenté avec précision par un modèle modal d’ordre faible. On peut obtenir un tel modèle par diagonalisation et réduction d’un modèle numérique discret détaillé, par réduction directe d’un modèle analytique ou par des méthodes heuristiques ([7, chap. 4], [62]). Si le couplage entre des sous systèmes est linéaire aussi, la synthèse modale permet de trouver directement le modèle modal de l’ensemble en fonction des modèles réduits des sous-systèmes (voir [36]). Le deuxième axe du projet SYMBOL concerne la «Boîte à Outils Logiciels». L’apparition des nouveaux concepts logiciels et outils de programmation ont initié cette nouvelle approche de la modélisation dans le projet. Un des objectifs du projet SYMBOL est de mettre à dispositions des ingénieurs thermiciens ces nouveaux moyens. On se place à leur niveau pour la présentation des outils logiciels 3.2 Cadre : le projet SYMBOL 37 comme des codes de calcul et des logiciels qui seront développés dans ce cadre. Ces outils doivent se présenter au thermicien d’une façon naturelle et conforme à son environnement habituel. Leur intérêt est d’alléger la tâche de l’ingénieur en évitant les nécessités habituelles d’un travail sur ordinateur. On veut lui épargner les questions qui se posent normalement au physicien théorique, à l’informaticien, au mathématicien ou au numéricien. C’est la capitalisation des connaissances sous forme de programmes et données informatiques. Ces objectifs généraux du deuxième axe du projets SYMBOL sont abordés à l’aide des idées de la modularité et de la visibilité. Modularité et visibilité sont appliquées à travers toutes les phases d’une étude systémique mentionnées précédemment (§ 2.1.4). Modularité Parmi les conclusions que l’on peut tirer du chapitre précédent, on voit qu’il est souhaitable de pouvoir connecter facilement des morceaux de programmes afin d’en créer de nouveaux. Ces morceaux peuvent provenir de sources différentes, et peuvent être partagés entre plusieurs études. Des conventions relatives à la forme des programmes développés dans le projet SYMBOL ont conduit à une architecture informatique modulaire dans laquelle on peut connecter et substituer des modules écrits pour des applications a priori différentes (voir plus loin § 3.2.2). On trouve dans l’environnement SYMBOL d’une part des modules plus ou moins généraux comme par exemples les descriptions de composants d’un système qui sont dans un format précis. Ces descriptions ne sont pas spécifiques à une application particulière. Elles peuvent éventuellement être réemployés pour d’autres applications. D’autre part, il existe dans SYMBOL des modules qui sont spécifiques à certaines tâches, c’est à dire, adaptés à un contexte particulier. Les fichiers décrivant les modes de simulation pour le logiciel Motor-2 en sont un exemple. Cette modularité encourage fortement une réutilisation des morceaux existants. Cette utilisation fréquente des modules induit des modules plus sûrs, mieux conçus, mieux documentés et surtout validés grâce à un plus important effort initial et continu globalement sensible.1 Visibilité limitée Parmi les objectifs du projet SYMBOL se trouve avant tout la mise à disposition des résultats de recherche appliquée au monde des ingénieurs thermiciens. Pour diffuser les méthodes et algorithmes développés par les chercheurs, il faut souvent les réécrire et les remettre en forme. Au cours des travaux de recherche ceci a souvent déjà été fait, au moins en partie. Notre object est de réutiliser 1. Il faut remarquer que l’amélioration des modèles ne peut pas être garantie par une utilisation plus fréquente. Certaines modifications qui sont une «amélioration» pour un modèle donné, peuvent poser des problèmes dans un autre contexte. La validation et l’amélioration dépendent fortement de l’environnement d’usage. 38 Objectifs de Motor-2 directement ces résultats déjà existants. La séparation des rôles d’un utilisateur et d’un développeur de méthodes dans la conception du projet SYMBOL et Motor-2 a pour but de découpler les démarches et de faciliter la transmission de connaissances. Un des moyens pour l’atteindre est la notion de visibilité. Il existe des règles pour spécifier quelle est la part d’un module qui peut être vue par les autres. C’est une sorte d’interface qui définit d’une manière abstraite le comportement du module, une spécification de ce qu ‘il fait. Seule cette partie est accessible par le reste de l’environnement. L’implémentation de ces spécifications, comment il fait, est totalement cachée. Des modifications éventuelles dans cette partie n’ont pas de conséquences (directes) sur le continu des autres modules. Cette séparation entre spécifications et implémentations traduit une visibilité limitée sur les modules. Elle augmente la modularité et permet des échanges de modules sans difficulté. Elle facilite en même temps la maintenance et le développement de modules, et de cette manière la diffusion de ces derniers. Le concept de visibilité limitée est aussi utilisé dans la nouvelle approche de programmation orientée-objet que nous allons traiter plus loin (voir § 4.3). L’idée de séparation entre différentes couches descriptives sera reprise et élargie dans la présentation des niveaux d’abstraction (§ 4.1), mais d’abord nous allons regarder l’architecture globale du projet SYMBOL et ce qui concerne la «Boîte à Outils Logiciels».

Structure de l’environnement SYMBOL

L’environnement SYMBOL comprend aujourd’hui plusieurs modules logiciels autonomes. La communication entre les programmes passe en général par des fichiers et est assurée par une syntaxe spéciale basée sur les idées de modularité et visibilité2 . Si on regarde la figure 3.1, on peut constater que tous les programmes s’organisent autour de bibliothèques. Ceci souligne le rôle important que jouent ces bibliothèques dans le projet SYMBOL. La gestion d’un ensemble de modèles (mais éventuellement aussi de module) passe par une « modélothèque», une sorte de bibliothèque de modèles. Ici on stocke les informations relatives aux modèles. Plus particulièrement on spécifie la partie visible d’un modèle, son interface. Différentes implémentations pour une même spécification peuvent être disponibles. Comme dans un jeu de construction on peut choisir les briques pour les connecter et pour construire une représentation du système étudié. Néanmoins on retrouve dans la conception du projet SYMBOL et dans son architecture (fig. 3.1) un chemin principal qui part d’une description de système, passe par un logiciel d’analyse ou de simulation pour finalement obtenir des résultats. Regardons cette figure plus en détail.