Admin CliCours
Télécharger le fichier original (Mémoire de fin d’études)
Recon guration dynamique
Dans ce chapitre, nous allons etudier les pratiques de recon guration dynamique dans l’etat de l’art. Tout d’abord, dans la section 2.1, nous allons poser le vocabulaire et de nir ce qu’est la recon guration dynamique dans le cadre de cette these. Puis dans la section 2.2 nous allons etudier les mecanismes de recon guration de trois frameworks de composants. En e et, la recon guration dynamique a particulierement et etudiee dans ce contexte. De plus, les systemes distribues a base de composants partagent des similarites avec les systemes de systemes, malgre des di erences comme l’independance des constituants qui est speci que aux systemes de systemes. Dans la section 2.3, ceci nous permettra de mettre en lumiere les choix qui se posent lors de la conception d’une recon guration, aboutissant a motiver le besoin de documentation ainsi que les types de documentation.
De nitions
La recon guration dynamique, c’est modi er un systeme pendant qu’il est utilise. Plu-sieurs vocables ont et employes, parmi lesquels nous pouvons noter les references sui-vantes : mise a jour dynamique du logiciel (dynamic software updating) (Chen et al., 2016; Hicks and Nettles, 2005; Neamtiu et al., 2006; Baumann et al., 2005), recon gu-ration dynamique (Batista et al., 2005; Purtilo and Hofmeister, 1991; Rasche and Polze, 2005), de structure ou architecture dynamique (Magee and Kramer, 1996; Oquendo, 2004; Allen et al., 1998), evolution a l’execution (Oreizy et al., 1998; Perez et al., 2005), auto-adaptation ou adaptation dynamique (Oreizy et al., 1999; Brun et al., 2009), autonomic computing (Rutten et al., 2017; Kephart and Chess, 2003). En nous basant sur les tra-vaux existants, nous allons proposer les de nitions qui xent le cadre de cette these. Dans cette these, nous nous interessons uniquement a la recon guration dynamique. Une recon guration dynamique est corrective si elle corrige un bug ou modi e une decision architecturale. Elle est fonctionnelle si elle ajoute ou supprime une fonction au systeme, ou non-fonctionnelle si elle modi e la qualite de service du systeme. Pour realiser l’une ou l’autre de ces modi cations, une recon guration dynamique peut agir sur les composants, leurs implementations et les liaisons qui constituent l’architecture du systeme. Ainsi, a la n de la recon guration dynamique, le systeme s’execute avec la nouvelle architecture.
Développement évolutionnaire de systèmes de systèmes avec une approche par patron de reconfiguration dynamique Franck Petitdemange 2018
Recon guration dans les systemes distribues
S’agissant d’une recon guration dynamique, elle doit prendre en compte les contraintes d’execution du systeme pour se realiser harmonieusement pendant que le systeme est en cours d’execution et d’utilisation, sans perturber le systeme. Parmi les criteres habituels, une recon guration dynamique est evaluee par sa capacite a s’appliquer promptement (timeliness), avec une interruption ou degradation de service contr^olee, et sans mettre en cause le bon fonctionnement du systeme.
Dans l’etat de l’art, l’automatisation de la production d’une recon guration dynamique a et etudiee. Par exemple, Georgiadis et al. (2002); Waewsawangwong (2004) ont etudie la generation automatique d’une architecture. Plut^ot que de lister exhaustivement les objets architecturaux, l’architecture est decrite par un ensemble de contraintes architecturales a resoudre en fonction des composants disponibles dans l’environnement. Par ailleurs, d’autres auteurs parmi lesquels Arshad et al. (2005); Andre et al. (2012); da Silva and de Lemos (2011) ont experiment la generation de la sequence d’actions constituant une recon guration a l’aide d’algorithmes de plani cation. Plut^ot que d’utiliser un algorithme generaliste de plani cation, Boyer et al. (2017) de nissent un algorithme ad-hoc, realisant la m^eme t^ache pour un modele de composants speci que representatif de plusieurs frame-works usuels. A contrario et comme Buisson et al. (2015), en fournissant manuellement, par exemple, de nouvelles implementations de composants, il est possible de produire des recon gurations evitant ou limitant la degradation de service. Ceci montre qu’il peut y avoir un inter^et a laisser l’architecte intervenir dans la conception d’une recon guration dynamique. Dans ce type d’approche, l’architecte intervient dans la conception de la re-con guration, par exemple, pour decider de rel^acher certaines contraintes architecturales ou de qualite de service, ou bien, autre exemple, pour deployer des mecanismes non prevus a la conception du systeme pour mieux preserver certaines contraintes architecturales ou de qualite de service.
Dans cette these, nous adoptons resolument une approche considerant que l’architecte est implique dans la conception de la recon guration dynamique. Nous aborderons les recon gurations qui ont un impact sur les decisions architecturales des SdSs (systemes de systemes).
Recon guration dans les systemes distribues
L’objectif de cette section est d’etudier les mecanismes de recon guration dynamique. Ceux-ci ont et particulierement etudies dans le cadre des systemes distribues, et plus par-ticulierement les systemes distribues construits par assemblage de composants. En e et, ces systemes distribues evoluent dans des environnements ouverts. Ils sont donc sujets a des changements dans leur environnement, y compris apres deploiement, qui peuvent ^etre pris en compte par recon guration dynamique. Cette section s’interesse particulierement aux principaux frameworks a composants. Pour assister la recon guration dynamique, cer-tains frameworks a composants sont structures en suivant les principes des architectures re exives.
Dans cette section, nous rappellerons donc tout d’abord ce qu’est un systeme re exif Développement évolutionnaire de systèmes de systèmes avec une approche par patron de reconfiguration dynamique Franck Petitdemange 2018
Recon guration dans les systemes distribues
d’une maniere generale, section 2.2.1. Puis, en section 2.2.2, comme les systemes de systemes sont des systemes distribues, constitues de composants independants, nous al-lons presenter succinctement les frameworks de composants qui servent de support a notre etude. En section 2.2.3, nous detaillerons, pour chaque service de re exivite, sa mise en uvre par les frameworks de composants que nous etudions. En n, dans une synthese en section 2.2.4, nous conclurons par les enseignements generaux que nous tirons de cette analyse de l’etat de l’art, en vue d’identi er les services de re exivit qui pourraient ^etre o erts par un SdS et ses constituents, compte tenu des contraintes speci ques des SdS decrites a la section 1.1.
Introduction a la re exivit
Dans les langages de programmation et dans les environnements d’execution, la re exion est la capacite pour un programme a manipuler comme des donnees quelque chose repr – sentant son propre etat, durant son execution. Elle peut ^etre quali ee de re exion struc-turelle ou comportementale. La re exion est structurelle quand elle modi e la structure du programme. Par exemple, la re exion structurelle permet de modi er la de nition d’une classe ou d’ajouter de nouvelles classes dans un programme. La re exion est com-portementale quand elle modi e la semantique du langage. Par exemple, dans les travaux de Maes (1987), un meta-objet est associe a chaque objet. Ce meta-objet implemente les primitives du langage comme l’appel de methode. En remplacant ce meta-objet, il est donc possible de modi er l’implementation de ces primitives, et donc la maniere dont le programme est interpret .
Un second axe de classi cation introduit le terme introspection pour indiquer que le programme peut s’observer et donc raisonner sur son propre etat. L’intercession signi-e que le programme a la capacite de modi er son propre etat d’execution ou d’alterer son interpretation ou sa signi cation. L’introspection et l’intercession peuvent ^etre struc-turelles ou comportementales. Par exemple, l’introspection est comportementale si elle surveille les messages envoyes entre deux objets, elle est structurelle quand elle regarde les attributs d’un objet.
Ces deux axes de classi cation nous servent, dans l’etude des frameworks de composants re exifs de la section 2.2.2, a organiser les mecanismes de recon guration qui seront listes dans la table 2.2. Comme il est etabli notamment depuis les travaux de Maes (1987), une separation nette entre le domaine applicatif et les services de re exivit est souhaitable. Cela a conduit a architecturer les systemes en separant strictement un niveau de base, en charge du domaine applicatif, et un meta-niveau, en charge des services de la re exivit . C’est un principe de conception que l’on retrouve dans les frameworks de composants re exifs decrits en sous-section 2.2.2.
Table des matières
1 Introduction
1.1 Contexte
1.2 Problematique
1.3 Contributions
1.4 Plan du memoire
I Etat de l’art
2 Reconguration dynamique
2.1 Denitions
2.2 Reconguration dans les systemes distribues
2.2.1 Introduction a la re
exivite
2.2.2 Frameworks de composants re
exifs
2.2.3 Mecanismes de reconguration
2.2.4 Re
exivite dans les systemes de systemes
2.3 Documentation des recongurations
2.3.1 Decision de conception des recongurations
2.3.2 Documentation
2.4 Synthese
3 Processus de modelisation des systemes de systemes
3.1 Pratiques de modelisation des architectures de systemes de systemes
3.1.1 Modelisation architecturale de grands systemes
3.1.2 SySML
3.1.3 UDPM
3.2 Le projet COMPASS
3.2.1 Framework COMPASS
3.2.2 Phase de modelisation de l’architecture niveau SdS
3.2.3 Phase de modelisation de l’architecture niveau CSs
3.2.4 Phase d’analyse du modele
3.3 Le projet DANSE
3.3.1 Phase de modelisation de l’architecture niveau SdS
3.3.2 Phase de modelisation de l’architecture niveau CSs
3.3.3 Phase de generation d’une architecture
3.3.4 Phase d’analyse de l’architecture
3.4 Synthese
II Contribution
4 Etude de cas : le service des secours francais
4.1 Contexte
4.2 Congurations
4.2.1 Scenario
4.2.2 Denition des congurations
4.3 Synthese
5 Framework de modelisation pour les systemes de systemes
5.1 Choix de modelisation
5.1.1 Langage de modelisation
5.1.2 Outils et processus
5.2 Modelisation de l’etude de cas
5.2.1 Cas 1 : collaboration operationnelle entre SDIS 56 et 35
5.2.2 Cas 2 : collaboration tactique entre SDIS 56 et 35
5.2.3 Cas 3 : collaboration medicale entre SDIS 56 et 35, le SAMU et la
securite civile
5.3 Synthese
6 Patron de reconguration
6.1 Contenu du patron
6.2 Processus de denition d’un patron de reconguration
6.2.1 Donnees en entree du processus
6.2.2 Patron de co-evolution
6.3 Synthese
7 Processus de reconguration
7.1 Besoin de specication d’une architecture de transition
7.2 Processus de conception d’une reconguration
7.3 Synthese
III Framework d’experimentation et resultats
8 Framework de reconguration
8.1 Architecture du framework
8.2 Programmation des recongurations
8.3 Verication des proprietes de reconguration
8.4 Interaction de l’architecte avec le framework
8.5 Synthese
9 Experimentation
9.1 Planication de l’experimentation
9.1.1 Selection du contexte
9.1.2 Formulation des hypotheses
9.1.3 Selection des variables
9.1.4 Choix de conception du type d’experimentation
9.1.5 Instrumentation
9.2 Exploitation de l’experimentation
9.2.1 Preparation
9.2.2 Execution
9.2.3 Chargement et execution
9.3 Synthese
IV Conclusion – Perspectives
10 Conclusion et perspectives
10.1 Synthese
10.1.1 Modelisation de la conguration du systeme de systemes
10.1.2 Processus de reconguration
10.1.3 Documentation a l’aide de patrons de reconguration
10.1.4 Experimentation
10.2 Perspectives
A Patron re-routing
B Contraintes OCL des modeles architecturaux
Bibliographie
