Une Approche pour l’Evolution des Systèmes Logiciels Manuel Oriol Présentation de doctorat 20 Avril 2004.

Présentation au sujet: "Une Approche pour l’Evolution des Systèmes Logiciels Manuel Oriol Présentation de doctorat 20 Avril 2004."— Transcription de la présentation:

1

2 Une Approche pour l’Evolution des Systèmes Logiciels Manuel Oriol Présentation de doctorat 20 Avril 2004

3 Une Approche pour l’Evolution des Systèmes Logiciels 2 Evolution d’Applications 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).

4 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 3 Applications Considérées Besoin 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

5 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 4 Exemple : Le Serveur WWW 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). Serveur WWW Fichiers Script

6 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 5 Problématique Traiter 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.

7 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 6 Evolution Contrainte/ non-Contrainte 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.

8 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 7 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…).

9 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 8 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/Beans/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.

10 Plan Démarche Infrastructure Générale Descriptions de Services Rapports d’Expérience Conclusion

11 Démarche

12 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 11 La Tradition des Applications Orientées-Objet ? Références Threads

13 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 12 Un Exemple de Structure de Serveur WWW Clients Servlet Fichiers Monitoring

14 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 13 Problème? Les Connections Références Threads

15 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 14 Que faire? Enlevons les connexions! ? ! ! ? !

16 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 15 Le Serveur WWW sans Connexion Clients Servlet Fichiers Monitoring ! ?

17 Infrastructure Générale

18 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 17 Entité et Services 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.

19 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 18 Enjeux 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.

20 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 19 Entités et Service Manager Service Manager Entités

21 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 20 Annoncer des Services Service Manager ! !

22 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 21 Invoquer un Service Service Manager ? ? T T

23 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 22 Renvoyer une Réponse Service Manager ! T T ?

24 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 23 Invoquer un Service Pas de Service Disponible? Service Manager ? ? Null

25 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 24 Le Serveur WWW Service Manager Clients Fichiers ServletsMonitoring ! ! ! ? ? ? ? ? ? ? ?

26 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 25 Un Correspondant Disparaît? Service Manager Clients Fichiers ServletsMonitoring ?? ?

27 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 26 Un Correspondant Evolue? Service Manager Clients Fichiers ServletsMonitoring ? ?

28 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 27 Fondements du Modèle : Asynchronisme Service Manager ? ? T T

29 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 28 Fondements du Modèle : Anonymat Service Manager ? ? T T

30 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 29 Liaison Tardive : Comment Designer/Localiser un Service? Service Manager ? ? T T En objet traditionnel, références: FileSaver fs = new FileSaver(); fs.write(ficName,content); Comment faire sans références?

31 Descriptions de Services

32 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 31 Comment le Programmeur Décrit-il les Services? Fonctionalité (F) : Qu’est-ce que ça fait? (comparable à un nom de méthode write ) Comportement (B) : 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)

33 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 32 Descriptions de Service

34 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 33 Problème Faire correspondre service recherché/services annoncés. ?

35 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 34 Arbres Root Node1 Node21Node22 Précision Relation ET Relation OU

36 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 35 d 3 =1 d 2 =2 d 1 =3 Le Service de Sauvegarde de Fichier F ‘‘FileSystem’’ ‘‘Write’’ B Stringchar[]String Q “local”

37 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 36 Comparer Les Arbres? Root Node1 Node21Node22 Root Node1 Node2 Node3 ? ? Le même nombre ? Nombre de Nœuds Communs Successifs?

38 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 37 2 2 Exemple de Comparaison B Stringchar[]String B B ’’MaVie.txt’’

39 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 38 3 3 Exemple de Comparaison (suite) B Stringchar[]String BB ’’Tout commença par un matin neigeux.’’ ‘‘Test’’2 ’’MaVie.txt’’

40 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 39 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é. 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.

41 Rapports d’Expérience

42 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 41 Implantation de l’infrastructure: LuckyJ 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.

43 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 42 LuckyJ Schémas Général

44 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 43 Caractéristiques de LuckyJ 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).

45 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 44 Autres Implantations 2 implantations distribuées: –Implantation centralisée Permet de distribuer à la volée des applications LuckyJ –Implantation semi- centralisée Pairs Clients Pairs Serveur

46 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 45 Le Serveur WWW : WeeselJ Service Manager Clients Fichiers FileSystemEntity, 28 HTTPDEntity, 161 MonitoringEntity, 7 MonitoringServletEntity, 9 ForumServletEntity, 10 ServletEntity, 18 …

47 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 46 Applications Test Serveur Web WeeselJ: –http://www.weeselj.orghttp://www.weeselj.org –Implémentation en marche depuis 18 mois. –Plus de 160 versions différentes de certaines parties du code. –99.99% de disponibilité (4 redémarrages de l’application). Morpion –Implantation pour les portes ouvertes du CUI 2003. –Programmé principalement par des étudiants. –Des versions on été recodées pour les participants.

48 Conclusion

49 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 48 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.

50 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 49 Travaux Futurs Validité des changements. Des descriptions de services sémantiques. L’évolution au niveau de l’objet. Les applications auto-organisées.

51 Questions

52 Annexes

53 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 52 Evolution: Un Correspondant Potentiel disparaît Service Manager ? ? T T

54 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 53 Evolution: Un Correspondant Potentiel Evolue Service Manager ? ? T T

55 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 54 Evolution:Le Code Appelant Evolue Service Manager ? ? T T ! T T ?

56 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 55 Profondeur de Matching (1) F « Sort » « BubbleSort »« SlowSort » F « Sort » « SlowSort » F « Sort » F F 2 F « SlowSort » F « Sort » « SlowSort » 3

57 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 56 Profondeur de Matching (2) B argument int []char [] return int []char [] B argument [1,2,3] return char [] B argument [1,2,3] B argument char [] B argument B char [] B argument [1,2,3] 3 B argument char [] B argument char [] return char [] B argument [1,2,3] return char [] 5

58 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 57 Profondeur de Matching (3) QoS Slow Fast QoS Fast Very Fast QoS Fast QoS Fast 2

59 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 58 Matcher les Descriptions de Service F « Sort » « BubbleSort » « SlowSort » B argument int []char [] return int []char [] B argument char [] QoS Slow Fast,,, 2, 5, 2 )(

60 20 Avril 2004Une Approche pour l’Evolution des Systèmes Logiciels 59 Matcher les Descriptions de Service