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

(1)

Une Approche pour l’Evolution des Systèmes Logiciels

Manuel Oriol Pré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).

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

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

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.

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.

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

La Tradition des Applications Orientées-Objet

?

Références Threads

Un Exemple de Structure de Serveur WWW

Clients Servlet

Fichiers

Monitoring

(3)

Problème?

Les Connections

Références Threads

Que faire?

Enlevons les connexions!

?

!

?

!

Le Serveur WWW sans Connexion

Clients Servlet

Fichiers

Monitoring

!

?

Infrastructure Générale

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.

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.

(4)

Entités et Service Manager

Service Manager

Entités

Annoncer des Services

Service Manager

! !

Invoquer un Service

Service Manager

? ?

T T

Renvoyer une Réponse

Service Manager

! T

? T

Invoquer un Service Pas de Service Disponible?

Service Manager

? ?

Null

Le Serveur WWW

Service Manager

Clients Fichiers

Servlets Monitoring

!

?

? ?

??

?

(5)

Un Correspondant Disparaît?

Service Manager

Clients Fichiers

Servlets Monitoring

?

Un Correspondant Evolue?

Service Manager

Clients Fichiers

Servlets Monitoring

?

Fondements du Modèle : Asynchronisme

Service Manager

? ?

T T

Fondements du Modèle : Anonymat

Service Manager

? ?

T T

Liaison Tardive : Comment Designer/Localiser un Service?

Service Manager

? ?

T T

•En objet traditionnel, références:

FileSaver fs = new FileSaver();

fs.write(ficName,cont ent);

•Comment faire sans références?

Descriptions de Services

(6)

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)

Descriptions de Service

Problème

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

?

Arbres

Root

Node1

Node21 Node22 Précision

Relation ET

Relation OU

d

₃

=1 d

₂

=2

d

₁

=3

Le Service de Sauvegarde de Fichier

F

‘‘FileSystem’’

‘‘Write’’

B

String

char[] String

Q

“local”

Comparer Les Arbres?

Root Node1 Node21 Node22

Root Node1 Node2 Node3

?

Le même nombre ? Nombre de Nœuds Communs

Successifs?

(7)

2 2

Exemple de Comparaison

B

String

char[] String

B

String

B

’’MaVie.txt’’

3 3

Exemple de Comparaison (suite)

B

String

char[] String

B B

’’Tout commença par un matin neigeux.’’

‘‘Test’’ 2

’’MaVie.txt’’

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

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.

LuckyJ Schémas Général

(8)

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

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

Le Serveur WWW : WeeselJ

Service Manager

Clients Fichiers FileSystemEntity, 28

HTTPDEntity, 161 MonitoringEntity, 7 MonitoringServletEntity, 9

ForumServletEntity, 10 ServletEntity, 18

…

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.

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.