Reconfiguration dynamique
2.4 Synth` ese
composants de l’application reconfigur´ee, afin de demander, par exemple, `a ce que certains composants suspendent leur activit´e.
Oliveira and Barbosa (2015) utilisent Reo. Il s’agit d’une notation plus souple que CSP (Bonsangue et al., 2012), mais l’approche ne fournit que des op´erations architec-turales qui manipulent les liaisons. Les reconfigurations document´ees par cette approche ne peuvent donc pas ajouter ni supprimer de composants, mais seulement modifier la topologie des liaisons. Pour Oliveira and Barbosa (2015), il n’est pas possible de d´ecrire comment la reconfiguration se coordonne avec l’ex´ecution du syst`eme reconfigur´e.
Ces approches formelles ont pour avantage d’ˆetre suffisamment pr´ecises pour permettre la v´erification de la documentation. Allen et al. (1998) expliquent par exemple comment v´erifier, `a l’aide d’un model checker, que la reconfiguration document´ee `a l’aide de leur approche ne conduit pas `a un interblocage lorsqu’elle est combin´ee avec l’application. Mais les approches formelles souffrent d’ˆetre g´en´eralement de trop bas niveau pour permettre une r´eutilisation effective.
Plutˆot que des notations formelles, Gomaa and Hussein (2004) propose une approche de conception de reconfiguration r´eutilisable et de fa¸con syst`ematique reposant sur le langage semi-formel UML. Gomaa and Hussein (2004) proposent un notion de patron de reconfigu-ration, qui mod´elisent comment des composants collaborent pour ´evoluer vers une nouvelle configuration architecturale. Pour ˆetre r´eutilable, le patron est document´e par un contexte d’utilisation, qui prend la forme d’un diagramme de collaboration d´ecrivant, comme son nom l’indique, la nature de la collaboration entre les composants. Des diagrammes d’´etats pr´esentent d’une part le comportement nominal des composants, et d’autre part les tran-sitions pour faire passer le composant concern´e vers un ´etat passif puis quiescent. Cette description de l’intention, notamment au travers du contexte, facilite la r´eutilisation de la solution repr´esent´ee par le patron. Cependant, l’espace de conception des reconfigurations est tr`es limit´e car Gomaa and Hussein (2004) ne se concentrent que sur des contextes de reconfiguration simplifi´es, et ils font l’hypoth`ese que les composants disposent d´ej`a des m´ecanismes de reconfiguration n´ecessaires.
Dorn and Taylor (2015) d´efinissent, pour aider l’architecte pendant la phase de r´eflexion, un canevas d’analyse concernant la capacit´e `a reconfigurer une architecture selon le style architectural adopt´e. Ce canevas traite de l’impact de la reconfiguration sur le contexte d’ex´ecution, des moyens d’observation requis, du comportement de la reconfiguration et de la fa¸con de changer l’´etat du syst`eme. Le canevas donne des indications concernant des aspects des reconfigurations qui m´eritent d’ˆetre document´es.
2.4 Synth`ese
L’objectif de cette th`ese est de fournir une approche pour la conception des reconfi-gurations dans le contexte des SdS. Nous avons vu que les frameworks composant nous fournissent une base de r´eflexion, mˆeme si des limites sont `a poser. En effet, par rapport aux solutions disponibles pour la reconfiguration des syst`emes distribu´es, les approches existantes consid`erent que tous les composants disposent des mˆemes m´ecanismes de
recon-2.4. Synth`ese
figuration. Or, du fait de l’ind´ependance manag´eriale des SdSs, les composants d´eploy´es risquent de ne pas avoir les mˆemes m´ecanismes de reconfiguration disponibles. Comme solution, nous envisageons une approche de conception des reconfigurations mettant l’ar-chitecte `a contribution. Les outils principaux de cette solution sont des patrons de recon-figuration et un processus de conception qui permettent d’aboutir `a une reconfiguration de l’architecture.
L’´etat de l’art met en avant la variabilit´e des choix de conception des reconfigurations. Par exemple, pour atteindre la quiescence des composants affect´es par la reconfigura-tion, l’architecte peut d´ecider d’une approche interventionniste, ou au contraire utiliser sa connaissance de l’application pour attendre que celle-ci atteigne d’elle-mˆeme le bon ´etat pour r´ealiser la reconfiguration. Pour ˆetre r´eutilisable, il s’agit de documenter les choix que r´ealise l’architecte, l’intention, le contexte qui est susceptible d’invalider ces choix, la probl´ematique trait´ee et les forces de ces d´ecisions. Nous avons vu les limites des langages formels pour documenter des reconfigurations. Ce type de documentation est trop bas niveau pour ˆetre r´eutilisable. Les langages semi-formels semblent plus adapt´es `a notre vision des patrons de reconfiguration. Ils sont compl´ementaires aux langages formels. Ils permettent une meilleure documentation de l’intention et du contexte d’une reconfigura-tion.
Comme nous le verrons en section 6.1, le contexte inclut les choix de conception archi-tecturale, ainsi que le type de gouvernance du syst`eme de syst`emes. Selon ce contexte, certaines op´erations de reconfiguration ou certains algorithmes peuvent ne pas ˆetre pos-sibles. C’est par exemple le cas de l’algorithme qui d´etermine quels composants rendre passifs pour rendre certains composants quiescents : il s’agit d’un algorithme centralis´e, seulement adapt´e au contexte d’un syst`eme de syst`emes ayant une gouvernance de type dirig´e. Les solutions existantes ne prennent pas en compte les divers types de gouvernances ni les choix de conception qui ont ´et´e r´ealis´es dans l’architecture.
Chapitre 3
Processus de mod´elisation des
syst`emes de syst`emes
L’architecture est l’artefact central des processus de d´eveloppement. Une architecture, comme le d´efinissent Medvidovic and Taylor (2010), d´ecrit l’organisation fondamentale des composants d’un syst`eme, ainsi que les relations entre ces composants et avec l’envi-ronnement. L’architecture documente les principes suivis pour concevoir le syst`eme. Elle assiste les phases de conception, impl´ementation, test, analyse, maintenance et ´evolution. Ce chapitre est consacr´e aux processus de d´eveloppement des syst`emes de syst`emes, aux langages utilis´es et aux outils mis en œuvre. L’objectif est de maˆıtriser les supports de mod´elisation et de faciliter le positionnement de nos travaux par rapport `a la reconfi-guration dynamique. Dans un premier temps, dans la section 3.1, nous nous int´eressons aux pratiques de mod´elisation des architectures de syst`emes de syst`emes, en rappelant au pr´ealable quelques d´efinitions des concepts de base des architectures : mod`ele architec-tural, style architecarchitec-tural, vue et point de vue. Parmi les pratiques de mod´elisation nous ciblons les deux principaux langages disponibles pour assister le processus de mod´elisation des Syst`emes de syst`emes (SdSs). Le langage de mod´elisation SysML (System Modeling Language) (Friedenthal et al., 2014) est d´edi´e aux syst`emes complexes et constitue un pr´eliminaire indispensable `a la mod´elisation des syst`emes de syst`emes. En effet, SysML d´efinit les concepts essentiels `a la description d’un syst`eme faisant intervenir des consti-tuants provenant de plusieurs corps d’ing´enierie. Le second langage ´etudi´e est UPDM (Unified Profile for DoDAF and MODAF) (OMG, 2013). Il s’agit d’un framework ar-chitectural pour la conception de syst`emes de syst`emes, de syst`emes d’entreprises et de syst`emes complexes. En unifiant les pr´ec´edents frameworks que sont DODAF, MODAF et NAF, UPDM int`egre les vues qui sont pertinentes dans un processus de conception pour de tels syst`emes. Les sections 3.2 et 3.3, quant `a elles, ´etudient deux projets eu-rop´eens majeurs dans le processus de d´eveloppement des SdSs (syst`emes de syst`emes) : COMPASS (Comprehensive Modelling for Advanced Systems of Systems) (Coleman et al., 2012) et DANSE (Designing for Adaptability and evolutioN in System of systems Engi-neering) (Shani et al., 2015). Nous y verrons les frameworks de mod´elisation mis en œuvre en ´etudiant les points de vue d´evelopp´es au regard des processus de d´eveloppement et ou-tils utilis´es. Ces enseignements alimenteront la section 3.4 qui d´efinira les orientations de strat´egie de mod´elisation en termes de langage, processus et outil choisis dans la suite de
3.1. Pratiques de mod´elisation des architectures de syst`emes de syst`emes
la th`ese.