Université de Savoie Laboratoire LSR-IMAG de Grenoble Mémoire rédigé dans le cadre du DEA D INFORMATIQUE : COMMUNICATION ET COOPERATION DANS LES SYSTEMES A AGENTS Modèle d application pour le déploiement de logiciel Soutenu le 28 juin 2000 Par Vincent Lestideau Sous la direction de Messieurs Noureddine Belkhatir et Pierre Yves Cunin Travail effectué au sein de l équipe génie logiciel Adèle LSR
Remerciements Je tiens tout particulièrement à remercier : Noureddine Belkhatir et Pierre Yves Cunin pour avoir acceptés de m encadrer dans ce travail, Les personnes de l équipe Adèle du laboratoire Logiciel Systèmes et Réseaux, pour leur accueil chaleureux, Flavio Oquendo pour sa collaboration. Laura Gomez pour sa participation dans ce projet Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000 - i
Résumé Ce travail traite du déploiement logiciel et des modèles d application pour la description des logiciels, et en particulier le logiciel de CAO CATIA de Dassault Système. Ces modèles décrivent la structure de l application à déployer et ses caractéristiques. Les déploiements actuels sont en parti manuel, ce qui implique un coût important en temps et en moyens humains. 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. Ainsi la technologie et le procédé de déploiement sont complètement intégrés avec l Internet exploitant les possibilités offertes par cette infrastructure. 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 les modèles d application. 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ésultants de la recherche et de l industrie. Nous avons ensuite proposé un modèle objet permettant d exprimer les caractéristiques des applications. L intérêt de cette modélisation est de permettre à un outil externe comme SoftwareDock de gérer la configuration et l installation de l application. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000 - ii
Table des matières 1. Introduction...1 2. Contexte...3 3. Technologie de déploiement : Etat de l art et de la pratique...4 3.1. Concepts... 4 3.1.1. Niveau du producteur... 7 3.1.2. Niveau de l entreprise cliente... 8 3.1.3. Niveau de l utilisateur final... 11 3.2. Les 2 outils... 12 3.2.1. Un outil universitaire : SoftwareDock... 12 3.2.1.1. Exemple... 12 3.2.1.2. Concepts... 12 3.2.1.2.1. La notion de Dock... 12 3.2.1.2.2. Les fichiers DSD... 13 3.2.1.3. Les activités supportées par le processus de déploiement:... 14 3.2.1.4. L architecture :... 15 3.2.2. Un outil industriel : Target Link... 16 3.2.2.1. Concepts... 16 3.2.2.2. Les composants... 16 3.2.2.3. Les activités... 17 3.2.2.4. Exemple... 18 3.2.2.5. Architecture des composants... 18 3.2.3. Synthèse des 2 outils... 19 3.3. Les modèles d application... 20 3.3.1. Open Software Description (OSD)... 20 3.3.2. Deployable Software Description (DSD)... 21 3.3.3. Synthèse... 24 4. Notre approche...25 4.1. Introduction... 25 4.2. Expression des besoins...25 4.3. Modèle d application... 25 4.3.1. CATIA... 25 4.3.1.1. Présentation... 25 4.3.1.2. Architecture de CATIA... 26 4.3.1.3. Modélisation de CATIA... 29 4.3.2. Modèle d application... 32 4.3.2.1. Les propriétés du logiciel... 32 4.3.2.2. Les propriétés importées... 32 4.3.2.3. Les règles de composition... 32 4.3.2.4. Les contraintes... 32 4.3.2.5. Les interfaces... 32 4.3.3. La modélisation de CATIA en utilisant DSD... 33 4.3.3.1. Le modèle de classes... 33 4.3.3.2. Justification du modèle... 34 4.3.3.3. Mise en œuvre vers un outil de déploiement... 34 Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000 - iii
5. Expérimentation...36 5.1. Générer le modèle d application... 36 5.1.1. Saisie des informations sur CATIA... 37 5.1.2. Saisie des informations nécessaires au déploiement... 39 5.1.3. Génération du modèle d application... 39 5.2. Déploiement... 39 6. Conclusions et Perspectives...41 Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000 - iv
Table des Illustrations Figure 1 : Les 3 acteurs du déploiement... 4 Figure 2 : le cycle de vie d un logiciel... 7 Figure 3 : Le schéma des activités sur le niveau producteur.... 8 Figure 4 : Creation de l application entreprise... 9 Figure 5 : Création du modèle de déploiement... 10 Figure 6 : Création de l application deployable... 11 Figure 7 : Architecture de SoftwareDock... 15 Figure 8 : Architecture de Target Link... 18 Figure 9 : Exemple graphique d une règle de composition... 22 Figure 10 : Exemple de possibilités de configuration pour CATIA... 26 Figure 11 : arborescence vue de la racine... 27 Figure 12 : Arborescence de CATIA chez le producteur... 27 Figure 13 : Arborescence des frameworks Code chez le client... 28 Figure 14 : Arborescence des frameworks Education chez le client... 29 Figure 15 : Modélisation de CATIA... 31 Figure 16 : Modèle de classes... 33 Figure 17 : Exemple d une fenêtre de saisie d informations... 36 Figure 18 : Fenêtre création des listes d informations... 37 Figure 19 : Fenêtre de création des frameworks Code et Education... 38 Figure 20 : Fenêtre d aide à la saisie de l expression de garde... 38 Figure 21 : Fenêtre résumant les différentes étapes de l installation... 40 Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000 - i
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 les preuves. 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. 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 vitale pour réussir ses opérations. 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és 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. Le domaine des systèmes de déploiement logiciel s'intéresse à la conception et au développement de systèmes destinés à fournir un support automatisé au déploiement des logiciels à grande échelle. Les systèmes de déploiement considèrent pour la plupart un processus simplifié et des logiciels avec une structure pauvre en terme de répertoires et de fichiers. Ils offrent des services d installation, de mise à jour et de notification et supportent quelques contraintes matérielles et logicielles simples et prédéfinies. La prochaine génération de systèmes de déploiement augmentera le niveau d automatisation des procédés et fournira des facilités pour personnaliser et automatiser le processus de déploiement. Il s agit d une approche supportant des services adaptables et composables. Cette nouvelle génération de systèmes tend à s appuyer sur des modèles puissants : modèle d application décrivant la structure de l application à déployer et ses caractéristiques, modèle d entreprise décrivant l organisation de l entreprise où s effectue le déploiement, modèle de processus décrivant le processus de déploiement et les stratégies à employer, modèles de sites décrivant les caractéristiques des différents sites en terme de configuration logicielle et matérielle et leurs états en terme de logiciel déployé. Le document est structuré de la manière suivante : Le chapitre 2 présente le contexte du déploiement à grande échelle et sa problématique. L'état de l art et de la pratique correspond au chapitre 3. La première partie de ce chapitre est le résultat d un travail en commun avec ma camarade Laura Gomez (DEA SI), qui travaille sur l aspect site du déploiement. Elle consiste en une explication générale du processus de déploiement [4], en définissant les concepts de base et les 3 niveaux identifiés dans le processus. La deuxième partie détaille plus particulièrement 2 outils fournissant un support automatisé au déploiement. Il s agit d un produit universitaire SoftwareDock [8,9,10,11,12] et d un produit industriel Target Link [19]. Enfin, la dernière partie de ce chapitre 3 est en rapport avec mon thème de travail. Elle présente 2 modèles d application, Open Software Distribution (OSD) [13,14,15] et Deployable Software Distribution (DSD) [8,9,10]. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-1
Le chapitre 4 présente notre approche d un modèle d application avec ses besoins et notre proposition d un modèle d application illustré avec le logiciel CATIA de Dassault Système [6]. Dans le chapitre 5, nous décrivons le prototype permettant à un outil externe (ici SoftwareDock) de prendre en charge le déploiement sur les postes cibles. En conclusion, nous analysons les résultats obtenus en soulignant les intérêts de notre approche et évoquons les perspectives de ce travail. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-2
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 : Niveau producteur. Le producteur qui fournit le logiciel Niveau entreprise. L entreprise qui met ensemble les différents composants en accord à ses besoins pour avoir une application qui contient le logiciel prêt à déployer Niveau 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 a pour cadre de travail l application CATIA [6] 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 modèle d application, qui caractérise le logiciel. Pour cela, nous avons étudié 2 outils d automatisation du déploiement et 2 modèles d applications. Ceci nous a permis d exprimer toutes les informations nécessaires au déploiement. A partir de ces informations, nous avons introduit une approche de modélisation orientée objet. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-3
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, nous expliquons les 3 niveaux du processus. Pour l état de la pratique, nous présentons les outils logiciels SoftwareDock et TargetLink, puis 2 modèles d application Open Software Distribution et Deployable Software Distribution. 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 [11], 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 Client Utilisateur Figure 1 : Les 3 acteurs du déploiement 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 Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-4
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 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. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-5
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 (au sens client serveur), des bases de données Dans cette description informelle, nous avons décrit les activités, modèles, produits et ressources qui participent au déploiement. Cependant, il y a d 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. Il s agit de «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», 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». Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-6
Nouvelle version Fin du support Installer Désinstaller Mettre à jour Reconfigurer Activer Désactiver Figure 2 : le cycle de vie d un logiciel 3.1.1. 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. 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, existe 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. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-7
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 de l application Modèle d application Outils de construction et de tests Nouvelle version disponible Fin du 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. 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. 3.1.2. Niveau de l entreprise cliente 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, Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-8
que le changement peut générer. Ce nouveau modèle d application entreprise va être exploité dans l étape suivante. Application Les extensions locales Assembler Défaire Composer Tester Créer la nouvelle application et son modèle Application entreprise Figure 4 : Creation de l application entreprise 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ée 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. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-9
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 Figure 5 : Création du modèle de dé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. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-10
3.1.3. Niveau de l utilisateur final 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, il 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éployée 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 à disposition transférer Application deployable Figure 6 : Création de l application deployable Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-11
3.2. Les 2 outils 3.2.1. Un outil universitaire : SoftwareDock SoftwareDock (SD) [8,9,10,11,12] 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 configurations ou de versions du logiciel. SD décrit les différents sites et les configurations logicielles par le biais de fichiers appelés Deployable Software Description (DSD), qui sont spécifiés en XML [3]. Afin de mieux comprendre le fonctionnement de SD, prenons un exemple de logiciel à déployer. 3.2.1.1. 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 logiciels. 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). 3.2.1.2. Concepts Dans SoftwareDock, 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 [18], 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. 3.2.1.2.1. 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 Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-12
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 FieldDock). 3.2.1.2.2. 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-valeur. 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 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 ). Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-13
3.2.1.3. 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, puis 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 registre 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. 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. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-14
3.2.1.4. 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 SoftwareDock Les agents sont codés en Java, dans un environnement multi-agents dont la mobilité est assurée par l outil Voyager [16]. La gestion des événements entre les différents Docks est assurée par un serveur d événements [18]. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-15
3.2.2. Un outil industriel : Target Link Target Link [19] est un produit basé sur Java qui réalise les fonctions de distribution et d installation des logiciels. Ces logiciels sont déployés sous la forme de packages. Un package est formé par des composants compressés de logiciels. 3.2.2.1. 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 un é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. Un package est défini par les attributs suivants : 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é à un utilisateur ou à un groupe selon leur profil. 3.2.2.2. Les composants Qprep Les outils fournis par ce module sont Packaging et des utilitaires. Les fonctions de Packaging comprennent : 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. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-16
QinstallShield. Installe le package d un logiciel qui a été créé en utilisant InstallShield. Les fonctions utilitaires sont : Traces d Installation Traces de désinstallation 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 et 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 (ré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é. 3.2.2.3. 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 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 moment là 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é à chaque fois. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-17
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. 3.2.2.4. Exemple Le composant Qprep permet de sélectionner un ensemble de fichiers afin de les compresser et d 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 à ê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 délivré au moyen de notifications à tous les clients ayant souscrit à ce package. Le client reçoit la notification et il décide de le 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. 3.2.2.5. Architecture des composants Administrateur Préparer le package Création des templates Installation à distance Monitor Etat Serveur Souscription Client Templates Demande applications Notification et Distribution QPrep Préparations de fichiers Preuves d installation Compression Utilitaires Base de données Garde info packages, clients, états. Figure 8 : Architecture de Target Link Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-18
3.2.3. Synthèse des 2 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 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 Target Link sont au niveau du transfert et de l installation (notion de groupes, notification, souscription ) et ceux de SoftwareDock sont au niveau du modèle d application (contraintes matérielles et logicielles ). Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-19
3.3. Les modèles d application 3.3.1. Open Software Description (OSD) OSD [13,14,15] est un standard créé par Marimba et Microsoft. Il a été soumis au W3C [15]. Il offre un vocabulaire pour décrire les logiciels, leurs versions, leurs structures et leurs relations avec d autres logiciels. Il est basé sur le langage extensible Markup Language (XML) [3]. OSD permet de définir une famille de logiciel, une famille étant un ensemble de configurations logicielles. Pour chaque famille, on peut spécifier : Son identité : nom, description et localisation de l accord de licence, Les différentes configurations du logiciel, Les dépendances : relations du logiciel avec d autres logiciels ou composants. Pour chaque configuration, on peut spécifier : La localisation des composants, L OS requis, avec sa version, L espace disque minimum, Le type de l implémentation, Le langage, La taille mémoire minimum, Le processeur, La machine virtuelle, Les dépendances de la configuration. Pour OSD, il existe 2 types de dépendance avec une cohésion : Forte : si la dépendance n est pas déjà présente sur la machine cliente, alors on ignore la famille du logiciel, Faible : si la dépendance n est pas déjà présente, on la récupère et on l installe. Avec OSD, la sélection est appliquée avec un niveau de granularité important, qui est la configuration. OSD est par définition extensible, puisque basé sur XML. On peut donc rajouter des éléments pour enrichir la description du logiciel. Les propriétés de la configuration sont confondues avec celles du site, il n y a en a pas pour décrire les options du logiciel. L exemple suivant [15] montre comment OSD traite les dépendances. Il décrit un logiciel du Solitaire. Il y a 2 configurations possibles, une pour la plate-forme Microsoft et l autre pour la plate-forme Java. La configuration java a une dépendance avec un objet, le paquet de cartes. <SOFTPKG NAME="com.foobar.www.Solitaire" VERSION="1,0,0,0"> <TITLE>Solitaire</TITLE> <ABSTRACT>Solitaire by FooBar Corporation</ABSTRACT> <LICENSE HREF ="http://www.foobar.com/solitaire/license.html" /> <!-- Solitaire est implementé en code native for Win32, en code Java pour les autres plates-formes --> <IMPLEMENTATION> <OS VALUE="WinNT"><OSVERSION VALUE="4,0,0,0"/></OS> <OS VALUE="Win95"/> <PROCESSOR VALUE="x86" /> <LANGUAGE VALUE="en" /> Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-20
<CODEBASE HREF ="http://www.foobar.org/solitaire.cab" /> </IMPLEMENTATION> <IMPLEMENTATION> <IMPLTYPE VALUE="Java" /> <CODEBASE HREF ="http://www.foobar.org/solitaire.jar" /> <! - La configuration Java a besoin de l objet paquet de cartes --> <DEPENDENCY> <CODEBASE HREF ="http://www.foobar.org/cards.osd" /> </DEPENDENCY> </IMPLEMENTATION> </SOFTPKG> 3.3.2. Deployable Software Description (DSD) Le format DSD [1,2] offre un vocabulaire pour décrire les logiciels et leurs relations avec d autres logiciels hétérogènes. Il est basé sur le langage XML. DSD nécessite un modèle de site, qui décrive les propriétés, les contraintes et les ressources de la cible du déploiement. DSD permet de décrire une famille de logiciels à travers un seul schéma. Voici la structure du DSD (voir Annexes B.1) avec les éléments les plus importants : Famille L élément Famille du schéma correspond à l élément de haut niveau du document XML. Il décrit la famille du logiciel à travers les éléments suivants. Id Il fournit l identité de la famille en terme de nom, de description, de producteur Attributs externes Ce sont les attributs, qui décrivent le site cible du déploiement, telles que le système opérateur (OS) ou l architecture. La valeur de l attribut est enregistrée pendant le déploiement. L attribut OS est un exemple d un tel attribut : <ExternalProperties> <Property> <PropertyName>OS</PropertyName> <PropertyType>STRING</PropertyType>... </Property> < /ExternalProperties> Attributs internes Ce sont les attributs, qui décrivent les caractéristiques du logiciel. Pour chacune, on fournit son nom, sa description, sa valeur par défaut et la liste de ses valeurs possibles. L attribut Implementation en est un exemple : <InternalProperties> <Property> <PropertyName> Implementation </PropertyName> <PropertyType>STRING</PropertyType> Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-21
<PropertyValue>Native,Java</PropertyValue>... </Property> </InternalProperties> Remarque : Tous les attributs (internes et externes) sont facultatifs (non nécessairement instanciés lors du déploiement). Les règles utilisent cette propriété. Règles de composition Elles décrivent des relations spécifiques entre plusieurs attributs de la famille. Les règles se décomposent en 3 parties : un prédicat, un opérateur de relation et un ensemble d attributs concernées par la règle. DSD utilise 4 opérateurs : EXCLUDES, si le prédicat est vérifié alors on ne permet pas la liste des attributs, INCLUDES, si le prédicat est vérifié alors on permet la liste des attributs, ONEOF, si le prédicat est vérifié alors on permet l un des attributs et on ne permet pas les autres, ANYOF, le prédicat est vérifié alors on permet un ou plusieurs attributs. L exemple suivant illustre les règles de composition: <CompositionRule> <RuleCondition> ($OS$!= Win95 ) && ($OS$!= WinNT ) </RuleCondition> <RuleRelation>EXCLUDES</RuleRelation> <RuleProperties>WinHelp</RuleProperties>... </CompositionRule> Cette règle peut être lue de la manière suivante : si le système opérateur (OS) n est pas Win95 ou WinNT alors l attribut WinHelp n est pas permis. Une autre utilisation possible des règles de composition est la suivante (figure 9), si la propriété «Help» est sélectionnée, alors on a le choix entre 2 types d aide (WinHelp et HTMLHelp). Figure 9 : Exemple graphique d une règle de composition Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-22
Contraintes DSD permet de construire des configurations valides en utilisant des expressions attributs. Il y a 2 classes de contraintes : les assertions et les dépendances. Les assertions décrivent des contraintes, qui doivent être vraies sinon la configuration est invalide et le processus de déploiement s'arrête. L exemple suivant illustre une telle contrainte : <Assertion> <AssertionCondition> ($OS$== Win95 ) ($OS$== WinNT ) ($OS$== Solaris ) </AssertionCondition>... </Assertion> Cette expression signifie que tous les autres OS différents de {Win95,WinNT,Solaris} entraîne une configuration invalide. En d autres termes, le logiciel ne fonctionne que sous les OS Win95, WinNT ou Solaris. Les contraintes, appelées dépendances, sont résolvables. On associe à chaque dépendance, une action, qui essaye de la satisfaire. <Dependency> <Guard>($Implementation$ == Java )</Guard> <DependencyCondition>(!installed( Cards ))</DependencyCondition> <DependencyFamily>Cards</DependencyFamily> <DependencyInterface>Install</DependencyInterface>... </Dependency> Les composants Ce sont les composants physiques, qui composent le logiciel. Les composants sont réunis dans des ensembles (collection) de un ou plusieurs composants. Chaque ensemble est contrôlé par une expression, une garde. Celle-ci a pour rôle de déterminer si la collection est incluse dans la configuration. De plus, on peut, si la collection a plus d un élément, spécifier un garde pour chaque élément de la collection. L exemple suivant donne l exemple d une collection de composants {solitaire.exe, multiplayer.exe}. Le composant «solitaire.exe» sera présent dans toutes les configurations dont l implémentation sera «Java» et «multiplayer.exe» sera présent dans les configurations dont l implémentation sera «Java» et où le nombre de joueurs sera supérieur à 1. <Artifacts> <Guard>($Implementation$ == Java )</Guard> <Artifact> <ArtifactSourceName>solitaire.class</ArtifactSourceName> <ArtifactSource>/cardgames/java/classes</ArtifactSource> <ArtifactDestinationName>solitaire.class</ArtifactDestinationName> <ArtifactDestination>classes</ArtifactDestination>... Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-23
</Artifact> <Artifact> <Guard>($MaxPlayers$ > 1)</Guard> <ArtifactSourceName>multiplayer.class</ArtifactSourceName> <ArtifactSource>/cardgames/java/classes</ArtifactSource> <ArtifactDestinationName>multiplayer.class</ArtifactDestinationName> <ArtifactDestination>bin</ArtifactDestination>... </Artifact> </Artifacts> 3.3.3. Synthèse Nous avons décrit dans le chapitre 3.3, deux modèles de site existants : OSD et DSD. Tous les deux utilisent la notion de famille de logiciels, ceci permettant de gérer les différentes versions des logiciels. Le niveau de granularité traité dans OSD est de type configuration ce qui entraîne la description de toutes les configurations possibles selon les caractéristiques matérielles et logicielles du site cible. Le niveau de granularité traité dans DSD est plus fin. Il est défini au niveau composant ce qui permet de construire automatiquement des configurations en spécifiant des règles de composition. Le modèle DSD nous semble plus pertinent. Nous avons intégré ces propriétés de construction de configuration dans notre modèle. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-24
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 auprès 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 site 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é, il est important de s appuyer sur des modèles puissants permettant d exprimer toutes les caractéristiques du déploiement comme ceux présenté dans la section 3.1. Dans ce travail nous nous sommes intéressés plus particulièrement au modèle d application. 4.2. Expression des besoins Une application à déployer est constituée de composants de différentes nature (code, doc, conception ), chaque composant pouvant exister en plusieurs versions. Afin de réaliser la sélection au niveau du composant, nous avons besoin de caractériser les composants par des propriétés matérielles (OS, architecture ) ou logicielles (langage ). Par exemple, le fichier lisezmoi.hlp serait caractérisé par les propriétés suivantes: Plate-forme=Windows, Langue=français. Il est possible ainsi de construire automatiquement des configurations regroupant des composants compatibles. Ceci est exprimé à l aide de règles de composition opérant sur les propriétés de chacun des composants. 4.3. Modèle d application Notre modèle d application à déployer s appuie sur le logiciel industriel de CAO CATIA de Dassault Système. Dans les sections suivantes nous décrivons le logiciel CATIA et notre proposition de modèle d application exprimé en UML. 4.3.1. CATIA 4.3.1.1. Présentation Catia est un logiciel de CAO développé et commercialisé par Dassault Système [6]. Les «gros» clients de ce logiciel sont Boeing, Chrysler, ceci parmi d autres. CATIA possède différentes fonctionnalités, que DS a rassemblé sous 3 sous produits : Mechanical Design, Shape Design and Styling, Plant. Chacun de ces sous produits correspond à une utilisation particulière de CATIA. Ils ont différentes fonctionnalités; certaines sont obligatoires, d autres sont facultatives (par Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-25
exemple la description en 3D). Pour permettre aux clients de choisir la meilleure configuration possible, DS décompose chaque sous produit en configurations, qui correspondent à un ensemble de fonctionnalités (figure 10 pour un exemple de décomposition du sous produit «Mechanical Design»). Figure 10 : Exemple de possibilités de configuration pour CATIA Par exemple, parmi ces fonctionnalités, «Interactive Drafting» offre un environnement de dessin et d annotation, ainsi qu une évolution progressive des méthodologies du 2D vers celles du 3D. 4.3.1.2. Architecture de CATIA Notion de Framework Une configuration est constituée de composants (comme par exemple, une DLL). Ceux ci sont réunis dans des entités, appelées frameworks. Chaque framework est décomposé en 2 (sous) frameworks : Framework code, il contient toutes les ressources du framework, Framework education, il contient la description des méthodes et des classes du framework. Les frameworks sont liés par des relations de dépendance. Un framework A dépend d un framework B (prérequis) si A utilise une méthode de B. Pour chaque framework, la liste de ses prérequis est spécifiée dans un fichier appelé IdentityCard.h. Chaque framework a son propre fichier IdentityCard.h. Nous allons maintenant décrire l architecture de CATIA chez le producteur et chez le client. Architecture chez le producteur Les frameworks Code et Education sont réunis dans 2 répertoires différents (figure 11). Un Framework est constitué de : Modules, contenant des composants, Son fichier IdentityCard. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-26
Figure 11 : arborescence vue de la racine La structure simplifiée d un framework de CAT IA, chez le producteur est la suivante (figure 12). Figure 12 : Arborescence de CATIA chez le producteur Structure chez le client La structure chez le client est exprimée sous forme d une arborescence de répertoires. Elle est différente de celle définie chez le producteur. La figure 13 montre un exemple de structure utilisée chez le client de Dassault. Comme dans la structure chez le producteur, on distingue les composants issus des frameworks Code et ceux issus des frameworks Education. ). CATIA fonctionne sous plusieurs plate-formes, et chaque framework est décliné pour toutes ses plate-formes. Tous les composants issus de frameworks Code sont réunis dans des sous répertoires (comme bin et lib) du répertoire Windows, dans le cas de la plate-forme du même nom. On remarque que la notion de framework Code disparaît chez le client, il n y a plus que les composants. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-27
Figure 13 : Arborescence des frameworks Code chez le client Les composants issus des frameworks Education sont réunis dans le sous répertoire doc, du répertoire Education (figure 14). A la différence des frameworks Code, l arborescence chez le client garde la notion de framework : ceux ci deviennent des sous répertoires du répertoire doc. De plus lors du déploiement, des fichiers html sont générés, un par framework. Le fichier système.html est un exemple d un tel fichier, tous ces fichiers générés sont réunis au même niveau dans l arborescence que les frameworks Education. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-28
Figure 14 : Arborescence des frameworks Education chez le client 4.3.1.3. Modélisation de CATIA A partir de la description précédente, on remarque qu il y a 3 notions importantes, qui interviennent dans la description et le déploiement de CATIA : le produit (CATIA), le framework et le composant. En effet, le produit CATIA est composé de frameworks constitués des composants. Nous allons donc modéliser [17] ces 3 notions. Les classes définies contiennent des attributs de base. Elles peuvent être à la demande par d autres attributs. La classe Produit Tous les logiciels appartiennent à des familles de logiciels, par exemple Word5 appartient à la famille de logiciel Word. Donc on caractérise un produit (figure 15), en indiquant : sa famille la description de la famille, la version du produit, des informations telles que le nom du producteur du logiciel, le numéro de licence et la date de création du logiciel. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-29
La classe Framework Les frameworks de CATIA sont spécialisés, selon les plate-formes de support à l exécution; ainsi on indique pour chaque framework, le système (Windows, Unix ) de support. Pour installer un framework du site producteur au site client, on a besoin de connaître le nom et la localisation du framework à la fois sur le site producteur et sur le site cible. Afin de gérer d éventuels conflits, on indique la version du framework (figure 15). La classe composant Pour les mêmes raisons que précédemment, on indique le nom et la localisation de chaque composant, sur le site client et sur le site producteur. On rajoute l attribut type, qui donne le type (archive, exécutable ) du composant et l attribut modifiable, afin de préciser si le composant a la possibilité d être modifié une fois installé (figure 15). Modélisation objet de CATIA On a vu que CATIA se présente sous forme de 3 configurations différentes. On modélise les configurations avec la classe Sous-produit, qui hérite de la classe Produit, ce qui permet de n avoir qu un seul attribut pour cette classe, le nom du sous-produit (figure 15). On a vu précédemment avec le fichier IdentityCard.h, que les frameworks avaient besoin d autres frameworks, les frameworks prérequis. Dans la pratique, ce sont les frameworks Code et Education, qui ont des prérequis. Il faut donc rajouter les classes Framework Code et Framework Education (figure 15). Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-30
Figure 15 : Modélisation de CATIA Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-31
4.3.2. Modèle d application Nous avons vu précédemment ce que nous attendons d un modèle d application; nous allons maintenant modéliser les informations nécessaires pour construire un tel modèle en utilisant les concepts présentés en 3.3. Nous avons besoin d informations sur : Les propriétés Les règles de composition : pour la construction des configurations, Les contraintes : pour vérifier la validité des compositions, Les interfaces : pour les liens avec les agents réalisant les activités du déploiement. 4.3.2.1. Les propriétés du logiciel Ces propriétés permettent de caractériser le logiciel. Par exemple, on peut avoir une propriété langue, qui indique la langue utilisée par le logiciel. Pour chaque propriété, on a besoin de son nom, de son type, de sa description, de ses valeurs possibles (figure 16). 4.3.2.2. Les propriétés importées Ce sont celles, qui décrivent le site cible du déploiement. On n a besoin que du nom de la propriété (figure 16), par exemple, le type de l architecture ou l OS de la cible. La valeur de la propriété est récupérée, via son nom dans FieldDock le modèle de site de SoftwareDock. 4.3.2.3. Les règles de composition On a besoin de la condition, qui sera testée, afin de voir si on applique la règle, de la propriété, si elle existe, qui contrôle la règle, de l opérateur de relation et des propriétés concernées par cette règle (figure 16). 4.3.2.4. Les contraintes Elles sont de 2 formes : matérielles et logicielles. Dassault Système fournit une liste de type de machines avec leurs caractéristiques, ce sont les contraintes matérielles. Pour les modéliser (figure 16), on a besoin du type de la machine, de la carte-mére, du processeur, de la carte graphique, du driver graphique, de la mémoire et de la mémoire vidéo. De plus pour chaque type de machine, on a la date de certification. Les contraintes logicielles, ce sont les logiciels qui doivent être présents sur le site cible, afin que le logiciel fonctionne. Pour les modéliser (figure 16), on utilise le nom du logiciel exigé et sa version afin de permettre une gestion de configuration. 4.3.2.5. Les interfaces Une interface permet d accéder à un agent pouvant être utilisé lors du déploiement. Pour chaque logiciel, on donne la possibilité de sélectionner quels types d activités, on pourra effectuer lors du déploiement, par exemple l activité de mise à jour. On utilise pour cela des agents, auxquels on accède en utilisant leurs interfaces, chaque activité étant prise en charge par un agent. Pour les modéliser, on utilise le nom de l interface, celui de l agent et sa description (figure 16). Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-32
4.3.3. La modélisation de CATIA en utilisant DSD 4.3.3.1. Le modèle de classes Figure 16 : Modèle de classes Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-33
4.3.3.2. Justification du modèle L élément central de notre modélisation est le framework dans le sens de CATIA. Pour chaque framework, on lui associe : des propriétés (importées et logicielles), des règles de composition, des contraintes(matérielles et logicielles), des interfaces. On introduit la classe descriptioncomposant (figure 16) qui associe à chaque composant ses propriétés. Le modèle d application vérifie les dépendances. Pour cela il utilise un modèle de site qui décrit les caractéristiques matérielles du site et donne la liste des applications déjà présentes sur le site. 4.3.3.3. Mise en œuvre vers un outil de déploiement A partir du modèle d application, il est possible de générer différentes instances dans une représentation cible comme DSD ou OSD et exprimée dans un formalisme de type XML. Pour réaliser la mise en œuvre, nous avons besoin de connaître la liste des frameworks de CATIA, la liste des prérequis de chaque frameworks et la liste des composants de chaque framework. Pour cela, nous utilisons des fichiers fournis par Dassault, qui permettent après traitement de récupérer les informations précédentes. Nous allons maintenant donner les différentes étapes du processus de création du modèle d application et du processus de déploiement de SoftwareDock. Le processus de création du modèle réalise les activités suivantes: Saisie des informations sur le produit (ici CATIA), Saisie des informations sur les sous-produits, Récupération la liste des frameworks de chaque sous-produits, Pour chaque framework, on saisit : les informations telles que le nom, la liste des propriétés matérielles, la liste des propriétés logicielles, la liste des interfaces, les règles de composition. Récupération la liste des prerequis, Récupération les composants de chaque framework (Code ou Education), Pour chaque composant, on saisit : Les informations telles que la localisation, l expression de garde. Génération automatique du modèle de chaque frameworks. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-34
Ensuite pour déployer l application, on utilise SoftwareDock qui : Configure le logiciel, Contrôle les assertions, Résout les dépendances, Localise les composants, Décompacte les composants, Mets à jour les registres. Cette mise en œuvre est décrite dans le chapitre suivant qui présente l expérimentation et l interface construite à cet effet. Remarque : Des informations comme les propriétés logicielles et les règles de composition qui les accompagnent ne sont pas utilisées, car les données et la politique de Dassault en terme de déploiement, ne permettent pas une configuration dynamique lors du déploiement. Le processus de création du modèle d application est câblé dans notre prototype. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-35
5. Expérimentation 5.1. Générer le modèle d application Pour valider notre approche, nous avons développé un prototype en java permettant à l outil SoftwareDock de supporter notre modèle de définition de l application. Les ressources pour faire fonctionner le prototype sont : Le fichier prerequis.txt, qui regroupe tout les prerequis de tous les frameworks, Le fichier NAN.txt, qui regroupe tous les composants de tous les frameworks. La définition de l application se fait via une interface graphique. Une des actions fréquentes lors de l exécution de cette implémentation consiste en la saisie des informations (sur le produit, les frameworks, les composants ). On utilise dans ce cas, une fenêtre dite de «saisie». La figure 17 présente l interface de saisie pour le produit. Figure 17 : Exemple d une fenêtre de saisie d informations Afin de faciliter la saisie, le prototype propose souvent des interfaces pre-remplies, que l on peut modifier ou valider. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-36
5.1.1. Saisie des informations sur CATIA Lors de cette étape, on a besoin de saisir les informations sur le produit, le(s) sousproduit(s), le(s) framework(s) et enfin sur le(s) composant(s). Etape 1 : Elle consiste à ouvrir la première fenêtre, qui permet de saisir les informations concernant le produit (figure 17). Etape 2 : On saisit les informations sur le sous-produit, c est à dire une configuration pour CATIA. Une fois le nom du sous-produit et la liste des frameworks du sous-produit sélectionnée à partir de l extraction des données du fichier prerequis.txt, on passe à l étape 3. Cette étape sera répétée autant de fois qu il y a de frameworks sélectionnés. Etape 3 : Lors de cette étape, on saisit les informations sur : Le framework, avec le nom et la localisation Les propriétés internes, ce sont celles qui concernent la cible du déploiement, comme le type d architecture ou l OS, Les propriétés externes, ce sont celles qui caractérisent le framework décrit, La saisie de ces différentes informations est gérée de la manière suivante : on affiche une fenêtre (figure 18), qui permet d ajouter des éléments, puis de valider l ensemble des éléments. Dans le cas des contraintes matérielles, on clique sur le bouton «ajouter», l interface de saisie apparaît, on valide les informations, ensuite on peut recommencer l opération pour une autre contrainte ou valider la (ou les) contraintes. Figure 18 : Fenêtre création des listes d informations Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-37
On a vu que chaque framework était composé de 2 frameworks, le framework Code et le framework Education. On affiche une fenêtre (figure 19), qui permet à l utilisateur de réaliser l étape 4, pour le framework Code et le framework Education. Figure 19 : Fenêtre de création des frameworks Code et Education Remarque importante : La saisie de toutes ces informations n est pas obligatoire, seules celles sur le framework, et sur les propriétés externes le sont. Etape 4 : Elle consiste pour les frameworks (Code ou Education) a récupérer la liste des composants et celle des prerequis. Pour chaque composant, on réalise l étape 5. Etape 5 : On saisit les informations sur le composant puis on affiche une fenêtre (figure 20), qui va aider à la construction de l expression de garde du composant. Pour cela, on affiche toutes les propriétés (internes et externes) du framework et on demande à l utilisateur d associer une valeur par propriété. Figure 20 : Fenêtre d aide à la saisie de l expression de garde Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-38
5.1.2. Saisie des informations nécessaires au déploiement Cette saisie regroupe toutes les informations concernant les frameworks. Ce sont, les règles de composition, les interfaces et les contraintes matérielles et logicielles. 5.1.3. Génération du modèle d application Une fois les informations sur CATIA et sur le déploiement saisies, il faut générer le modèle. Nous avons fait le choix de créer un fichier DSD par framework. La réalisation du modèle d application ne nécessite pas d intervention de la part de l utilisateur, le processus consiste à parcourir les différentes instances des classes et de produire une description d une application dans un langage cible (ici DSD). Le résultat final est sauvegardé dans un fichier DSD, qui a pour nom celui du framework. 5.2. Déploiement Pour réaliser l installation du logiciel, on utilise l outil SoftwareDock, qui se sert du modèle précédemment créé. Le processus de déploiement (figure 21) est le suivant : Configurer le logiciel, Contrôler les assertions, Résoudre les dépendances, Localiser les composants, Décompacter les composants, Mettre à jour les registres. Configurer le logiciel (figure 21) consiste pour le client à choisir pour chaque propriété externe, une valeur parmi celles possibles. Par exemple, pour la propriété «version», on peut choisir entre la version 1.0 et 1.2. Une fois la configuration choisie, c est à dire, que l on a assigné une valeur à toutes les propriétés externes, SoftwareDock vérifie que les assertions sont vérifiées; cela concerne les contraintes matérielles et logicielles. S il y en au moins une, qui n est pas vérifiée, alors le processus s arrête. Dans le cas contraire, on vérifie les dépendances ; il s agit des frameworks prerequis. S ils ne sont pas présents sur le site, on lance leur installation. A la fin de ces installations, on récupère les composants du logiciel, dont la condition de garde indique qu ils font partie de la configuration choisie. SoftwareDock les réunit dans un «package» compressé et les envoie au client. Pour chaque composant, on connaît sa localisation sur le site cible. L installation physique de l application consiste à décompacter les composants puis à les installer à la bonne place. SoftwareDock met à jour ses registre. Il crée notamment le nœud de l application déployée et son arborescence. Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-39
L outil «Workbench» de SoftwareDock (figure 21) affiche le résultat du déploiement, c est à dire affiche la configuration installée sur le site en indiquant pour chaque propriété externe la valeur choisie. Configuration Résultat Figure 21 : Fenêtre résumant les différentes étapes de l installation Vincent Lestideau DEA Communication et coopération dans les systèmes à agents 28 juin 2000-40