La complexit´e additionnelle apport´ee par la gestion des variants peut alourdir la tˆache des archi-tectes logiciels qui doivent aboutir `a une solution logique pour une famille donn´ee. Une gestion propre de la variabilit´e est ´egalement importante pour le succ`es de l’architecture, car la variabilit´e permet `a l’architecture d’ˆetre instrument´ee de mani`ere `a favoriser l’´evolution. Il est donc indis-pensable d’organiser l’espace de mod´elisation de la ligne de produits autour d’une plate-forme conceptuelle bas´ee sur le patron d’architecture.
Le cadre de d´eveloppement des applications suit toujours la m´ethodologie pr´esent´ee dans [Voi08]. Les activit´es de mod´elisation sous-tendent les d´eveloppements syst`eme et logiciel pour les exigences, la conception conceptuelle et d´etaill´ee et l’impl´ementation. Les niveaux d’abstraction d´efinis sont pour rappel : Contexte, Logique et Physique.
12.3.1 La plate-forme conceptuelle
Le patron d’architecture pr´esent´e pr´ec´edemment introduit un ensemble de conventions et r`egles de par ses couches et partitions, permettant d’organiser l’architecture par des modules coh´esifs. La figure12.6illustre la situation de la plate-forme conceptuelle dans son environnement.
Figure 12.6: Plate-forme conceptuelle pour les Lignes de Produits.
Le patron organise la variabilit´e et s´epare les pr´eoccupations m´etier de celles d’interface. Cons´equemment, les points de variation de la ligne de produit sont distingu´es par leur degr´e de stabilit´e. Les instables, induits par l’environnement, sont restreints, autant que faire se peut, dans les couches d’interface. `A l’inverse, les couches m´etier (Core expertise) contiennent des points de variations et variants stables.
La figure 12.7repr´esente la variabilit´e au niveau Logique d’un cas d’exemple simplifi´e afin d’illustrer cette section (avec des st´er´eotypes “variation” et “variant”, des contraintes d’inclusion et d’exclusion ; le profil manipul´e est inspir´e de [ZHJ03]). Sa taille permet de clarifier les couches ABCDE et le type de variabilit´e pr´esent dans les lignes de produits de Thales. L’exemple ne permet pas par contre d’illustrer les partitions. Les syst`emes de la famille de contrˆole antia´erien re¸coivent en entr´ee des donn´ees de capteurs (g´en´eralement des radars, la figure12.7en repr´esente deux : Radar1 qui envoie vitesse et position, Radar2 qui envoie deux positions), effectuent des traitements (calcul de position et optionnellement de vitesse au besoin) et renvoient des donn´ees `
12.3. Consid´erations architecturales appliqu´ees `a l’espace de mod´elisation
cart´esiennes par exemple). La variabilit´e est limit´ee : au type de donn´ees en entr´ee (d´elivr´ees par des radars externes), au type de traitement n´ecessaire inf´erant, `a la pr´esence/absence de m´emoire interne et enfin, au type de donn´ees produites et d´elivr´ees. Notons que la variabilit´e provient, en grande partie, des acteurs externes comme dans nos applications r´eelles.
Figure12.7: Une architecture conceptuelle r´eceptacle de variabilit´e.
12.3.2 Une structuration de l’espace de mod´elisation autour de la
plate-forme
La plate-forme conceptuelle introduite dans la section pr´ec´edente renforce la structure de la ligne de produits. Cette section d´ecrit, de mani`ere globale, l’organisation de la LdP autour de cette plate-forme. L’objectif n’est ni d’expliquer l’adoption de la LdP, ni de d´ecrire son l’´evolution ; la probl´ematique de l’extraction de la variabilit´e dans des mod`eles de variabilit´e ne fait pas l’objet de ces travaux.
La figure12.8situe la plate-forme au niveau Logique (d´elimit´ee par un rectangle discontinu) et l’organisation de l’espace de mod´elisation autour de cette derni`ere. L’organisation de l’es-pace de mod´elisation refl`ete le processus IDM, avec le d´ecoupage en niveaux Contexte, Logique, et Physique), ainsi que la structure architecturale apport´ee par le patron (`a partir du niveau logique).
Au niveau Contexte, les “Use-Cases” repr´esentent des fonctionnalit´es significatives et centrales du syst`eme final. Au niveau Logique, les ´el´ements de r´eutilisation de base (“Core assets”) sont des classes ou des composants logiques et leurs relations. Enfin, au niveau Physique, les ´el´ements de base sont des composants et leurs relations. Un d´eveloppement orient´e composant n’est pas, en lui-mˆeme, suffisant pour permettre d’obtenir un mod`ele produit valide et coh´erent par d´erivation. Les modules r´eutilisables (“Core Assets”) sont caract´eris´es par leur niveau d’abstraction et leur affiliation `a un niveau d’abstraction, et donc rang´es et pr´eserv´es suivant cette classification. Les modules de niveau m´etier peuvent garder une variabilit´e interne (la r´esolution et fixation du point
Figure12.8: Vue d’ensemble : structuration de l’espace de mod´elisation.
de d´erivation se faisant lors de la d´erivation), exemple figure12.7, alors que ceux d’interface ont une granularit´e plus fine.
La figure 12.7ne repr´esente pas les relations introduites dans la partie pr´ec´edente, mais les symbolise grossi`erement. Les artefacts de mod´elisation sont reli´es entre eux par : (i) des relations d’extraction / r´ealisation de la variabilit´e (“Variability Extraction / realization”), (ii) des relations de satisfaction / r´ealisation (“Satisfaction / Realization”), (iii) des relations de sp´ecialisation (“Specification / Realization”), et (iv) des relations de raffinement “Refinement”.
Du point de vue lignes de produits, les mod`eles de variabilit´e internes r´ealisent la sp´ecifica-tion de la variabilit´e externe (li´ee au Contexte - espace du probl`eme) au travers de liens vers des modules logiques. La translation du Contexte vers le Logique correspond `a une r´esolution technologique de la variabilit´e.
La d´ecomposition des mod`eles de feature et les d´ependances de satisfaction permettent de connecter les objectifs commerciaux et la description de l’architecture et son impl´ementation. Une am´elioration de la filiation des exigences vers les d´etails logiques du syst`eme en d´eveloppement peuvent ´eviter l’apparition de d´eviations architecturales significatives.
12.3.3 L’impact du patron d’architecture dans l’espace de la variabilit´e
L’espace de mod´elisation est dans le cas pr´esent d´ecoup´e en mod`eles de variabilit´e externe et interne (sur deux niveaux d’abstraction), cf. section12.1. Dans l’exemple qui suit, les mod`eles de
12.3. Consid´erations architecturales appliqu´ees `a l’espace de mod´elisation
variabilit´e employ´es sont des mod`eles de features de type External Feature Model - EFM (pr´e-c´edemment not´e de mani`ere g´en´erique EVM) et Internal Feature Model - IFM (pr´e(pr´e-c´edemment IVM).
Toujours sur le mˆeme cas d’exemple (introduit section12.3.1), la figure12.9- a) repr´esente le mod`ele de feature externe. Ce mod`ele de caract´eristiques ne contient pas intrins`equement dans sa hi´erarchie de contraintes de conception propres `a la solution architecturale.
Figure12.9: Mod`ele de feature du cas d’exemple
Le motif architectural est abstrait dans le mod`ele de variabilit´e de la solution. `A partir du niveau Logique les mod`eles logiciels d´ependent du patron sp´ecifique pr´esent´e dans la section10.3
(soit `a partir des IFMs dans l’espace de la variabilit´e). La variabilit´e est, d`es lors, organis´ee en diagrammes avec des pr´eoccupations de d´ecoupe en couches ABCDE et partitions. Les IFMs contiennent autant de sous-ensembles d´elimit´es que de couches d’architecture. Le r´ef´erentiel cou-che/partition cˆot´e architecture est adapt´e `a la description en diagrammes de caract´eristiques et les partitions sont exprim´ees telles des contraintes de co-implication entre features.
`
A noter, dans l’exemple de la figure 12.9 - b) la pr´esence de features composites, permet-tant d’am´eliorer la compr´ehension de l’ing´enierie. Les features composites ne sont pas forc´ement abstraits (les features abstraits permettent de structurer le FM sans avoir d’impact sur l’impl´e-mentation). Les IFMs, plus techniques, sont construits par et pour les ing´enieurs, qui ont leurs pr´eoccupations en tˆete. Dans ce type de mod`ele de variabilit´e, une d´ecomposition architecturale apparaˆıt, par ex. la figure 12.9- b) d´ecrit des features Entities, Data, Controls et Boundaries qui proviennent de l’utilisation de la plate-forme conceptuelle. Remarquons que la profondeur de l’arbre diff`ere suivant les quatre principales branches : le motif d’architecture organise la
variabi-lit´e et la concentre vers les couches Controls et Boundaries. Dans la r´eavariabi-lit´e, il n’y a pas forc´ement un variant Controls correspondant `a un variant Boundaries.
12.3.4 Discussion
La m´ethodologie et le patron d’architecture propos´es, bien que r´esultant de besoins rencontr´es dans le domaine de la d´efense, ne se limitent pas `a ce dernier : le nombre de partitions et l’organisation pouvant ˆetre diff´erents en fonction des pr´eoccupations m´etier cibl´ees. De plus, dans l’absolu, il est possible d’ajuster les contraintes d´elivr´ees au niveau logique par le patron au niveau physique, c.-`a-d. qu’une adh´erence stricte au patron n’est pas obligatoire, elle doit cependant ˆetre motiv´ee et document´ee.
Une variation de l’approche plus importante est possible. La plate-forme conceptuelle ´etablie par le patron est consid´er´ee comme une caract´eristique de la ligne de produits. Par cons´equent, une autre LdP, adressant des pr´eoccupations pour un domaine distinct, mettrait en œuvre un autre patron. Par exemple le “Pipes and Filters” pourrait ˆetre une plate-forme conceptuelle pour une famille de syst`emes orient´es traitement de flux de donn´ees. La structure amen´ee par le motif d’architecture r´ev`ele la variabilit´e de l’architecture, dans le cas du patron ABCDE, au niveau des couches. Un patron d’architecture guide l’identification de la variabilit´e en regard de ces concepts manipul´es.
Le mod`ele de variabilit´e interne (dans le cas de notre exemple l’IFM) fournit des renseigne-ments, par del`a sa structuration par un patron d’architecture, sur la variabilit´e des concepts du patron. Une grande profondeur d’arbre am`ene `a s’interroger sur l’ad´equation entre le domaine et le patron s´electionn´e.
Les b´en´efices lors de la d´erivation
Dans l’approche, l’architecture de la LdP et sa variabilit´e sont organis´ees en termes de features, offrant une canalisation pas `a pas du processus de d´erivation de produits.
La dualit´e variabilit´e du probl`eme et de la solution est renforc´ee par la d´efinition de la plate-forme conceptuelle d’architecture qui met en exergue les contraintes architecturales dans l’espace de la solution et dans l’espace de mod´elisation (mod`eles de variabilit´e et de core assets). La transition entre les features “marketing” (externes) et l’impl´ementation se retrouve favoris´ee.
Alors que dans les approches traditionnelles, les d´ecisions de conception sous-jacentes se retrouvent habituellement enfouies dans les composants de r´ealisation, l’approche pr´esent´ee ici, renforc´ee par l’utilisation d’une plate-forme conceptuelle bas´ee sur l’explicitation d’un patron r´eduit la complexit´e cognitive du processus de d´erivation, et renforce la validation du produit par construction.
De plus, les mod`eles de variabilit´e internes, proches de la solution technique, incorporant des contraintes architecturales, favorisent l’obtention d’un mod`ele valide lors de la d´erivation.
En conclusion, le motif d’architecture est garant de la coh´erence de la ligne de produits (de par son int´egration `a l’ing´enierie du domaine), et permet une d´erivation d’autant plus ais´ee que contrainte et organis´ee (lors de l’ing´enierie de l’application).
La plate-forme conceptuelle et l’´evolution de la LdP
La plate-forme conceptuelle se base sur un patron d’architecture qui borne le p´erim`etre de la LdP, n´eanmoins il paraˆıt l´egitime de s’interroger sur l’avenir de l’architecture lorsque l’´evolution sort significativement des normes impos´ees par le patron.
Consid´erons AP comme ´etant l’ensemble des patrons d’architecture et A, ensemble des ar-chitectures. Consid´erons maintenant deux patrons x, y ∈ AP . Si une architecture a ∈ A est