Dans la Section 2.2, nous avons donné la définition ainsi que des exemples de métho-dologies de conception de simulations. La grande majorité des auteurs sont d’accord : la conception de simulations se fait par un processus particulier, mais il n’existe pas de consen-sus autour du détail de celui-ci.
L’expression "Tronc commun" insiste sur le fait qu’il s’agit d’un ensemble de phases communes à plusieurs méthodologies. Cette trame est basée sur des travaux précédents présentés au Chapitre 2. Elle nous permettra de positionner nos contributions présentées dans la Section 6.3 suivante. Ce tronc commun comporte les cinq phases de la Figure 6.1 :
1. Une phase de modélisation initiale : Les thématiciens, aidés par les modélisateurs,
partent du système complexe réel et établissent un modèle de domaine. En général, il s’agit d’une modélisation grossière qui s’affine et gagne en pertinence au fur et à mesure. 2. Une phase de formalisation : Les modélisateurs, accompagnés des thématiciens,
agent, passant du langage non-formel à un langage formalisé "agent".
3. Une phase d’opérationnalisation : Les deux précédents groupes collaborent
mainte-nant avec des modélisateurs-informaticiens1, qui procèdent à une phase d’opération-nalisation. Elle consiste à exprimer les agents avec des propriétés en relation avec l’implémentation (sans toutefois implémenter le modèle). Il peut s’agir de propriétés techniques comme la distribution physique des agents ou de techniques d’ordonnance-ment temporel. En d’autres termes, les modélisateurs-informaticiens établissent avec les thématiciens et modélisateurs un "cahier des charges".
4. Une phase d’implémentation : Les programmeurs, à partir du "cahier des charges"
précédent, implémentent la simulation sur la plateforme choisie, avec ses concepts spécifiques et réalisent les tests de validation.
5. Une phase d’exécution : Une fois le modèle informatique implémenté, les utilisateurs
procèdent à une succession d’expériences sur la base de scénarios de simulation. Ces utilisateurs sont les thématiciens, les responsables du projet. . .
Dans cette trame, nous avons volontairement omis les cycles et retours ainsi que les étapes d’analyses. La principale raison est que, dans notre cadre de travail, nous nous intéressons particulièrement à la co-construction de modèle et à sa réutilisation. De plus, l’accompagne-ment d’experts en SOA est un point important à chaque phase. Ceux-ci aident à avancer de manière efficace et à employer un niveau de dialogue adapté à chacun et à ce que l’on veut produire pour une modélisation de SOA.
6.2.1 La collaboration entre les différents acteurs
Dans un projet de modélisation de comportement des tortues marines Chelonia mydas de la zone sud-ouest de l’Océan Indien [Gangat et al., 2010,Dalleau et al., 2012], nous avons abordé le sujet de la collaboration entre les différents acteurs participant à un projet de modé-lisation commun en partie, en structurant notre approche sur la dualité : modèle conceptuel / modèle informatique. En nous référant aux phases principales de conception de simula-tions identifiées par Ralambondrainy (voir Section 2.2.2), nous avons établi un prototype en travaillant sur deux documents en parallèle :
1. La description conceptuelle, qui énonce le modèle suivant ce que les thématiciens souhaitent exprimer.
2. La description informatique, qui spécifie le modèle tel qu’il est (ou sera) implémenté sur le prototype.
La distance entre ces deux documents est appelée distance implémentatoire. La réduction de cette distance impose des modifications sur les deux documents, donc des efforts de la
1Dans la Section 2.2.1 nous avons expliqué la différence entre modélisateurs-informaticiens et programmeurs. Le premier établit son modèle indépendamment de la manière que ce dernier sera implémenté. Le second s’appuie, lui, sur un langage de programmation ou une plateforme de simulation particulière.
PROGRAMMEURS, MODÉLISATEURS-INFORMATICIENS, MODÉLISATEURS THÉMATICIENS MODÉLISATEURS-INFORMATICIENS MODÉLISATEURS THÉMATICIENS MODÉLISATEURS THÉMATICIENS A c c o m p a g n e m e n t d 'u n e x p e rt Modèle opérationnel Modèle de conception Modèle informatique Modèle simulé Opération-nalisation Implémentation Exécution
FIGURE6.1 – Tronc commun aux méthodologies de conception de SOA
part de chacun des acteurs (pour ce projet, il s’agissait de thématiciens, de modélisateurs-informaticiens et de programmeurs). La description conceptuelle doit être réexprimée (voire simplifiée) pour être en adéquation avec les contraintes (et les limites) informatiques. La description informatique doit être améliorée pour se rapprocher au mieux des attentes des thématiciens.
Au final, plus la distance implémentatoire sera faible, plus le risque d’un manque de perti-nence du prototype le sera aussi. Dès que la minimisation de ce risque sera jugée acceptable, l’effort du passage du prototype à l’outil final sera envisagé. Cette distance ne peut être réduite que lorsque chacun des intervenants travaille en synergie avec les autres. De plus, la présence d’un expert de la SOA demeure importante pour aider à la modélisation. Ce constat reste le même à chaque niveau, car la source de cette connaissance à laquelle nous devons nous référer suit une certaine hiérarchie :
• Les thématiciens, avec les modélisateurs, créent un modèle de domaine.
• Les modélisateurs, avec les thématiciens, mettent en place le modèle de conception. • Les modélisateurs-informaticiens, travaillant surtout avec les modélisateurs et parfois
les thématiciens, établissent un modèle opérationnel.
• Les programmeurs, aidés des modélisateurs-informaticiens, et parfois des modélisa-teurs et thématiciens, implémentent un modèle informatique.
Dans cette hiérarchie, pour chaque étape, le premier intervenant cité (en gras dans la Figure 6.1) joue le rôle prépondérant ; ceux qui suivent tiennent le rôle d’accompagnateurs. Par exemple, les modélisateurs-informaticiens établissent le modèle opérationnel, mais ils ont besoin de l’aide des modélisateurs et thématiciens aussi. Ils apportent leur concours tout au long de cette adaptation progressive du modèle : la mise en place d’un modèle de niveau n implique parfois un ajustement supplémentaire par rapport au modèle précédent n ° 1. Les acteurs du degré n ° 1 doivent donc ajuster leur propre modèle et vérifier la correspondance avec ceux du degré n ° 2. Et ainsi de suite. . .
Cette collaboration essentielle permet une meilleure modélisation. En particulier, la pré-sence des experts dans le processus de modélisation-simulation est un élément-clef. Mais elle ne doit pas se limiter à la réalisation commune de quelques étapes. L’ensemble du processus de modélisation doit se faire en étroite collaboration. Suivant ce principe, la méthodologie que nous proposons permettra à tous les acteurs de travailler et de communiquer sur la base d’un cadre commun. Il est évident qu’il s’agit là d’une répartition théorique des rôles, mais souvent le même groupe de personnes représente les modélisateurs-informaticiens, les programmeurs et les experts en SOA. Cependant, il reste préférable de bien définir les rôles pour faciliter la création des différents modèles dans les contextes les plus généraux possible. Ce tronc com-mun nous permettra de mieux visualiser notre méthodologie qui facilitera l’accompagnement et la collaboration des acteurs du projet.