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

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


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

Serveur WWW

Fichiers

Script


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.


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.


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


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

Démarche


11

La Tradition des Applications Orientées-Objet

?

Références

Threads


12

Un Exemple de Structure de Serveur WWW

Clients

Servlet

Fichiers

Monitoring


13

Problème?Les Connections

Références

Threads


14

Que faire?Enlevons les connexions!

?

!

!

?

!


15

Le Serveur WWW sans Connexion

Clients

Servlet

Fichiers

Monitoring!

?

Infrastructure Générale


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.


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

??

TT


22

Renvoyer une Réponse

Service Manager

! T

T?


23

Invoquer un ServicePas de Service Disponible?

Service Manager

??

Null


24

Le Serveur WWW

Service Manager

ClientsFichiers

Servlets Monitoring

!

!

!

?

?

?

??

??

?


25

Un Correspondant Disparaît?

Service Manager

ClientsFichiers

Servlets Monitoring

??

?


26

Un Correspondant Evolue?

Service Manager

ClientsFichiers

Servlets Monitoring

?

?


27

Fondements du Modèle : Asynchronisme

Service Manager

??

TT


28

Fondements du Modèle : Anonymat

Service Manager

??

TT


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?

Descriptions de Services


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)


32

Descriptions de Service


33

Problème

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

?


34

Arbres

Root

Node1

Node21 Node22

PrécisionRelation ET

Relation OU


35

d3=1

d2=2

d1=3

Le Service de Sauvegarde de Fichier

F

‘‘FileSystem’’

‘‘Write’’

B

String

char[] String

Q

“local”


36

Comparer Les Arbres?

Root

Node1

Node21 Node22

Root

Node1

Node2

Node3

?

?

Le même nombre ?

Nombre deNœuds Communs

Successifs?


37

22

Exemple de Comparaison

B

String

char[] String

B

String

B

’’MaVie.txt’’


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’’


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.

Rapports d’Expérience


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.


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

Service Manager

ClientsFichiers

FileSystemEntity, 28

HTTPDEntity, 161

MonitoringEntity, 7MonitoringServletEntity, 9

ForumServletEntity, 10

ServletEntity, 18

…


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.

http://www.weeselj.org/




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 à l’asynchronisme.

• Une technique de comparaison d’arbres de manière valuée.

• Diverses implantations.


49

Travaux Futurs

• Validité des changements.

• Des descriptions de services sémantiques.

• L’évolution au niveau de l’objet.

• Les applications auto-organisées.

Questions

Annexes


52

Evolution: Un Correspondant Potentiel disparaît

Service Manager

??

T

T


53

Evolution: Un Correspondant Potentiel Evolue

Service Manager

??

TT


54

Evolution:Le Code Appelant Evolue

Service Manager

??

TT ! T

T?


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


56


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


57


QoS

Slow Fast

QoS

Fast Very Fast

QoS

Fast

QoS

Fast

2


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


59

Matcher les Descriptions de Service

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

Documents