9.2 Autour de PLiMoS specialisation
9.2.3 Coh´erence des mod`eles
i=1 JEViK
L’approche propose une d´efinition d’un axiome de compositionnalit´e pour des mod`eles de variabilit´e, sur la base des relations d’´equivalence et de similarit´e (cf. section 8.4.1). Elle offre de ce fait, une composition partielle ou globale des mod`eles de variabilit´e, avec filtrage des pr´eoccupations possibles.
L’op´erateur de fusion repr´esente un cas simple, car il concerne des mod`eles homog`enes (de features, ou autres), avec une sp´ecification explicite du chevauchement. L’interpr´etation de l’´equi-valence est la suivante : L’op´erateur ⊕ est d´efini tel que :
⊕ , ∀x ∈ A, y ∈ B · x = y ⇒ C = (C ∪ {x}) ∧ (C ∪ {y})
La strat´egie de composition de similarit´e est la suivante : un renommage d’un des ´el´ements pour permettre l’alignement, le renommage par d´efaut soutenant l’abstraction (propagation du plus au moins abstrait). Dans la pratique, la fusion des mod`eles de variabilit´e entraˆıne une cr´eation d’un nouveau mod`ele.
Note : la fusion de core assets lors de la r´ealisation d’un produit peut suivre le mˆeme principe. Le match et l’identification des relations d’´equivalence s´emantique se doivent d’ˆetre automatis´es (par exemple sur la base de r`egles de composition du langage de mod´elisation cibl´e, cf. section11.5.1).
9.2.3 Coh´erence des mod`eles
Maintenir un alignement op´erationnel revient `a conserver une coh´erence s´emantique et structu-relle entre des mod`eles h´et´erog`enes, d’abstraction et de granularit´es diff´erentes.
Les mod`eles de l’espace de mod´elisation de la ligne de produits associ´es par le langage PLiMoS sont de deux grandes natures, entrainant une gestion de la coh´erence sur deux plans distincts :
1. La coh´erence dans le cadre de l’IDM : avec en premier lieu une conformit´e aux langages (et m´etamod`eles), ainsi qu’aux r`egles OCL additionnelles (notamment dans les mod`eles de variabilit´e). Au del`a des consid´erations sur l’ensemble coercitif de coh´erence dans un IDM, des contraintes de conception sont susceptibles d’ˆetre d´efinies pour respecter un style architectural et imposer des restrictions sur les possibilit´es d’´evolution de la LdP (pour plus de d´etails, voir chapitre10). Par exemple, pour un style d’architecture en couches, la contrainte peut d´ecrire qu’une couche de haut niveau peut utiliser une de ses semblables de plus bas niveau mais pas l’inverse.
2. La coh´erence dans le cadre de la LdP : avec une v´erification des r`egles de bonne formation de la variabilit´e, une coh´erence logique des produits (de type sat) et des core assets (g´er´es par l’IDM dans la perspective de safe composition).
La suite du paragraphe s’attache `a d´ecrire la seconde coh´erence, celle de la ligne de produits. L’objectif est d’inscrire une proc´edure op´eratoire de validation, afin de rendre possible les tests qui sont mis en œuvre au plan formel pour interroger les formules correspondantes. Encore faut-il que le caract`ere normatif des r`egles de translation ait ´et´e circonscrit avec nettet´e, et qu’aucun postulat de signification ne soit import´e dans la proc´edure.
Il est donc primordial d’´etablir des ´equivalences propositionnelles depuis le “monde” IDM et de fournir une s´emantique translationnelle au langage PLiMoS. Cons´equemment, des r`egles d’inf´erence sont d´efinies pour les langages de variabilit´e (FM, OVM, voir ci-apr`es), et d`es lors,
concernant le langage PLiMoS, il s’agit d’effectuer une translation en n´egligeant les nuances de sens des diverses interpr´etations s´emantiques.
L’objectif de la validation est de circonscrire le champ d’application d’une formule donn´ee sur une distribution de valeurs de v´erit´e. La formule est rendue vraie (ou satisfiable) s’il est d´emontrable qu’elle est vraie pour toutes les assignations qui lui sont donn´ees. L’approche se place en utilisateur de techniques ´eprouv´ees de v´erification de satisfiabilit´e des mod`eles, dans le cas pr´esent, `a l’aide de solveurs SAT1 [Man02, MWC09,TBK09]. Des exemples d’op´erations classiques associ´ees sont : la v´erification de satisfiabilit´e, la v´erification qu’une configuration donn´ee est valide au vu des contraintes, le calcul de la commonalit´e, la d´etection de la pr´esence d’´el´ements fantˆomes (dead nodes) [BCTS06].
Les op´erations sont d´efinies comme suit :
❼ Satisfiabilit´e : un mod`ele de variabilit´e vm conforme `a un langage L est satisfiable si une configuration valide peut ˆetre ´etablie - JvmKL 6= ∅ ; cette op´eration renseigne sur la coh´erence du mod`ele de variabilit´e et des relationships associ´ees ;
❼ Validit´e d’une configuration : une configuration c est dite valide si elle satisfait les contraintes du mod`ele de variabilit´e vm - c ∈ JvmKL;
❼ D´ecouverte de la commonalit´e : les ´el´ements communs CE ⊂ E, avec E d´esignant l’en-semble des ´el´ements, sont tels que ∀c ∈ JvmKL· CE ⊆ c
R`egles de translation vers l’espace propositionnel
La s´emantique translationnelle est associ´ee `a PLiMoS et donc aux mod`eles de variabilit´e associ´es. Les cas d’´etudes trait´es se limitent `a l’utilisation de mod`eles de features et de mod`eles de type OVM (introduit section3.2.4), en cons´equence, sont donn´ees ci-apr`es les r`egles de translation de ces deux cat´egories de mod`eles.
Tout d’abord, concernant les mod`eles de features : Soit c un feature composite, S repr´esente l’ensemble des sous-features s de ce dernier, avec sp d´esignant un sous-feature particulier (p ∈ N = {1, . . . , n}, et n = card(s). De la mˆeme mani`ere, d´efinissons q ∈ N ). De plus, d´esignons par f un feature quelconque. Le tableau9.1pr´esente un r´esum´e des ´equivalences entre les op´erateurs des mod`eles de features et la logique propositionnelle. Pour rappel, l’op´erateur Vi,jest l’op´erateur g´en´erique logique, les diverses valeurs de i et j sont observ´ees dans le tableau.
Ensuite, de mani`ere similaire, des ´equivalences logiques sont ´etablies entre le langage OVM et les formules propositionnelles (cf. tableau 9.2). Dans ce tableau, vp repr´esente un point de variation, v in variant (v ∈ V , ensemble des variants de vp, avec card(V ) = n).
Enfin, concernant PLiMoS et ses relations, un nombre non unitaire de propri´et´es s´emantiques peut ˆetre associ´e `a une mˆeme structure relationnelle ; ces derni`eres, si elles poss`edent un des attributs de coordination (implication, co-implication, exclusion) identiques sont ´equivalentes d’un point de vue propositionnel. Concernant l’attribut de coordination propositionnelle, il est primordial que toute relation ayant pour vocation `a ˆetre interpr´et´ee en logique soit renseign´ee. Par ailleurs, les niveaux de criticit´e des relations (high, medium, low ) rentrent en compte comme param`etre du module de translation, permettant une certaine s´electivit´e.
Dans la pratique, les propositions logiques doivent ˆetre converties dans une forme conjonctive normale (conjunctive normal form (CNF)) pour ˆetre absorb´ees par le solveur ; des algorithmes reconnus le permettent. Ne constituant pas le propos de la th`ese, l’impl´ementation de la trans-lation est r´ealis´ee de mani`ere simple par l’implantation d’un visiteur permettant un parcours r´ecursif dans les graphes ; aucune optimisation n’a fait l’objet d’´etudes approfondies.
9.2. Autour de PLiMoS specialisation
Tableau 9.1: Mod`eles de features et formules propositionnelles Mod`eles de features Formules propositionnelles
Optional, V0,1 sp ⇒ c V0,n W p∈Nsp⇒ c Xor, V1,1 c ⇔W p∈Nsp ∧V p,q∈N |p<q(¬sp∨ ¬sq) Or, V1,n c ⇔W p∈Nsp And, Vn,n c ⇒V p∈Nsp ∧W p∈Nsp ⇒ c Vi,j, 1 6 i 6 j < n W M ⊂S|i6Card(M )6j c ⇔V m∈Msm ∧V r∈M,s∈N/M(¬sr∨ ¬ss) V0,j, 1 < j < n WM ⊂S|i6Card(M )6j c ⇒V m∈Msm ∧V r∈M,s∈N/M(¬sr∨ ¬ss) Implication f1⇒ f2 Co-Implication f1⇔ f2 Exclusion ¬ (f1∧ f2)
Tableau 9.2: Mod`ele OVM et formules propositionnelles Entit´es d’OVM Formules propositionnelles
mandatory vp ⇔ v optional v ⇒ vp alternative choice (min = 1, max = 1) vp ⇔W p∈Nvp ∧V p,q∈N |p<q(¬vp∨ ¬vq) alternative choice (min = 1, max = n) vp ⇔ W p∈Nvp alternative choice (min = n, max = n) vp ⇒V p∈Nvp ∧W p∈Nvp⇒ vp alternative choice (min = i, max = j), 1 6 i 6 j < n W M ⊂V |i6Card(M )6j vp ⇔V m∈Mvm ∧V r∈M,s∈N/M(¬vr∨ ¬vs) alternative choice (min = 0, max = j), 1 < j < n W M ⊂V |i6Card(M )6j vp ⇒V m∈Mvm ∧V r∈M,s∈N/M(¬vr∨ ¬vs) requires V V v ⇒ v requires V VP v ⇒ vp requires VP VP vp ⇒ vp excludes V V ¬(v ∧ v) excludes V VP ¬(v ∧ vp) excludes VP VP ¬(vp ∧ vp)
Exemple d’application `a une d´ecomposition de mod`eles de feature
Consid´erons le cas particulier introduit dans la section6.1.1, avec une s´eparation de la variabilit´e du contexte CV M , du probl`eme EV M , et de la solution IV M (pour rappel il s’agit de la figure6.1, page86). Dans l’exemple suivant, chaque type est repr´esent´e par un mod`ele de features. La coh´erence de ces mod`eles pourrait ˆetre envisag´ee s´epar´ement, n´eanmoins la v´erification de coh´erence doit concerner ´egalement la v´erification de l’absence de relations conflictuelles dans et entre les diff´erents mod`eles. L’incoh´erence dans les diff´erents mod`eles de feature correspond `a un ´etat dans lequel deux ou davantage d’´el´ements appartenant `a diff´erents mod`eles font des affirma-tions sur certains aspects du syst`eme qu’ils d´ecrivent qui ne sont pas conjointement satisfiables. Consid´erons l’ensemble des configurations de variabilit´e possibles (evCV M) de l’environnement JCV M KL. Soit, ´egalement, JEV M KL l’ensemble des produits (evEV M) que le management des lignes de produits d´ecide d’offrir. Enfin JIV M KL symbolise l’ensemble des produits (evIV M) que la plate-forme autorise `a construire. Les produits (p) v´erifient une configuration valide (ev ∈ JV M KL), les ´el´ements variables ev se traduisant en pratique par des features, variants et points de variation. Dans la suite, la notation |xrepr´esente une projection s´emantique sur un ensemble d’´el´ements variables (E) : Z|X = {y ∩ X|y ∈ Z}.
La coh´erence de ces mod`eles peut ˆetre dans un premier temps envisag´e s´epar´ement (satisfia-bilit´e s´epar´ee), des v´erifications combin´ees sont ´egalement r´ealisables et sont exprim´ees comme suit :
❼ V1 : Assouvissement de la variabilit´e du contexte. Existe-t-il des contraintes de contexte (ou variabilit´e externes environnementales) non r´ealisables ? Une combinaison de contraintes produits du CVM, evCV M ∈ JCV M K, est r´ealisable s’il existe des liens d’induction en-vironnementale permettant d’assouvir sa variabilit´e, soit : evCV M ∈ (JEV M K|Ecvm ∪ JIV M K|Ecvm). Les ´el´ements non r´ealisables sont donn´es par l’ensemble JCV M K \
(JEV M K|Ecvm∪ JIV M K|Ecvm), qui ne doit ˆetre vide.
❼ V2 : R´ealisabilit´e de la ligne de produits. Existe-t-il des produits propos´es non r´ealisables par la plate-forme de conception ? evEV M ∈ JEV M K est r´ealisable s’il poss`ede un lien de r´ealisation, soit evEV M ∈ JIV M K|Eevm.
❼ V3 : Identit´e de r´ealisation. Existe-t-il une mˆeme combinaison de l’IVM r´ealisant plusieurs combinaisons de l’EVM ? Il est exprim´e comme suit, (eve1∪ evi) ∈ JIV M K ∧ (eve2∪ evi) ∈ JIV M K ∧ (eve16= eve2).
❼ V4 : Commonalit´e de la ligne de produits. Existe-t-il de la commonalit´e entre les produits r´ealisables par la plate-forme de conception (TJIV M K|Eevm\TJEV M K) ?
❼ V5 : Pr´esence d’´el´ements variables fantˆomes. Existe-t-il des ´el´ements non r´ealis´es et non satisfiables ? (EEV M \SJIV M K|Eevm.
❼ V6 : Multiplicit´e de r´ealisation. Existe-t-il plusieurs combinaisons de l’IVM r´ealisant une mˆeme combinaison de l’EVM ? Cet ´etat de fait n’est pas `a proscrire, il peut r´esulter du fait que du non fonctionnel n’apparait pas forcement dans l’EVM, relatif au coˆut, `a la performance, `a la s´ecurit´e, etc. Il est exprim´e comme suit, (eve∪ evi1) ∈ JIV M K ∧ (eve∪ evi1) ∈ JIV M K ∧ (evi16= evi2).
9.3 En r´esum´e
L’op´erationnalisation de PLiMoS a trait `a ses deux facettes, sp´ecification et sp´ecialisation. Dans le premier cas, il s’agit de mettre en œuvre la m´ecanique de d´efinition du langage dans un environnement MOF, ce qui se traduit par la r´ealisation de transformations de mod`eles. Dans le second cas, l’op´erationnalisation touche aux divers usages du langage relationnel final, `a savoir : l’´edition et la visualisation, la fusion, la v´erification de coh´erence.
Troisi`eme partie
´
Evolution incr´ementale de la
mod´elisation des lignes de produits
“It is not the most intellectual of the species that survives ; it is not the strongest that survives ; but the species that survives is the one that is able to adapt to and to adjust best to the changing environment in which it finds itself . . . so says Charles Darwin in his “Origin of Species”[. . .]”
— Megginson, L. C., Key to Competition is Management, 1964
10 Consid´erations architecturales et pr´ecision du p´erim`etre de la LdP
10.1 Une architecture de ligne de produits ouverte . . . 140