La variabilité des exigences non-fonctionnelles est la principale problématique que doit traiter une démarche de génie logiciel dédié à la réalisation des systèmes TR2E. Ainsi, il
est utopique de réaliser une unique démarche qui couvre l’ensemble des exigences de ce domaine. Du système de contrôle aérien, au logiciel d’asservissement du pod de reconnais- sance installé sur un avion de chasse, en passant par la radio logicielle qui équipe les soldats en opération, il est évident que les habitudes de conception, guidées par des exigences fonc- tionnelles et non-fonctionnelles très différentes, aboutissent à des démarches très différentes de conception et de réalisation des logiciels TR2E.
Dans le domaine des systèmes TR2E, il est donc nécessaire d’adapter la démarche de
génie logiciel au domaine d’activité qui l’utilise. Plusieurs solutions ont été envisagées pour ré- pondre à ce besoin. Une première solution consiste à utiliser des composants logiciels prédéfi- nis afin d’implanter le comportement répondant aux besoins spécifiques d’un domaine [Borde
et al., 2007]. Il suffit alors de connecter ces composants prédéfinis avec le reste de l’application
pour obtenir le comportement désiré.
Une telle approche n’est pas suffisante dans le contexte des systèmes critiques. Non seulement elle masque la sémantique du composant derrière une implémentation particu- lière, ce qui rend l’analyse du comportement de l’application difficile, mais surtout, un certain nombre d’exigences doivent nécessairement être prise en charge par le générateur de code
6.2. Choix technologiques en lui même. Par exemple, en ce qui concerne les systèmes critiques, il est nécessaire de disposer de générateurs de code qui ne produisent aucune allocation dynamique de mémoire. Pour répondre à la variabilité des exigences non-fonctionnelles des systèmes TR2E, une
autre solution consiste à adapter le générateur de code lui même. L’objectif étant de faciliter cette adaptation, nous nous sommes appuyés sur trois méthodes de génie logiciel complé- mentaires : la génération de l’analyseur syntaxique, la méta-modélisation, et l’utilisation d’un intergiciel schizophrène.
Présentons les bénéfices de chacune de ces méthodes dans le but d’adapter une méthode de génie logiciel dirigée par les modèles à de nouvelles exigences non-fonctionnelles.
Génération de l’analyseur syntaxique Adapter une démarche de génie logiciel dirigée par les modèles aux variations des exigences non-fonctionnelles d’un domaine nécessite le plus souvent de modifier le format de représentation associé à cette démarche. Cela revient fi- nalement à concevoir un langage spécifique au domaine d’activité pour lequel nous devons proposer une démarche de génie logiciel. Dans ce mémoire, nous nous plaçons dans le do- maine des systèmes critiques et adaptatifs. Nous avons donc limité la sémantique d’exécution aux activités périodiques et sporadiques. Si nous nous étions placés dans un autre domaine d’activité, les activités apériodiques auraient été utiles. Plutôt que de ré-inventer un nouveau langage pour pouvoir traiter ce besoin, pourquoi ne pas étendre la spécification de COAL ? Une modification du langage est donc nécessaire pour pouvoir modéliser les entités correspondant à cette extension. L’utilisation d’une méthode de génération d’analyseur syntaxique facilite ce type d’adaptations en proposant des mécanismes d’héritage de grammaire. En outre, au delà de la génération du code de l’analyseur syntaxique, cette méthode fournit une représentation graphique des règles grammaticales, une représentation graphique de l’arbre syntaxique abs- trait des exemples de test, ainsi que la vérification de l’absence d’ambiguïtés ou de boucles infinies dans les règles spécifiées (une ambiguïté correspond au fait que deux règles gramma- ticales identiques aboutissent à deux actions différentes).
Méta-modélisation Une fois que l’analyseur syntaxique a été mis à jour pour intégrer les besoins de représentation spécifiques d’un domaine d’activité, sont mises à jour les structures de données associées au générateur de code, ainsi que les outils de transformation de mo- dèle. La méta-modélisation facilite la résolution de ce problème dans la mesure où elle permet (i) de partager une représentation graphique de la structure de données de chaque modèle (AST et/ou modèles intermédiaires) ; (ii) de générer le code des interfaces associées à cette structure de données ; et (iii) de générer des outils de représentation des données associées à une instance du méta-modèle. Ainsi, si on dispose de trois méta-modèles, par exempleMa, Mb etMc, il est alors possible de réaliser et de tester les transformateurs deMa versMb et
deMbversMcen parallèle puisqu’on peut instancier indépendamment les structures de don-
nées associées à chacun des méta-modèlesMaetMb. Ceci facilite largement le prototypage
d’un outil. De plus, un méta-modèle donné peut référencer un autre méta-modèle. Ainsi, pour ajouter la méta-donné correspondant à une tâche sporadique, il suffit de référencer le méta- modèle de COAL et d’ajouter la méta-classe correspondant à la tâche apériodique pour définir l’AST du nouveau langage.
Intergiciel schizophrène Outre la nécessité d’adapter les générateurs de code, un besoin important lors de l’adaptation d’une méthode de génie logiciel dédié au systèmes TR2E
consiste à utiliser un intergiciel capable de prendre en compte la variabilité des exigences de ces systèmes. Pour ce faire, nous avons choisi de nous appuyer sur la notion d’intergiciels schizophrènes [Pautet, 2001]. Avec ce type d’intergiciel, les services fournis sont adaptés en fonction des besoins applicatifs (personnalités applicatives) et des besoins de communication (personnalités protocolaires). Ainsi, l’utilisation d’un bus de terrain particulier consistera en l’utilisation d’une personnalité protocolaire spécifique de cet intergiciel.
Dans cette section, nous avons présenté les méthodes de génie logiciel sur lesquels nous nous sommes appuyés pour améliorer l’adaptabilité de notre prototype à différents domaines d’activité. Dans la section suivante, nous allons illustrer la mise en œuvre de cette démarche à travers la réalisation des générateurs de code du framework à composants MyCCM-HI.