Reconfiguration dynamique
3.3 Le projet DANSE
3.3.4 Phase d’analyse de l’architecture
Les objectifs de la phase d’analyse sont principalement de prendre en compte la ca-ract´eristique de d´eveloppement ´evolutionnaire du SdS. L’approche se fait par simulation de mod`eles. L’architecture est, en premier, transform´ee en un mod`ele ex´ecutable par l’outil de model-checking statistique PLASMA (Jegourel et al., 2012). L’architecte d´ecrit une boucle de contrˆole qui g`ere l’ex´ecution du mod`ele en utilisant le formalisme des grammaires de graphe (K¨onig, 2014), c’est-`a-dire que l’architecte donne un ensemble de r`egles qui indiquent, pour chaque ´ev´enement, une transformation du mod`ele de l’archi-tecture, vu comme un graphe. Ces r`egles sont d´ecrites par des st´er´eotypes qui annotent les ´ev´enements dans la vue SV-4, le d´etail est donn´e dans le rapport (Etzien et al., 2014). Le model-checking statistique est une technique pour r´esoudre le probl`eme du passage `
a l’´echelle. Plutˆot qu’une exploration exhaustive de l’espace des ´etats, comme cela est r´ealis´e par les approches traditionnelles de model-checking, les r`egles indiquent la distri-bution (au sens de la statistique) des variables : une distridistri-bution uniforme, normale ou quelconque. La loi de distribution ainsi indiqu´ee donne la probabilit´e pour chaque va-leur de la variable concern´ee, et est utilis´ee pour g´en´erer et s´electionner al´eatoirement les chemins d’ex´ecution les plus probablement repr´esentatifs.
3.4. Synth`ese
Table 3.9: Mise en correspondance des vues de COMPASS et DANSE
```` ```` ```` ``` COMPASS DANSE
ov-1 ov-2 ov-5
vue-1-1 x vue-1-2 x vue-1-7 x vue-1-8 x ```` ```` ```` ``` COMPASS DANSE sv-1 sv-4 vue-2–2 x vue-2–3 x vue-2–5 x
3.4 Synth`ese
Ce chapitre confirme l’importance des architectures dans le processus de d´eveloppement des SdSs. Les architectures sont les artefacts centraux des phases d’analyse des SdSs. Nous voyons que les principales difficult´es sont la d´efinition des abstractions et des comporte-ments ainsi que les principes architecturaux requis pour la r´ealisation du SdS.
Nous avons montr´e les principales caract´eristiques des langages de mod´elisation ar-chitecturale et leur utilit´e. SysML et UPDM apportent des ´el´ements d’expression qui facilitent la description `a des niveaux d’abstraction de nature diff´erente d’un syst`eme. La description des composants avec la notion de bloc permet de faire apparaˆıtre les parties ind´ependantes d’un syst`eme. Les possibilit´es de description des interconnexions entre ces parties ind´ependantes et de natures diff´erentes enrichissent ´egalement l’expressivit´e du langage et les m´ecanismes de tra¸cabilit´e. UPDM apporte, en particulier, un ensemble de concepts qui permet une s´eparation dans le mod`ele des parties qui concernent les niveaux SdS et CS. Le framework de mod´elisation de COMPASS est couvert par le framework UPDM comme le montre le tableau 3.9. Le tableau montre la correspondance des vues des frameworks de mod´elisation COMPASS et DANSE. Il nous donne une indication sur la pertinence de UPDM pour la mod´elisation des SdSs.
Le framework UPDM est utilis´e comme description semi-formelle de l’architecture. La vue op´erationnelle permet de mod´eliser les principales abstractions et comportements requis `a la r´ealisation du SdS. Le projet DANSE a d´evelopp´e des patrons architecturaux pour assister la phase d’identification. Le projet COMPASS r´eutilise les mˆemes concepts mais ajoute la notion d’environnement aux ´el´ements de mod´elisation. Cela permet de faire apparaˆıtre clairement les fronti`eres du SdS. Ceci est utile dans les phases de r´eutilisation des mod`eles architecturaux.
Cependant, les travaux de DANSE et COMPASS montrent que ces mod`eles architec-turaux ne sont pas suffisants. En effet, nous avons vu qu’ils s’appuient sur des langages
3.4. Synth`ese
formels pour les phases de g´en´eration automatique et d’analyse de l’architecture. Les langages formels permettent de capturer, en particulier, la notion de contrat. Le choix d’une approche par contrat repose sur la caract´eristique d’ind´ependance des syst`emes. Il convient donc de v´erifier d’une part que les sp´ecifications d’un syst`eme sont bien compa-tibles avec le SdS, et d’autre part que la composition les contrats est robuste. Les contrats permettent ´egalement de prendre en compte la contrainte que les CSs ne sont pas connus `
a l’avance. Les architectures abstraites ne peuvent donc ˆetre que partiellement v´erifi´ees avant de connaˆıtre concr`etement les CSs.
Concernant le processus de d´eveloppement, les deux projets montrent qu’il est int´egr´e dans un atelier de d´eveloppement qui met en relation les diff´erents outils d´evelopp´es dans les projets. Celui de COMPASS est bas´e sur Artisan Studio. Il connecte un environnement de mod´elisation bas´e sur le framework d´evelopp´e avec des outils de transformation de mod`eles et de simulation. Les mod`eles en entr´ee sont donc des mod`eles du framework et la sortie sont des mod`eles CML (COMPASS Modelling Language). Celui de DANSE fonctionne sur le mˆeme principe. L’environnement de mod´elisation est bas´e sur Rhapsody Architecture. Les outils mis en œuvre sont des outils de simulation avec PLASMA.
Le processus de d´eveloppement montre que les ateliers se basent sur des descriptions partielles de l’architecture. Les processus de raffinement des architectures sont pr´ec´ed´es des phases d’analyse qui garantissent un certain niveau de certitude sur l’impl´ementation du SdS. Par rapport `a d’autres types de processus comme RUP (Rational Unified Process), les mod`eles en cascade ou le cycle en V, les phases de v´erification sont r´ealis´ees d`es la conception et non plus apr`es la phase d’impl´ementation.
Du point de vue de la reconfiguration dynamique, les phases de g´en´eration d’architecture peuvent ˆetre vues comme des reconfigurations puisqu’elles peuvent red´efinir des configu-rations. Cependant les reconfigurations sont statiques et non dynamiques. En effet, pour prendre en compte la reconfiguration dynamique il faudrait que le g´en´erateur d´ecrivent diff´erents ´etats de l’architecture ainsi que les transitions qui permettent de passer d’un ´
etat `a l’autre.
Par cons´equent, nous envisageons de d´evelopper notre propre cas d’´etude pour ´etudier notre proposition pour la reconfiguration dynamique des architectures de SdS. Une pre-mi`ere contribution sera donc la mod´elisation de l’architecture du SdS du cas d’´etude comportant des cas d’´evolution. Une difficult´e dans la mod´elisation d’un nouveau cas d’´etude est la v´erification de son exactitude. Dans les cas d’´etude d´evelopp´es que nous avons ´etudi´es, l’exactitude n’est pas prise en compte dans le d´eveloppement. Nous en-visageons aussi d’int´egrer une approche de v´erification des reconfigurations d´evelopp´ees qu’il faudra prendre en compte dans les mod`eles architecturaux et processus utilis´es. Le processus de d´eveloppement du mod`ele architectural devrait reprendre les caract´eristiques communes aux processus de d´eveloppement des deux projets ´etudi´es, `a savoir, une phase de mod´elisation de l’architecture logique et physique, et une phase de v´erification de l’architecture logique devrait ˆetre ajout´ee.
3.4. Synth`ese
Les mod`eles d´evelopp´es devraient reprendre des ´el´ements de UPDM. Dans la phase de mod´elisation de l’architecture logique, nous envisageons d’utiliser des vues du point de vue op´erationnel. Par rapport `a DANSE, les choix des vues et des diagrammes doivent ˆ
etre diff´erents pour faire mieux apparaˆıtre les objectifs d’interaction. Ensuite, le point de vue syst`eme de UPDM permet de capturer les d´ecisions de conception, notamment en termes d’interfaces. Comme les deux projets COMPASS et DANSE, nous envisageons des approches plus pr´ecises. Notre objectif est de mod´eliser les aspects statiques pour minimiser l’effort de mod´elisation en int´egrant les aspects dynamiques pour ajouter de la pr´ecision aux architectures. Pour v´erifier les reconfigurations d´evelopp´ees, nous utiliserons des approches par simulation, les mod`eles int`egreront des sc´enarios d’ex´ecution.
Par ailleurs, les approches de reconfiguration automatique comme la g´en´eration d’ar-chitectures est limit´ee comme le montre d’autres travaux (Guessi et al., 2016). Les temps de r´esolution peuvent ˆetre trop longs pour esp´erer g´en´erer automatiquement de nouvelles architectures pendant l’ex´ecution. Une autre limite concernent les outils d’analyse qui reposent sur des mod`eles dynamiques, ce qui limite fortement les b´en´efices des outils lorsqu’ils sont g´en´er´es par des approches manuelles.