Modèle de Sites pour le déploiement de logiciels.

Transcription

1 Ana Laura GOMEZ Mémoire rédigé dans le cadre du DEA Systèmes d Information MATIS Modèle de Sites pour le déploiement de logiciels. Sous la direction de Messieurs Noureddine Belkhatir et Pierre-Yves Cunin Juin 2000 Laboratoire LSR IMAG Ana Laura GOMEZ DEA Systèmes d Information 26 Juin i

2 Résumé Ce travail traite du déploiement du logiciel qui est l étape importante où le logiciel va être mis à la disposition des utilisateurs. Il consiste en une mise à jour des sites généralement distants et répartis au sein d une organisation. Les travaux récents s orientent vers le support automatisé au déploiement devant déboucher sur de nouvelles approches tirant avantage des réseaux. L objectif général de notre recherche est d appliquer aux systèmes de déploiement logiciel un processus de modélisation les rendant adaptables et extensibles. Le travail de DEA est centré sur la gestion des sites. La description du «site» se limite souvent à sa localisation physique et ses caractéristiques en termes de une ou deux variables. L intérêt de l approche réside dans la proposition d un modèle de sites qui permet d assurer automatiquement la cohérence du parc en terme de versions, licences, configuration matérielle et logicielle. Nous avons, dans un premier temps, étudié les différents niveaux qui font partie du processus de déploiement ; puis pris connaissance du fonctionnement des outils existants résultant de la recherche et de l industrie. Nous avons ensuite proposé un modèle objet (framework) des sites permettant d exprimer les caractéristiques des sites L intérêt de cette modélisation est de permettre à un outil externe (ici Target Link) de prendre en charge la diffusion automatique d applications sur les sites cibles et ce, sans intervention manuelle et avec le moins de contraintes possibles pour l utilisateur. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin ii

3 TABLE DES MATIERES 1. INTRODUCTION CONTEXTE TECHNOLOGIE DE DEPLOIEMENT : ETAT DE L ART ET DE LA PRATIQUE CONCEPTS Niveau du producteur Niveau de l entreprise Niveau de l utilisateur LES OUTILS LOGICIELS Produit Universitaire : Software Dock Exemple Concepts Les activités supportées par le processus de déploiement L architecture Produit Industriel : Target Link Concepts Les composants Les activités Exemple Structuration des composants Synthèse des Outils Système de Gestion d Applications : Tivoli Tivoli Inventory Tivoli Inventory et Tivoli Software Distribution NOTRE APPROCHE INTRODUCTION MODELE DE SITES Expression des besoins Cas d utilisation Scénarios Notification d application disponible pour déploiement PULL Association utilisateur-site par déploiement PUSH Vérification de Contraintes Matérielles Vérification des Contraintes Logicielles Transfert Installation De Installation Analyse Diagrammes de transition d états Conception Diagrammes de classes INTERFACE Fenêtre Logiciels Fenêtre Composants Fenêtre Applications Dépendantes Fenêtre Applications en Conflit Fenêtre Utilisateurs Fenêtre Déploiement EVALUATION DE NOTRE MODELE Ana Laura GOMEZ DEA Systèmes d Information 26 Juin iii

4 4.5 CONCLUSION ET PERSPECTIVES BIBLIOGRAPHIE ANNEXE A ANNEXE B AnaLauraGOMEZ DEASystèmesd Information 26Juin2000-iv

5 TABLE DES FIGURES Figure 1 Les trois niveaux de déploiement... 3 Figure 2 Cycle de vie du déploiement... 6 Figure 3 Le schéma des activités sur le niveau producteur... 7 Figure 4 Création de l'application entreprise... 8 Figure 5 Création du modèle de déploiement... 9 Figure 6 Création de l'application déployable...10 Figure 7 Architecture de Software Dock...14 Figure 8 Architecture de Target Link...18 Figure 9 Déploiement PUSH et PULL...22 Figure 10 Cas d'utilisation du déploiement...23 Figure 11 Diagramme de Séquence: Notification par déploiement PULL...24 Figure 12 Diagramme de Séquence: Association utilisateur- cible par déploiement PUSH...25 Figure 13 Diagramme de Séquence: Vérification contraintes matérielles...26 Figure 14 Diagramme de Séquence: Vérification contraintes logicielles...28 Figure 15 Diagramme de Séquence: Transfert, Installation, De Installation...29 Figure 16 Diagramme de transition d états: Classe Application (global)...30 Figure 17 Diagramme de transition d'états: Classe Application (Spécifique)...31 Figure 18 Diagramme de transition d états: Class Application à déployer...32 Figure 19 Diagramme de classe: Modèle des sites...35 Figure 20 Fenêtre Logiciels...38 Figure 21 Fenêtre Composants...40 Figure 22 Fenêtre Applications Dépendantes...42 Figure 23 Fenêtre Applications en Conflit...44 Ana Laura GOMEZ DEA Systèmes d Information 26 Juin v

6 Figure 24 Fenêtre Utilisateurs...46 Figure 25 Fenêtre Déploiement...48 Figure 26 Modèle de Conception: Etat...49 Figure 27 Modèle de Conception: Observateur...50 Figure 28 Modèle de Conception: Fabrication...51 AnaLauraGOMEZ DEASystèmesd Information 26Juin2000-vi

7 1. Introduction Dans le domaine de l ingénierie logiciel le cycle de vie couvre classiquement les étapes suivantes : l analyse, la conception, la réalisation et la validation. Cependant, le cycle de vie d un logiciel ne finit pas à ce moment-là, mais il continue avec la phase de déploiement qui a pris un nouvel essor avec l avènement de l internet et la possibilité de déployer directement les logiciels du producteur vers les sites clients [1]. Le déploiement est considéré comme un processus complexe nécessitant plusieurs activités réalisées à l aide de différentes ressources et modèles. Au sein d une large organisation basée sur des milliers de postes de travail, l automatisation du processus de déploiement est vital pour réussir ces opérations [5]. La plupart des grandes entreprises se dotent d une nouvelle plate-forme appelée généralement centre de distribution de logiciel et prenant en charge le processus de déploiement Récemment ce domaine a fait l objet d un développement actif comme en témoignent les produits sur le marché, cependant les solutions et les technologies utilisées n offrent que des solutions partielles et ad hoc au problème du déploiement. Ce qui rend l adaptation difficile pour des entreprises qui ont besoin de personnaliser leurs solutions [2]. L objectif de mon travail de DEA est de proposer des fonctions évoluées permettant d avoir une vue intégrale et globale du site en terme de configuration matérielle, logicielle et état des logiciels déployés. Ce travail propose la définition d un modèle de sites. Le document est structuré de la façon suivante : Le chapitre 2 explique de façon générale le déploiement de logiciels. Il explique la problématique dans un contexte de déploiement à grande échelle. L étude de l état de l art est proposée dans le chapitre 3. La première partie de ce chapitre est le résultat d un travail en commun avec mon camarade Vincent Lestideau, étudiant de DEA qui travaille dans le domaine. Cette partie définit les concepts de base, et les différents niveaux identifiés dans le déploiement. La deuxième partie de ce chapitre présente des exemples d outils logiciels destinés à fournir un support automatisé au déploiement. Un issu du monde universitaire Software Dock et deux autres issus du monde industriel : Target Link et Tivoli. Le chapitre 4 présente notre approche. Nous présentons les techniques d introspection utilisées pour la capture de l information sur les sites et son utilisation dans le processus de déploiement. Puis nous proposions un modèle de site basé sur une approche objet que nous décrivons en utilisant la notation UML et la méthodologie enseignée en SI. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

8 2. Contexte Le processus de déploiement de logiciels couvre les étapes depuis que le produit est validé par le producteur jusqu à son installation sur les sites finaux. Dans ce travail, nous nous intéressons plus particulièrement au déploiement à grande échelle, dans le contexte d une entreprise, pour lequel un support automatisé est nécessaire. Ceci nécessite la prise en compte : - Des aspects organisationnels permettant d identifier les variables et contraintes en ce qui concerne les stratégies et la manière de travailler de l entreprise. - Des aspects techniques pour supporter le processus de déploiement. Ces technologies supportent différents degrés de complexité mais il n y a pas de solution complète qui couvre tout le cycle de vie du processus de déploiement. Au vu de ces aspects, nous avons identifié trois niveaux intervenant dans le processus de déploiement [3] : Producteur. Le producteur qui fournit le logiciel Entreprise. L entreprise qui met ensemble les différents composants en accord avec ses besoins pour avoir une application qui contient le logiciel prêt à déployer Utilisateur final (site) où le déploiement physique est fait en considérant toutes les contraintes de l environnement technique et de l organisation Notre étude à pour cadre de travail l application CATIA développée par Dassault, notre partenaire dans ce projet. CATIA est un logiciel de CAO composé de centaines de composants évoluant de plus en plus rapidement. De plus, CATIA est déployé à des milliers d utilisateurs finaux ce qui rend le déploiement complexe et envisageable uniquement à l aide d un support automatisé. Dans ce travail, nous nous intéressons plus particulièrement au niveau de l utilisateur final ( appelé site par la suite). L objectif est de développer un travail dans le cadre de la gestion de sites. Pour cela, il est nécessaire de faire l analyse des activités qui ont lieu au niveau du site, afin de proposer une approche dirigé par un modèle de sites qui permette d exprimer l information sur les sites de manière flexible et adaptable. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

9 3. Technologie de déploiement : Etat de l Art et de la Pratique. Dans ce chapitre, nous présentons premièrement les concepts du processus de déploiement en définissant le cycle de vie avec l identification des activités, modèles, rôles, produits et ressources. Ensuite, on explique les trois niveaux du processus. Pour l état de la pratique, nous présentons les outils logiciels Software Dock, Target Link et Tivoli. 3.1 Concepts Déployer un logiciel ne consiste pas seulement à installer le logiciel mais aussi à le gérer. On introduit ici la notion de cycle de vie, elle regroupe toutes les activités ayant lieu depuis la fin du développement jusqu à la désinstallation du logiciel sur les sites des utilisateurs. Dans le cas que nous traitons, les logiciels sont déployés au sein d une entreprise sur des milliers de machines. Ceci implique l existence de nombreuses configurations différentes. Il faut donc rajouter entre le niveau producteur (où est développé le logiciel) et le niveau site utilisateur (où est installé le logiciel) un autre niveau, celui de l entreprise. Afin de mieux comprendre le processus du déploiement, nous allons décrire rapidement ce qui se passe dans les 3 niveaux (figure 1). Dans notre travail, nous considérons le déploiement sous la forme de 3 processus, dont les activités sont réalisées sur des niveaux différents : Sur le niveau du Producteur, où l objectif est de livrer l application aux clients, Sur le niveau de l Entreprise, où l on va préparer le déploiement physique sur chaque machine, Sur le niveau de l Utilisateur, où l on installe l application spécifique à chaque machine. Producteur Entreprise Utilisateur Client Figure 1 Les trois niveaux de déploiement Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

10 Prenons le cas d une entreprise qui décide d installer un logiciel. Elle informe le producteur de son intérêt pour le logiciel. Dès la disponibilité d une (nouvelle) version du logiciel, le producteur en informe le client. Les logiciels, que nous déployons, sont constitués de composants. Souvent le client a la possibilité de sélectionner les composants, qui l intéressent. Les composants ont des relations et des dépendances entre eux, ainsi que des dépendances avec d autres logiciels. Ces informations doivent être fournies aux clients. Pour cela le producteur utilise un modèle d application. Notre étude concerne les logiciels complexes, qui sont déployés à grande échelle. Les clients ont généralement la possibilité de créer leurs propres extensions au logiciel. Il faut donc intégrer au logiciel un environnement de travail, qui permette de compiler et de tester le nouveau logiciel, obtenu en ajoutant les extensions. Une fois, que le client a choisi les composants qui l intéressent, le producteur prépare le logiciel (les composants), le modèle d application et l environnement de travail. Il «compresse» l ensemble et obtient un objet, que l on nomme «application producteur» Pour effectuer le transfert du producteur vers le client, il y a 2 stratégies. Dans la première, c est le producteur, qui décide d envoyer l application à ses clients. Dans ce cas, on parle de technique dite du «push». Dans la seconde c est le client, qui décide de la date du transfert. Ceci garantit au client une certaine indépendance envers le producteur et une sécurité plus grande pour son site (utilisation de firewall). Cette technique est dite du «pull». Le transfert une fois effectué, l entreprise doit intégrer ses propres extensions, si elles existent. Elle utilise pour cela, l environnement de travail qui doit être fourni par le producteur. Lors de ces ajouts, le modèle de l application est souvent modifié; on rajoute donc les nouvelles contraintes et dépendances au modèle. A la fin de cette étape, on a un nouveau logiciel et un nouveau modèle d application, le tout formant l «application entreprise». Dans une entreprise, tous les personnels n ont pas les même besoins. C est la raison pour laquelle, on doit connaître l organisation de l entreprise et les rôles de chacun de ses employés. Ceci va permettre de savoir quels composants on va fournir à chaque utilisateur du logiciel. L organisation sera obtenue au moyen d un modèle de l entreprise. La stratégie de l entreprise, elle aussi modélisée, permettra de réaliser une sélection parmi les composants du logiciel, afin de créer la configuration adéquate pour chaque utilisateur ou groupe d utilisateurs. La façon dont le déploiement vers les utilisateurs est effectué est aussi une stratégie de l entreprise. On peut choisir de déployer le logiciel vers tous les utilisateurs en même temps, c est la stratégie dite du big-bang. A l inverse, on peut déployer par étapes, par exemple, équipe par équipe. Il existe bien sur beaucoup d autres stratégies possibles. A la fin des ces activités, on sait pour chaque utilisateur quels composants, il recevra et quand il les recevra. Il faut ensuite installer physiquement le logiciel sur le site utilisateur. Ceci est réalisé selon la stratégie mise en place, au niveau entreprise. Au moment voulu, le processus installe le logiciel en le configurant, c est à dire en configurant les composants, que chaque utilisateur reçoit. Cette configuration est propre à chaque utilisateur, elle dépend en particulier des caractéristiques matérielles de son ordinateur. Par exemple, s il utilise WinNT, il faut que sa configuration fonctionne sous ce système. On a vu précédemment, que le logiciel pour fonctionner doit respecter des contraintes et des dépendances. Il faut Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

11 donc les vérifier et si c est nécessaire, dans le cas d une dépendance vis à vis d un autre logiciel, installer le logiciel en question, s il n est pas déjà présent sur la machine. Une fois la configuration et les vérifications terminées, on installe pour chaque utilisateur, la bonne configuration du logiciel. Il faut ensuite gérer le logiciel, tout le temps pendant lequel il sera présent sur le niveau utilisateur. La figure 2 montre les activités du déploiement. Le logiciel étant transféré, on exécute l activité activer, qui a pour rôle d activer les composants pour rendre le logiciel opérable, c est à dire prêt à fonctionner. Les composants peuvent être des serveurs, des clients, des bases de données (au sens client serveur) Dans cette description informelle, nous avons décrit les activités, modèles, produit et ressources qui participent au déploiement. Cependant, il y a des autres activités à considérer pour supporter les logiciels installés sur les sites. La figure 2 montre aussi les activités qui ont lieu à partir du déploiement d une nouvelle version du logiciel. L installation est faite sur les sites et différentes activités ont lieu, soit mettre à jour ou reconfigurer. Si une nouvelle extension entreprise est créée, cela modifie l application entreprise. Si l utilisateur est concerné par cette modification, il faut changer la configuration qui se trouve sur sa machine. On est aussi amené à modifier la configuration si des changements dans les caractéristiques matérielles du site ont eu lieu. Dans les 2 cas, l activité concernée s appelle «reconfigurer», Par ailleurs, le client peut souscrire auprès du producteur, afin d être informé lorsqu une nouvelle version du logiciel est disponible. Lorsque le producteur annonce au client, qu une nouvelle version du logiciel est disponible et que le client désire se la procurer, le processus présenté précédemment recommence. Il s agit alors de l activité «mettre à jour», ce qui peut ne concerner que certains des composants. Comme, on a vu auparavant, l installation entraîne l activation des composants. A l inverse «désactiver» désactive tous les composants actifs du système. Cette activité est souvent utilisée lors de la réalisation d une mise à jour ou d une désinstallation. L activité «désinstaller» consiste, comme son nom l indique à retirer le logiciel du site. Il ne faut pas oublier de modifier les registres et de faire attention aux ressources du logiciel (comme les bases de données) qui sont partagées avec d autres logiciels. Pour les logiciels comme CATIA, les producteurs fournissent un support, dont une des facettes importantes est l aide en ligne. Si le producteur décide de mettre fin à ce support, par exemple si le logiciel est devenu obsolète, alors il ne fournit plus de nouvelles versions, mais le logiciel reste sur les sites de ses clients. C est l activité «fin du support». Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

12 Nouvelle version Fin du support Installer Désinstaller Mettre à jour Reconfigurer Activer Désactiver Figure 2 Cycle de vie du déploiement Niveau du producteur Le but des activités sur le niveau du producteur est d envoyer l application aux clients. A ce stade du déploiement, on ne se contente pas d envoyer simplement le logiciel, on fournit aussi des outils de construction et de tests ainsi que l information nécessaire pour installer et gérer le logiciel sur les sites clients. L information sera fournie par le modèle d application. Tous ces éléments réunis forment l «application producteur». Le modèle d application consiste en la description de l architecture de l application en termes de composants et de connections. Il doit décrire notamment : Les options de l application, La compatibilité entre les versions des composants, Les contraintes (logicielles et matérielles), Les dépendances inter-applications (par exemple, nécessité d éditeurs de texte). En particulier, pour les applications très complexes, il est important de souligner les dépendances entre les applications afin de définir les stratégies du déploiement. Plus l application est complexe, plus le modèle d application doit être détaillé, pour réaliser les activités d installation et de maintenance. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

13 Une fois l application développée, le producteur annonce aux clients, qu une (nouvelle) version est disponible. Cette annonce peut se faire sous diverses formes, par exemple, diffusion multicast. Nous avons choisi de donner la possibilité au producteur de configurer le logiciel avant de l envoyer au client. Cette situation, lorsque que le client souscrit pour une partie seulement des fonctions du logiciel. (Par exemple, il ne veut pas la fonction 3D du logiciel CATIA). Une fois, les fonctionnalités choisies, il y a sélection des «artefacts» qui correspondent et création de l application. Pour chaque application, le producteur fournit un support. Cela peut être une aide en ligne. Si le producteur décide de mettre fin au support, il doit l annoncer aux clients de l application. On peut résumer les activités effectuées sur le niveau du producteur par la figure 3. Artefacts Modèle d application Outils construction &test Nouvelle version disponible Fin Support pour un produit sélectionner configurer Créer l application Notifier Application Figure 3 Le schéma des activités sur le niveau producteur Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

14 On obtient donc à la fin des activités effectuées sur le site du producteur, l application producteur. On peut alors transférer cette application sur le site de l entreprise cliente. Ce transfert peut utiliser l une des 2 techniques «push» ou «pull» déjà présentées. Cette application contient un environnement de travail permettant de rajouter des composants à l application Niveau de l entreprise Une fois l application transférée sur le niveau entreprise, le but est de préparer le déploiement physique vers les machines utilisateurs. A ce moment du déploiement, il faut remarquer que les clients des applications, que nous souhaitons déployer, ont souvent créé leurs propres extensions, qu il faut rajouter à l application producteur. Dans le cas du logiciel CATIA, par exemple, l entreprise BOEING rajoute plusieurs millions de lignes de code. C est l étape, que nous appelons «Assembler». Elle consiste à utiliser les outils de construction et de tests fournis par le producteur, afin de composer la nouvelle application que nous appelons application entreprise. Ce changement implique aussi une modification, qui peut être importante, du modèle d application. En effet, il faut tenir compte des nouvelles contraintes et dépendances, que le changement peut générer. Ce nouveau modèle d application entreprise va être exploité dans l étape suivante. Application Extensions locales assembler Dé faire composer tester Créer nouvelle application Application entreprise Figure 4 Création de l'application entreprise Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

15 Connaissant ce qui va être déployé, il reste à fixer où, quand et comment le déploiement va se réaliser. C est le rôle de l activité appelée «prédisposer». Cette activité établit un lien entre l application de l entreprise et l organisation de celle ci. L organisation est contenue dans un modèle d entreprise associé à des stratégies de déploiement. Ces stratégies sont en fait un ensemble de contraintes (par exemple, l équipe A doit avoir la nouvelle version avant l équipe B), de politiques de contrôle du déploiement (comme la notification) et la méthode à employer (big-bang..). Le modèle d entreprise décrit l organisation de l entreprise en termes d équipes, d agents humains, de positions (par exemple, manager ou ingénieur) et de rôles (programmeur, testeur...). Il est important de prendre en compte cette information car la façon dont l entreprise est organisée peut affecter le déroulement du processus de déploiement. Par exemple, le modèle de l entreprise peut montrer les flux de données entre équipes de travail, ce qui est utile pour définir l ordre des activités du processus de déploiement. Supposons que les documents, sur lesquels l équipe B travaille, soient développés par l équipe A, 2 semaines auparavant. Il faut donc déployer l application chez B, au plus tard 2 semaines après l avoir déployé chez A. De même, il est intéressant de faire le déploiement en considérant les projets de travail (et leurs planifications) dans l entreprise. Le résultat de cette activité est un modèle de déploiement, qui spécifie pour chaque utilisateur, quelle version de l application il aura selon sa position, son rôle ou son équipe. Il spécifie aussi à quel moment et comment, l utilisateur aura cette application. Modèle entreprise Stratégies de déploiement Modèle application entreprise Prédisposer Modèle déploiement Figure5Créationdumodèlededéploiement Nous disposons donc de l application entreprise, qui contient ce qui va être déployé et du modèle de déploiement, qui spécifie où, quand et comment le déploiement va être réalisé. Il reste à réaliser le déploiement physique sur les machines. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

16 3.1.3 Niveau de l utilisateur Nous utilisons le modèle de site, qui donne les informations liées au matériel et aux logiciels installés sur la machine cible. Cette information sur les cibles doit être exploitée pour réussir le déploiement. Avant de faire le déploiement, li est nécessaire de vérifier que la cible satisfait les contraintes matérielles ainsi que logicielles de l application à déployer. On peut décomposer le déploiement physique en différentes activités : Configurer. Choisir les meilleures options pour l installation selon l information contenue dans le modèle du site, Mettre à disposition. L application est prête à être déployer sur une cible (elle est configurée), Transférer. Transport de l application à l utilisateur final. A noter que les transferts se font souvent dans un format compressé, Installation. L application est installée. Une fois l application installée sur le site, d autres activités sont à considérer comme : Mise à jour et Adaptation. La différence entre ces deux opérations est la suivante : la mise à jour est due à une modification faite au niveau de l entreprise ou au niveau du producteur, et l adaptation est une réponse à des modifications faites au niveau de l utilisateur final, Reconfiguration dynamique. Le logiciel doit être capable de se reconfigurer si nécessaire. Application entreprise Modèle déploiement Modèle site configurer Mettre à dispositio n transférer Application deployable Figure 6 Création de l'application déployable Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

17 3.2 Les Outils Logiciels Dans cette section, nous présentons une synthèse de trois outils logiciels qui servent au processus de déploiement. Les deux premiers outils présentés donnent une approche différente de la façon de faire le déploiement : le premier, Software Dock, est le résultat d un travail de recherche et l autre, Target Link, est un produit industriel utilisé pour déployer sur les sites des utilisateurs finaux. Le troisième outil exposé est Tivoli. En particulier nous expliquons le détail des deux produits de la famille Tivoli, la distribution de logiciels et «l inventory». Ces produits sont analysés afin de mieux comprendre la gestion de sites Produit Universitaire : Software Dock Software Dock (SD) permet d installer et de gérer des applications avec des relations clients/serveurs. Il est le résultat d un travail de recherche effectué à l université du Colorado. SD introduit la notion de famille de logiciels, représentant un ensemble de configurat ions ou de versions du logiciel. SD décrit les différent s sit es et les configurations logicielles par le biais de fichiers appelés Deployable Software Description (DSD), qui sont spécifié en XML. Afin de mieux comprendre le fonctionnement de SD, prenons un exemple de logiciel à déployer Exemple Considérons le logiciel réalisant le jeu du Solitaire. Ce logiciel existe sous 2 versions : 1.0 et 1.2. Chacune de ces versions existe sous 2 formes : Win95 et Solaris. L utilisateur a la possibilité de configurer son application, en particulier il peut installer un fichier d aide. Ce fichier se présente sous 2 formes : html ou hlp. Afin d assurer un bon fonctionnement de l application, on impose que l architecture du site client soit de type ipc86 et que la mémoire soit supérieure à 64Mo pour la version Win95 et à 32Mo pour la version Solaris. De plus, pour fonctionner, on doit trouver sur le site client, les cartes à jouer, qui appartiennent à une autre famille. De plus, on impose la version 1.2 de cette dépendance. Pour réaliser le déploiement, on doit modéliser le client, le serveur et les applications (solitaire et cartes) Concepts Dans Software Dock, il y a 2 concepts importants : les Docks, qui modélisent les clients et les serveurs et les fichiers DSD, qui modélisent les applications. A chaque Dock, on associe un «registre» et un ou plusieurs agents. Un registre est une base de données que les agents modifient. Chaque modification de la BD entraîne des événements, auxquels les agents peuvent souscrire. Il y a 2 types d agents : Ceux qui peuvent migrer vers d autres Docks, ce sont les agents externes, comme l agent d installation, Ceux qui restent fixés à leur Dock, ce sont les agents internes, comme l agent de site, qui gère les modifications sur les sites. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

18 La notion de Dock Les Docks servent à modéliser les différents niveaux du déploiement, que sont le producteur (ReleaseDock), l entreprise (InterDock) et l utilisateur (FieldDock). FieldDock : Il réside sur le site consommateur. Il y en a un par site consommateur. Il offre un registre d informations sur l environnement matériel et logiciel présent sur le site. Ses agents (notamment l agent de site) gèrent les modifications apportées à l environnement. ReleaseDock : Il réside sur le site producteur. Il offre un registre d informations sur les différents logiciels disponibles pour le déploiement. Il possède les agents utilisés lors du déploiement tels que l agent d installation et celui de mise à jour. Son registre d informations est modifiable via une interface utilisateur. Dés qu un client choisit de télécharger un logiciel, un agent est envoyé sur le site consommateur. Cet agent interagit avec le FieldDock du consommateur et obtient l information sur la configuration appropriée. Ensuite, il retrouve les composants corrects dans le Release Dock et il les installe sur le site consommateur. Interdock : Il réside dans une organisation intermédiaire entre les producteurs et les sites cibles. Il offre des informations globales afin de créer une vue globale de l organisation (qui comprend plusieurs Field Dock). Les fichiers DSD Ils modélisent les différents sites et les applications. Le serveur (releasedock.dsd) : Ce fichier spécifie la localisation du serveur et les différentes applications que le serveur peut déployer. Pour chaque application, on a la localisation du fichier DSD correspondant et le nom de la famille à laquelle il appartient. Le client (FieldDock.dsd) : Ce fichier spécifie la localisation du client et les informations matérielles (architecture, mémoire ) et logicielles (OS et les applications déjà présentes sur le site..). Les applications : Ces fichiers DSD sont basés sur la notion de propriété. Les propriétés sont des paires nom-valeurs. Elles sont divisées en 2 classes : internes et externes. Les propriétés externes se rapportent aux propriétés qui décrivent le site utilisateur (par exemple, le système opérateur ou l architecture). Les propriétés internes décrivent des caractéristiques du système lui-même, comme la version. Les attributs d une propriété sont le nom, le type (chaîne de caractères, entier ou booléen) et la valeur par défaut. Pour certains types, on peut associer un ensemble Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

19 de valeurs possibles pour la propriété. Par exemple pour la propriété qui indique la version, on peut donner le choix entre la version 1.0 ou 1.2. Chaque logiciel a des exigences matérielles ou logicielles afin de pouvoir s exécuter normalement, ce sont les contraintes. Par exemple, un espace disque suffisant ou un autre logiciel. On distingue 2 types de contraintes, celles qui sont résolvables et les autres. Une assertion est une contrainte qui ne peut pas être résolue, si elle n est pas vérifiée. Dans notre exemple, nous imposons que l OS soit du type Win95 ou Solaris. Si l OS de l utilisateur est du type Unix, alors le déploiement du logiciel échoue. Une dépendance est une contrainte, qui peut être résolue, par exemple si la présence d un autre logiciel est exigée, alors on installe celui-ci et ensuite, on continue. Les artefacts sont les fichiers physiques, qui composent le logiciel. Pour chacun, on spécifie son nom et sa localisation avant et après le déploiement. Les Artefacts sont regroupés dans des collections Enfin pour chaque DSD, on spécifie les agents, qui seront fournis par le système (agent d installation, de mise à jour ) Les activités supportées par le processus de déploiement Il y a 5 activités du cycle de vie mises en œuvre par SoftwareDock : l installation, la mise à jour, la reconfiguration, la vérification de cohérence et la désinstallation. L installation Au début du déploiement, l agent d installation est téléchargé vers le FieldDock. Le téléchargement est initié soit par l utilisateur, soit par un autre agent lors de l installation d une dépendance par exemple. Une fois en place, il récupère le registre de configuration du site. Ensuite, il récupère la liste des dépendances du logiciel. S il y en a et que le logiciel en question n est pas installé sur le site, l agent fait une requête au serveur pour télécharger l agent d installation du ReleaseDock du logiciel. Une fois la dépendance résolue, l agent d installation récupère la bonne configuration du logiciel. Ensuite, il crée un nœud application pour le logiciel dans le registre du FieldDock, un événement est généré, qui est reçu par l agent de site du FieldDock. Cet agent crée un répertoire physique pour la nouvelle application. Ensuite, l agent d installation insère les nœuds des fichiers et des répertoires du logiciel, juste sous le nœud application créé précédemment. A chaque insertion, un événement est généré et l agent de site crée physiquement l arborescence. A la fin de l installation, on arrime au FieldDock, l agent de mise à jour. La mise à jour Lorsqu une nouvelle version est disponible, on l insère dans le regist re du ReleaseDock. L événement ainsi généré est reçu par l agent de mise à jour, qui avait souscrit à ce type d événement. Cet agent recherche le registre du FieldDock et communique avec le ReleaseDock, pour retrouver la bonne configuration. Il insère ensuite, les nœuds fichiers et répertoires, qui correspondent et l agent de site crée physiquement l arborescence. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

20 La cohérence Vérifier la cohérence du logiciel, c est à dire vérifier que tous les fichiers et répertoires sont bien présents, consiste à comparer le nœud de l application avec la réalité physique. La reconfiguration La reconfiguration consiste à réinstaller le logiciel sous sa nouvelle configuration. La désinstallation Cette activité consiste à effacer physiquement l application et à enlever les nœuds, qui correspondent à l application L architecture Agent Agent Release Dock Agent Serveur d événements Inter Dock Agent Agent Field Dock Agent Agent Agent Field Dock Agent Figure 7 Architecture de Software Dock Les agents sont codés en Java, dans en environnement multi-agents dont la mobilité est assurée par l outil Voyager. La gestion des événements entre les différents Docks est assurée par un serveur d événement. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

21 3.2.2 Produit Industriel : Target Link Target Link est un produit basé sur Java qui réalise les fonctions de distribution et d installation des logiciels [12]. Ces logiciels sont déployés sous la forme de packages. Un package est formé par des composants compressés de logiciels Concepts La notion d application Pour Target Link, une application est un fichier de type binaire, texte ou autre. Une application est définie par les attributs suivants : Nom Version Etat : Approuvé ou en attente Type : Indique le type de traitement lors de l installation et de l exécution OS supporté Localisation Tant que l application ne se trouve pas dans l état «Approuvé», elle peut être utilisée pour former des packages. La notion de package Un package est un ensemble d applications qui forment le logiciel à déployer. package est défini par les attributs suivantes : Un Nom Version Etat Nombre d applications composant le package OS supporté Les scripts de pré et post installation Le script d installation La notion de template Un template est un ensemble de packages. Les templates peuvent être assignés à un utilisateur ou à un groupe selon leur profil Les composants QPREP. Les outils fournis par ce module sont Packaging et des utilitaires. Les fonctions de Packaging comprennent : Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

22 QZip. Compresse un ensemble de fichiers pour générer des fichiers avec l extension qpk. Qpack. Montre les modifications faites au système pendant l installation d un logiciel et établit un package avec ces modifications. QinstallShield. Établit le package d un logiciel qui a été crée en utilisant InstallShield. Les fonctions utilitaires sont : Traces d Installation Traces de de-installation Vérification de l intégrité d un fichier avec l extension qpk. Vérification de l intégrité d une installation faite à partir d une application type Qinstall. Stockage du package dans la base de données. Administrateur L administrateur est le responsable de la gestion des utilisateurs, des groupes, des packages et des notifications. Il a l autorisation pour préparer les packages ; programmer les notifications et les déploiements ; définir les groupes des utilisateurs et leurs profils. Un package peut avoir différentes contraintes matérielles et logicielles pour pouvoir s installer. Les contraintes matérielles peuvent être par exemple, une quantité minimum d espace disque, des contraintes de dépendances ou des conflits avec d autres logiciels. Client Le client peut souscrire aux différents packages qu il souhaite recevoir. Il peut aussi choisir le répertoire où le logiciel sera installé si l administrateur ne l impose pas. Le client peut exécuter deux actions qui sont déjà prédéfinies en Target Link : vérification de l espace disque avant de faire l installation et le «checksum» des fichiers pour s assurer qu ils sont en bon état. Le checksum compte le nombre de bits dans une unité de transmission de telle façon que le client puisse vérifier si le même nombre est arrivé. Le client a aussi la possibilité de vérifier l intégrité des logiciels installés et de faire une adaptation (re-installation) si nécessaire. Base de données Toutes les actions faites chez le client sont gardées dans la base de données. Il est possible de consulter cet historique par utilisateur et par package déployé. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

23 Les activités La notification Target Link utilise des notifications pour prévenir et envoyer des actions aux utilisateurs. Ces notifications indiquent si l action à réaliser est un téléchargement ou une installation. La notification peut avoir une action obligatoire, c est à dire, la notification prévient le client et l action s exécute immédiatement. En revanche, s il n y a pas d action obligatoire, la notification va demander au client s il veut faire l installation à ce momentlà ou après. La notification peut être dirigée vers un utilisateur, vers un groupe ou vers tous les souscripteurs de l application. Un seul package ou un template est déployé à la fois. L installation En utilisant la technique pull, le client peut souscrire aux packages disponibles. De cette manière, il peut recevoir des notifications quand une nouvelle version est prête. Le client peut aussi faire des téléchargements des logiciels ainsi que des installations. Au moment d assigner un template à un utilisateur ou à un groupe d utilisateurs, l ensemble des packages qui appartiennent à ce template sont déployés immédiatement et sans notification. C est la technique push. Une autre façon de faire un déploiement avec cette technique est via l envoi d une notification associé à une action obligatoire au client Exemple Le composant Qprep permet de sélectionner un ensemble de fichiers afin de les compresser et obtenir un fichier avec l extension qpk. Ces types de fichiers sont utilisés pour vérifier l intégrité du logiciel. Ce fichier est mis dans la base de données de manière qu il puisse être accessible depuis l interface de l administrateur. L administrateur définit une application qui contient le fichier qpk. Il crée ensuite un package qui contient cette application et d autres pour former le logiciel à déployer. Ce package est envoyé avec des notifications à tous les clients ayant souscrit à ce package. Le client reçoit la notification et décide de transférer puis de l installer immédiatement ou en différé. Les états de la notification, et de l installation sont rapportés au serveur et tout l historique est gardé dans la base de données. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

24 Structuration des composants Administrateur Client Préparer le package Création des templates Installation à distance Monitor Etat Souscription Serveur Templates Demande applications Notification et Distribution QPrep Préparations de fichiers Traces d installation Compression Utilitaires Base de données Info de packages, clients, états. Figure 8 Architecture de Target Link Synthèse des Outils Chacun de ces 2 outils a des avantages et des inconvénients, mais aucun d eux ne permet d automatiser entièrement le déploiement. Les points communs : La possibilité de réaliser les activités de reconfiguration et de vérification de la cohérence, La gestion des contraintes logicielles Les points forts : Target Link : La possibilité d utiliser les 2 modes de transfert «pull» et «push» lors de l installation Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

25 La notion de groupe, pour la souscription et le transfert, La planification du déploiement, La notification. SoftwareDock sont : La possibilité de configurer le logiciel pendant le déploiement, La grande diversité des contraintes matérielles (liste extensible). Les points faibles : Target Link : Les contraintes matérielles sont faiblement représentées avec 2 éléments (OS et checksum), Pas de possibilité de configurer pendant le déploiement, on doit créer un package par configuration, L architecture du logiciel chez le client est la même que celle sur le serveur du producteur. SoftwareDock : Pas de planification possible, Pas de notification, Pas de notion de groupe existante, un package pour un seul utilisateur, Pas d installation possible en mode pull, Conclusion : Les 2 outils ont des caractéristiques intéressantes. Les points forts de TL sont au niveau du transfert et de l installation (notion de groupes, notification, souscription ) et ceux de S/W sont au niveau du modèle d application (contraintes matérielles et logicielles ) Système de Gestion d Applications : Tivoli Tivoli est un système de déploiement intégrant un outil puissant appelé système de gestion d applications (SGA) qui collecte l information matérielle et logicielle des sites de manière automatique [11]. La base de données des SGA est généralement centralisée. Elle contient l information sur les applications et les sites. Dans ce qui suit nous décrivons le Systèmes de Gestion d Applications TME-10 de Tivoli en ce qui concerne l Inventory et la distribution de logiciels Tivoli Inventory Ce produit collecte l information à partir des différents sites de l entreprise et garde toute l information dans une base de données relationnelle [7]. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

26 Caractéristiques : La collection d informations est réalisée par différents outils spécialisés qui existent sur le marché. Tivoli contient un module qui rend la communication transparente avec n importe quelle type de base de données relationnelle. L information collectée est mise dans la base de données en accord avec le modèle de données défini par Tivoli. Tivoli utilise principalement deux relations : une pour les logiciels définies dans l environnement et l autre pour les logiciels installés sur chaque nœud. Ces relations sont mises à jour à chaque requête. La façon de fonctionner de Tivoli Inventory est : 1. L administrateur détermine les types de données à chercher sur les sites en utilisant Tivoli. 2. L outil de collection de données réalise les opérations de requête sur les sites 3. L outil de collection donne comme résultat un fichier de type MIF. Ces types de fichiers sont créés basés sur un format standard industriel. 4. Les fichiers MIF sont transportés au serveur de Tivoli Inventory. 5. Les données sont traitées puis stockées dans la base de données Tivoli Inventory et Tivoli Software Distribution Ces deux produits ont été intégrés afin de considérer l état des applications déployées dans la base de données du Tivoli Inventory [8]. Caractéristiques : Les relations utilisées par Tivoli Software Distribution sont créés quand on définit le modèle de données en Tivoli Inventory. Tivoli Software Distribution fait des requêtes à la base de données avant de faire le déploiement. Tivoli Software Distribution fait le déploiement vers le(s) groupe(s) d ordinateurs sélectionnés. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

27 4. Notre Approche 4.1 Introduction Le déploiement est une étape importante dans le cycle de vie d une application. C est la phase de mise à disposition des utilisateurs de l application. Cette application devra être installée sur les postes de travail et ceci sans entrer en conflit avec d autres logiciels déjà installés. Le déploiement automatisé permet une réduction importante des coûts (déploiement limité dans le temps, déplacements sur sites réduits) et permet d assurer une cohérence globale des sites en terme de versions installées et licences. Il permet aussi une facilité de développement accrue. Pour offrir un niveau d automatisation élevée, il est important de s appuyer sur des modèles puissants permettant d exprimer toutes les caractéristiques du déploiement. Dans ce travail nous nous sommes intéressés plus particulièrement à la conception d un modèle de sites Les aspects que nous considérons concernent l introspection des sites (identifier la configuration matérielle, logicielle ) et leur suivi en terme de disponibilités des logiciels installés ainsi que leur profil en terme d organisation d entreprise. On doit tenir compte de ces aspects afin de pouvoir prévoir l impact du déploiement sur l organisation. La gestion des sites traite de la saisie, la mise à jour et l utilisation de cette information. Les informations sur les sites ainsi que leur gestion sont généralement centralisées. Il existe ainsi des outils logiciels qui peuvent réaliser les opérations de collection d information à partir des sites et leur stockage dans une base de données centrale. Dans ce type d environnement, un administrateur est responsable de l approbation des nouvelles versions et du contrôle de toutes les activités de déploiement vers les sites [6]. De plus, on introduit la notion de réalisation du déploiement vers un utilisateur et non vers un ordinateur ce qui permet d offrir un niveau de granularité plus fin. La description des sites est précisée dans l annexe A. 4.2 Modèle de Sites Dans cette section, nous présentons notre modèle de sites à l aide de la notation UML [9]. Premièrement, on décrit l expression de besoins à travers l identification des cas d utilisation. A partir de ces cas d utilisation, on extrait les scénarios et on construit les diagrammes de séquence. Pour l analyse, on explique les transitions d états de l application à déployer. Enfin, nous présentons le modèle de classe avec l explication de chaque classe et association Expression des besoins Le déploiement peut se réaliser de deux manières : PUSH ou PULL. La technique utilisée dépend de la stratégie définie dans le modèle de déploiement. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin

28 L entreprise est représentée par une station centrale. Dans cette station, on administre toutes les applications à déployer vers les sites utilisateurs. Ces sites se trouvent connectés à la station centrale à travers des réseaux internet, intranet ou extranet. Les sites peuvent recevoir ainsi les applications via le réseau. Quand l entreprise transfère l application aux sites, on parle de technique PUSH et quand l utilisateur demande l application, on parle de technique PULL. Entreprise PULL PUSH Site Internet/Intranet Site PULL Site Site PUSH Site Figure 9 Déploiement PUSH et PULL Cas d utilisation Le déploiement PUSH est déclenché par l administrateur des systèmes au niveau de l entreprise. Par contre, le déploiement PULL est déclenché par l utilisateur à partir du site. Les deux déploiements visent le même but, celui de l installation d applications dans les stations de travail et ordinateurs des utilisateurs. Dans notre approche, le déploiement PUSH est dirigé vers une cible identifiée en terme d utilisateur. Une relation utilisateur ordinateur est définie pour déterminer les machines sur lesquels l installation sera faite. La vérification de contraintes matérielles et logicielles préalables à l installation, est rendu nécessaire car l environnement peut changer dynamiquement. Le procédé PULL est initié suite à des notifications informant de la disponibilité de nouveaux logiciels ou versions. Au moment, où il décide l installation (PULL), un processus de «Vérification Contraintes» est entamé. Ana Laura GOMEZ DEA Systèmes d Information 26 Juin