12.2 Mod´elisation avec les Relationships `a une granularit´e plus fine
En s’int´eressant `a la mod´elisation de l’infrastructure de l’espace de mod´elisation avec une gra-nularit´e fine, le langage PLiMoS vise `a faciliter la gestion des relations entre artefacts durant la phase d’ing´enierie du Domaine.
Les relations sont trait´ees telles des artefacts de premi`ere importance et ´elicit´ees dans le processus de ligne de produits ; certaines relations sont explicites et r´eifi´ees, d’autres sont inf´er´ees. Les relations de bas niveau sont d´efinies comme des associations s´emantiques entre artefacts de mod´elisation (entit´es, mod`eles totalitaires ou fragmentaires).
La figure12.2pr´esente une repr´esentation cartographique de la teneur des relationships mises en œuvre. Une relation de collaboration revˆet plusieurs caract´eristiques, et il est important de r´epondre aux questions telles que : quels sont les acteurs participant `a cette collaboration ? Quelle est l’importance de cette collaboration pour les acteurs qui y participent ? Ces questions trouvent r´eponse dans la mod´elisation intentionnelle pr´esent´ee en section pr´ec´edente. Les questions “com-ment s’organise cette collaboration ?” et, “qu’est-ce qui est manipul´e, ´echang´e, partag´e par cette collaboration ?” font partie des r´eponses `a apporter par la structure de relationships. Le gra-phique renseigne sur (i) l’´etendue de la collaboration (inter-LdP, inter-mod`eles, intra-mod`ele), (ii) la nature de celle-ci (mise `a disposition - implication, ´echange - co-implication, ou partage - structure complexe), (iii) sa complexit´e en terme d’action `a r´ealiser (induction, modification), ainsi que (iv) son moment d’action (conception, ex´ecution, ´evolution).
Figure12.2: Contour des relationships n´ecessaires
La section fournie une description de l’infrastructure cˆot´e sp´ecialisation, pour des d´etails sur le mod`ele de sp´ecification `a l’origine des mod`eles, voir l’annexeC, sectionC.2.
12.2.1 L’infrastructure ´etablie sur la base des relations concr`etes
L’intention d’obtention d’un produit s’accompagne, dans le cadre d’une ligne de produits de son objectif de d´erivation d’un produit, se traduisant par une mise en relation op´erationnelle des ´el´ements de mod`eles. Les d´ependances et relations entre artefacts de mod´elisation sont explicit´ees et r´eifi´ees dans un m´etamod`ele pour composer l’ensemble des relations grain-fin de la mod´elisation de l’espace de mod´elisation par le langage PLiMoS. Mod´eliser des relations statiques aide `a la connexion de nombreuses activit´es et outils comme des syst`emes de gestion de version, de gestion de coh´erence, etc. (cf. chapitre 9), un pr´e-requis `a la maintenance et l’´evolution de la ligne de produits.
Le sous-ensemble PLiMoSspecialisationr´ealise un chevauchement avec le langage de variabilit´e et ceux des core assets (cf. fig.6.8). De plus, l’approche utilise des mod`eles de features comme mod`eles de variabilit´e. Le langage PLiMoSspecialisation sp´ecifique `a l’espace de mod´elisation du cas Thales est consid´er´e comme ´etant constitu´e d’un ensemble de relationships intra-mod`ele de features (F M R), d’un ensemble de relationships inter-mod`eles (IM R) et d’un ensemble de relationships d´eriv´ees (DR) (pr´esent´e dans la section suivante).
P LiM oSspecialisationT hales, hF MR, IMR, DRi Relations dans les mod`eles de variabilit´e
L’approche utilise des mod`eles de features comme mod`eles de variabilit´e, typ´es en mod`eles de contexte, externe, et interne. La s´emantique des mod`eles de features utilis´es figure dans la section introductive de ce document (section 3.3, page 44). Dans la suite de la pr´esenta-tion, les ensembles de features se distinguent par l’apposition en indice du type de mod`ele concern´e, c.-`a-d. {CVM,EVM,IVM}, par ex. FCV M pour un ensemble de features de CVM (FCV M ∩ FEV M = ∅, FCV M ∩ FIV M = ∅, FEV M∩ FIV M = ∅).
Un mod`ele de relation de FM (F M R) est d´efini comme un 4-uplet hE, IDC, CIDC, EDCi : ❼ Consist-of (χ): sont des relations de co-implication, binaires (1-to-1), homog`enes, non-d´eriv´ees. Ces relations basiques de hi´erarchisation sont raffin´ees par une intention donn´ee, soit de d´ecomposition part-of, soit de g´en´eralisation generalization, et E ⊆ F × {generali-zation, decomposition}×F ;
❼ Implication (ι): ces relations d’expression de n´ecessit´e sont des contraintes de configuration non-sym´etriques mais transitives, IDC ⊆ F × F , IDC ⊆ CE ;
❼ CoImplication (I) : ce sont des contraintes sym´etriques d’implication, CIDC ⊆ F × F , CIDC ⊆ CE ; elles sont binaires (1-to-1), homog`enes, concr`etes, comme les pr´ec´edentes ; Cette relation peut ˆetre n´ecessaire dans les mod`eles techniques exprimant la variabilit´e de la solution, o`u une premi`ere d´ecomposition hi´erarchique n’est pas suffisante. Par exemple, les mod`eles de features avec une utilisation de features composites et abstraits utiles `a une d´ecomposition proche de la structure de la solution (pour des convenances de lecture et compr´ehension) peuvent impliquer un besoin de contraintes transverses bidirectionnelles ; ❼ Exclusion (η): d´ecrivent des relations sym´etriques mais non transitives de mutuelle
exclu-sion, EDC ⊆ F × F , EDC ⊆ CE ; ces relations sont de type 1-to-1, homog`enes, non d´eriv´ees ;
Manifestement, E ∩ IDC ∩ CIDC ∩ EDC = ∅. Les relations de d´ependances du mod`ele de features (ι, I, η), peuvent dans certains processus ˆetre associ´ees `a d’autres interpr´etations s´eman-tiques pour un besoin pr´ecis, par ex. en fonction des usages, comme base pour des activit´es de d´erivation ou de v´erification de coh´erence. Notamment, il est possible de distinguer des relations de d´ependance li´ees aux op´erateurs And, Or, Xor et Optional et aux variants.
Relations entre les mod`eles
Le sous ensemble PLiMoSspecialisation est ´egalement concern´e par l’expression des relationships inter-mod`eles de l’espace de mod´elisation. Un mod`ele irm de relationships inter-mod`eles (IM R) est un 3-uplet hSR, IR, RRi tel que :
❼ EIR ⊆ P(CCV M) × P(FEV M∪ FIV M)) × {implication, exclusion} est un ensemble fini de relations d’Environment-Induction (σ). Les variants externes sont induits par ceux de l’en-vironnement, et σ sp´ecialise la relation intentionnelle µ#16. Afin d’illustrer cette relation, consid´erons trois ´el´ements features du mod`ele de variabilit´e du contexte, FCV M 1, FCV M 2, et FCV M 3, et FEV M 1, FEV M 2, deux ´el´ements features du mod`ele de variabilit´e externe.
12.2. Mod´elisation avec les Relationships `a une granularit´e plus fine
({FCV M 1}, {FEV M 1, FEV M 2}, ι) ∈ EIR repr´esente le fait que l’´el´ement FCV M 1 implique FEV M 1et FEV M 2. De mani`ere similaire, prenons l’exemple ({FCV M 2, FCV M 3}, {FEV M 2}, η) ∈ EIR qui lui indique que la conjonction des ´el´ements FCV M 2 et FCV M 3 exclut FEV M 2; ❼ SR ⊆ P(CEV M) × P(FIV M) est un ensemble fini de relations de Satisfaction (ζ). Les
variants externes “marketing” sont satisfaits par des variants techniques internes des IVMs : les mod`eles internes satisfont les exigences et les besoins des mod`eles externes. La relation ζ est un raffinement de la relation intentionnelle µ#17;
❼ ER ⊆ (FIV M L× FIV M L) ∪ (FIV M P× FIV M P) est un ensemble fini de relations Identity (Ξ), avec FIV M Lle feature d’un mod`ele IVM `a un niveau d’abstraction logique (FIV M P
pour le niveau physique). La relation d’identit´e entre deux features signifie une similarit´e en respect de la variabilit´e et des concepts associ´es ; par cons´equent, les core assets associ´es, si diff´erents, doivent ˆetre totalement disjoints. La relation Identity est utilis´ee pour s´eparer des pr´eoccupations diverses `a un mˆeme niveau d’abstraction (horizontale). Ξ sp´ecialise la relation µ#19;
❼ SiR ⊆ VIV M L× VIV M P encode l’ensemble des relations d’´equivalence Equivalence (ξ). Un lien d’´equivalence entre deux features signifie une similarit´e en regard de la variabilit´e mais pas des concepts. L’´equivalence est utilis´ee pour s´eparer des pr´eoccupations `a diff´e-rents niveaux d’abstraction (verticale) ; les core assets associ´es doivent ˆetre distincts et `a diff´erents niveaux d’abstraction. ξ sp´ecialise l’intention µ#18;
❼ RR ⊆ (CEV M × CA) ∪ (CIV M × CA) est l’ensemble des relations de Realization (P). Un variant peut ˆetre r´ealis´e par une entit´e de core assets(CA). Il n’y a pas de relations n-aires vers les core assets, cependant il faut garder en m´emoire que le concept de CA repr´esente un ensemble de core assets. P sp´ecialise l’intention µ#15;
❼ ReR ⊆ (CCA × LCA) ∪ (LCA × P CA) est l’ensemble des relations de raffinement (Refine-ment - ρ). La relation d´ecrit le raffine(Refine-ment technologique entre deux niveaux d’abstraction dans le processus mod´elis´e de d´eveloppement (elle sp´ecialise les relations intentionnelles µ#6et µ#7).
La figure12.3illustre le positionnement de certaines relations, et la figure12.4pr´esente un extrait du m´etamod`ele de sp´ecialisation g´en´er´e.
Figure12.3: Repr´esentation sch´ematique de relationships entre ´el´ements de mod`eles de l’espace de mod´elisation
Figure12.4: Extrait du m´etamod`ele PLiMoS de sp´ecialisation - relationships principales
12.2.2 L’infrastructure ´etablie sur la base des relations d´eriv´ees
Cette section d´ecrit un sous-ensemble de relations d´eriv´ees, et donc inf´er´ees tout au long du processus. L’int´erˆet d’expliciter des relations ne se limite pas aux relations structurelles comme pr´esent´ees dans la section pr´ec´edente, mais s’´etend ´egalement aux relations d´eriv´ees, notamment pour des besoins de visualisation, v´erification de coh´erence, et d´erivation de produits.
Des relationships nouvellement d´eriv´ees peuvent ˆetre inf´er´ees en composant des relationships structurelles, mettant en lumi`ere un ensemble de connaissances jusque l`a implicites, et permettant de mettre en exergue des incoh´erences entre mod`eles non ´evidentes. L’inf´erence de ces relations aide `a renforcer la coh´erence s´emantique entre les ensembles de mod`eles reli´es. Ces relations sont r´eifi´ees dans un sous-paquetage du m´etamod`ele et introduites comme d´eriv´ees, volatiles et transient.
Les relationships intra-mod`ele des mod`eles de features ont des impacts sur les autres mod`eles de l’espace de mod´elisation. La figure12.5(a) et (b) repr´esente le fait que les relations χ avec des op´erateurs entre C (un feature compos´e) et Si(les sous-features, i identifiant les features distincts par un indice, M ⊆ {1, . . . , n}) correspondent `a des relations de co-implication ou d’exclusion. “And-χ” traduit une co-implication (I) entre les sous-features, “Xor-χ” relie les sous-features par des relations d’exclusion (η), et “Or-χ” n’induit aucune relation particuli`ere de d´ependance entre les sous-features.
Concernant l’EVM et les IVMs, des contraintes de conception peuvent apparaˆıtre dans la solution, qui ne sont a priori pas corr´el´ees avec le mod`ele externe. Des relations “Design-ι”, “Design-I”, “Design-η”, sont ainsi d´eriv´ees des contraintes des mod`eles de variabilit´e internes, et
transpos´ees dans la vue externe.
En ´etendant la description aux d´ependances inter-mod`eles, (c) montre une transposition d’une relation Implication depuis le domaine des core assets en d´eveloppement, d´efinissant par cons´e-quent une d´ependance d’implication “Core-ι”. De mani`ere similaire sont sp´ecifi´ees les relations
12.2. Mod´elisation avec les Relationships `a une granularit´e plus fine
Figure12.5: Des exemples de relations d´eriv´ees
“Core-I” et “Core-η”. Une connaissance de l’algorithme de composition des core assets (dans le cas d’une variabilit´e positive) rend possible le d´eroulement d’analyse sur la base des core assets et permet l’inf´erence de contraintes dans les IVMs. Les relations “core” sont d´eriv´ees et montr´ees dans des vues sp´ecifiques, et, si confirm´ees par l’utilisateur, peuvent ˆetre transform´ees en des relations intra-mod`eles de variabilit´e interne.
❼ DCE ⊆ FEV M× DGCT × FEV M est l’ensemble des contraintes de conception, avec Design Graphical Constraint Type ´etant {ι,I, η}, et DCE ∩ CEEV M = ∅ ;
❼ CCE ⊆ FIV M × CGCT × FIV M est l’ensemble des relations de contraintes “core”, avec CGCT - Core Graphical Constraint Type - qui est {ι,I,η}, et CCE ∩ CEIV M = ∅ ; D’autre part, la v´erification de coh´erence de mod`eles de features induit l’´emergence de rela-tions “Conflict”. Cette relation est sym´etrique, non r´eflexive et non transitive.
L’´elicitation syst´ematique des relations d´eriv´ees, des absences de liens permettent de statuer sur la non satisfaction de certains features, ou de core assetss non employ´es (non connect´es `a aucun feature), et ceci grˆace `a des techniques externes de computation (par ex. solveurs SAT).
Un autre processus n´ecessite des relations d´eriv´ees, la d´erivation de produits de l’ing´enierie de l’application. La figure 12.5(d) montre une relation sym´etrique “compose-with” qui est inf´er´ee `a partir de relations Implication et Resolution (“ι”s et “P”s). En cons´equence, la sp´ecification de configuration d’un produit est d´efinie par l’ensemble des relations Implication & CoImplica-tion, et la sp´ecification de d´erivation de produits par un ensemble de relations “compose-with” (specialisant µ#21).
12.2.3 Une synth`ese et classification des relationships utilis´ees
Une relation peut ˆetre caract´eris´ee par le crit`ere du niveau d’abstraction. Ce crit`ere distingue les relations verticales (raffinement selon Anquetil et al. [AKM+10]) si les relations sont transverses aux niveaux, des relations horizontales (similarit´e pour Anquetil et al. [AKM+10]) si elles se limitent `a un niveau donn´e. Un autre crit`ere concerne la nature homog`ene ou h´et´erog`ene des relations. Homog`ene entre les mod`eles de variabilit´e, ou dans les core assets, ou h´et´erog`ene entre les deux types de mod`eles (correspondant `a la dimension de variabilit´e de [AKM+10]).
Concernant les relations d´eriv´ees, dont le m´etamod`ele n’est pas repr´esent´e ici, c.-`a-d. les relations d´eriv´ees :
❼ les relations homog`enes horizontales d´eriv´ees sont : “Design-ι”, “Design-I”, “Design-η”, “Core-ι”, “Core-I” and “Core-η”;
❼ La relation “Compose-with” est homog`ene mais ne peut ˆetre class´ee avec le crit`ere verti-cal/horizontal.