Le besoin de gérer les états dans lesquels sont les applications : active, en arrêt, dépendances résolues et en attente de démarrage, en installation ou en désinstallation, est apparu avec les premiers systèmes d’exploitation multitâche. Ces quatre états et les transitions entre ces états peuvent être représentés sous la forme d’un automate. On appelle de façon plus générale cet automate, le cycle de vie d’une application. Il est toutefois important de différencier ce cycle de vie de celui de la discipline du génie logiciel tel que le modèle en cascade : spécification, conception générale, conception détaillée, développement, intégration, mise en production et maintenance. Dans notre contexte, on peut relier notre définition du cycle de vie aux étapes
mise en productionet maintenance du modèle en cascade.
Le cycle de vie d’une application représente donc les différents états dans lequel peut être une application à partir de son installation jusqu’à sa désinstallation sur un appareil ou un système. Voici donc les différents états du cycle de vie et leurs transitions (Figure 1.1) :
– en installation : l’application s’installe sur l’appareil et vérifie si les ressources néces- saires sont présentes ;
– résolue : dans cet état l’application est installée, les dépendances matérielles et logicielles sont résolues, l’application est prête à être utilisée. À partir de cet état, il est possible de mettre à jour l’application, i.e. retourner dans l’état en installation, de démarrer l’appli- cation ou bien désinstaller celle-ci ;
– en démarrage : l’application est en cours de démarrage, elle fait l’allocation de ses be- soins en ressources et instancie ses processus ;
– active : l’application est démarrée, fonctionnelle et peut être utilisée. Dans cet état, l’ap- plication peut être arrêtée ;
– en arrêt : l’application est en cours d’arrêt, elle fait la désallocation des ressources utili- sées et dé-instancie ses processus ;
– en désinstallation : l’application est en cours de désinstallation. À la sortie de cet état, l’application n’est plus disponible sur le système.
Cette représentation, somme toute simple du cycle de vie d’une application, défini par l’OSGi Alliance [42], ne présente pas les états et transitions inhérents à l’exécution de l’ap- plication : synchronisation de fils d’exécution, en attente d’entrées de données, etc. Une défi- nition du cycle de vie d’un service est donnée par le World Wide Web Consortium(W3C) [43] et complète le cas plus général des applications logicielles.
Il est donc important de tenir compte d’autres transitions possibles. Par exemple, une ap- plication peut retourner dans l’état en installation dans le cas d’une mise à jour de ses com- posantes. Dans le cas de fautes logicielles ou matérielles, l’arrivée de tels événements peut provoquer un changement d’état, tout dépendant de la façon dont le système traite la faute. Par exemple, dans le cas de la spécification OSGi, toutes les fautes non traitées à l’aide d’un
try-catch, entraînent l’arrêt du module et son retour à l’état résolu. Dans le cas d’OSGi, peu de fautes logicielles peuvent entraîner l’arrêt de la plateforme et de tous les modules, mais certaines peuvent altérer les performances telles que la saturation de la pile mémoire (Stack
Overflow).
Afin de bien cerner le contexte du travail, il est important de définir précisément ce qu’est la gestion logicielle. On peut définir celle-ci au sens large comme le processus menant à la
FIGURE1.1 – Graphe présentant les états du cycle de vie d’une application et ses transitions
prévision, la manipulation (commandement), l’organisation, la coordination et le contrôle des logiciels dans un milieu en rapport aux besoins du gestionnaire et/ou des besoins des individus représentés par le gestionnaire. Cette définition, appliquée aux logiciels, est inspirée de celle de Henri Fayol sur la gestion en général [44].
La notion de manipulation ou de commandement des logiciels amène une manipulation de l’état du cycle de vie des applications à un instant donné. La prévision, l’organisation et la coordination peuvent quant à elles être résumées au concept de configuration des logiciels, i.e. la disposition stratégique des applications sur les entités d’un milieu face aux besoins des applications, les caractéristiques des composantes et utilisateurs des milieux. La configura- tion logicielle traite également de l’adaptation des applications aux contextes des entités et de l’adaptation des modes d’interaction homme-machine face aux profils des utilisateurs. En regard du cycle de vie des applications, la configuration logicielle concerne essentiellement le déploiement des applications dans un milieu, i.e. les actions reliées à l’installation d’un logiciel sur une entité : téléchargement du code (binaire ou non selon le type d’application), installa- tion de celui-ci sur l’entité, vérification des dépendances de l’application sur l’entité et, pour terminer, passage à l’état résolu. Le déploiement d’un logiciel peut concerner une ou plusieurs
applications à déployer à la fois et pouvant avoir entre elles des dépendances logicielles, avec un couplage fort (dépendance de code) ou un couplage faible (dépendance de services).
Enfin, le contrôle des logiciels peut être résumé à la maintenance de ses logiciels. La main- tenance vise à maintenir, à rétablir ou même améliorer les logiciels déployés dans un milieu. Elle concerne donc la résolution des pannes ou des fautes logicielles, la mise à jour des logi- ciels suite à la résolution des fautes et finalement les manipulations de l’état du logiciel selon les besoins donnés.
En conclusion, la gestion des logiciels dans les espaces intelligents comprend à la fois la manipulation des états des logiciels, la configuration des logiciels dans le milieu ainsi que la maintenance de ceux-ci au cours de leur utilisation. Dans tous les cas, une manipulation de l’état de vie des logiciels est nécessaire.