Modules et Raccordement : les deux entités majeures de Motor-2

La notion de module

Nous rappelons brièvement notre terminologie en ce qui concerne la description d’un système. Un module est une unité « facilement identifiable »1 à l’intérieur d’un ensemble; plus particulièrement, un module est un composant de notre système. La combinaison ou juxtaposition ou mieux le raccordement des modules permet la construction d’un système composé. À chaque étape du découpage d’un système (voir 4.2), nous appelons les composants obtenus des modules. Cela crée deux types de modules. Nous distinguons des modules élémentaires qui sont les modules terminaux du découpage (les feuilles) et des modules composés qui sont des modules de raccordement (les ramifications). Un module composé est un ensemble de plusieurs sous-modules et de liens de raccordement qui gèrent les informations sur la connexion. 1. par facilement identifiable nous indiquons que l’unité peut être facilement repérée et délimitée dans son environnement. Cette identification n’est pas toujours «facile», et n’est pas une démarche absolue. Modules et Raccordement : les deux entités majeures de Motor-2 64 Modules et Raccordement : les deux entités majeures de Motor-2 Si nous revenons aux deux phases d’une étude de système qui sont la modélisation et la simulation, nous employons le terme modèle dans la première phase (construction de modèles) et le terme module dans la deuxième phase (un système est composé de plusieurs modules). Lors de la description de notre système réel, nous associons à chaque module un certain type, un modèle de représentation. Ceci s’applique surtout pour les modules élémentaires. On dit par exemple que le module du MUR NORD est représenté par un modèle de DIFFÉRENCES FINIES lD. Pour les modules composés qui sont situés aux niveaux supérieurs de l’arbre de découpage, nous disons tout simplement que le module est du type COMPOSÉ. Nous avons appliqué aux modules les règles qui traduisent une visibilité limitée. Les deux points de vue d’un objet (voir 4.3) s’appliquent également au module. La vue extérieure spécifie la partie visible d’un module, la vue intérieure contient son implémentation. C’est la vue intérieure qui établie le lien entre un module et son type, le modèle associé. Il doit y avoir aussi cohérence entre les spécifications, la partie visible, d’un module et les entrées/sorties des spécifications du modèle associé. C’est à dire, que l’on ne peut pas associer un modèle qui nécessite trois entrées à un module qui n’a que deux entrées, par exemple. 5.1.1 Vue extérieure Comme les modules doivent échanger des informations, on est alors conduit à définir des frontières de communication. Dans le cas d’un mur par exemple on peut définir les faces gauche et droite comme frontières ; le champ de température à l’intérieur du mur n’est pas vu de l’extérieur. Toute communication avec le module MUR passe par ces frontières GAUCHE et DROITE. Son état interne n’est pas directement visible. En général, une frontière regroupe plusieurs variables ou ce que nous appelons des pattes (pins). Ces pattes sont orientées, c’est à dire que les variables sont désignées comme variables d’entrée ou de sortie pour le module. Dans une représentation graphique, nous utilisons des ellipses qui signifient des frontières pour en souligner la nature composée. De plus, nous associons un type à chaque frontière. La face gauche du mur comprend une température et un flux de chaleur. Cette frontière peut être du type DIRICHLET, par exemple. Le type d’une frontière nous donne la possibilité de vérifier la description des connexions. Nous pouvons par exemple refuser le raccordement d’une frontière de type DIRICHLET avec une frontière du type CONVECTION VERTICALE. L’avantage de la notion d’une frontière est de pouvoir remonter à un niveau plus abstrait pour définir complètement la partie visible d’un module. Nous pouvons ainsi rester aux niveaux technique / physique dans la phase descriptive du système, car le raccordement entre modules peut s’exprimer maintenant en termes techniques, plutôt que par une expression mathématique. On dit que la face extérieure du béton est en contact parfait avec la face intérieure de l’isolant. L’interprétation mathématique et algorithmique de cette phrase est connue dans l’environnement Motor-2 pour la simulation. 5.1 La notion de module 65 liste de frontières GAUCHE actions, capacités m i t Put_ Get_ Time DROITE J^> Frontier(Msg) Frontier(Msg) _Step(T) Terminate Ü FlG. 5.1 – Les parties visibles d’un module: les frontières (en haut) spécifient les variables de communication, et les actions (en bas) que le module peut effectuer. Dans le cadre de la simulation par Motor-2, les spécifications d’un module sont plus étendues. En utilisant la correspondance entre un composant du système et une file d’exécution séparée (tâche), nous ajoutons une qualité supplémentaire au module. Parfois on emploie le terme acteur pour désigner cette entité, parce que l’objet créé est une unité de calcul active, une sorte de programme indépendant. Nous avons donc dans la vue extérieure non seulement une partie statique des données (les frontières), mais aussi une partie dynamique. Il faut donc définir les actions qu’un module peut exécuter. Tout type de module est dérivé d’un type de base abstrait (Any.Module), qui définit les actions nécessaires qu’un module doit être capable d’effectuer. Celle-ci sont par exemple l’initialisation et la terminaison de l’objet. Mais le développeur d’un modèle peut ajouter d’autres actions. Une extension à spécifier séparément est éventuellement la capacité du module à calculer des dérivées. Un utilisateur n’a pas besoin de s’occuper des capacités des modules, puisqu’elles sont liées au modèle utilisé pour le module. C’est le développeur de modèle qui définit les capacités. Tous les modules qui sont de ce type peuvent alors les exploiter. Vu de l’extérieur, il n’y a pas de différence entre des modules composés et des modules terminaux. L’algorithme de résolution traite tous les modules de la même manière. Ceci est un principe de conception qui permet à Motor-2 de rester un environnement ouvert pour traiter des modèles a priori quelconques. La vue extérieure d’un module étant définie, nous avons le choix entre plusieurs représentations internes. Nous pouvons facilement échanger les modèles associés sans besoin de modifier l’algorithme de raccordement. De cette manière, un modèle plus détaillé peut être exploité pour une partie du système, ou bien un modèle plus simple pour des composants jugés sans importance. L’utilisateur n’est pas obligé de modifier la structure du système. La description du système reste la même. On ne change que le modèle employé par un des composants.

Vue intérieure

La partie intérieure d’un module est définie par le modèle qui est associé à celui-ci. L’environnement Motor-2 traduit les appels qui arrivent aux frontières d’un module par des appels correspondants aux fonctions définies par le modèle. Si par exemple le module MUR est de type DIFFÉRENCES FINIES ID , et reçoit des nouvelles entrées aux frontières, ces valeurs sont automatiquement attribuées aux nœuds extrêmes, et un nouvel état peut être calculé à l’intérieur. Les modules terminaux se voient attachés leurs propres méthodes locales (contenues dans le modèle). Nous ne nous en occupons pas pour l’instant. Le développement des modèles de calcul est la tâche d’un modélisateur. Ce sujet est traité plus en détail dans le chapitre 7.3.1. La résolution du système consiste à déterminer les évolutions d’état des modules terminaux ainsi que la résolution locale du couplage. C’est la résolution des raccordements entre les modules. Le raccordement est situé à l’intérieur des modules composés. La vue interne d’un module composé contient donc les vues externes des sous-modules et les contraintes de raccordement. Pour exprimer ces raccordements dans le projet SYMBOL nous utilisons la notion d’interface. Le type d’une interface décrit la nature du raccordement. Une interface du type CONTACT PARFAIT vérifie l’égalité des températures et la compatibilité des flux de chaleur. Au contraire de ce qui est en usage dans le langage courant, il faut remarquer ici que nous utilisons le terme interface pour la communication entre modules et non pour la spécification d’un module qui est une frontière. Aussi les modules composés peuvent être des sous-modules et doivent communiquer avec l’extérieur à travers des frontières. Qu’est ce qu’est une frontière 5.2 Moyens de communication des modules: frontières et pattes 67 pour un module composé? Dans un cas simple et général, on peut déclarer une frontière d’un sous-module comme équivalent à la frontière du module composé dans lequel il s’intègre (voir fig. 5.3). Nous extrayions la frontière d’un module fils, et nous la déclarons visible au niveau du père. La face intérieure du BÉTON est en même temps la face intérieure du MUR. Néanmoins il est quelque fois souhaitable de présenter plusieurs frontières internes comme une seule frontière externe. Le mur pourrait avoir deux parties, en béton en bas et en bois en haut par exemple. L’ensemble des frontières intérieures du BOIS et du BÉTON constituent maintenant la frontière INTÉRIEURE du MUR. Dans ce cas, il se pose la question pour l’utilisateur de savoir, quelles variables choisir pour la vue extérieure.