Une Approche pour lEvolution des Systmes Logiciels

1
Une Approche pour lEvolution des Systèmes
Logiciels

• Manuel Oriol
• Présentation de doctorat
• 20 Avril 2004

2
Evolution dApplications

• 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).

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

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).

Script
Serveur WWW
Fichiers
5
Problématique

• Traiter lévolution dapplications programmées
  dans un langage orienté-objet.
• Les évolutions non-anticipées, non-contraintes et
  dynamiques.
• Notre but est doffrir aux programmeurs et
  concepteurs dapplications un modèle et une
  plateforme permettant de telles évolutions.

6
Evolution Contrainte/non-Contrainte

• Une évolution contrainte est une évolution qui
  obéit à priori à un certain nombre dinvariants.
• 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 nont pas ces
  limitations.
• VR on peut tout modifier sur les plans.
• POO Modifier une application.

7
Evolution Dynamique/Statique

• Une évolution statique nécessite darrêter
  lapplication.
• VR Les plans dun immeuble sont changés, on
  refait l immeuble.
• POO Arrêter lapplication, modifier son code,
  la relancer.
• Une évolution dynamique est réalisée pendant que
  lapplication tourne.
• VR modifier des bureaux tout en utilisant le
  bâtiment.
• POO le processus de chargement et de liaison
  dynamique (dll, loading en java).

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
  na pas été initialement prévue.
• VR rajouter un parking souterrain.
• POO Un bug de sécurité, un changement profond.

9
Plan

• Démarche
• Infrastructure Générale
• Descriptions de Services
• Rapports dExpérience
• Conclusion

10
Démarche
11
La Tradition des Applications Orientées-Objet
?
12
Un Exemple de Structure de Serveur WWW
Monitoring
Servlet
Clients
Fichiers
13
Problème?Les Connections
14
Que faire?Enlevons les connexions!
?
!
?
15
Le Serveur WWW sans Connexion
Monitoring
Servlet
!
Clients
Fichiers
16
Infrastructure Générale
17
Entité et Services

• La notion dentité peut
• donc être mappée sur
• Un objet.
• Un composant
• (servlet, bean)
• Un nud de réseau.

Services
Données
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.

19
Entités et Service Manager
Service Manager
Entités
20
Annoncer des Services
Service Manager
21
Invoquer un Service
Service Manager
22
Renvoyer une Réponse
Service Manager
23
Invoquer un ServicePas de Service Disponible?
Service Manager
?
24
Le Serveur WWW
Servlets
Monitoring
Service Manager
Fichiers
Clients
25
Un Correspondant Disparaît?
Servlets
Monitoring
Service Manager
Fichiers
Clients
26
Un Correspondant Evolue?
Servlets
Monitoring
Service Manager
Fichiers
Clients
27
Fondements du Modèle Asynchronisme
28
Fondements du Modèle Anonymat
Service Manager
29
Liaison Tardive Comment Designer/Localiser un
Service?

• En objet traditionnel, références
• FileSaver fs
• new FileSaver()
• fs.write(ficName,content)
• Comment faire sans références?

Service Manager
30
Descriptions de Services
31
Comment le Programmeur Décrit-il les Services?

• Fonctionalité (F)
• Quest-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)

32
Descriptions de Service
33
Problème

• Faire correspondre service recherché/services
  annoncés.

?
34
Arbres
Root
Précision Relation ET
Node1
Node21
Node22
Relation OU
35
Le Service de Sauvegarde de Fichier
local
Write
36
Comparer Les Arbres?
Root
Root
?
Node1
Node1
Nombre de Nuds Communs Successifs?
Node2
Node21
Node22
Node3
?
Le même nombre ?
37
Exemple de Comparaison
MaVie.txt
38
Exemple de Comparaison (suite)
MaVie.txt
MaVie.txt
Tout commença par un matin neigeux.
39
Comparer les Descriptions de Service

• On compare chacun des arbres lun après lautre.
• On impose davoir 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 dabord la fonctionnalité, ensuite le
  comportement et enfin la qualité de service.

40
Rapports dExpérience
41
Implantation de linfrastructure LuckyJ

• Permets de faire des changements arbitraires dans
  la structure des applications qui lutilisent.
• Le composant est lunité dévolution élémentaire.
• Utilise le modèle précédemment décrit.

42
LuckyJ Schémas Général
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).

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

45
Le Serveur WWW WeeselJ
MonitoringEntity, 7
MonitoringServletEntity, 9
ForumServletEntity, 10
ServletEntity, 18
Service Manager

HTTPDEntity, 161
Fichiers
Clients
FileSystemEntity, 28
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
  lapplication).
• Morpion
• Implantation pour les portes ouvertes du CUI
  2003.
• Programmé principalement par des étudiants.
• Des versions on été recodées pour les
  participants.

47
Conclusion
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
  à lasynchronisme.
• Une technique de comparaison darbres de manière
  valuée.
• Diverses implantations.

49
Travaux Futurs

• Validité des changements.
• Des descriptions de services sémantiques.
• Lévolution au niveau de lobjet.
• Les applications auto-organisées.

50
Questions
51
Annexes
52
Evolution Un Correspondant Potentiel disparaît
Service Manager
53
Evolution Un Correspondant Potentiel Evolue
Service Manager
54
EvolutionLe Code Appelant Evolue
Service Manager
55
Profondeur de Matching (1)
F
F
F
 Sort 
 Sort 
 Sort 
 BubbleSort 
 SlowSort 
 SlowSort 
56
Profondeur de Matching (2)
B
B
B
B
argument
argument
argument
argument
int
char
1,2,3
1,2,3
char
return
return
return
int
char
char
57
Profondeur de Matching (3)
QoS
QoS
 Slow 
 Fast 
 Fast 
Very Fast 
58
Matcher les Descriptions de Service
,
, 2, 5, 2 )
(
,
59
Matcher les Descriptions de Service