Le cadriciel est détaillé dans ce chapitre, décomposé en deux parties, la première présente le processus de son développement et la seconde son architecture.
3.1 Développement du cadriciel
La conception d’un cadriciel n’est pas chose facile lorsqu’on veut offrir la généricité à partir de spécifications faites par l’homme. Il est en effet fréquent qu’une architecture et son logiciel dérivé posent des problèmes pendant la phase de test ou lorsqu’ils sont exploités par un l’utilisateur final. Pour éviter de tomber dans ces travers nous avons adopter un cycle de développement différent en associant deux ressources disponibles : la communauté scientifique et la communauté du logiciel libre.
Pour cela, nous avons produit une implémentation du cadriciel dès les premiers instants de son développement. L’environnement de modélisation ainsi créé, JDEVS (Java Discrete EVent Simulator), est présenté dans le chapitre 5 de ce document.
Le cadriciel a ensuite été exposé à la communauté scientifique, par des publications, [Filippi et al., 2002b], [Filippi et al., 2002a] et [Filippi et Bisambiglia, 2003] puis experimenté dans le cadre de contrats de recherches où se sont exprimés les besoins de spécialistes dans des domaines divers, allant de l’écologie à l’énergétique. Les retours d’informations ont permis de mieux définir les rôles de chacun dans le cadriciel ainsi que de nouveaux modes d’interactions ; plus précisément, le travail dans le cadre de contrats de recherches nous a amené à intégrer plu-sieurs techniques au cadriciel pour répondre à des besoins spécifiques en modélisation. A chaque problème spécifique nous avons apporté une réponse générique en développant des composants spécifiques et en redéfinissant l’architecture générale du logiciel pour qu’il permettre l’intégra-tion de ses composants par héritage. Ces passages successifs du développement spécifique vers le générique nous ont permis d’assurer une architecture modulaire mais maintenant figée à l’environ-nement.
La seconde ressource utilisée pour contribuer aux spécifications du cadriciel est la commu-nauté du logiciel libre. Pour y accéder nous avons publié le logiciel sur un site de travail partagé,
CHAPITRE 3 3.1. DÉVELOPPEMENT DU CADRICIEL
JEOS
Constructeur d’Application
Construit l’environnement
Modélisateur
Construit les modèles
Utilisateur Final
Utilise les modèles
Usage scientifique, validation de théorie.
Usage politique, étude d’impact et prise de décision Définit l’architecture logicielle
Intègre les techniques de modélisation
Définit le cadre expérimental Spécifie les composants de modélisation
Bibliothécaire
Stocke les modèles validés
Spécialiste
Valide les modèles
Choisis la technique de modélisation
Collecte les données d’initialisation
Collecte les données réelles Définit le protocole expérimental
Compare avec les données réelles
Décompose le modèle en parties indivisibles Renseigne les metadonnées
Classe les modèles Assure la maintenance du logiciel
<<extend>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<extend>> <<include>> <<include>> <<include>> <<extend>>
CHAPITRE 3 3.1. DÉVELOPPEMENT DU CADRICIEL Freshmeat[Filippi, 2003] dès qu’une version stable fut disponible. Nous avons pu ainsi inventorier et sérier les problèmes et conseils évoqués par utilisateurs. Ces retours continuels d’informations et la relative hétérogénéité des problèmes à traiter, ont permis d’optimiser la spécification du ca-driciel. L’étude des cas d’utilisation redéfinis tout au long du processus de spécification a permis son organisation sous forme de packages. La notation UML [Muller et Gaertner, 1970] est utilisée dans la suite de ce document pour illustrer les différentes parties de notre approche.
La figure 3.1 présente le diagramme final des cas d’utilisation. Nous avons cinq acteurs : – Le constructeur d’application : il assure la construction du logiciel, son support et de sa mise
à jour. Il est aussi chargé d’offrir une réponse logicielle aux besoins d’ajout de techniques de modélisation dans l’environnement.
– Le bibliothécaire : il doit assurer l’entretien de la bibliothèque de modèles c’est-à-dire leur indexation en renseignant des méta-données facilitant leur recherche et enfin leur classement dans une architecture de bibliothèque hiérarchique telle que définie dans [Bernardi et Santucci, 2002].
– Le spécialiste du domaine d’application : il est chargé de fournir les spécifications du mo-dèle à construire, de mettre en place le protocole expérimental permettant de récolter les données réelles et les données d’initialisation. Lorsque cette tâche est partagée, le spécialiste travaille en étroite collaboration avec le modélisateur pour l’implémentation et la validation des modèles.
– Le modélisateur : il est chargé d’implémenter le modèle ; à ce titre il a besoin de connaître parfaitement l’environnement et d’avoir des connaissances basiques en informatique. Il est aussi chargé de choisir la technique de modélisation la plus appropriée et de formater les résultats pour permettre à l’utilisateur final de les analyser.
– L’utilisateur final : il utilise les modèles validés, formate les données d’initialisation et ana-lyse les résultats. Nous avons déterminé deux cas principaux d’utilisation pouvant nécessiter deux types de cadres expérimentaux différents :
– l’étude de théories nouvelles pour observer virtuellement des systèmes ne pouvant pas être directement étudiés en conditions réelles.