Une Approche pour l’Evolution des Systèmes Logiciels
Manuel OriolPrésentation de doctorat
20 Avril 2004
20 Avril 2004 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).
20 Avril 2004 Une 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
20 Avril 2004 Une 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
20 Avril 2004 Une 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.
20 Avril 2004 Une 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.
20 Avril 2004 Une 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…).
20 Avril 2004 Une 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.
Plan
• Démarche• Infrastructure Générale• Descriptions de Services• Rapports d’Expérience• Conclusion
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
11
La Tradition des Applications Orientées-Objet
?
Références
Threads
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
12
Un Exemple de Structure de Serveur WWW
Clients
Servlet
Fichiers
Monitoring
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
13
Problème?Les Connections
Références
Threads
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
14
Que faire?Enlevons les connexions!
?
!
!
?
!
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
15
Le Serveur WWW sans Connexion
Clients
Servlet
Fichiers
Monitoring!
?
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
17
Entité et Services
Données
ServicesLa notion d’entité peut donc être mappée sur : • Un objet.
• Un composant(servlet, bean…)
• Un nœud de réseau.
20 Avril 2004 Une 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 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
19
Entités et Service Manager
Service Manager
Entités
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
20
Annoncer des Services
Service Manager
!!
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
21
Invoquer un Service
Service Manager
??
TT
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
22
Renvoyer une Réponse
Service Manager
! T
T?
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
23
Invoquer un ServicePas de Service Disponible?
Service Manager
??
Null
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
24
Le Serveur WWW
Service Manager
ClientsFichiers
Servlets Monitoring
!
!
!
?
?
?
??
??
?
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
25
Un Correspondant Disparaît?
Service Manager
ClientsFichiers
Servlets Monitoring
??
?
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
26
Un Correspondant Evolue?
Service Manager
ClientsFichiers
Servlets Monitoring
?
?
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
27
Fondements du Modèle : Asynchronisme
Service Manager
??
TT
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
28
Fondements du Modèle : Anonymat
Service Manager
??
TT
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
29
Liaison Tardive : Comment Designer/Localiser un Service?
Service Manager
??
TT
•En objet traditionnel, références:
FileSaver fs =
new FileSaver();
fs.write(ficName,content);
•Comment faire sans références?
20 Avril 2004 Une 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)
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
33
Problème
• Faire correspondre service recherché/services annoncés.
?
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
34
Arbres
Root
Node1
Node21 Node22
PrécisionRelation ET
Relation OU
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
35
d3=1
d2=2
d1=3
Le Service de Sauvegarde de Fichier
F
‘‘FileSystem’’
‘‘Write’’
B
String
char[] String
Q
“local”
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
36
Comparer Les Arbres?
Root
Node1
Node21 Node22
Root
Node1
Node2
Node3
?
?
Le même nombre ?
Nombre deNœuds Communs
Successifs?
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
37
22
Exemple de Comparaison
B
String
char[] String
B
String
B
’’MaVie.txt’’
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
38
33
Exemple de Comparaison (suite)
B
String
char[] String
B B
’’Tout commença par un matin neigeux.’’
‘‘Test’’ 2
’’MaVie.txt’’’’MaVie.txt’’
20 Avril 2004 Une 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.
20 Avril 2004 Une 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.
20 Avril 2004 Une 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).
20 Avril 2004 Une 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
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
45
Le Serveur WWW : WeeselJ
Service Manager
ClientsFichiers
FileSystemEntity, 28
HTTPDEntity, 161
MonitoringEntity, 7MonitoringServletEntity, 9
ForumServletEntity, 10
ServletEntity, 18
…
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
46
Applications Test
• Serveur Web WeeselJ:– http://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.
20 Avril 2004 Une 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.
20 Avril 2004 Une 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.
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
52
Evolution: Un Correspondant Potentiel disparaît
Service Manager
??
T
T
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
53
Evolution: Un Correspondant Potentiel Evolue
Service Manager
??
TT
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
54
Evolution:Le Code Appelant Evolue
Service Manager
??
TT ! T
T?
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
55
Profondeur de Matching (1)
F
« Sort »
« BubbleSort » « SlowSort »
F
« Sort »
« SlowSort »
F
« Sort »
F
« Sort »
F
« Sort »
2F
« Sort »
« SlowSort »
F
« Sort »
« SlowSort »
3
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
56
Profondeur de Matching (2)
B
argument
int [] char []
return return
int [] char []
B
argument
[1,2,3]
return
char []
B
argument
[1,2,3]
B
argument
char []
B
argument
B
argument
char []
B
argument
[1,2,3]
3
B
argument
char []
B
argument
char []
return
char []
B
argument
[1,2,3]
return
char []
5
20 Avril 2004 Une 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
20 Avril 2004 Une Approche pour l’Evolution des Systèmes Logiciels
58
Matcher les Descriptions de Service
F
« Sort »
« BubbleSort »
« SlowSort »
B
argument
int [] char []
return return
int [] char []
B
argument
char []
QoS
Slow Fast
, , , 2, 5, 2 )(