Jusqu’à présent, le développement de logiciels pour HDEs est ad-hoc. Chaque développeur de l’application tente de mettre en œuvre des techniques et des con- trôles pour répondre aux spécifications sur ces environnement. Cependant, il n’y a pas de processus systématique, ni de modèle personnalisé qui peut être utilisé systématiquement pour produire des applications de haute qualité pour HDEs.
Dans ce travail, nous proposons un modèle de composant logiciel, le modèle de cloud component, pour combler cette lacune entre le besoins de développement
1.5. Conclusion 17
des logiciels actuels et les techniques d’ingénierie et les méthodes de développe- ment logiciels disponibles. Le modèle de cloud component est basé sur un changement de paradigme de la transparence de la distribution à la localisation comme préoccupation de première classe. En d’autres termes, nous n’avons plus à cacher les emplacements, au contraire, nous reconnaissons tous les aspects liés à la localisation y compris la spécification des dispositifs, les caractéristiques des réseaux qu’ils utilisent, les spécifications de réseau différents, les caractéristiques de sécurité, et toutes les propriétés associées à l’environnement de déploiement. En outre, nous proposons une théorie d’assemblage afin de bâtir une base pour les CC. Une notation formelle est proposée pour les CC, les assemblages de CC, leur processus de développement. Cette notation formelle ouvre la porte à un large éventail de sujets théoriques, y compris l’inférence de type de composant, sous-types, etc. Cette approche formelle permet au concepteur de produire des représentations lisibles par la machine où les outils automatisés peuvent vérifier les propriétés spécifiques au moment de la conception, qui à leur tour, augmente le niveau de confiance dans la correction de la conception.
Une des principales valeurs du modèle CC est la prise en compte de la com- patibilité entre le logiciel et matériel dans les HDEs. Il s’agit d’un défi majeur en sachant l’hétérogénéité de ces milieux. Notre modèle est le premier à utiliser une modélisation ontologique du matériel et des exigences des logiciels afin de véri- fier leur comptabilité. Ce vérificateur, ainsi que le processus de développement proposé des CC sont les fondements de notre affirmation selon laquelle textit le modèle CC garantit la QoS attendue au point d’utilisation de l’utilisateur final. Nous avons soutenu ce modèle avec des outils pleinement mis en œuvre: vérifi- cateur d’assemblage de CC, l’ontologie logiciel / matériel, le système de gestion des cloud components (CCMS) et du Registre. Enfin, nous avons pleinement
mis en œuvre un système CC avec une application multimédia, afin de valider notre proposition.
La contribution de cette thèse a plusieurs faces, mais ces faces sont co- hérentes. Chacune de ces faces forme une contribution partielle, toutefois, chaque contribution ne veut rien dire si on l’isole de la proposition globale. 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 étudiées ensemble.
Il pourrait être considéré comme une des limites de ce travail que nous n’avons pas de vérification dynamique dans notre modèle. Par exemple, nous ne décrivons pas la dynamique (temporelle) caractéristiques d’un rôle de CC, comme résultat, c’est la responsabilité du concepteur pour assurer le bon com- portement dynamique des rôles lors de l’exécution. D’autre part, d’éviter de telles méthodes formelles est destiné à maintenir le modèle facile à utiliser par les ingénieurs logiciels moyenne.
Une autre limitation est la condition de l’existence d’une puissante machine qui exécute le CCMS et l’utilité du Registre. En outre, nous supposons un lien entre cette machine et tous les dispositifs de déploiement. Alors que la dernière condition pourrait être assouplie, nous n’avons pas étudié l’effet de la non-existence absolue d’une telle machine par rapport au modèle CC. Est-il encore utilisable? Et comment y parvenir? La majorité des applications ne nécessitent pas une telle condition extrême, cependant, il est encore intéressant d’étudier le potentiel du modèle CC dans une situation grave telle.
Part I
INTRODUCTION
Chapter 2
Introduction & Motivation
2.1
Quick Response Code - QR
Quick response code (QR code as in figure 2.1) has enjoyed great popularity recently. Using QR code reader, it is possible to access a large volume of informa- tion that ranges from commercial products to scientific posters. However, when a smartphone user installs QR code reader software on his/her phone, there is a probability that this software will not operate properly. All QR code readers available now require an auto-focus camera, while many smartphones currently are equipped with fixed-focus camera. As result, the software will not be able to scan the QR code. We think that this fault is neither isolated nor shallow. It is deep and fundamental. Moreover, it spans to the whole spectrum of software development for highly distributed environments - HDEs. This simple example is used to emphasize the fact that software development for HDEs is different from developing applications for stable distributed environments.
Figure 2.1: QR code for the URL of the English Wikipedia Mobile main page, http://en.m.wikipedia.org. (From Wikipedia).