Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
V & V : Vérification et Validation
Malheureusement, ces bonnes pratiques n’ont pas encore résolu la crise que le logiciel connaît depuis la fin des années 60. La conception de logiciels fiables passe nécessairement par des phases de vérification et de validation. La « vérification » [9] d’un système logiciel consiste à s’assurer de sa complétude, de sa cohérence, et de sa correction. Elle s’oppose dans la littérature à la « val-idation » qui assure que le système répond bien aux exigences des utilisateurs. De manière plus concise, la vérification s’assure que le système est bien construit, alors que la validation s’assure que le système construit est le bon. Regroupées sous l’appellation « V&V » elles forment un do-maine trop vaste pour être résumé en quelques paragraphes et ceux qui suivent se cantonnent donc à la vérification.
Lorsque la vérification porte sur un modèle du système ou qu’elle ne nécessite pas l’exécution du système réel, on parle de « vérification statique ». De manière simple, il peut s’agir de relecture de code, mais également de vérifications automatiques ou semi-automatiques. De nombreuses méthodes de vérification existent, basées sur des graphes de contrôle, des graphes de flots de données, etc. La preuve de programme est également une solution pertinente pour s’assurer du bon comportement d’un système logiciel. La notion de modèle, présentée précédemment à propos de l’ingénierie des modèles, est une des techniques majeures pour intégrer et fédérer des vérifications formelles reposant sur des formalismes différents. A partir d’un modèle initial, UML par exemple, l’ingénierie des modèles permet de basculer (par transformation de modèles) vers des formalismes appropriés pour la vérification (automate, réseau de Petri, modèle markovien, etc), mais également d’exploiter et de formaliser les résultats issus de ces mêmes vérifications.
Par opposition, lorsque les outils de vérification nécessitent l’exécution du programme ou du système, on parle de « vérification dynamique ». L’idée est d’essayer de mettre en évidence des défaillances en testant le système avec des entrées pour lesquelles on connaît le résultat attendu. Pour cela, on tente de couvrir au mieux le domaine d’entrée en sélectionnant un certain nombre de données représentatives (cas limites, cas typiques, etc), puis on exécute le système avec ces mêmes données, et on compare le résultat (ou l’état du système) avec un oracle, qui connaît le résultat attendu. Une erreur est mise en évidence lorsque le résultat produit et l’oracle diffèrent, et une correction est alors nécessaire. Ce processus se répète jusqu’à ce que la confiance (généralement associée à un critère de couverture) soit suffisante. La figure 2.2 présente le principe général de la vérification, et les trois problèmes qui s’y rattachent, respectivement, la génération de données de test, la définition d’un oracle, et le critère d’arrêt.
Cependant, l’exemple d’Ariane 5 [52] entre autres, a montré la nécessité d’embarquer une cer-taine forme de vérification à l’exécution, les « contrats », pour garantir les interactions entre les composants et ainsi maximiser et sécuriser leur réutilisation. Cette notion de contrat, inspirée de la société moderne, reflète un accord entre plusieurs participants et définit les droits et les devoirs de chacun. Un contrat est une sorte d’oracle partiel utilisé à l’exécution pour détecter d’éventuels dys-fonctionnements. Beugnard et al [8] distinguent quatre niveaux, allant de vérifications syntaxiques vers des vérifications de qualité.
Niveau syntaxique il s’agit de vérifier la cohérence syntaxique d’un système en s’assurant par exemple, que tous ses éléments sont bien définis ; il s’agit de techniques classiques liées à la compilation et à la vérification de type.
Niveau comportemental il s’agit de vérifier que le comportement attendu est bien celui qui est offert. On utilise par exemple, la vérification de pré et de post condition (Eiffel [74]).
Niveau protocolaire il s’agit de vérifier la coordination des systèmes, propriétés de sûreté, de vivacité, existence d’inter-blocages, etc. Ce type de vérification est généralement statique. Niveau qualité il s’agit de vérifier des contraintes de qualité de services, ce qui englobe des prob-lématiques de consommation de ressources, de temps, mais également de contraintes liées au domaine de l’application.
Il est important de noter que quel que soit le type de propriété, la vérification dynamique implique une capacité d’observation dédiée. La vérification du temps de réponse, par exemple, implique l’existence d’une horloge, celle de la mémoire libre d’une sonde mémoire, ou d’une technique de calcul quelconque.
Vers des systèmes auto-adaptatifs
Vers une définition commune
Avec l’avènement des systèmes mobiles qui sont confrontés à des environnements fluctuants, les systèmes « auto-adaptatifs » sont devenus un besoin et une réalité incontournables. Cependant, cette nouvelle branche du génie logiciel ne dispose pas encore de normes ou de standards, et il n’y a ni définition ni vocabulaire communs.
Cette section propose donc une définition qui permet de cerner les limites de notre étude, mais reflète également le regard que nous portons sur la conception et la réalisation des systèmes adaptatifs. Elle permet par ailleurs de définir le vocabulaire qui nous semble pertinent dans ce domaine. Cette définition est la suivante : un système « auto-adaptatif » est un système capable de modifier sa configuration ou sa structure interne pour prendre en compte les changements de son environnement et ainsi offrir un service d’une qualité optimale.
Le corps humain est un bon exemple de système adaptatif. Lorsque l’environnement change, celui-ci s’adapte pour préserver au mieux les fonctions vitales. Si la température augmente par ex-emple, le système de sudation se déclenche et maintient (dans une certaine mesure) une tempéra-ture interne acceptable. De manière plus concrète, le système de capture vidéo introduit précédem-ment peut intégrer de nombreuses adaptations. La qualité du flux vidéo par exemple (résolution spatiale, temporelle, couleurs, son, etc) peut être adaptée en fonction des ressources disponibles (bande passante, mémoire, CPU, etc) lors de la capture ou lors du rendu. Comme notre définition le stipule, l’objectif inhérent aux systèmes adaptatifs est de maintenir la qualité du service rendu quel que soit l’état de l’environnement. Il s’agit de stabiliser la qualité de service.
Trois capacités essentielles caractérisent un système adaptatif : l’observation, la décision et l’intro-action2.
Observation Un système adaptatif est un système qui observe son environnement et en détecte les changements. D’un point de vue technique, cette capacité se traduit par l’existence de sondes (logicielles ou matérielles) permettant de mesurer les propriétés pertinentes de l’en-vironnement. Décision En fonction de l’état de l’environnement, mais également fonction de sa configuration actuelle (capacité d’introspection), un système adaptatif décide par lui-même de la nouvelle configuration à adopter pour fonctionner de manière optimale.
Intro-action Pour modifier sa propre configuration, le système adaptatif manipule et modifie les éléments qui le constituent. Ces « intro-actions » sont des actions de l’intérieur sur l’in-térieur. Il s’agit d’une capacité d’introspection active.
Ces trois capacités reflètent également le cycle de l’adaptation : observation – décision – ac-tion à la base de l’automatisme et de la théorie du contrôle. Par ailleurs, la capacité d’intro-action inhérente à ces systèmes, implique un système à l’architecture clairement définie en terme d’élé-ments identifiés et interchangeables. Les architectures à composants sont donc prédisposées à supporter le développement de ces systèmes.
Trois générations de systèmes adaptatifs
L’un des principes de base du génie logiciel est l’anticipation. Concevoir un système, c’est, en effet, anticiper toutes les situations auxquelles le système devra faire face et anticiper le com-portement relatif du système. En d’autres termes, un bon concepteur doit pouvoir anticiper à la fois les changements de l’environnement et les configurations du système. Or dans le cas des sys-tèmes adaptatifs simples, la complexité de l’environnement engendre un très grand nombre de configurations possibles, qu’il est difficile d’anticiper et coûteux de concevoir séparément. L’idéal serait donc de concevoir un système qui infère lui-même les configurations à utiliser en fonction des variations de l’environnement. Plus généralement encore, il est difficile d’anticiper les états possibles de l’environnement et le système idéal doit inférer également les états critiques de son environnement et peut-être même inférer comment le mesurer.
Ce problème d’anticipation traduit l’existence de trois générations potentielles de systèmes adaptatifs, allant de systèmes statiques vers des systèmes inférant à la fois la configuration adéquate mais également les mesures pertinentes à effectuer sur l’environnement.
Les systèmes de première génération sont statiques, ou pseudo-adaptatifs. L’architecture d’un système statique n’évolue pas tandis que celle d’un système pseudo-statique supporte quelques évolutions implémentées de façon ad hoc. La plupart des systèmes temps réel actuels sont conçus de cette manière, par manque d’outils et de techniques appropriées.
Les systèmes de seconde génération sont capables d’inférer l’architecture la plus pertinente vis-à-vis de l’état de leur environnement. Ils intègrent pour cela un certain nombre de cap-teurs prédéfinis qui leur permettent de détecter les changements d’environnement. Certains systèmes mobiles commencent tout juste à intégrer ce type de fonctionnalités.
Ce mot n’existe pas en français, mais s’oppose par construction, à l’introspection. On trouve parfois dans la littéra-ture anglophone le terme intercession mais son équivalent français n’a pas réellement de rapport.
Les systèmes de troisième génération sont capables de découvrir un certain nombre de cap-teurs disponibles dans leur environnement, d’apprendre à les utiliser pour adapter au mieux leur architecture et satisfaire ainsi différents objectifs prédéfinis. Cette vision, qui relève de l’autonomic computing [55, 54] est celle vers laquelle tendent les systèmes multi-agents, les systèmes sensibles au contexte, les systèmes intelligents, etc.
Une nouvelle branche du génie logiciel, centrée sur les systèmes adaptatifs est donc en train de se dessiner. Elle intègre des technologies issues de différents domaines de l’informatique, princi-palement du génie logiciel et de intelligence artificielle mais également de l’informatique répartie. Il s’agit réellement d’une discipline émergente au sens premier du terme et une communauté scien-tifique commence à s’organiser. L’apparition d’ateliers tels SelfMAN (créé en 2005), M-ADAPT créé en 2007 et associé à la conférence ECOOP, MoDeLs@runtime créé en 2006 lors de la con-férence MoDeLs, SEAMS créé en 2006 au sein de la conférence ICSE, ARAMIS et WCAT créés en 2008 lors de la conférence ASE, reflètent cette tendance. Des conférences ainsi que des jour-naux apparaissent également tels que SASO (1ere édition en 2007) et TAAS (journal).
Comme nous allons le montrer par la suite, les systèmes produits actuellement sont des sys-tèmes de première génération. La principale raison à cela est le manque d’outils dédiés à la réal-isation de systèmes adaptatifs. Concevoir un système fiable, capable d’observer, de décider et de s’adapter n’est pas encore chose aisée. La suite de ce premier chapitre dresse un état de l’art sur ces trois problèmes que sont l’observation, la décision, et l’intro-action.
Observation et systèmes sensibles au contexte
Modélisation des données observables
S’adapter en fonction de l’environnement nécessite de le sonder pour connaître ses caractéris-tiques. Un système adaptatif inclut donc nécessairement un ensemble de moyens de mesure dédiés
son environnement. Avec l’apparition de systèmes mobiles et de l’informatique ubiquitaire, la notion de systèmes sensibles (ou Context-aware System en anglais) prend de plus en plus d’impor-tance. Naturellement, la notion de « contexte » n’a pas de définition communément acceptée. Dey [35] présente un bref résumé des différentes définitions et propose : « Le contexte correspond à l’ensemble des informations qui peuvent être utilisées pour caractériser la situation3 d’une entité (logicielle, matérielle, humaine, etc) ». Les systèmes sensibles sont clairement des systèmes auto-adaptatifs mais ont généralement pour objectif d’améliorer l’interface utilisateur, en observant son comportement.
Panorama des approches existantes
La solution la plus simple pour modéliser le contexte d’une application consiste à utiliser un ensemble de couples « clé-valeur ». Les différentes données observables sont alors accessibles via l’étiquette qui leur est associée. La simplicité de cette méthode a permis de mettre en place des systèmes efficaces de découverte dynamique de services [98] par exemple. Des modèles de données plus structurés ont également été proposés avec le Composite Capabilities/Preferences Profile du W3C et le Resource Description Framework (RDF) [62] conçus tous deux comme des schémas XML.
D’autres approches encore utilisent des modèles logiques pour alimenter directement des bases de faits exploitées par des systèmes experts (voir section 2.4.1). Ces systèmes utilisent les mé-canismes d’inférence fournis par la logique sous-jacente pour dériver de nouveaux faits ou pour raisonner sur le contexte. On peut noter les travaux de McCarthy qui proposent une première mod-élisation formelle du contexte [70], ceux de Akman et Surav qui réutilisent la théorie des situations [1], ou ceux plus récents, de Kaenampornpan qui propose une théorie des activités [53].
Des approches orientées-objet ont également été proposées, à l’aide d’UML par exemple [101], mais également à l’aide du langage ORM (Object Modeling Role) [48] qui s’avère très efficace pour générer des modèles relationnels et les bases de données qui leur sont associées. Cependant, parmi les différents états de l’art sur les modèles de données contextuelles [102, 10, 4], les approches à base d’ontologies [103, 45, 92] semblent les plus utilisées.
Utilisation d’ontologies
A l’instar des modèles entité-relation ou des modèles objets, les ontologies décrivent les dif-férents concepts d’un domaine et les relations qui les lient. Si la différence entre un modèle orienté-objet et une ontologie reste floue [58], les ontologies, issues de l’Intelligence Artificielle, sont fréquemment couplées à des systèmes de raisonnement automatique. Chen et al. [23] intègrent par exemple dans leur intergiciel CoBrA un moteur leur permettant de raisonner sur les ontologies. L’objectif est de combiner une base de faits intégrée dans le système, aux données contextuelles mesurées par les capteurs pour maximiser les capacités de raisonnement. Cette approche, parti-culièrement utilisée pour la géo-localisation d’individus permet par exemple de confronter une localisation mesurée (i.e à l’aide de badge RFID) avec une localisation calculée (i.e à l’aide d’em-ploi du temps).
Une ontologie possible pour modéliser le contexte du système vidéo est représentée par la fig-ure 2.3 à l’aide d’un diagramme de classe UML. Elle permet, entre autres, de capturer facilement les préférences de l’utilisateur en terme de qualité par exemple. Le système peut essayer de max-imiser la dynamique du flux vidéo (nombre d’images par seconde) ou sa qualité (résolution des images). La figure 2.3 représente les données qui peuvent entrer en jeu lors de l’adaptation. Il est naturel d’y modéliser à la fois les ressources physiques telles que la mémoire, le CPU, ou la bande passante, mais également des ressources logiques à la disposition du système comme les com-posants logiciels disponibles par exemple. Surtout, adopter une approche de haut niveau, comme le suggère la littérature sur les systèmes sensibles, permet de capturer directement des éléments tels que les intentions de l’utilisateur, ou celles de l’administrateur dans le cas de notre service de capture vidéo.
Il faut admettre cependant que la modélisation des données n’est plus réellement un problème difficile, mais qu’il faut maintenant être capable d’exploiter ces données et de les interpréter. C’est d’ailleurs, l’un des manques des approches orientées-objet pourtant avancées en terme de modéli-sation : elle ne permettent pas de raisonner sur les données. A l’inverse, le monde des ontologies, plus mature sur le raisonnement, n’a pas encore convergé en terme de modélisation.
Observation et systèmes sensibles au contexte
De nombreuses plates-formes ont été proposées pour faciliter le développement de systèmes sensibles. Elles offrent un accès transparent aux différentes informations contextuelles, masquant par exemple l’accès à des sondes matérielles. La plupart exploite un modèle du contexte issu des approches présentées dans la section 2.3.1.
Panorama des approches existantes
Comme l’explique Chen [23] trois principales architectures sont utilisées pour l’acquisition de données, allant de l’accès direct aux sondes matérielles à des réseaux de capteurs dédiés en passant par l’intégration de services dédiés dans des intergiciels. Toutefois, à l’exception de COSMOS [27] peu d’approches intègrent les notions de composant et d’architecture.
Parmi les architectures les plus simples, le système WildCat [32] développé pour Fractal offre une interface de haut niveau permettant d’accéder de manière homogène à des capteurs matériels ou logiciels.
CoBrA [23] propose un intergiciel dédié à l’accès aux informations contextuelles qui masque en grande partie la complexité de tels accès. D’autres travaux existent tels que CORTEX [112] construit autour de la notion d’objet sensible ou SOCAM [46] qui est également un intergiciel centralisé dédié aux données contextuelles.
Parmi les approches distribuées, LeWYS [15] est une plate-forme de mesure et de surveil-lance développée pour les applications distribuées. Dédiée aux applications J2EE, elle permet de collecter des données hétérogènes. Cette approche ne permet pas de filtrer et de combiner les données contextuelles comme le fait Phoenix [95, 96] qui offre un langage de description des don-nées observables incluant quelques opérateurs (variations, amplitude, etc.). Context Toolkit [97] utilise également une architecture distribuée, intégrant des agrégateurs et des filtres permettant de construire des données contextuelles complexes.
Agrégation de données contextuelles avec COSMOS
Une autre approche, basée sur Fractal a été proposée dans [27]. L’idée est de représenter l’acquisition de données contextuelles sous la forme d’une composition de sources de données. Cette approche repose sur l’utilisation du pattern composite et sur la capacité du modèle Fractal partager des composants entre plusieurs composites. Assez naturellement, cette approche per-met de définir ses propres sources et ses propres compositions de données, mais n’intègre pas une description de haut niveau des données, et reste donc très liée à l’implémentation.
La figure 2.4 présente le principe de COSMOS appliqué à notre exemple de capture vidéo. L’acquisition du contexte se présente en trois niveaux. Le premier représente l’information que l’on veut obtenir, ici, une métrique permettant de décider de la nécessité d’une reconfiguration. Le second niveau décrit comment interpréter les données de base, c’est-à-dire comment combiner les différentes métriques. Enfin, le dernier niveau montre les mesures physiques ou logiques faites par le système.
COSMOS n’intègre pas directement une notation graphique comme peut le laisser entendre la figure 2.4. Chacun des éléments est en fait un composant Fractal composé des éléments qu’il requiert et qui implémente si besoin la combinaison de plusieurs métriques. Cependant, en offrant un certain nombre de sondes et d’opérateurs de base, COSMOS intègre élégamment l’accès au contexte dans une plate-forme à composants.
Prise de décision automatique et systèmes experts
Des systèmes experts pour la prise de décision
Le cœur d’un système adaptatif est un moteur de décision, c’est-à-dire à dire un élément ca-pable de décider des modifications à apporter à l’architecture en fonction des observations que les capteurs du système lui envoient. Cette capacité de raisonnement est cruciale, car elle influe directement sur la pertinence des adaptations effectuées. Cependant, alors que les techniques liées au raisonnement et à la décision automatique arrivent à maturité, les systèmes adaptatifs intègrent toujours des éléments développés de façon ad hoc.
Panorama des techniques de décision automatique
La capacité de prendre des décisions caractérise entre autre l’intelligence humaine, obligeant ainsi la communauté de l’Intelligence Artificielle à proposer des méthodes et des outils pour la décision automatique. Parmi ces différentes techniques, on peut citer les tables de décision et les approches basées sur des calculs d’utilité, les systèmes experts, les algorithmes de satisfaction de contraintes, les réseaux de neurones, les approches floues (contrôle et raisonnement), ou des combinaisons.
Les tables de décision [7] sont les systèmes les plus simples. Elles opposent structurellement (sous forme de tables) différents critères de décision à différents choix possibles. Utilisées dans le cas des systèmes adaptatifs, elles opposeraient ainsi l’état de l’environnement aux différentes architectures possibles, chaque case du tableau indiquant la pertinence (ou non) d’une architecture par rapport à l’état de l’environnement. Ces tables sont généralement couplées à des fonctions d’utilité qui permettent une analyse plus fine de la situation. Chaque décision possible se voit associer un certain nombre de conséquences (valuées) et il s’agit alors de maximiser l’utilité, calculée à l’aide des fonctions du même nom.
Une autre solution utilisée est le « système expert » [51] introduit dans les années soixante-dix aux Etats-Unis. Il s’agit de modéliser sous la forme de faits et de règles les connaissances utiles d’un expert. A partir de cette base de faits, le système utilise alors les règles pour produire de nouveaux faits ou pour prendre des décisions. La puissance d’un système expert dépend de la logique utilisée : logique des prédicats, logique des défauts, logiques modales non-monotones, etc. La principale difficulté est alors de capturer l’expertise et de la traduire sous forme de règles. L’apprentissage à l’aide de réseaux de neurones est également utilisé pour résoudre des prob-lèmes décisionnels. Il s’agit de faire « apprendre » au système un certain nombre de cas de base et de lui donner les moyens d’inférer d’autres cas, avec un certain degré d’erreur (que l’on veut minimal). L’un des problèmes liés à ce type de solution, est qu’il est parfois délicat de comprendre a posteriori pourquoi le système a pris telle ou telle décision.
Logique floue et contrôle flou
Prenons le cas des approches dites « floues » et plus précisément du contrôle flou qui est util-isé par la suite. La notion de contrôle décrit généralement de manière naturelle des problèmes de commande, de pilotage ou de régulation, très présents en automatique. Contrôler la pression des freins d’une voiture pour en contrôler la vitesse ou ajuster la puissance d’un four pour maîtriser sa température sont de bons exemples. Plus généralement, il s’agit de contrôler un certain nombre de valeurs de sortie en fonction d’un certain nombre de valeurs en entrée. Une grande partie des tech-niques de contrôle utilisent des modèles mathématiques (équations différentielles par exemple) et sont donc parfaitement adaptées aux systèmes ayant un petit nombre de variables qui se prêtent facilement à une modélisation formelle. Le cas des systèmes adaptatifs nécessite de contrôler l’ar-chitecture logicielle en fonction de propriétés nombreuses et structurées et ne se prête donc pas aussi bien à ce genre de modélisation.
La logique floue a permis d’aborder ces problèmes moins intuitifs de manière élégante en pro-posant de modéliser le savoir-faire et l’expertise qu’un opérateur humain déploie dans ce genre de situation. L’une des particularité du raisonnement humain est son manque de précision : calculer la racine carrée de 23, par exemple, n’est pas aisé pour un humain mais est trivial pour une machine. A l’inverse, évaluer globalement la trajectoire d’un ballon pour l’intercepter est possible pour un humain, mais délicat pour une machine. L’idée de la logique floue est là : raisonner de manière globale et qualitative au lieu de raisonner de manière précise et quantitative.
Pour raisonner de manière qualitative, il faut décrire les qualificatifs associés aux grandeurs que l’on manipule ou sur lesquelles on raisonne. Pour cela, la logique floue utilise la notion d’ensembles flous » dont l’appartenance est graduelle par opposition aux ensembles classiques dont l’appartenance est stricte. En logique floue, un élément peut appartenir « plus ou moins » à un ensemble. Ce degré d’appartenance est représenté par une fonction (d’appartenance) nommée µ généralement. La figure 2.5 représente ainsi les trois ensembles flous( nommés mauvaise, correcte, excellente), choisis pour qualifier la bande passante dans le cas du système vidéo. Chacun de ces ensembles est défini par une fonction d’appartenance de telle sorte qu’une bande passante de 6000 ko/s sera considérée comme excellente à 20% et correcte à 60%.
|
Table des matières
1 Introduction
2 Problématique et contexte
2.1 Réalisation de systèmes logiciels classiques
2.1.1 Conception et modélisation
2.1.2 Vers l’ingénierie des modèles
2.1.3 V & V : Vérification et Validation
2.2 Vers des systèmes auto-adaptatifs
2.2.1 Vers une définition commune
2.2.2 Trois générations de systèmes adaptatifs
2.3 Observation et systèmes sensibles au contexte
2.3.1 Modélisation des données observables
2.3.2 Vérification et validation de systèmes sensibles
2.3.3 Observation et systèmes sensibles au contexte
2.4 Prise de décision automatique et systèmes experts
2.4.1 Des systèmes experts pour la prise de décision
2.4.2 Vérification de systèmes experts
2.4.3 Support de la décision à l’exécution
2.5 Architecture et systèmes intro-actifs
2.5.1 Modélisation de systèmes intro-actifs
2.5.2 Validation de systèmes intro-actifs
2.5.3 Plate-forme d’exécution pour les systèmes intro-actifs
2.6 Synthèse et positionnement
3 Modélisation d’architectures auto-adaptatives
3.1 Vers des architectures intro-actives
3.1.1 Portée et régie des intro-actions
3.1.2 Adaptation architecturale vs. adaptation configurative
3.2 Observation de données qualifiables
3.2.1 Observation de données
3.2.2 Modélisation de données qualifiables
3.3 Prise de décision
3.3.1 Sélection d’intro-actions
3.3.2 Modélisation de politiques d’adaptation
3.3.3 Composition de politiques d’adaptation
3.4 Conclusion
4 Validation a priori par simulation
4.1 TANGRAM : Modélisation exécutable d’architectures logicielles
4.2 Modélisation des architectures à base de composants
4.2.1 Modélisation des aspects structuraux
4.2.2 Modélisation des données
4.2.3 Modélisation des traitements
4.2.4 Description des coordinations
4.3 Sémantique et simulation d’architectures auto-adaptatives
4.3.1 Simulation des communications
4.3.2 Simulation des processus
4.3.3 Simulation des composants
4.3.4 Le simulateur TANGRAM
4.4 Validation a priori d’architectures auto-adaptables
4.4.1 Critère de validation d’une architecture auto-adaptable
4.4.2 Simulation des effets de bords extra-fonctionnels
4.4.3 Exemple de validation
4.5 Synthèse et discussion
5 Intégration dans la plate-forme Fractal
5.1 Conception d’un contrôleur Fractal dédié
5.1.1 Extension de Fractal à l’aide de contrôleurs
5.1.2 Principe du contrôleur d’adaptation
5.1.3 Spécialisation des politiques d’adaptation pour Fractal
5.1.4 Conception du contrôleur d’adaptation
5.2 Génération de code pour Fractal
5.2.1 Un patron pour les composants
5.2.2 De TANGRAM vers FScript/FPath
5.3 Synthèse
6 Etude de cas
6.1 Architecture du serveur CHEROKEE
6.2 Intégration de propriétés extra-fonctionnelles
6.3 Vers un serveur Cherokee dynamique
6.4 Modélisation des politiques d’adaptation
6.4.1 Gestion du cache
6.4.2 Gestion des serveurs de fichier
6.5 Validation a priori
6.6 Implémentation dans la plate-forme Fractal
7 Conclusion
8 Perspectives
8.1 Devenir des contrats dans les architectures auto-adaptatives
8.2 Vers un langage de données structurées qualifiables
8.3 Inférence d’intro-action
8.4 Description de scénarios de tests
8.5 Vers un processus de développement
Bibliographie
Télécharger le rapport complet
