Processus de réalisation de systèmes TR2E

Processus de réalisation de systèmes TR2E

La figure 3.1 détaille le processus classique de réalisation d’un système TR2E selon une approche basée sur l’IDM. Le point d’entrée est la spécification de l’architecture des composants de l’application à l’aide d’un formalisme de description. A partir de cette spécification initiale, un ou plusieurs modèles d’analyse sont élaborés à des niveaux d’abstraction différents pour assurer l’analyse d’un aspect du système (comportement, ordonnancement, flots de données, etc). Les différents résultats produits lors de ces analyses permettent alors de conclure sur la faisabilité du système avant son implantation et valident les spécifications faites en amont du cycle de développement. Après cette étape de validation, certaines informations architecturales sont extraites pour l’élaboration de modèles de code autorisant le pilotage des différentes étapes de sélection, de configuration et de déploiement des composants nécessaires pour la production d’une partie ou de l’ensemble du code de l’application dans un langage de programmation cible (Ada, C, etc). Cette dernière étape procède aussi à l’intégration des composants intergiciels requis par l’application et des composants applicatifs spécifiés par l’utilisateur.

Limite 1 : Cohérence des différents modèles

Modèles d’analyse et modèles de code

L’analyse du processus de réalisation de systèmes critiques présenté dans la section précédente (figure 3.1) illustre l’utilisation de transformation de modèles à différents niveaux. Une première transformation exogène est réalisée pour l’élaboration des modèles d’analyse nécessitant parfois un haut niveau d’abstraction afin de limiter la complexité des techniques et outils d’analyse (exemple des méthodes formelles section 2.2.2). Une deuxième transformation exogène ou endogène verticale génère un modèle de code avec un faible niveau d’abstraction autorisant la spécification d’informations relatives à la plate-forme d’exécution et assurant la sélection, la configuration et le déploiement des composants logiciels. Une dernière transformation exogène verticale assure la traduction d’une partie des composants vers les artefacts d’un langage de programmation. Si ces transformations ont en commun le même modèle source, elles sont d’autant plus complexes qu’elles impliquent des formalismes différents et émettent des hypothèses sur les propriétés des systèmes. Ainsi, chaque transformation peut être réalisée selon des hypothèses différentes, ceci complexifiant la cohérence entre modèles d’analyse et modèles de code mais aussi la mise en œuvre de techniques de traçabilité. Modèles et implantation Les processus de conception, étudiés lors de notre état de l’art (section 2.4), proposent une phase de génération de code pilotée par l’analyse de la description architecturale du système critique. Lors de cette phase, de nombreuses constructions sont ajoutées pour le support et l’exécution des composants applicatifs du système. Ces éléments ont un impact non négligeable sur la gestion des ressources et sur le comportement du système. S’ils sont pris en compte lors de différentes analyses du code de l’application (analyses à la compilation ou à l’exécution, tests, etc.), ce n’est pas le cas lors des analyses effectuées sur les modèles, en amont du cycle de développement, relatives à la validation des spécifications. Ceci révèle ce que nous qualifions par manque de cohérence entre le système modélisé et validé et son implantation – i.e. le code généré. La non prise en compte de ces constructions au sein des modèles d’analyse s’explique par leur étroite dépendance vis-à-vis des choix d’implantation portant sur la plate-forme d’exécution, les mécanismes de communication et le langage de programmation. En effet, l’intégration de ces composants dès les premières phases d’analyse nécessite l’élaboration de descriptions architecturales et comportementales des composants du système avec un faible niveau d’abstraction (niveau de détail élevé). Ceci pourrait rendre l’extraction des informations pertinentes par les outils d’analyse plus difficile et à terme de complexifier ces analyses. Enfin, les formalismes de description architecturale utilisés pour la génération de code ne permettent de spécifier explicitement qu’une partie de ces informations et ne tiennent pas compte du comportement de l’application. Proposition Les éléments que nous venons de présenter plus haut illustrent la difficulté actuelle d’assurer la cohérence entre les différents modèles et l’implantation du système. Nous observons que le formalisme de description utilisé et le processus de conception proposé sont limités voir inadaptés aux contraintes des systèmes TR2E critiques. La solution que nous proposons vise à fournir un unique modèle de code analysable. Ce modèle est réalisable à l’aide du langage AADLv2 et de ses récentes avancées. Pour cela, nous identifions ces constructions additionnelles et nous les intégrons, par transformation de modèles verticale (avec préservation de la sémantique), aux descriptions architecturale et comportementale tout en assurant l’analysabilité du système et le respect des spécifications initiales. La mise en évidence explicite de ces composants et de leur comportement nous permettrait alors de diminuer les différences sémantiques entre modèles et code généré et, par conséquent, de renforcer la cohérence entre les résultats des analyses sur modèles et les vérifications effectuées sur le code généré. La préservation de l’analysabilité du système est notamment assurée via la définition de contraintes de modélisation (patrons de modélisation, restrictions des composants architecturaux, etc.) conformes aux recommandations du profil architectural Ravenscar et aux restrictions classiques sur les systèmes critiques (présentées section 2.3.2). Ces restrictions font l’objet de la définition du langage intermédiaire AADL-HI Ravenscar (un sous-ensemble d’AADL et de son annexe comportementale) présenté dans la section 3.4.2 de ce chapitre et détaillé dans le chapitre

Limite 2 : Prise en compte des aspects comportementaux

Limitations des ADLs et des DSMLs usuels Lors de l’étude des processus d’analyse et d’implantation de systèmes critiques (section 2.4), nous avons présenté le rôle et l’utilisation de spécifications comportementales pour valider le comportement attendu du système. Les formalismes de descriptions architecturales ne permettent pas d’expliciter concrètement le comportement d’un composant et son analyse (par exemple, le comportement est implanté dans un formalisme externe et est attaché au composant à l’aide d’un mécanisme de type boite noire). Ainsi, nous devons recourir à l’utilisation d’un formalisme tiers (basé sur les automates, les graphes, les flots, etc) pour expliciter et analyser les différents aspects comportementaux. Dans un processus de réalisation automatisé, les langages de description d’architecture actuels ne sont pas conçus pour expliciter ces aspects et imposent alors à l’utilisateur d’établir des règles de transformation complexes et d’effectuer des hypothèses fortes sur l’architecture pour traduire le comportement d’un composant. Ceci introduit de nouveaux facteurs limitants comme la difficulté de représentation et l’assurance de la cohérence entre la description architecturale et la spécification comportementale du système. Ces derniers points empêchent notamment la réutilisation de ces spécifications comportementales pour la phase de génération de code. Proposition L’utilisation des descriptions comportementales et leur mise en relation avec les composants architecturaux pour les étapes d’analyse et de génération de code renforceraient la cohérence entre modèles et implantations. Notre solution vise à fournir des descriptions comportementales explicites et incluses au sein même de la description architecturale. Le langage AADL et son annexe comportementale autorisent la spécification explicite du comportement des composants (matériel ou logiciel) sous la forme d’automates attachés aux composants architecturaux. De plus, les actions spécifiées au sein d’un automate se refèrent directement à ces composants architecturaux. Cette combinaison renforce la cohérence entre les représentations architecturales et comportementales mais aussi simplifie la traduction des spécifications comportementales vers un formalisme dédié à l’analyse comportementale. Notre implication au sein du comité de rédaction AADL nous a permis d’introduire certaines constructions dans le langage d’action de ces automates facilitant la manipulation d’éléments architecturaux tels les données et les sous-programmes. Ces constructions proches de celles d’un langage de programmation impératif simplifient le processus de génération code en autorisant dans la plupart des cas un mapping simple (voir sémantiquement équivalent) des éléments architecturaux modélisés vers les artefacts du langage de programmation cible. Nous présentons, dans le chapitre 4, l’ensemble de ces contributions.