UN CADRE CONCEPTUEL POUR LA METAMODELISATION : L’INGENIERIE DIRIGEE PAR LES MODELES

Télécharger le fichier pdf d’un mémoire de fin d’études

Spécification par transformation de modèles de la sémantique d’un langage

La sémantique d’un langage consiste en une relationsémantique entre une syntaxe abstraite et un domaine. Dans cette section, nous présentons les deux approches possibles pour décrire la sémantique d’un langage dans le cadre conceptuel de l’IDM. La première consiste en l’implémentation d’une transformation de la syntaxe abstraite du langage (un métamodèle) vers la syntaxe abstraite d’un langage formel où la sémantique dynamique est déjàimplémentée par un outil (section3.2.1). Dans ce cas, on réutilise un formalisme. La deuxième approche consiste en une implémentation de la sémantique dynamique au niveau de la syntaxe abstraite du langage (section 3.2.2).

Homéomorphisme

SmartQVT est une implémentation de la norme QVT [142] (Query View Transformation) de l’OMG. Cette norme constitue un premier pas vers une uniformisation des approches à base de règles incluant trois langages complémentaires (comprenant des constructions déclaratives et impératives).

L’approche par homéomorphisme consiste en la spécification d’une transformation de modèles entre le métamodèle représentant le langage et un étamodèle représentany son domaine. Cette approche permet de réutiliser la sémantique d’un langage déjà existant (le domaine), ce qui correspond à la définition d’un langage donnée en section 1. Dans la littérature, ce type de transformation est parfois appelé projection, morphisme ou encore transformation homéomorphe [47, 116] . Elle est par exemple utilisé dans le cadre du projet PUML [147] visant à munir UML [50] d’une sémantique formelle définie sur le formalisme Z [128]. Il estalors possible de profiter conjointement de la syntaxe accessible de UML et des outils d’analyses formelles associés à Z. Les outils de vérification présenté en section 3.2.3 du Chapitre I implémentent aussi des homéomorphismes,réalisés de manière ad-hoc.

Les langages à base de règles sont les plus indiqués dans ce cas. Cette approche nécessite généralement la spécification d’un programme transformant une instance du métamodèle du domaine en un texte sémantiquement équivalent . Ce texte est ensuite fourni à un outil implémentant la sémantique du domaine. Ce programme n’est pas nécesaire si l’outil a été implémenté en suivant une approche dirigée par les modèles. Dans ce cas, l’outil accepte directement le modèle du domaine produit par la transformation homéomorphe. La Figure 15 schématise les deux possibilités d’implémentation d’un homéomorphisme, suivant que ’outil réutilisé est implémenté avec des technologies IDM ou non.

Sémantique opérationnelle embarquée

La deuxième approche consiste en la spécification d’une sémantique opérationnelleau niveau du métamodèle du langage. Une sémantique opérationnellest décrite par un ensemble d’opérations manipulant les concepts du métamodèle du langage. Ces opérations sont spécifiées à l’aide d’un langage d’action comme Kermeta [146]. Dans ce cas, le métamodèle du langage représente à la fois la syntaxe abstraite et le domaine sémantique du langage46 (syntaxe et domaine se confondent). Cette approche est indiquée pour décrire la sémantique und’ formalisme (comme par exemple la sémantique du formalisme IDM de la Figure 15). La suite de cette section présente brièvement Kermeta et illustre la spécification d’une sémantique opérationnelle avec ce langage. Définition – sémantique opérationnelle: sémantique dynamique exécutable, décrite par un ensemble d’opérations associées aux métaclasses du métamodèle. Tout modèle conforme à un métamodèle muni d’une sémantique opérationnelle estexécutable.

Le langage d’action Kermeta [145] est une extension d’une version simplifiée de EMOF47 . Mathématiquement, un homéomorphisme conserve la structure de l’information suivant les lois des langages vu comme des groupes (en particulier les lois de composition).

Ce type de programme est appelée « pretty printer» en compilation (fonction inverse du « parsing »).

La fonction sémantique est dans ce cas l’identité,c’est-à-dire que tout modèle est l’image de lui-même pas la fonction sémantique.

EMOF (Essential MOF) est une version simplifier de MOF.

Le langage d’action est impératif, orienté objet eta été spécialement conçu pour intégrer un process u de développement dirigé par les modèles. Il fournitles constructions classiques d’un langage de programmation orienté objet (encapsulation, héritage …) et des constructions dédiées à la manipulation de modèles (constructions « à la OCL » comme la navigation, les opérations sur les collections telles select ou collect). Le langage d’action de Kermeta est particulièrement adapté aux activités de métamodélisation comme la spécification des langages de modélisation, la simulation et prototypage de métamodèle.

La Figure 16 fournit (a) un métamodèle possible demachine à état et (b) le même métamodèle muni d’une sémantique opérationnelle de simulation (ajout d’opérations et de relations). Ces opérations sont embarquées dans les différents concepts du métamodèle (par exemplefire() dans la métaclasse TRANSITION). L’association currentState entre les concepts FSM et STATE a été ajoutée pour maintenir en mémoire l’état courant d’une machine à état en cours de simulation. La Figure 17 fournit une implémentation en Kermeta de l’opération step embarquée par le concept STATE (cf. Figure 16). La spécification informelle de cette action est donnée ci-dessous :

L’action step ne peut être appelée que sur l’état courant (voirla pré-condition).

Si un évènement entrant satisfait l’événement d’entrée d’une transition de l’état courant, alors la transition est tirée et l’état courant mis à jour (soit la redirection du lien instance de currentState vers la cible TRANSITION.target de la transition tirée).

Si plusieurs transitions sont satisfaites, la machine à état est indéterministe et une exception est levée.

Cette approche a plusieurs avantages. Tout modèle conforme au métamodèle de la Figure 16 (b) est exécutable par construction. Pour le modeleur (celui qui crée des machines à états dans l’exemple de la Figure 16), c’est un mécanisme intéressant pour la vérification des modèles, puisqu’un modèle ne se comportant pas correctement n’est pas valide structurellement (sauf erreur au niveau de la spécification de la sémantique opérationnelle). Pour le métamodeleur (celui qui conçoit la sémantique opérationnelle), l’exécutabilité facilite la validation de la sémantique opérationnelle définie au niveau du métamodèle. Cependant, il est important de noterqu’une sémantique opérationnelle n’est pas toujours facile à spécifier de cette manière. Cela dépend de ce qui est représenté par le métamodèle. Lorsque le langage représenté est un formalisme, une sémantique opérationnelle est facile à définir comme une composition des concepts de sa syntaxe abstraite. Dans le cas contraire, il est plus intéressant de définir un homéomorphisme vers un métamodèle de la syntaxe abstraite du domaine (première approche), quitte à munir celui-ci dans un deuxième temps d’une sémantique opérationnelle.

Composition de modèles

La composition de modèles [40-46, 78] est un problème général, utile à un grand nombre de domaines informatiques. C’est une étape nécessaire si l’on désire analyser automatiquement une spécification décrite à l’aide d’une collection de spécifications partielles48 . C’est en outre une technique supérieure aux approches de comparaison en ce qui concerne la détection d’incohérences

La composition de modèles revêt plusieurs appellations, suivant le domaine en question et la nature de ce qui est composé : composition de points de vue, de vues, de spécifications partielles, intégration de vues, fusion, amalgamation ou encoretissage d’aspects. Nous préférerons dans la suite l’appellation composition de modèles, cette dernière étant plus générale car ne faisantaucune hypothèse sur ce qui est composé.

La section 4.1 introduit les principes généraux d’un processusde composition de spécifications partielles hétérogènes. Elle présente un processusde composition comme une transformation de modèles et définit un cadre conceptuel IDM pour lacomposition. La section 4.2 présente les travaux clés sur la composition de modèles dans les domaines de l’ingénierie des exigences et le domaine du développement logiciel par aspect (AOSD). Ces travaux sont décrits avec la terminologie proposée en sections 1 et 2, bien que la plupart ne soient pas construits avec des technologies IDM. Cette section n’offre pas une rétrospective complète. Néanmoins,les travaux présentés couvrent un large spectre et sont représentatifs des travaux plus anciens.

Principes généraux

La composition de modèles a pour but l’obtention d’un modèle global. Ce modèle global capture une partie des informations initialement dispersées dans une collection de modèles d’entrée. Il représente la spécification opérationnelle obtenueaprès composition et sert de modèle d’entrée aux outils d’analyse une fois exempt d’incohérences statiques (cf. section 3 du Chapitre I). Un modèle d’entrée est conforme à un métamodèle d’entréereprésentant la syntaxe abstraite d’un langage d’entrée. Le modèle global est instance du métamodèle cœur représentant la syntaxe abstraite d’un formalisme 49 (langage cible du processus de composition). Le formalisme spécifie le domaine sémantique choisi pour la composition. Le RM présenté dans le Chapitre IV est un exemple de formalisme pour un processus de composition, tout comme KAOS [97], Telos [95], RML [93-94] ou encore Albert II [96].

Définition – langage d’entrée (et métamodèle d’entrée): langage dont les expressions peuvent être acceptées en entrée d’un processus de composition. C’est un langage de modélisation, défini par un métamodèle (sa syntaxe abstraite) et une fonction sémantique définie sur le formalisme. Un langage d’entrée est représenté par un métamodèle ’entréed. Un modèle d’entrée est une instance d’un métamodèle d’entrée.

La décomposition d’un problème en des problèmes plus simple à résoudre permet de mieux maîtriser sa complexité (voir la section 2.1 du Chapitre I). Cependant, les solutions à ces problèmes doivent être composées pour obtenir une solution globale au problème initial.

Le terme de formalisme souligne bien le caractère formel et outillé du langage cible défini par un métamodèle appelé métamodèle cœur (du processus de composition). Le métamodèle coeur représente la syntaxe abstraite du formalisme. Un formalisme permet la résolution d’une classe de problèmes (via un ensemble de techniques d’analyse formelle). Le choix d’un formalisme détermine cette classe de problèmes (et les techniques d’analyses pouvant être appliquées en aval du processus de composition).

Définition – modèle global : résultat d’un processus de composition, expression du formalisme et instance du métamodèle coeur.

La composition de modèle partage avec les approches de comparaisons structurelles (cf. section 3.2.2 du Chapitre I) le besoin d’identifier les superpositions sémantiquesentre modèles d’entrée. Ces superpositions reflètent des redondances dans la représentation fragmentée de l’information. Pour obtenir un modèle global, ces redondances doivent être résolues de sorte que toute information n’est représentée qu’une et une seule fois. La différencentre composition et comparaison réside dans la nécessité pour la première de résoudre les superpositions sémantiques identifiées. Nous donnons ci-dessous une définition de la notion de superposition sémantique ainsi qu’une définition de la notion de résolution d’une superposition sémantique. Définition – Superposition sémantique : Une superposition sémantique est une situation où un ensemble de fragments de modèles représentent une même information. Une superposition reflète une redondance d’information.

Définition – Résolution (d’une superposition sémantique): La résolution d’une superposition sémantique est une transformation homéomorphe de l’information visant à supprimer la redondance d’information reflètée par cette superposition. L’information après résolution est sémantiquement équivalente à l’information avant résolution ; seule la syntaxe est modifiée.

Certains travaux fournissent des mécanismes semi-automatiques pour la détection de superpositions sémantiques (par exemple Theme [44]et Kompose [78]) alors que d’autres considèrent cette activité comme entièrement manuelle (le travail de Sabetzadeh [40] par exemple). Ces mécanismes sont sujets à caution à cause des situat ions de collisions [105] (voir définition ci-dessous). Les collisions sont le résultat de divergences conceptuelles entre parties prenantes (cas des collisions structurelles), ou plus simplement de différence dans le choix des termes employés pour désigner les éléments du domaine (collisions terminoloiques et énotationnelles)d. Quoi qu’il soit, il convient de garder à l’esprit que la détection de superpositions sémantique ne peut être entièrement automatisée puisqu’une même information peut être représentée différentes manières.

Définition – Collision : Une collision est une situation responsable d’une erreur lors de la détection des superpositions sémantiques. On distingue trois types de collisions :

Collision terminologique : Situation où deux termes distincts désignent le même élément du domaine.

Collision dénotationnelle : Situation où un même terme désigne deux éléments distincts du domaine.

Collision structurelle : Situation où une même information est représentée par des fragments de modèle syntaxiquement différents. Cette notion est une généralisation de la notion de collision terminologique.

Pamela Zave et Mickael Jackson ont introduit dans [41] les principes et problèmes principaux de la composition de modèles, quels que soient les langages d’entrée utilisés (composition multi-formalisme). Zave et Jackson définissent la composition comme la conjonction logique des modèles d’entrée, préalablement traduits dans un même formalisme logique (le domaine sémantique). La traduction des modèles à composer vers le domaine sémantique est réalisée par des fonctions (appelées fonctions d’interprétations) mettant en relation la syntaxe des langages d’entrée et le domaine sémantique (ce sont donc des relations sémantiquesdans notre terminologie IDM). Zave insiste sur le fait que ces fonctions peuvent être variables dèsorsl que le langage concerné est semi-formel. En effet, celui-ci peut comporter des variations sémantiques(voir section 1 du Chapitre II fonctions sémantiques » car un langage d’entrée n’est pas nécessairement formel). Cette figure respecte la terminologie définie plus haut. On retrouve les deux manières de réaliser la sémantique d’un langage en IDM (cf. section 1.3 du Chapitre IV) : (i) à l’aide d’une transformation ho méomorphe vers un métamodèle représentant un domaine ou (ii)à l’aide d’une sémantique opérationnelle embarquée. Ce dernier cas est symbolisé par une fonction sémantique dont la source et la cible sont identiques (le formalisme est alors son propre domaine). La représentation de la sémantique des langages d’entrée est conforme au premier cas alors que celle du formalisme peut être conforme à l’un ou l’autre.

Notation – processus de composition φ : On notera φ un processus de composition. C’est une transformation acceptant en entrée un ensemble de modèles d’entrée conformes aux métamodèles d’entrée du processus et produisant en sortie le modèle global.

Approches de composition de modèles

Seuls Pamela Zave et Mickael Jackson considèr la problématique de composition de modèles dans le cas général [41], c’est-à-dire dans un cadre multi-langage. Ils discutent des principes et problèmes principaux de la composition de modèles, quels que soient les langages d’entrée utilisés (la Figure 18 de la section précédante est conforme à leur visiond’un processus de composition). Cependant, le travail de Zave et Jackson n’apporte pas de solutions concrètes à la composition de modèles. En particulier, il n’aborde pas le problème de résolution des superpositions sémantiques (suppression des redondances). Les travaux présentés dans la suite roposent des solutions de composition de modèles instances d’un même langage d’entrée.

Ainsworth propose [42] une méthode de composition de spécifications partielles exprimées en Z Cette approche est donc mono-langage et ne requiert pas de traduction préalable des modèles vers le domaine sémantique. Les relations entre les spécifications à composer sont décrites manuellement par des invariants fonctionnels et des obligations de preuves peuvent être menées à bien pour vérifier l’exactitude de la composition. Cette approche est plus une méthode qu’un mécanisme automatique de composition. L’approche consiste en trois étapes : la première vise à identifier les superpositions sémantiques et restructurer les spécifications pour faciliter la composition ; la deuxième a pour but de déceler et résoudre les collisions (cf. section Chapitre I3.1) éventuelles entre spécifications ; la dernière étape est l’étape deompositionc des spécifications. Dans [43], les auteurs décrivent une plate-forme pour produire une spécification HOL [148] (pour high order logic) à partir de modèles décrits dans différentes notations (machines à états, tables de décisions et HOL). La spécification résultante peutensuite être analysée avec des outils dédiés à HOL. La sémantique d’un langage d’entrée est définie à’aidel de fonction HOL. Il est alors possible de combiner ces fonctions pour décrire la sémantique ‘und nouveau langage d’entrée que l’on désire ajouter à la plate-forme. L’intérêt de cette approche réside en la possibilité d’ajouter de nouveaux langages d’entrée en réutilisant des parties de lasémantique des langages déjà intégrés. Cependant,esl auteurs ne précisent pas comment traduire une expression d’un langage d’entrée en une spécification HOL. Comme [42], cette approche est donc fastidieuse car demandant un traitement manuel des modèles avant composition.

Sabetzadeh et Easterbrook présentent une approche de composition basée sur le concept de co-limite de la théorie des catégories [40]. L’intérêtde cette approche est le fait qu’un modèle globalpeut être obtenu même lorsque les modèles composés sontstatiquement incohérents, ce qui est de première importance lorsque les modèles capturent des exigences. Cette approche est mono-langage et est illustrée avec le langage i* [129]. Les modèles à composer sont représentés par des graphes orientés. L’opérateur de composition (co-limite) est formellement défini et des liens de traçabilité entre les modèles d’entrée et le modèle global résultant sontautomatiquement inférés. La résolution des superpositions sémantiques est automatique mais les superpositions sémantiques doivent être identifiées manuellement par l’analyste.

On trouve dans le domaine de l’AOSD (cf. section 2.1 du Chapitre I2.1) des travaux portant sur la composition de modèles, puisque la décomposition d’une information en une collection d’aspects (pour mieux appréhender un problème) nécessite ensuite urle composition (pour résoudre le problème). Certains travaux [44-46] à la frontière entre les domaines de l’ingénierie des exigences et l’AOSD décrivent des mécanismes de composition. Dans le cas de [45-46], ces mécanismes sont largement informels, car la notion de superposition est réduite à l’égalité entre des annotations associées manuellement aux exigences dans le but de les classer plus finement que ce que permet l’approche classique par points de vue. Deux travaux issus de l’AOSD sont toutefois intéressants dans le contexte de cette section: Theme [44] et Kompose [78].

Approche proposée et réalisation concrète

Le projet de la plate-forme R2A est né dans le cadre du projet collaboratif MUTATION (pour Modélisation UML pour l’automatisation de la production de test), associant en particulier l’équipe Triskell de l’IRISA et TAS (Thalès Airborne System). Ce projet fait partie intégrante d’un projet de recherche plus large (CARROLL). L’objectif du projet MUTATION était le transfert de méthodes académiques de génération automatique de tests (voir les travaux de Clémentine Nebut [55, 152]) dans le cadre du processus de développement pour les systèmes embarqués de grande échelle de TAS. La plate-forme a ensuite été étendue pour la modélisation de services télécoms à France Télécom (voir le site de la plate-forme R2A pour plus de détails [153]) dans le but de fiabiliser les spécifications d’exigences produites, générer des tests système etextraire des ébauches de spécifications système.

Cette section présente d’abord en section 0 l’approche de développement logiciel que nous proposons. Elle vise à fiabiliser les spécifications d’exigences et plus généralement à améliorer la qualité des logiciels produits, dans un contexte où les exigences restent les seuls artefacts de développement entièrement maîtrisés par les équipesde développement FT. La section0 décrit ensuite la version actuelle de la plate-forme R2A, réalisation concrète de l’approche.

Description générale de l’approche

La Figure 1 présente une vue générale de notre approche au sein d’un processus de développement. Cette approche est généraliste et peut être appliquée dans des contextes industriels très variés. Ellest indépendante des méthodologies de classement choisies. Nous avons opté pour un classement par points de vue pour son application chez France Télécom (voir Chapitre V). Notons que la mise en place d’une autre méthodologie nécessite une modification du formalisme, puisque ce dernier capture les concepts de la méthodologie retenue (voir la vue classification du formalisme RM en Annexe E). Dans tous les cas, il existe des superpositions sémantiques implicites entre spécifications partielles. Ces liens sont détectés par le processus de composit on comme nous le verrons en Chapitre VI. L’approche est aussi indépendante du modèle de processus de développement choisi (le « cycle en V » par exemple, comme dans la Figure 1). Enfin, elle est indépendante des méthodes et techniques utilisées durant les étapes préliminaires d’analysedu domaine et d’identification des objectifs (cf. Annexe B).

L’approche est structurée autour d’un modèle globaldes exigences obtenu par composition de spécifications partielles. Les spécifications partielles produites durant les phases de développement amont représentent les exigences identifiées par les parties prenantes. Ces spécifications partiellessont spécifiées à l’aide d’un ensemble de langages appelés langages d’entrée53 . Elles représentent uniquement les informations nécessaires à l’application des outils d’analyse visés. Les autres

Cette figure ne présente que les artefacts de développement, c’est-à-dire des expressions. Les langag es (langages d’entrée et formalisme) ne sont pas présentés. informations restent informelles. Toutes sont consignées dans le cahier des charges. Le modèle résulta de la composition des spécifications partielles est une instance d’un formalisme représenté par un métamodèle ditmétamodèle cœur. Une fois le modèle global obtenu, les outils embarqués dans la plate-forme peuvent être utilisés. La Figure 1 classe ces outils dans trois grandes catégories : outils V&V, outils d’extraction d’informations (pour la génération d’artefacts de développement aval par exemple54) et outils de génération de tests système. Enfin,l’approche suppose le maintien de liens de traçabilité entre les spécifications informelles, esl spécifications partielles produites par les parties prenantes et le modèle global obtenu par composition.

La plate-forme R2A : une plate-forme de recherche dirigée par les modèles

La plate-forme R2A a été entièrement développée ’aideàl de technologies MDE (EMF [154], Kermeta [146]) pour les besoins de FRANCE TELECOM. En tant que tel, c’est un prototype de recherche et une étude de cas pour l’application systématique de méthodes de conception dirigée par les modèles. C’est aussi une opportunité pour la mise à l’épreuve des outils de l’IDM en cours de maturation comme Kermeta. L’intérêt d’une conceptio de ce type réside dans la flexibilité de l’architecture de la plate-forme. Cette flexibilité facilite l’adaptabilité de la plate-forme à différents contextes industriels. Enfin, la plate-forme R2A vise à étendre l’approche de développement dirigée par les modèles type MDA aux premières étapes de développement logiciel, durant le processus d’ingénierie logicielle.

La plate-forme R2A (Requirements To Analysis) réalise concrètement l’approche proposée plus haut au sein d’un même environnement technologique .La version courante est spécialisée pour le contexte industriel de France Télécom et a été entièrement développée à l’aide de technologies MDE (voir l’architecture en Annexe D). Elle supporte actuellement la simulation fonctionnelle des exigences (validation), la détection d’incohérences (vérification), l’aide au diagnostic via la visualisation des modèles d’exigences (validation), ainsi que la gestion des liens de traçabilité précis entre exigences et artefacts de développement. Utilisés conjointement, ces fonctionnalités offrent un environnement semi-automatisé pour un processus IE.

La Figure 23 donne une vue globale des fonctionnalités de la plate-forme R2A. Le formalisme RM forme le cœur de la plate-forme (voir le Chapitre IV), dont le modèle global d’exigences est une instance. La plate-forme comporte aussi des langages d’entrée et de sortie de la plate-forme ainsi qu’un ensemble de transformation liant ces langages au formalisme. La transformation d’import est particulière car elle réalise la composition des spécifications partielles ; les autres produisent diférents artefacts de développement logiciel. Ces transformations réalisent les fonctionnalités de la plate-forme.

Elles peuvent être adaptée et de nouvelles peuventêtre implémentées. Les fonctionnalités de la plate-forme dans son état actuel sont :

Import de spécifications partielles. L’import des spécifications partielles d’exigences est réalisé par le mécanisme de composition présenté dans leChapitre VI. Ce mécanisme est multi-langage. Actuellement, les langages d’entrée de la plate-forme sont :

Des expressions RDL (voir Chapitre IV),

Des expressions logiques textuelles RM (voir Chapitre IV),

Des diagrammes de classes UML,

Des diagrammes d’activités UML.

Simulation fonctionnelle des exigences. La plate-forme offre un mécanisme de simulation fonctionnelle des exigences. La simulation des exigences offre un moyen de valider intuitivement les exigences avec les parties prenantes. C’est un moyen d’évaluer si les exigences correspondent aux besoins réels et d’évaluer la complétude des exigences [155].

Inspection du modèle global d’exigences. L’obtention d’un modèle global des exigences est utile pour la validation des exigences. La plate-forme offre un mécanisme d’édition du modèle global par requêtes. Les vues obtenues peuvent servir de support à la discussion et la négociation.

Génération de machines à états.La plate-forme génère une machine à état utilisable par des outils de vérification formelle (voirChapitre IV). Une partie de l’analyse peut ainsi être déléguée à des outils de model-checking, pour confronter exigences fonctionnelles et non-fonctionnelles de qualité de service, par exemple.

Génération d’une ébauche de spécifications système. La plate-forme permet d’extraire un ensemble de modèles pouvant servir de base à la production d’une première spécification système. Ces modèles regroupent un diagramme de cas d’utilisation UML et un modèle métier. Le premier décrit les agents du système et les principales fonctions que le système leur fournit. Le deuxième capture l’ensemble des agents du système, les concepts métiers, leurs propriétés et relations. Il est exprimé sous la forme un diagramme de classe UML.

Génération d’objectifs de test système.La génération de cas de tests système (appelés jectifsob de tests système car n’étant pas raffinés pour êtredirectement évalués) et utilisés pour évaluer sie l logiciel implémenté satisfait les exigences. Cette fonctionnalité limite le coût des activités de validation système [55].

Spécifications d’exigences étudiées

Cette section présente les spécifications d’exigences étudiées. La section3.1 décrit brièvement ces spécifications. La section3.2 détaille une spécification utilisée comme illustration dans la suite.

Etudes de cas réalisées

Nous avons étudié plusieurs études de cas provenantde deux industriels et d’un partenaire académique. Nous présentons brièvement ces étudese dcas, dans l’ordre chronologique :

Thalès. Les spécifications d’exigences étudiées portaientessentiellement sur le système de navigation des armements de la dernière générationde l’aviation de combat (Mirage et Rafale), dont TAS développe le processeur principal et les ogiciels d’application. Ces spécifications ont permis de valider une première version du RDL et l’outil de génération de test système de la plate-forme R2A, fruit du travail de thèse de Clémentine Nebut [54-58].

France Télécom.Nous avons tout d’abord modélisé les étapes d’initialisation de la Livebox55 et avons étudié les spécifications de deux servicestélécoms : la « Live-radio Baracoda » développée au sein du Livebox Lab et un prototype de réunion virtuelle. Ce dernier est à l’origine de l’exemple fourni dans ce manuscrit et présenté en section suivante. C’est l’exemple le plus complet et le plus réaliste que nous ayonsétudié à France Télécom.

Ensieta. Nous avons spécifié un système réactif d’alarmeésidentieller (système domotique). Cette spécification regroupe des exigences représentatives de celles rencontrées au sein des spécifications confidentielles d’Airbus confiées à l’Ensieta 57 . Cette étude de cas n’est pas encore aboutie, mais elle nous a permis de nous faire une idée de ce qu’est une spécification opérationnelle d’un système réactif. Dans ce contexte, les exigences fonctionnelles du système sont décrites en RDL et en SDL [86] ; les exigencesnon-fonctionnelles en RDL.

Exemple d’une spécification d’exigences : le système SRV

L’exemple utilisé tout au long de ce manuscrit est un système de réunions virtuelles (SRV). Cette spécification est fournie en section3.2.1. La section 3.2.2 fournit une analyse de cette spécification.

Spécification informelle du système SRV

Cette spécification est donnée sous la forme de sixparagraphes en langage naturel. Cette spécification est représentative des premières spécifications d’exigences : elle est peu détaillée, l’information n’est pas classée et très impréciseVoici. le texte :

P1 00 « Un système de réunion virtuelle permet aux employés de la compagnie de mettre en place des réunions de travail via internet. Le système héberge un ensemble de réunions.

Chaque participant peut avoir une caméra branchée à sa machine, ce qui lui permet quand celle-ci est allumée, d’être vu des participants des réunions auxquelles il prend part. Le système propose un mécanisme de vote, gérépar un modérateur au sein d’une réunion. Le système propose deux types de réunions .Des réunions publiques ouvertes à l’ensemble des participants. Des réunions privées, auxquelles un participant ne peut accéder que si le modérateur l’y a autorisé. »

P2 08 « Pour pouvoir participer à une réunion, un participant doit d’abord se connecter au serveur du système, puis consulter la liste des réunions disponibles. Il peut alors choisir une réunion et y entrer. Pour prendre la parole, un participant doit la demander au Le modem vendu par France Télécom, support des offres télévisuelles, téléphonie fixe et internet.

Incubateur de produits et services internet pour le « home network ».

Parmi celles-ci, on trouve par exemple une spécification de l’AFN ( Aircraft Facilities Notification), un protocole assurant la prise de contact et l’échange de messages entre les avions et les centres de contrôle aérienmodérateur de la réunion. Lorsqu’un participant a al parole, il peut envoyer un ensemble de messages aux autres participants. Il peut aussi rendre la parole à tout moment. Un participant peut quitter une réunion à tout moment. Le système doit garantir que le temps de chaque prise de parole par un participant n’excède pas trois minutes. »
P3 15 « Tout participant peut planifier une réunion. Dans ce cas, il est considéré comme le gestionnaire de la réunion. En tant que tel, il peut définir un modérateur pour cette réunion et définir le type de la réunion. Un gestionnaire peut ouvrir les réunions qu’il a planifiées.

Une réunion doit être ouverte avant qu’un participant puisse y entrer. Le modérateur peut donner la parole à un participant mais aussi la lui retirer à tout moment. Il est aussi responsable de la fermeture d’une réunion. Dans ce cas, les participants sortent de cette réunion et ne peuvent plus y entrer. »

P4 22 « Le système de réunion doit offrir un haut niveau de sécurité, car les décisions votées au sein des réunions peuvent être cruciales pour la co mpagnie. Les messages manipulés par le système doivent être cryptés par clé RSA. De plus, l’identité des participants doit être strictement vérifiée. Pour ce faire, chaque participant doit, une fois connecté à un serveur du système, se connecter à un serveur externe pour identification avant de pouvoir entrer dans une réunion. Le serveur externe est mis en place par une société privée et le temps de connexion est au maximum de 30 secondes. De plus, un participant ne peut voter que s’il a une caméra et que si celle-ci est allumée. Ces règles de sécurité ne s’appliquent que dans le cas de réunions privées. »

P5 31 « Une réunion ne peut être ouverte si un modérateur ne lui a été affecté. De plus, une réunion ne peut comporter plus d’un modérateur. Un modérateur peut fermer les réunions dont il est responsable. Il doit être impossible à deux participants d’avoir la parole en 34 même temps. Pour des raisons de sécurité, la caméra d’un utilisateur doit être automatiquement éteinte lorsqu’un participant quitte une réunion. Le temps de connexion sur le serveur prend en moyenne quinze secondes. »

P6 37 « Les responsables des réunions sont généralement les assistant(e)s de projets. Le besoin de réunions virtuelles étant important au sein de la compagnie (nécessité de réduire les coûts de déplacements), la création de réunions doit être rapide et aisée, afin de limiter la charge de travail supplémentaire pour les assistant(e)s. L’interface doit être 41 intuitive de sorte que la planification d’une réunion soit possible en moins de 30 secondes. Le temps entre la demande de planification d’une réunion faite à un assistant et l’ouverture de cette dernière doit être inférieur à une minute (ordre de grandeur). »

Analyse de la spécification

La spécification SRV est une spécification d’exigences obtenue au tout début d’un processus d’ingénierie des exigences. C’est une spécificationinformelle mélangeant exigences fonctionnelles et non fonctionnelles du SRV ainsi que des objectifs décrivant les besoins initiaux des clients. Dans cete section, nous illustrons les notions introduites dans les Chapitre I et Chapitre II.

Ambiguïtés. Cette spécification comporte de nombreuses ambiguïtés. Certaines peuvent être dues à la nature informelle du langage naturel. Par exemple, il est impossible de déterminer syntaxiquement à quel mot se réfère « celle-ci » dans la phrase du premier paragraphe58 : « Chaque participant peut avoir une caméra branchée à sa machine, ce qui lui permetquand celle-ci est allumée … » (lignes 2 à 4). Cette ambiguïté a des chances d’être résolue intuitivement et de la même manière par l’ensemble des parties prenantes (néanmoins, il est possible qu’une partie prenante comprenne que c’est de la machine dont il est question).

Une autre cause d’ambiguïté est le manque de précions et par conséquent l’incomplétude de la spécification (ce que l’usage du langage naturel favorise). Voici quelques exemples de manques d’information au sein de la spécification SRV :

rien ne précise dans la spécification qu’un gestionnaire de réunion puisse participer à celle-ci. Autrement dit, un gestionnaire peut-il être un participant ?

En français, « celle-ci » représente toujours le dernier mot nommé, ici « machine ». Si on avait voulu désigner « caméra », il aurait fallu employer « celle-là ». En fait, il n’y a pas d’ambiguïté, même s’il est vrai que dans le langage courant, on tient rarement compte de cette règle de grammaire.

il n’est pas non plus spécifié si un gestionnaire eutp se définir lui-même comme modérateur.

il n’est pas précisé si un participant doit être enpossession d’une caméra pour pouvoir prendre part à une discussion privée. En effet, un vote a-t-il encore un intérêt dans le cadre d’une réunion privée où seul un participant est en possession d’une caméra (donc en mesure de voter) ?

la référence au « serveur » ligne 36 est ambiguë car il est impossible de déterminer si ce serveur correspond au serveur externe (pour l’identification sécurisée, cf. ligne 26 par exemple) ou au serveur du système (cf. ligne 9 par exemple).

Incohérences. La spécification SRV comporte plusieurs incohérences. Elle contient tout d’abord des incohérences de type sous-spécification comme nousavons vu en section précédente (incomplétude), ce qui est source d’ambiguïté. Elle contient aussid’autres types d’incohérences :

Contradiction logique statique : par exemple, l’expression « au serveur du système » (ligne 9) suppose qu’il existe un seul serveur pour la connexion des participants au système. Or, cette information est contredite par l’expression « à un serveur du système » (ligne 25-26). Cette incohérence est statique car elle porte uniquement sur une connaissance des états possibles du domaine.

Contradiction logique dynamique : par exemple, la spécification indique que le temps entre la connexion au serveur interne et l’ouverture d’une réunion doit être inférieur à une minute. Cette exigence peut être satisfaite par le scénario suivant: (i) connexion du gestionnaire au serveur du système en 15 secondes (cf. ligne 36), (ii) planification en 30 secondes (cf. ligne 41-42) puis ouverture (le temps est a priori négligeable puisqu’aucune durée n’est précisée). Cette exigence ne peut cependant pas être satisfaite si al réunion est privée, car il faut alors ajouter 30 secondes pour l’identification via le serveur externe (cf. ligne 28).

Collision : par exemple, il est question dans la spécification SRV de responsables (ligne 37) et gestionnaires de réunions (e.g. ligne 16). Les termes « responsables » et « gestionnaires » désignent en fait la même notion, mais désignée pardeux mots différents. C’est un cas de collision terminologique (cf. section 4.1 du Chapitre II). Le premier paragraphe contient en outre un exemple de collision dénotationnelle : le terme « employés » désigne en fait le même concept que « participant ». Les collisions structurelles ne peuvent être détectées au sein d’une spécification informelle car elles consistent en une différence dans la manière de modéliser une information complexe (plusieurs notions liées).

Nature des informations. La spécification SRV est une spécification d’exigences de haut niveau. En tant que telle, elle capture des informations mélangeant un grand nombre de types d’informations. On trouve pêle-mêle :

(A1) Des objectifs. Par exemple, la phrase « Le système de réunion doit offrir un haut niveau de sécurité car les décisions votées au sein des unionsré peuvent être cruciales pour la compagnie. » (lignes 22-23) décrit un objectif de confidentialité. Les deux phrases suivantes sont des objectifs raffinant ce dernier. En effet, le cryptage des messages échangés durant une réunion et l’identification des participants contribue à la confidentialité des informations échangées dans le système. La première partie du dernier paragraphe décrit aussi un objectif, relatif à la rapidité d’utilisation du système.

(A2) Des descriptions des états possibles du domaine. Les exigences décrivent aussi un aspect statique du domaine. Ce type d’informations comporte des informations sur les concepts du domaine, leurs relations et les cardinalités de celes-ci. Par exemple, la spécification SRV porte sur les concepts de « participant », de « réunion », de « caméra », de « serveur du système » … Elle spécifie que la machine d’un participant peut être reliée à une caméra (ligne 2), que plusieurs participants peuvent être connectés au serveur du système (ligne 25-26) …

(A3) Des contraintes sur les états du système. La spécification du SRV contient aussi des contraintes statiques comme le fait qu’il ne puisse y avoir plus d’un modérateur par réunion (ligne 32), ou qu’il soit impossible à deux participants d’une même réunion d’avoir la parole en même temps (ligne 33-34).

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
PREMIERE PARTIE : ETAT DE L’ART ET MOTIVATION
CHAPITRE I FIABILISATION DES EXIGENCES
1 Processus d’ingénierie des exigences
2 Capture des exigences
2.1 Décomposition et classement de l’information
2.2 Langages de modélisation des exigences
2.3 Approche de modélisation par patrons de spécifications et langage naturel contraint
3 Détection d’incohérences
3.1 Notion d’incohérence et classifications
3.2 Principales approches de détection d’incohérences
4 Synthèse
CHAPITRE II UN CADRE CONCEPTUEL POUR LA METAMODELISATION : L’INGENIERIE DIRIGEE PAR LES MODELES
1 Théorie des langages
2 Métamodélisation
2.1 Modèles et métamodèles
2.2 Relations entre modèles, métamodèles et langages
2.3 Niveaux de modélisation : l’architecture MDA
3 Transformation de modèles
3.1 Définition et langages actuels
3.2 Spécification par transformation de modèles de la sémantique d’un langage
4 Composition de modèles
4.1 Principes généraux
4.2 Approches de composition de modèles
5 Synthèse
CHAPITRE III PROBLEMATIQUES, PLATE-FORME DE RECHERCHES ET SPECIFICATIONS ETUDIEES
1 Problématique
2 Approche proposée et réalisation concrète
2.1 Description générale de l’approche
2.2 La plate-forme R2A : une plate-forme de recherche dirigée par les modèles
3 Spécifications d’exigences étudiées
3.1 Etudes de cas réalisées
3.2 Exemple d’une spécification d’exigences : le système SRV
DEUXIEME PARTIE : CONTRIBUTIONS
CHAPITRE IV LE FORMALISME RM ET LE LANGAGE RDL
1 Le formalisme RM
1.1 Vues, niveaux de description et niveaux de modélisation
1.2 Sémantique statique
1.3 Sémantique dynamique
2 Le langage RDL : un langage naturel contraint pour exprimer le domaine d’un système
2.1 Intérêt et Principes et du RDL
2.2 Patrons de spécification RDL et expressivité du langage
2.3 Description du langage RDL : le métamodèle RDM
CHAPITRE V CARACTERISATION D’UN PROCESSUS DE COMPOSITION DE SPECIFICATIONS PARTIELLES HETEROGENES
1 Exemple d’une spécification d’exigences opérationnelles
2 Analyse de la problématique
2.1 Description générale d’un processus de composition
2.2 Interprétation
2.3 Traitement des superpositions sémantiques
3 Résumé des caractéristiques d’un processus de composition d’exigences
CHAPITRE VI OBTENTION D’UNE SPECIFICATION OPERATIONNELLE GLOBALE : PROCESSUS DE COMPOSITION SIMPLE
1 Un processus itératif en trois étapes
1.1 Vue générale du processus
1.2 Description des trois étapes du processus
1.3 Itération et symétrie du processus
1.4 Relâchement du métamodèle cœur
2 Interprétation
2.1 Vue générale
2.2 Notion de règle d’interprétation
2.3 Nature des modèles intermédiaires produits
3 Fusion
3.1 Vue générale
3.2 Exemples de fragments à fusionner et caractérisation de l’étape de fusion
3.3 Approche adoptée et implémentation avec le langage FRL
3.4 Illustration
4 Analyse
4.1 Vue générale
4.2 Support de la traçabilité
4.3 Analyse statique du modèle global
4.4 Illustration
CHAPITRE VII CREATION DE PLATES-FORMES SPECIALISEES : PROCESSUS DE COMPOSITION DOUBLE
1 Motivation
2 Cadre conceptuel pour l’adaptabilité de la plate-forme R2A
3 Processus de composition double
3.1 Vue générale du processus
3.2 Exemple de sémantique de composition définie sur le MOF
3.3 Directives de composition
3.4 Cohérence du métamodèle cœur et de sa sémantique de fusion
CONCLUSION ET PERSPECTIVES
TROISIEME PARTIE : ANNEXES
ANNEXE A INDEX
ANNEXE B PROCESSUS D’INGENIERIE DES EXIGENCES
ANNEXE C CADRE CONCEPTUEL EN INGENIERIE DES EXIGENCES.
ANNEXE D ARCHITECTURE DE LA PLATE-FORME R2A
ANNEXE E DESCRIPTION DES VUES DU FORMALISME RM
ANNEXE F LANGAGE RDL.
ANNEXE G GRAMMAIRE EBNF DU LANGAGE IRL
ANNEXE H GRAMMAIRE EBNF DU LANGAGE FRL.
ANNEXE I SPECIFICATION IRL DE LA FONCTION SEMANTIQUE DU LANGAGE RDL DEFINIE SUR RM (F : RDL → RM). 181
ANNEXE J SPECIFICATION IDL DE REGLES DE DETECTION D’INCOHERENCES POUR LE METAMODELE RM.
ANNEXE K SPECIFICATION FRL DE LA SEMANTIQUE COMPOSITIONNELLE DU METAMODELE RM (ΦRM)
ANNEXE L MODELES INTERMEDIAIRES PRODUITS DURANT LA COMPOSITION DES MODELES DE LA FIGURE
ANNEXE M SPECIFICATION FRL DE LA SEMANTIQUE COMPOSITIONNELLE DU META METAMODELE MOF (ΦMOF)
PUBLICATIONS
BIBLIOGRAPHIE