instanceOf 1 steps * initialState 1 instances * effParams 1..* triggeredAction 1 value 0..1 instanceOf 1 elements 1..* instanceOf 1
Figure 33 - vue instanciation du métamodèle RM.
Etat (STATE). Un état du système est la donnée d’un ensemble d’instances des propriétés et des entités
du domaine. Un état du système représente une configuration du système à un instant donné.
Instance (INSTANCE). Une instance peut être un objet (OBJECT, instance d’un concept métier), un agent (AGENT, instance d’un acteur du système), une propriété d’une instance d’entité (ENTITYINSTANCE), ou encore un littéral. Par convention, on ne modélise les instances des attributs booléens que si leur valeur est à « vrai ». Les relations instanceOf permettent d’associer à chaque instance son type. Ces relations modélisent la relation d’instanciation entre les niveaux de modélisation théorique M0 et M1 (cf. section 1.1).
Scénario (SCENARIO). Un scénario est une séquence d’états (STATE) liés un à un par une transition (TRANSITION). Un scénario débute par un état initial (initialState). Chaque transition représente l’activation d’une action (triggeredAction) avec pour paramètres effectifs (effParams) une liste d’instances des éléments du domaine (autres que les instances de propriétés comme le spécifie la première règle OCL). Ces paramètres effectifs sont conformes aux paramètres formels de l’action activée. Seul l’état initial représente un état du système dans son intégralité, les autres états pouvant être calculés par simulation du scénario. La deuxième expression OCL contraint la propriété instances dans ce sens. Néanmoins, rien n’empêche de représenter dans leur intégralité l’ensemble des états.
1.3 Sémantique dynamique
Nous détaillons la sémantique dynamique du formalisme RM. Une description informelle est fournie en section 1.3.1. La section 1.3.2 suivante présente l’implémentation de la sémantique de RM à l’aide d’une sémantique opérationnelle pour la simulation des exigences fonctionnelles.
1.3.1 Description informelle
Etant donné un état du système S, les contrats d’une action spécifient si elle est applicable et quels sont les impacts sur S s’il est exécuté. En outre, les assertions décrivent aussi des liens de causalité modifiant l’état du système. Il est donc possible de créer de manière incrémentale des scénarios valides d’actions satisfaisant les exigences fonctionnelles et l’environnement. La construction d’une séquence valide est définie par l’algorithme suivant :
(i) Instanciation des actions avec des valeurs possibles pour chacun des paramètres, étant donné l’état courant du système.
(ii) Obtention d’un ensemble d’actions instanciées L dont la pré-condition est satisfaite par l’état du système.
(iii) Choix d’une action A à exécuter parmi les éléments de L. (iv) Mise à jour de S par application de la post-condition de A.
(v) Identification des assertions environnementales pouvant être exécutées et mise à jour de S par application de ces dernières.
(vi) Deux variantes :
o On cherche à vérifier si les exigences fonctionnelles satisfont les exigences non-fonctionnelles. Dans ce cas, on identifie les assertions environnementales pouvant être exécutées et on met à jour S par application de ces dernières.
o On cherche à valider par simulation des exigences. Dans ce cas, on identifie les propriétés non-fonctionnelles (assertions et contraintes) pouvant être exécutées et on met à jour S par application de ces dernières.
connect to the external server(John)
connected(John, server1)
entered(admin, meeting1)
private(meeting1)
entered(john, meeting2)
+identified(John)
disconnect (admin, John)
choix utilisateur propriété indicative choix utilisateur propriété indicative
-connected(John, server1)
assertion (b)
-identified(John)
contrainte (c)
-entered(John, meeting1)
(S0) (T0) (S1) (T2) (S3) (T3) (S4) (T4) (S5)+entered(John, meeting1)
(S2)enter(John, meeting1)
(T1)Figure 34 – Un exemple de scénario produit par simulation
En appliquant systématiquement cet algorithme, il est possible de générer un graphe fini et exhaustif représentant tous les comportements envisageables du système. La Figure 34 présente un extrait d’exécution de cet algorithme. C’est un scénario satisfaisant la sémantique dynamique. Il est composé d’une séquence de transitions liant deux à deux des états du système. L’état initial S0
représente un état du système où un participant « John » est dans une réunion publique « meeting2 » et un autre participant (un administrtaeur) est dans une réunion privée « meeting1 ». Chaque transition représente soit une action effectuée par un acteur du système (transitions T0 à T2), soit l’exécution
automatique d’une propriété non-fonctionnelle (T3 exécute l’assertion (b) de la Figure 26 et T4 exécute la contrainte (c)). Par exemple, la connexion au serveur externe de John (transition T0) modifie l’état du système en ajoutant le fait que « John » est désormais identifié par le système de sécurité (le serveur externe).
La Figure 34 est un exemple de scénario produit en choisissant la variante 6b de l’algorithme. En effet, la contrainte (c) est non pas évaluée mais exécutée. Dans ce cas, ce scénario représente les besoins des parties prenantes (cas d’une simulation pour validation). La variante 6a est appropriée si l’on cherche à vérifier que le logiciel satisfait ses exigences (cas du test système par exemple, ou du model-checking). Dans ce cas, un exemple de scénario pourrait être le même scénario que la Figure 34, excepté la dernière transition. A la place de cette dernière, il conviendrait d’ajouter une évaluation de la contrainte (c) sur le logiciel. Le couple scénario et évaluation forme un cas de test système (voir les travaux de Clémentine Nebut [57]).
1.3.2 Simulation par sémantique opérationnelle embarquée
Nous présentons ici l’implémentation de la sémantique RM à l’aide d’une sémantique opérationnelle embarquée60. Cette implémentation est spécialisée pour la simulation des exigences. Elle est implémentée en Kermeta, comme nous avons vu en section 3.2.2 du Chapitre II. La sémantique opérationnelle est donc spécifiée avec un ensemble d’opérations, de relations et de métaclasses étendant le métamodèle RM. La Figure 35 présente un extrait du métamodèle RM étendu. Elle comporte des métaclasses décrites précédemment dans ce chapitre et appartenant à différentes vues. Les éléments de la sémantique opérationnelle comme la métaclasse Simulator n’augmente pas la l’expressivité du formalisme RM ; ils servent uniquement à la spécification de la fonctionnalité de simulation. Nous verrons dans le Chapitre VII que le formalisme RM est en fait le résultat de la composition de composants ontologiques (les vues RM résultent de la fusion de composants ontologiques) et de composants fonctionnels (par exemple un composant de simulation).
initializeFromScenario() initializeFromState() triggerTransition() run() Simulator save() clone() State save() Scenario isRunnable() trigger() Transition apply() evaluate() Expression instanciate() Action apply() evaluate() Automata runningScenario 0..1 steps * instanceOf 1 preCond 1 postCond 1 initialState 1 newState 0..1 currentState 0..1 actions * possibleTransitions * simulatedNFProperties * Sémantique opérationnelle Sémantique opérationnelle
Figure 35 – Extrait du métamodèle RM étendu pour la simulation des exigences avec une sémantique opérationnelle embarquée Kermeta.
La métaclasse SIMULATOR définit quatre opérations utilisées pour piloter la simulation. L’opération run orchestre la boucle de simulation : calcul des transitions possibles (possibleTransitions), attente du choix de l’utilisateur, et enfin application des propriétés
60 L’implémentation à l’aide d’un homéomorphisme vers le langage IF pour la vérification des exigences non-fonctionnelles n’est pas présentée.
fonctionnelles simulées (simulatedNFProperties). La simulation peut être initialisée avec un état du système fourni par l’utilisateur (initializeFromState) ou avec un scénario (initializeFromScenario) ayant été créé et sauvegardé (save) au préalable par simulation. Cette initialisation affecte l’état courant du simulateur (currentState). Les transitions possibles sont produites en affectant aux paramètres des actions l’ensemble des instances d’entités existantes dans l’état courant (instanciate), puis en vérifiant si ces actions satisfont les pré-conditions (c’est-à-dire si l’état courant implique logiquement la pré-condition). Cette vérification est réalisée par la méthode isRunnable faisant elle-même appel à la méthode evaluate de la pré-condition. L’utilisateur choisit la transition a tirée en exécutant l’opération triggerTransition. Cette dernière procède en deux étapes :
- Dans un premier temps, la transition est exécutée (trigger), ce qui a pour effet d’appeler la méthode clone sur l’état courant, puis d’appeler la méthode apply de l’expression post-condition sur l’état cloné. Cet état devient le nouvel état courant.
- Dans un deuxième temps, les propriétés non-fonctionnelles connues du simulator (simulatedNFProperties) sont appliquées une à une. A chaque application, l’état courant est modifié en conséquence.
2 Le langage RDL : un langage naturel contraint pour exprimer le
domaine d’un système
Cette section présente le langage RDL, un langage naturel contraint à base de patrons de spécification initialement développé pour les besoins de Thalès [152], puis étendu pour ceux de France Télécom. Le RDL est le langage d’entrée principal de la plate-forme R2A. Il a fait l’objet d’un effort particulier afin de proposer une syntaxe adaptée à la manière dont sont rédigées les spécifications d’exigences chez nos partenaires industriels. Le RDL est un des langages d’entrée de la plate-forme R2A. Il propose une syntaxe accessible à l’ensemble des parties prenantes, permettant d’instancier de manière uniforme le métamodèle RM (son domaine). Il peut être considéré comme une syntaxe supplémentaire du formalisme RM dans son ensemble (les autres langages d’entrée de la plate-forme comme les diagramme de classe UML ou les diagrammes d’activités sont moins expressifs).
La section 2.1 discute de l’intérêt du RDL dans un processus IE et donne un exemple d’expression RDL. La section 2.2 caractérise l’expressivité du langage et fournit une description des patrons de spécification supportés. Enfin, la section 2.3 propose une description plus technique du langage. Elle décrit le métamodèle RDM, représentant la syntaxe abstraite du RDL. Cette description est utile pour illustrer le processus de composition simple du Chapitre VI. En effet, le mécanisme de composition de la plate-forme R2A comporte entre autre un ensemble de règles d’interprétation utilisées pour spécifier la sémantique des langages d’entrée (et en particulier le RDL, utilisé comme illustration).