Evolution d Applications. Une Approche pour l Evolution des Systèmes Logiciels. Exemple : Le Serveur WWW. Applications Considérées

Transcription

1 Evolution d Applications Une Approche pour l Evolution des Manuel Oriol Présentation de doctorat 20 Avril 2004 Une application est souvent modifiée entre sa première mise en service et sa dernière. Une application devient mature après plusieurs années de maintenance. Un serveur web peut continuer à être développé pendant des années (Apache est développé depuis 1995). 2 Applications Considérées Exemple : Le Serveur WWW esoin en haute disponibilité: P. Ex. : Les serveurs, PDA, téléphones mobiles, les systèmes automobiles, les systèmes de contrôle de satellite, de centrales nucléaires... Modifications arbitraires pour répondre à des changements de besoins ou corriger les bugs. P. Ex. : patches de sécurités Envoyer à travers le réseau des pages web aux clients (Netscape, Explorer). Les fichiers envoyés : simple fichiers issus du système de fichier résultat de computation (server-side scripting). Script Serveur WWW 3 4 Problématique Evolution Contrainte/ non-contrainte raiter l évolution d applications programmées dans un langage orienté-objet. Les évolutions non-anticipées, non-contraintes et dynamiques. Notre but est d offrir aux programmeurs et concepteurs d applications un modèle et une plateforme permettant de telles évolutions. Une évolution contrainte est une évolution qui obéit à priori à un certain nombre d invariants. Exemple de la Vie Réelle (VR) : On ne casse pas un bâtiment à moitié, on ne fait que des extensions. Exemple de Programmation Orientée Objet (POO) : Les contraintes de sous typage pour profiter du polymorphisme. Les évolution non-contraintes n ont pas ces limitations. VR : on peut tout modifier sur les plans. POO : Modifier une application

2 Evolution Dynamique/Statique Une évolution statique nécessite d arrêter l application. VR : Les plans d un immeuble sont changés, on refait l immeuble. POO : Arrêter l application, modifier son code, la relancer. Une évolution dynamique est réalisée pendant que l application tourne. VR: modifier des bureaux tout en utilisant le bâtiment. POO : le processus de chargement et de liaison dynamique (dll, loading en java ). Evolution Anticipée/ non-anticipée Une évolution anticipée est une évolution qui a été prévue à la conception. VR: un open space. POO : Les mécanismes de servlets/eans/plug-ins. Une évolution non-anticipée est une évolution qui n a pas été initialement prévue. VR : rajouter un parking souterrain. POO : Un bug de sécurité, un changement profond. 7 8 Plan Démarche Démarche Infrastructure Générale Descriptions de Services Rapports d Expérience Conclusion La radition des Applications Orientées-Objet Un Exemple de Structure de Serveur WWW Servlet Références hreads

3 Problème Les Connections Que faire Enlevons les connexions Références hreads Le Serveur WWW sans Connexion Servlet Infrastructure Générale 15 Entité et Services Enjeux Données Services La notion d entité peut donc être mappée sur : Un objet. Un composant (servlet, bean ) Un nœud de réseau. On doit pouvoir faire évoluer une entité : Ajouter une entité. Enlever une entité. Remplacer une entité. Une entités peut : Annoncer des services. Invoquer des services. Répondre

4 Entités et Annoncer des Services Entités Invoquer un Service Renvoyer une Réponse Invoquer un Service Pas de Service Disponible Servlets Le Serveur WWW Null

5 Servlets Un Correspondant Disparaît Servlets Un Correspondant Evolue Fondements du Modèle : Asynchronisme Fondements du Modèle : Anonymat Liaison ardive : Comment Designer/Localiser un Service En objet traditionnel, références: FileSaver fs = new FileSaver(); fs.write(ficname,cont ent); Descriptions de Services Comment faire sans références 29 5

6 Comment le Programmeur Décrit-il les Services Descriptions de Service Fonctionalité (F) : Qu est-ce que ça fait (comparable à un nom de méthode write) Comportement () : Comment cela le fait-il (comparable à une signature de méthode) Qualité de Service (QoS): A quel point le fait-il (comparable à une description de méthode dans les API) Problème Arbres Faire correspondre service recherché/services annoncés. Root Précision Relation E Node21 Node1 Node22 Relation OU Le Service de Sauvegarde de Fichier F FileSystem Write d 1 =3 char[] d 2 =2 Q local d 3 =1 Node21 Comparer Les Arbres Root Node1 Node22 Nombre de Nœuds Communs Successifs Root Node1 Node2 Node3 Le même nombre

7 Exemple de Comparaison Exemple de Comparaison (suite) 2 MaVie.txt 2 3 MaVie.txt 3 MaVie.txt char[] char[] out commença par un matin neigeux. est Comparer les Descriptions de Service On compare chacun des arbres l un après l autre. On impose d avoir des comparaisons minimales pour avoir une adéquation minimale entre ce qui est demandé et ce qui est proposé. Rapports d Expérience On choisit le service qui se compare le mieux. On préfèrera d abord la fonctionnalité, ensuite le comportement et enfin la qualité de service. 39 Implantation de l infrastructure: LuckyJ LuckyJ Schémas Général Permets de faire des changements arbitraires dans la structure des applications qui l utilisent. Le composant est l unité d évolution élémentaire. Utilise le modèle précédemment décrit

8 Caractéristiques de LuckyJ Autres Implantations Programmé en Java 2 standard. Chaque entité a son propre ClassLoader. Découplage entre ServiceManager et Description Passer. Plateforme légère (5000 lignes de code). 2 implantations distribuées: Implantation centralisée Permet de distribuer à la volée des applications LuckyJ Implantation semicentralisée Pairs Pairs Serveur Le Serveur WWW : WeeselJ ServletEntity, 9 Entity, 7 ForumServletEntity, 10 ServletEntity, 18 HPDEntity, 161 FileSystemEntity, 28 Applications est Serveur Web WeeselJ: Implémentation en marche depuis 18 mois. Plus de 160 versions différentes de certaines parties du code % de disponibilité (4 redémarrages de l application). Morpion Implantation pour les portes ouvertes du CUI Programmé principalement par des étudiants. Des versions on été recodées pour les participants Conclusion Conclusion Un modèle pour les évolutions non-anticipées, non-contraintes et dynamiques. Modèle basé sur une infrastructure basée sur le nommage associatif, la liaison tardive de code et à l asynchronisme. Une technique de comparaison d arbres de manière valuée. Diverses implantations. 48 8

9 ravaux Futurs Validité des changements. Questions Des descriptions de services sémantiques. L évolution au niveau de l objet. Les applications auto-organisées. 49 9