Évolution du modèle

 

Au cas où la modélisation présentée précédemment s'avère insuffisante (par exemple, après un test extensif par des experts littéraires), est-il possible de la modifier ? Et si l'on modifie le modèle, est-il possible de récupérer l'information sémique déjà stockée ?

Ces questions sont très importantes si nous voulons un modèle qui puisse évoluer. Car si l'on a rien prévu, l'ajout d'un attribut dans une classe rend la version du modèle déjà sauvegardé incompatible avec le nouveau modèle de classes. Ceci veut dire que nous ne pouvons plus accéder aux interprétations qui ont déjà été effectuées et stockées et que, par conséquent, il faut pratiquement tout recommencer à zéro : une évolution du modèle de classes est dans ce cas pratiquement impossible.

Cette << limitation >> du point de vue de l'évolution est due au mécanisme de linéarisation en Java qui remplit une demande de << sécurisation >> : il ne permet pas la lecture d'un objet linéarisé par un objet de type incompatible, même si leurs classes ont le même nom.

Pour effectuer ce contrôle, le système utilise une fonction (Secure Hash Algorithm) et il calcule un numéro qui caractérise de manière quasi-unique le contenu de la classe. Ce numéro est sauvegardé pendant la linéarisation d'un objet et il est comparé avec le numéro correspondant de l'objet qui essaie de délinéariser le fichier. Si les deux numéros diffèrent, alors les deux objets ne sont pas compatibles et la délinéarisation ne se fait pas.

Le calcul de la fonction est basé sur les éléments suivants d'une classe [33, chap.7] :

• son nom,
• les classes dont elle hérite,
• ses variables (sauf celles qui sont déclarées static ou transient),
• les signatures (types de paramètres et du résultat) de ses méthodes non-privées,
• l'appel à defaultReadObject ou defaultWriteObject au sein des méthodes privées readObject et writeObject, respectivement.

Ce dernier signifie que toute modification d'un de ces éléments rend la classe incompatible avec une ancienne linéarisation : la nouvelle version de la classe ne peut plus délinéariser une autre version déjà linéarisée.

Le problème qui se pose à ce point est le suivant : si l'évolution du modèle demande l'addition d'une variable au sein d'une classe ou d'une nouvelle méthode publique, alors la délinéarisation d'une ancienne version de cette classe ne sera plus possible par la nouvelle version et donc l'information sémique sauvegardée dans tout le graphe d'objets est pratiquement perdue.

Pour surpasser cette difficulté, Java 1.1 donne la possibilité de définir, dès la création de la classe, un numéro de version qui la caractérise. Ceci empêche l'application de la fonction SHA : le numéro qui sera attribué à la classe pendant sa linéarisation est celui fourni par la classe elle-même. Et ce sera la responsabilité de la classe de gérer les incompatibilités entre deux versions d'une classe ayant défini le même numéro de version.

Nous avons procédé de la façon suivante. À l'aide de la commande système (fournie par l'environnement de travail JDK 1.1^5.27) javaser uneClasse, nous appliquons la fonction SHA et nous récupérons un numéro unique pour la version actuelle de la classe. Ce numéro est transporté à l'intérieur de la classe à l'aide de la déclaration :

$$\texttt{static final long serialVersionUID = \emph{<le numéro>}}$$

Ce numéro caractérisera la classe tout au long de la vie du modèle statique. La modification d'une classe est gérée par la classe elle-même de la façon suivante : chaque fois qu'une modification est effectuée, la méthode readObject, qui est responsable de la délinéarisation d'un objet, est temporairement modifiée pour incorporer la modification.

Si par exemple une variable a été ajoutée dans la classe, la méthode readObject est adaptée de manière à initialiser convenablement la valeur de cette variable après la délinéarisation d'un objet de l'ancienne version de la classe. Une fois l'ensemble du graphe délinéarisé, nous le relinéarisons et remodifions la méthode readObject vers son état initial.

De cette manière nous arrivons à un nouvel état stable du modèle statique, dont la linéarisation contient la nouvelle variable initialisée et qui est prêt à être délinéarisée comme avant, avec la même méthode readObject.