ce cadre dépend fortement de l’ingénierie dirigée par les modèles dans la mod- élisation et la génération de code. Cela implique plusieurs modèles, des méta- modèles, et des transformations de modèle. De plus, ce cadre adopte une anal- yse très complexe de la mobilité qui inclut: la mobilité du logiciel, la mobilité logique, la mobilité des composants et la mobilité du matériel.
1.3
Contribution
Cette thèse est une réponse directe aux défis mentionnés des HDEs. La contribution de cette thèse est le modèle de composant “cloud component (CC)”. Toutefois, nous détaillons les contributions ci-après:
1.3.1 Première contribution
Nous proposons un changement de paradigme de la transparence de distri- bution à la reconnaissance de la localisation comme étant une préoccupation première importance. En d’autres termes, nous ne cachons plus la localisa- tion (pour l’abstraire), au contraire, nous reconnaissons tous les aspects liés à l’emplacement, y compris la spécification des dispositifs, les différentes carac- téristiques des réseaux qu’ils utilisent, les fonctions de sécurité, et toutes les caractéristiques liées à la mise en place de l’environnement. Nous discutons les HDEs et ce changement de paradigme dans la section 6.
1.3.2 Deuxième contribution
Pour atteindre l’objectif mentionné ci-dessus, nous proposons dans la sec- tion 7.1 un modèle de composant intitulé cloud component (CC). Ce modèle
comprend l’environnement de déploiement prévu dans sa définition, c’est-à-dire nous élevons l’importance de l’environnement de déploiement pour être égale à la fonctionnalité du composant. L’autre caractéristique importante de ce nouveau modèle est qu’il est fondamentalement distribué. Un simple CC est générale- ment réparti sur de nombreux hôtes distants, la spécification de ces hôtes sont considérée et fondamentalement reconnue au cours du processus de développe- ment des CC, et tous les aspects liés à la communication, la coordination, et la qualité de services sont déplacées à l’interieur de la frontière de la CC.
1.3.3 Troisième contribution
Un composant logiciel peut être considéré comme l’unité d’assemblage3. Cela est vrai pour tous les modèles de composants, y compris le modèle cloud component. Dans cette thèse, nous proposons une nouvelle approche pour as- sembler des CC en utilisant une méthodologie systématique qui maintient la propriétés du modèle CC. Nous proposons une démarche pour construire de grands systèmes utilisant des CC en tant que blocs de construction. En outre, nous présentons une technique pour vérifier automatiquement la validité de cette assemblage. Assemblage de composants et de vérification de l’assemblage sont présentés dans le chapitre 7.2 .
1.3.4 Quatrième contribution
Nous proposons un processus de développement des CC. Dans cette contri- bution, deux facteurs ont été considérés comme pivot. Le premier facteur est la
3. Dans cette thèse, nous préférons utiliser le mot assemblage plutôt que composition puisque la sortie de cette opération (assemblage) n’est pas un composant logiciel.
1.3. Contribution 13
pertinence de notre processus de développement logiciel qui doit être un proces- sus conforme aux processus bien communément acceptés. Le deuxième facteur est la compatibilité entre ce processus de développement et les applications HDE. Notre processus de développement est discuté dans la section 7.3.
1.3.5 Cinquième contribution
L’utilisation des lieux et de la localisation pour les HDEs sont la clé de notre contribution. Pour y parvenir, nous proposons une ontologie de modélisation basée sur l’environnement de déploiement. Cette ontologie sert de base à la vérification de la compatibilité logiciels/hardware de notre approche. Voir la figure 1.6. Ces sujets sont abordés dans la section 8.
1.3.6 Sixième contribution
Nous proposons une formalisation pour la modélisation des CC, d’un assem- blage de CC, du processus de développement des CC et des systèmes à base de CC. Ce langage formel est présenté dans la section 7. Le modèle de cloud component et son assemblage sont présentés informellement avec une notation graphique et formellement avec une notation mathématique. La notation in- formelle permet d’accélérer la compréhension des concepts généraux alors que le notation formelle ouvre la porte à un large éventail de la travaux théorique sur des sujets tels que l’inférence de type de composant, les sous-types, etc, et fournit un langage précis pour décrire les détails. En outre, les approches formelles permettent au concepteur de produire des représentations lisibles par la machine où des outils automatisés peuvent vérifier les propriétés spécifiques au moment de la conception, qui à son tour, augmente le niveau de confiance
dans la justesse de la conception.
1.3.7 Septième contribution
Dans la section 9 nous présentons nos outils de soutien: le CCMS, un système de gestion des cloud components, et l’utilitaire Registre. Ces outils facilitent l’installation, le déploiement, les vérifications de compatibilité, et la gestion de l’exécution. Ces outils, ainsi que le vérificateur d’assemblage et le vérificateur de logiciel/hardware sont indispensables et ils font du développement en utilisant le modèle CC un processus facile et puissant.
1.3.8 Remarque
La contribution de cette thèse a plusieurs faces, mais ces faces sont en co- hérence. Chacune de ces faces forme une contribution partielle, toutefois, chaque contribution partielle ne veut rien dire si on l’isole de la proposition globale. En outre, le mérite de la proposition globale ne peut être saisi par la lecture d’un apport partiel. Le mérite de la proposition n’est évident que si toutes les parties de ce travail sont organisés ensemble.