Introduction

Cet essai s'adresse à des architectes logiciels concevant des solutions autonomes et utilisant des langages de programmation de 3e génération et moins. Sont inclus ici les langages de programmation s’exécutant sur une machine virtuelle applicative (p. ex. : le Common Language Runtime (CLR) de Microsoft), dans la mesure où ceux-ci n’ont pas été conçus pour un domaine spécifique, comme l’a été le langage Logo, initialement conçu pour le domaine de l’enseignement [22]. Selon la norme IEC 9126 [3], plusieurs attributs de qualité doivent être observés lors du développement d’une solution logicielle. La tolérance aux pannes est l’un de ces attributs, et la disponibilité est une mesure permettant de l’évaluer.

La disponibilité d’une solution est une mesure quantifiable : elle permet de mettre en relief la tolérance aux pannes d’un système. La disponibilité de la solution est la proportion du temps où les services de l’interface publique de la solution sont totalement disponibles, en comparaison avec la durée totale d’un échantillon représentatif pour la solution logicielle analysée.

Le but recherché dans cet essai est de déterminer les mécanismes à mettre en place lors de la conception d'une solution pouvant offrir une meilleure disponibilité. La disponibilité est basée seulement sur des hypothèses quant à la disponibilité de l’implémentation physique de la solution. Il n’y a aucune disponibilité spécifiquement recherchée dans le cadre de cet essai; ce qui est recherché est une amélioration de la disponibilité qui se vérifiera par l’accroissement de la disponibilité de la solution.

Une solution logicielle ne repose pas que sur des composants logiciels conçus dans le cadre de la solution. Le logiciel et le matériel sur lesquels cette solution repose constituent des dépendances externes à celle-ci. Par exemple, le système d’exploitation, des cartes de réseau, ou des disques rigides sont des dépendances d’un composant logiciel, qui sont indispensables, pour que celui-ci puisse fonctionner. Les dépendances seront des dépendances externes, sauf indication contraire.

La première partie de l'essai est axée principalement sur l'abstraction de ces dépendances. Un exemple serait d’abstraire un lien réseau au niveau d’un moyen de communication, ou un disque rigide au niveau d’une unité de stockage. En se basant sur des modèles existants, les caractéristiques des différents types de dépendances seront établies, afin de pouvoir correctement identifier les dépendances lors de l’analyse d’une solution.

Une fois ces abstractions identifiées et leurs caractéristiques établies, les mécanismes à mettre en place pour maximiser la disponibilité d’une solution donnée sont déterminés. Ainsi, la deuxième partie de l’essai est dédiée aux mécanismes permettant une meilleure disponibilité. Des caractéristiques additionnelles sont alors ajoutées aux dépendances externes.

La troisième partie est axée sur l’adaptation de la méthode d’analyse de Tsai et Sang [23] pour analyser la disponibilité d’une architecture logicielle, en ajoutant les caractéristiques des dépendances externes.

Enfin, la méthode d’analyse est appliquée dans deux contextes distincts pour en valider l’efficacité. L’évaluation de l’architecture avant et après l’intégration des modifications permet alors d’établir la différence de disponibilité. Aussi, des hypothèses seront ajoutées aux contextes afin de raffiner le résultat d’analyse.

Les tests de validation mettent en relief les limitations de la méthode d’analyse mise en application dans l’essai. Quelques pistes d’améliorations sont aussi détaillées afin de faire évoluer le cadre d’analyse, et de rendre la méthode applicable à des contextes différents.

La méthode d’analyse exclut tout composant non contrôlé lors du développement d’une solution autonome, ainsi que tous les composants qui ne sont pas imposés lors du déploiement d’une solution. Les solutions utilisant des logiciels déjà en place (par exemple, les logiciels de gestion de ressources d’entreprise et les gestionnaires de relation client), ainsi que les solutions développées avec des langages de 4e génération et plus sont aussi exclues. L’implémentation de la solution est hors du contrôle du concepteur de la solution, ce qui est une prémisse de la présente analyse.