Le langage IRL est conceptuellement proche d’un langage à base de règles comme ATL [141]. Cependant, la spécification d’une fonction sémantique avec IRL diffère substantiellement d’une spécification avec ATL car le modèle produit a pour vocation d’être traité durant l’étape de fusion présentée en section suivante. Une fonction sémantique est en fait implémentée par un code IRL et la spécification de fusion commune à l’ensemble des fonctions sémantiques. En effet, la fusion permet de résoudre les redondances entre les modèles intermédiaires, de résoudre certaines ambiguïtés et de supprimer les malformations syntaxiques comme nous le verrons en section 3.
L’existence d’une étape de fusion diminue de fait la complexité des spécifications implémentant l’étape d’interprétation puisqu’une partie des spécifications des fonctions sémantiques est factorisée par le code implémentant l’étape de fusion. En outre, le traitement des superpositions sémantiques effectué par l’étape de fusion autorise la création de modèles intermédiaires (i) non-conformes au métamodèle coeur, (ii) comportant des redondances et (ii) des malformations syntaxiques. Nous décrivons dans cette section la nature des modèles intermédiaires produits par l’étape d’interprétation. La section 2.3.1 illustre la non-conformité des modèles intermédiaires et la section 2.3.2 souligne la redondance de l’information générée par l’interprétation.
2.3.1 Non-conformité et malformation syntaxique
On peut remarquer en observant la Figure 58 qu’un modèle intermédiaire comporte des malformations syntaxiques :
(i) L’action connect n’a pas de post-condition.
(ii) Il existe une instance de VARIABLE n’étant liée à aucune expression.
(iii) Il existe une instance de CONTAINMENT n’est pas liée à la description de l’action
connect.
Certaines malformations sont détectables grâce à la relation de conformité. C’est le cas de la malformation (i), puisque l’absence d’une instance du lien postCond pour une ACTION constitue une violation de cardinalité en regard du métamodèle RM. D’autres comme (ii) et (iii) ne peuvent être détectées de cette manière. Il est envisageable de définir des contraintes structurelles supplémentaires OCL dans cette optique. Cependant, nous avons vu que dans le cas général, certaines contraintes structurelles ne sont pas exprimables. En outre, il n’est pas raisonnable de définir toutes les contraintes structurelles possibles. L’absence d’une durée pour l’action connect pourrait aussi être une malformation, bien que dans le cas du RM, on considère par convention qu’une action sans durée définie est considérée comme instantanée. Quoi qu’il en soit, ces malformations reflètent un manque d’information caractéristique des modèles intermédiaires puisqu’ils représentent une information partielle par nature (les modèles d’entrée). Ces malformations doivent être résolues durant l’étape de fusion.
Enfin, on peut remarquer qu’un modèle intermédiaire vérifie un ensemble de contraintes structurelles propres à la nature des fragments produits par les productions des règles d’interprétation puisqu’une production spécifie un type d’informations. A titre d’exemple, il est impossible q’un
modèle intermédiaire contienne une instance de Parameter non lié à une action car cet objet n’aurait alors aucun sens. De même, une instance de Property est forcément lié à une entité (via une instance de la propriété properties) et à un type. Dans le cas contraire, soit le code implémentant l’interprétation comporte une erreur, soit le modèle d’entrée n’est pas conforme à son métamodèle d’entrée (par exemple, un diagramme de classe où une partie prenante a omis de préciser le type d’un attribut d’une classe). Dans le deuxième cas, l’incohérence est détectable avant composition, mais rien n’empêche d’appliquer l’étape de fusion ; l’incohérence sera aussi détectée sur le modèle global.
2.3.2 Redondance de l’information
L’étape de fusion résout les redondances entre les modèles intermédiaires. Cependant, elle peut aussi résoudre des redondances au sein d’un même modèle intermédiaire. Cette caractéristique permet de limiter la complexité des spécifications IRL. C’est le cas de la spécification IRL f : RDL → RM. Le
modèle intermédiaire de la Figure 58 illustre la création artificielle de redondance par f. A titre d’exemple, on peut remarquer deux superpositions sémantiques produit lors de l’interprétation d’un seul modèle d’entrée :
(i) Le concept métier participant est représenté deux fois ; par une instance de la métaclasse ACTOR (a) et par une instance de la métaclasse CONCEPT (b).
(ii) Le paramètre de l’action connect de type participant est représenté par les objets (c) et (d) (respectivement instances des métaclasses VARIABLE et PARAMETER).
La première redondance reflète la double référence à la notion de participant au sein de la spécification RDL textuelle. En effet, ce concept est représenté par le groupe nominal « A participant » et par le pronom « he ». La résolution de cette redondance est laissée à la charge de l’étape de fusion, ce qui limite la complexité du code IRL. Plutôt que de vérifier si une entité a déjà été créée pour représenter cette notion (cette entité pouvant être une instance d’Actor ou de Concept), la fonction f crée systématiquement une entité. La deuxième redondance reflète comme la première la double référence à la notion de participant. La fonction f génère systématiquement une instance de Variable pour toute entité, si cette dernière n’est pas liée à un paramètre d’une action. Cependant, il n’est pas possible dans ce cas de laisser à la charge de la fusion le soin d’identifier une superposition sémantique entre les objets (c) et (d). Alors qu’il est possible de statuer que les objets (a) et (b) désignent le même élément du domaine, il est impossible de déterminer si les objets (c) et (d) sont équivalents. Seul la connaissance de la spécification RDL permet d’être conscient de cette équivalence (grâce au référencement du pronom « he »). Il est donc nécessaire dans ce cas de préciser que (c) et (d) sont équivalents.
IR variableEquivalence(e : EntityRef) ? : variableOrParameter(e);
{
var l : List<<NominalGroup>> init Resolver.getReferencedNominalGroups(e); if (l.size() >= 1)
Tracer.declareAsEquivalent(Variable@(e), Variable@(l.get(0)), "variable"); } 01 05 IR variableEquivalence(e : EntityRef) ? : variableOrParameter(e); {
var l : List<<NominalGroup>> init Resolver.getReferencedNominalGroups(e); if (l.size() >= 1)
Tracer.declareAsEquivalent(Variable@(e), Variable@(l.get(0)), "variable"); }
01
05
Figure 60 - Déclaration d'équivalences entre objets d'un modèle intermédiaire durant l’étape d’interprétation.
Le langage IRL permet de déclarer des équivalences devant être résolues durant l’étape de fusion grâce à une instruction native. La Figure 60 fournit la règle d’interprétation déclarant l’équivalence entre des instances de VARIABLE. Cette règle ne produit pas de fragments ; elle se contente de déclarer équivalent les variables (instances de PARAMETER ou VARIABLE) produits pour des ENTITYREF
différents mais désignant la même instance d’ENTITY (par exemple, « A participant » et « he » dans la phrase de la Figure 58), grâce à l’appel de la méthode declareAsEquivalent (ligne 6 de la Figure 60). Les équivalences déclarées durant l’étape d’interprétation sont capturées par un modèle traité durant l’étape de fusion, présentée en section suivante. Ce mécanisme est aussi utilisé pour définir des équivalences entre modèles iintermédiaires lorsqu’il existe des relations sémantiques entre des champs
d’une notation. A titre d’exemple, les objets produits par interprétation et représentant les instances p, f et m dans les modèles d’entrée (e) et (f) (champs scope et diagram de la notation diagramme d’activité) sont déclarés équivalents durant l’interprétation en utilisant la méthode declareAsEquivalent.
3 Fusion
Nous avons vu en section précédente l’étape d’interprétation et la nature des modèles intermédiaires produits. Ces modèles capturent dans les termes du formalisme les informations décrites par les parties prenantes à l’aide des langages d’entrée et des notations supportés par le processus de composition. L’interprétation ne résout pas la décomposition initiale des informations sur les exigences d’un système rédigées par une multitude de parties prenantes. C’est le but de l’étape de fusion, c’est-à-dire la production d’une vue globale des exigences représentée par le modèle global. En outre, l’étape de fusion est aussi responsable de la résolution des ambiguïtés nécessitant un contexte global Nous détaillons dans cette section les principes de l’étape de fusion.
Cette section est organisée comme suit. La section 3.1 offre une vue générale de l’étape de fusion. La section 3.2 présente un ensemble de fragments de modèles intermédiaires résultant de l’interprétation des modèles d’entrée de la Figure 43 et caractérise l’étape de fusion par l’exemple. La section 3.3 détaille techniquement l’approche adoptée. Le langage FRL est présenté dans ses grandes lignes et l’étape de fusion est illustrée avec les fragments de modèles de la section 3.2. Nous présentons les deux types de règles de fusion proposées, à savoir les règles d’équivalences et les règles de normalisation, et discutons de l’ordonnancement de leur exécution. Nous montrons de plus la manière dont les ambiguïtés résultant de la décomposition de l’information sont traitées et résolues. Enfin, la section 3.4 donne une illustration de l’exécution de l’étape de fusion sur les fragments de modèles de la section 3.2.
3.1 Vue générale
L’étape de fusion a pour but (i) l’identification de superpositions sémantiques au sein des modèles intermédiaires et (ii) la résolution de ces superpositions sémantiques de sorte qu’il ne reste plus une seule redondance. Nous avons brièvement illustré cette problématique en section 2.3. L’identification de superpositions sémantiques repose sur une comparaison syntaxique des modèles intermédiaires83. Ces superpositions concernent des objets appartenant à des modèles intermédiaires, mais aussi dans certains cas à un même modèle intermédiaire puisque l’interprétation peut produire des superpositions artificielles (voir la section 2.3.2). L’identification d’une superposition porte généralement sur la comparaison d’objets de même type et ayant des similitudes concernant les valeurs de leur propriété. L'approche classique pour réaliser une fusion de modèles est de comparer les objets des modèles intermédiaires deux par deux et de les combiner sur la base d'équivalences syntaxiques. Cependant ce cas est particulier et l’équivalence entre deux objets ne peut être systématiquement déterminée par égalité syntaxique. En outre, l'efficacité de cette approche est limitée par les phénomènes de collisions. Nous avons aussi vu que l’identification d’une superposition peut dépendre d’une autre identification et plus généralement de la sémantique du métamodèle coeur.
La résolution d’une superposition décrit le remplacement d’un ensemble d’objets équivalents par un seul nouvel objet. Les propriétés de cet objet sont affectées de manière à ce qu’il reflète correctement l’information capturée par les objets remplacés. Dans certain cas, une résolution d’équivalence revient à une simple union des valeurs des propriétés des objets remplacés (c’est le seul cas considéré par Sabetzadeh et Easterbrook [40]). Cependant, une résolution d’équivalence est plus complexe dans le cas général car (i) les objets remplacés peuvent être de types différents, (ii) l’obtention de la valeur d’une propriété du nouvel objet peut nécessiter un calcul autre qu’une simple union et (iii) elle peut nécessiter la création de nouveaux fragments d’objets. Par exemple, dans le cas
83 La structure d’un modèle (la syntaxe) représente le sens d’un modèle, étant donné la sémantique de son métamodèle.
d’un ensemble d’objets e instances de PROPERTY et désignant une même propriété, l’entité contenant cette propriété correspond à l’entité la plus générale dans la hiérarchie de type (relation superTypes) liant les entités contenant les objets de e.
Les modèles intermédiaires sont instances du métamodèle cœur mais pas toujours conformes (voir section 2.3.1). Le modèle global est conforme au métamodèle cœur relâché84 puisque la résolution peut faire apparaître des violations portant sur les bornes supérieures des cardinalités. Ces violations peuvent refléter des incohérences au niveau des exigences ; elles sont analysées durant l’étape d’analyse. Cependant, d’autres peuvent refléter des malformations syntaxiques. Par exemple, une action ne comportera pas de post-condition au niveau du modèle global après résolution des superpositions si aucun modèle d’entrée ne spécifie d’informations en ce sens. Cette malformation syntaxique (détectée dans ce cas par la relation de conformité du métamodèle RM) doit être supprimée de telle sorte qu’une incohérence détectée dans le modèle global après fusion corresponde effectivement à une incohérence au niveau des exigences. Ce traitement est appelé normalisation et est à la charge de l’étape de fusion.
« instance de » « conforme à » Transformation de modèles « instance de » « instance de » « conforme à » « conforme à » Transformation de modèles Transformation de modèles métamodèle FRL métamodèle FRL M2 M1 modèle d’équivalences a ≡b c ≡d e ≡f modèle d’équivalences a ≡b c ≡d e ≡f métamodèle cœur modèle intermédiaire modèle intermédiaire modèle intermédiaire modèle intermédiaire modèle global modèle
global de tracede tracemodèlemodèle métamodèle de traçabilité métamodèle de traçabilité métamodèle d’équivalences métamodèle d’équivalences métamodèle cœur relâché
Figure 61 - Schématisation de l'étape de fusion.
La Figure 61 schématise l’étape de fusion dans une perspective IDM. Elle est implémentée par une transformation de modèle spécifiée par un ensemble de règles de fusion (règles d’équivalences et
règles de normalisation, voir la section 3.3.1). Dans le cadre de la plate-forme R2A, ces règles sont spécifiées par un code FRL (pour Fusion Rule Language). Cette transformation est commune à l’ensemble des fonctions sémantiques des langages d’entrée. Elle accepte en entrée l’ensemble des modèles intermédiaires produits par interprétation ainsi qu’un modèle d’équivalence décrivant les superpositions détectées durant l’interprétation et non détectable par la seule analyse des modèles intermédiaires. Le modèle global est construit progressivement par une application itérative des règles de fusion (la première version du modèle global rassemble l’ensemble des modèles intermédiaires au sein d’un seul modèle). L’ordre d’exécution de ces règles est partielle et explicitement défini (voir la section 3.3.2). Le langage FRL supporte un mécanisme de traçabilité natif, tout comme IRL. L’étape de fusion produit donc en plus du modèle global un modèle de traçabilité, qui, associé au modèle de traçabilité produit durant l’étape d’interprétation, permet d’associer sémantiquement les objets du modèle global aux objets des modèles d’entrée (voir section 4.2).
84 Il ne peut être que conforme puisqu’un métamodèle relâché ne comporte aucune contrainte structurelle par définition.
L’étape de fusion porte sur l’ensemble des modèles intermédiaires, ce qui permet de déterminer quelles variations sémantiques choisir lorsque ces dernières ont pour cause la décomposition de l’information statique. En revanche, les variations sémantiques dynamiques du même type doivent être résolues par un dialogue avec les parties prenantes. Nous avons vu en section 2.2.3 que cette résolution peut être effectuée de deux manières possibles : (i) par proposition exhaustive des alternatives possibles ou (ii) par simulation ou génération de scénarios. Nous illustrons la première possibilité et discutons des problèmes liés à la deuxième en section 3.4.