Soutenance mémoire
La notion de plateforme logicielle
L’objet de ce paragraphe est double, d’une part donner une définition de la notion de plateforme propre au contexte de notre travail et d’autre part, une fois cette définition admise, établir une trame d’analyse des plateformes logicielles. Différentes définitions de la notion de plateforme logicielle (framework) existent dans la littérature. Selon Campbell et al (1991), “a framework is an architectural design for objectoriented systems. It describes the components of the system and the way they interact”. D’après (Fayad et Schmidt, 1997), “a framework is a reusable, ‘semi-complete’ application that can be specialized to produce custom applications”. D’après (Brugali et al., 1997), “a framework is an integrated set of domain-specific software components that can be reused to create applications”. D’après (Hillyer et al., 2003), “a framework enables the assembly of simulation models from previously and independently developed models”. Enfin, d’après (Murray et al., 2004), “a framework is a reusable design that requires software components to function”. Ces définitions s’accordent sur le fait qu’une plateforme logicielle permet de réunir des éléments, qu’ils soient objets pour Campbell et Fayad, composants logiciels pour Brugali et Murray, ou programmes pour Hillyer. Cependant, elles divergent sur ce qu’est formellement une plateforme. Pour Campbell, il s’agit d’une conception architecturale (architectural design) qui supporte l’interaction d’éléments. Pour Fayad, c’est une application « générique » qui permet de produire des applications spécifiques. Pour Hillyer, il s’agit d’un support d’assemblage de programmes développés indépendamment. Pour Murray enfin, il s’agit d’une application qui nécessite l’insertion d’éléments pour fonctionner. Ces auteurs ont par conséquent un point de vue différent sur la notion de plateforme : depuis la structure d’assemblage à l’outil qui nécessite l’instanciation pour être utilisé. Bien que chaque auteur en livre une définition particulière, nous admettrons qu’une plateforme logicielle est une structure d’accueil d’éléments exogènes. Cette structure d’accueil est dotée d’un langage dévolu à l’assemblage des éléments, et dont la composition constitue un ensemble opérationnel.
R1 et S1
La mise en relation des processeurs DEVS s’effectue via un bus commun auquel tous sont connectés (Kim et Kim, 1998). Dans la mesure où le bus ne peut être utilisé que par un seul processeur à la fois, l’arbitrage des échanges est assuré par un contrôleur (Figure 07). Ce contrôleur permet également le fonctionnement en parallèle de processeurs DEVS par la diffusion simultanée d’une même information auprès de plusieurs processeurs (Quesnel et al., 2007). L’utilisation du Bus, la multivalence des processeurs DEVS et le fonctionnement de chaque processeur selon un pas de temps propre permettent de construire des enchaînements de programmes qui varient suivant l’état de sommeil de chaque processeur et les informations qui interrompent le sommeil. Par construction, DEVS permet les dix-huit formes d’interrelations de la Figure 02 (zeigler, 1972). La Figure 08 présente un enchaînement de processeurs DEVS, extrait de Quesnel et al. (2009). Dans cette figure, les processeurs sont représentés par des rectangles comportant des flèches pointant vers l’intérieur et d’autres vers l’extérieur, correspondant respectivement aux ports d’entrée et de sortie. Différentes configurations se présentent : les processeurs peuvent avoir un ou plusieurs ports d’entrée, et dans le cas où il y a plusieurs ports d’entrée, un port de sortie peut soit être commun à plusieurs ports d’entrée, soit être associé à chaque port d’entrée, auquel cas il y a autant de ports d’entrée que de ports de sortie. Les traits réunissant les ports d’entrée/sortie des processeurs correspondent aux enchaînements d’exécution des programmes. On y retrouve les formes d’interrelations que sont la relation d’ordre (image n°4, Figure 02), l’interaction (image n°7, Figure 02) et le parallélisme (image n°12, Figure02). L’exemple porte sur l’intervention de pompiers luttant contre des feux de forêt, déclenchés par un pyromane. Cet exemple est implémenté sous la forme d’un automate cellulaire. Dans ce graphe, le pyromane est représenté par le processeur ‘Agent’, et les forêts par les processeurs ‘Forest11’, ‘Forest12’, ‘Forest13’ et ‘Forest14’. Le processeur ‘Move’ gère le déplacement de ‘l’Agent’ au sein de l’automate cellulaire. Les interrelations établies entre les processeurs Forest correspondent (i) au parallélisme, puisque la sortie d’un processeur Forest est connectée à l’entrée de plusieurs autres processeurs Forest, par exemple Forest22 alimente les processeurs Forest21 et Forest12, et (ii) à l’interaction, à l’exemple du processeur Forest21 qui alimente le processeur Forest 22. La mise en place de l’interrelation, du type action, entre ‘l’Agent’ et un processeur ‘Forest’ s’effectue en fonction de la position de ‘l’Agent’ au sein de l’automate cellulaire et de la présence ou non d’un processeur ‘Forest’. Dans ce graphe, ‘l’Agent’ est connecté avec ‘Forest12’.
Les programmes agronomiques en question
Les programmes considérés dans les plateformes APES, DSSAT et SEAMLESS-IF rassemblent des équations numériques aux dérivées partielles. Le programme requiert en entrée des données de différentes natures – données observées (climat, etc.), constantes (physiques, mathématiques etc.) et paramètres – et produit des données de sortie. Ces programmes comportent deux types de paramètres : les paramètres de pilotage qui décident de l’algorithme, et les paramètres de calage qui sont insérés dans les équations numériques. Le rôle de ces derniers est d’ajuster les données de sortie produites par le programme en regard de données observées. Le programme est caractérisé au moyen de deux notions sémantiques. La première est le sens littéral du programme. Le sens littéral du programme correspond à son objet, la simulation des flux hydriques dans le sol par exemple. La seconde notion est la fonction sémantique du programme, qui correspond à la relation de transformation d’un jeu de valeurs des données d’entrée en un jeu de valeurs de données de sortie (Ward et Zedan, 2007). Il s’agit donc d’une relation logico-mathématique. A titre d’exemple, l’interception de la lumière par un couvert végétal peut être simulée en regard de diverses formes de représentations du couvert (Martin et al, 2007b ; à partir des travaux de Clouvel et al., 2008a et Dauzat et al., 2008). Ainsi, changer la valeur des paramètres de calage du programme pour un jeu de données d’entrée modifie sa fonction sémantique, et non son sens littéral. Changer la valeur des paramètres de pilotage altère la fonction sémantique mais peut aussi modifier son sens littéral. Par exemple,soit un programme de simulation d’objets situés sur une parcelle agricole et un paramètre p qui, dans le cas où il est égal à 1, force la simulation à considérer le sol et la culture, et dans le cas où il est égal à 2, à n’impliquer que le sol. Suivant la valeur de p, respectivement 1 et 2, le sens littéral du programme est « simuler une culture agricole » ou « simuler le fonctionnement du sol d’une parcelle agricole », ce qui est différent sur le plan sémantique. L’implémentation de ces programmes est assurée au moyen de deux familles de langages. La première, utilisée classiquement par les informaticiens, s’appuie sur une logique particulière (logique prédicative ou du 2ème ordre) et s’inscrit dans des paradigmes conceptuels de l’informatique (procédural vs objet, impératif vs déclaratif, etc.). La seconde famille est celle des langages dits « d’Aide à la Modélisation » (LAM), comme Stella® ou SIMILE (Muetzelfeldt et Massheder, 2003) par exemple. Les LAM sont élaborés à partir d’un langage de la première famille (surcouche), mais selon une école de pensée particulière à l’exemple de la théorie des systèmes (von Bertalanffy, 2002). Le choix du langage définit donc les limites de formulation du programme, et dans le cas des LAM, impose en sus un mode de pensée. Un terme correspond à un programme numérique aux dérivées partielles. Ce programme est caractérisé (i) par un sens littéral, c’est à dire l’objet naturel qu’il représente, et (ii) par une fonction sémantique. La fonction sémantique correspond à la relation qui transforme un jeu de données d’entrée en un jeu de données de sortie. La formulation de la fonction sémantique s’effectue au moyen d’un langage redevable d’un mode de pensée de la discipline informatique (langage et paradigmes conceptuels), voire d’une autre école de pensée (théorie des systèmes, système multiagents, etc.) dans le cas de l’utilisation d’un LAM.
Mise en place de l’interchangeabilité des composants : le cas du doublon « Soilwater » et « Soilwater2 »
La construction d’un programme avec APES s’effectue par juxtaposition de composants. L’insertion du composant ‘Soilwater2’ en 2008 a donné lieu à une nouvelle fonctionnalité offerte par APES, à savoir l’échange de composants. Dans le cas présent, l’échange concerne les composants ‘Soil_water’ et ‘Soilwater2’, dont le sens littéral est identique (la simulation de flux hydriques dans un sol), de même que le nom des variables d’entrée et de sortie, mais dont la fonction sémantique est différente. Afin de caractériser les flux, le sol est discrétisé en un nombre fini de couches. De façon à garantir l’interchangeabilité vis-à-vis des autres composants, notamment l’accès aux informations par couche de sol, c’est APES qui impose la discrétisation du sol, et donc la dimension des vecteurs de données d’entrée et de sortie. En matière de métadonnées, les données intitulées ‘teneur en eau d’une couche de sol’ et ‘teneur en eau d’une couche de sol à saturation’ sont respectivement exprimées en m3 d’eau/m3 de sol pour ‘Soil_water’ et en kg d’eau/kg de sol pour ‘Soilwater2’. De façon à garantir l’interchangeabilité, les entrées/sorties de ‘Soilwater2’ ont du être adaptées pour être connectées aux autres composants d’APES sur la base des entrées/sorties de ‘Soil_water’. Pour ce faire, des fonctions de conversion des données ont été adjointes aux entrées/sorties de ‘Soilwater2’ (voir § 4.2 pour plus de précision). Dans la mesure où les composants ‘Soil_water’ et ‘Soilwater2’ ne disposent pas d’une même fonction sémantique, l’ensemble des paramètres des composants (plante etc..) a du être recalculé afin de respecter la fonction sémantique de l’assemblage. La modification des paramètres d’un composant implique la modification de sa fonction sémantique. De ce fait, l’opération d’échange effectuée ne respecte pas la fonction sémantique propre de chaque composant.
|
Table des matières
Liste des figures
Liste des tables
Introduction
Chapitre A Les sémantiques dans les plateformes logicielles
1 La notion de plateforme logicielle
1.1 Définition
1.2 Le langage d’assemblage de programmes
1.3 Trame d’analyse
2 Les plateformes logicielles
2.1 The Modular simulation Component (MODCOM)
2.2 Virtual Laboratory Environment (VLE)
2.3 Open Modelling Interface (OpenMI)
2.4 Récapitulatif des caractéristiques des supports génériques
3 Les plateformes agronomiques
3.1 Les programmes agronomiques en question
3.2 Description des plateformes agronomiques choisies
3.2.1 Une construction ad hoc, la plateforme DSSAT
3.2.1.1 Les versions successives
3.2.1.2 DSSAT dans la trame d’analyse DRS
3.2.2 APES, instance de MODCOM
3.2.3 SEAMLESS-IF, instance d’OpenMI
3.3 Etude comparative des plateformes agronomiques
3.3.1 Architecture et sémantique
3.3.2 Impact du sens littéral des termes
3.3.3 Conclusion partielle
4 La constitution du dictionnaire
4.1 Reformatage d’un terme d’après un langage imposé
4.1.1 L’expérience APES
4.1.2 Discussion
4.2 Typage d’un terme et Pragmatique
4.2.1 Les deux formes de typages
4.2.2 Discussion
5 Conclusion de la partie A
Chapitre B Accès au sens implicite
1 Bibliographie linguistique
1.1 La question de la sémantique dans la production d’un énoncé
1.2 L’interrogation dans la production d’un énoncé
1.3 L’interrogation et la structure de réponse associée
1.3.1 Où et la Localisation
1.3.2 Pourquoi et la Raison
1.3.3 Comment et la Manière
1.3.4 Qui et l’Actant
1.3.5 Quand et la Temporalité
1.3.6 Quoi/Que et acte
2 Vers une structure de graphes
2.1 Exploitation de la littérature et formulation de graphes
2.1.1 Où et la Localisation
2.1.2 Pourquoi et la Raison
2.1.3 Comment et la Manière
2.1.4 Qui et l’Actant
2.1.5 Quand et la Temporalité
2.1.6 Quoi/que et
2.2 Structure de description et assemblage
2.2.1 L’hypothèse d’une structure commune aux groupes fonctionnels
2.2.1.1 La classe Organisation
2.2.1.2 La classe Référentiel
2.2.2.3 La classe Sémantique
2.2.2 La structure de description
2.3 Description du contexte
3 Proposition d’un modèle formel d’accès aux connaissances pragmatiques
3.1 Formalisation syntaxique d’un terme
3.2 Dictionnaires
3.3 Mise en œuvre du modèle formel
3.3.1 Les réseaux sémantiques
3.3.2 Représentation du modèle formel au moyen des graphes conceptuels
4 Discussion
Chapitre C Illustration
1 Exemple de description d’un système complexe
1.1 Description littérale du système biologique
1.2 Représentation formelle du système biologique
1.3 Vocabulaire et sens implicite
1.4 Transcription informatique
2 Discussion
Conclusion
Glossaire
Références
1 Productions de l’auteur du mémoire
1.1 Projet Européen SEAMLESS (2005-2009)
1.2 Réseau excellence Endure
1.3 Travaux en lien avec le mémoire
1.4 Autres travaux (dans revues internationales à comité de lecture)
2 Introduction
3 Chapitre A
4 Chapitre B
5 Chapitre C et Conclusion
Annexe
Télécharger le rapport complet
