- Les classes persistantes -

Les classes persistantes sont celles dont les objets sont enregistrés de façon permanente dans des fichiers indépendants, un ou plusieurs fichiers XML ou une base de données. La base de données peut être relationnelle (ACCESS, MySQL, SQL-Server…), objet-relationnel (Oracle) ou orientée-objet (O2).

Dans le cas d'utilisation de fichiers, chaque classe persistante donnera lieu à la création d'un fichier différent. Les liaisons existant entre les fichiers devront être gérées de façon explicite par des pointeurs ou des index. Par exemple, pour représenter une liaison d'un fichier Client vers les commandes passées qui sont enregistrées dans un fichier séquentiel indexé Commandes on pourra joindre à chaque client une liste de numéros de commandes qui sont les index d'accès au fichier Commandes. Si l'on désire constituer une base Lotus-Notes, chaque classe persistante sera représentée par un masque (les objets étant alors des documents saisis avec ce masque) et les liaisons entre les documents pourront être implémentés par des champs composés de "liendocs" ou de références à entrées multiples qu'il faudra programmer de façon explicite.

L'enregistrement dans un fichier XML permettra de réaliser des sauvegardes et des lectures globales d'un ensemble d'objets pour lesquels il faut faire apparaître une structure hiérarchique. La structure hiérarchique peut être obtenue en considérant les associations de type (1 ; *) ainsi que les relations de composition. Pour chaque structure hiérarchique obtenue on construira une DTD (Document Type Definition) qui permettra de générer, contrôler et valider un fichier XML différent.

Dans le cas d'utilisation d'une base de données, il est nécessaire d'en définir le schéma qui permettra son implémentation avec le SGBD considéré. La réalisation du schéma consiste tout simplement à extraire le sous-diagramme de classes correspondant aux classes persistantes. Il correspondra bien souvent au diagramme des classes métiers obtenu lors de la conception globale limité aux classes mises en œuvre dans le prototype en cours d'étude et augmenté d'une part des classes métiers découvertes lors de la conception détaillée, d'autre part des classes techniques d'association.

Sauf dans le cas où on utilise une base de données purement orientée-objet, le principe de non-régression des prototypes ne pourra pas s'appliquer aux classes persistantes étant donné que le concept d'héritage n'existe pas dans tous les autres cas de structures de données enregistrées. Au fur et à mesure de la constitution des prototypes la structure des fichiers ou le schéma de la base de données devra donc être modifiée en le complétant avec les nouvelles classes. Si une classe persistante a été redéfinie pour lui ajouter des attributs on les rajoutera directement dans le schéma de la base de données qu'il faudra recompiler. Dans le cas d'une base de données de type objet-relationnel, les méthodes rajoutées dans les classes relationnelles devront également être rajoutées en tant que procédures cataloguées.

Afin d'éviter les modifications trop fréquentes des structures de données enregistrées il est conseillé d'intégrer dès le premier prototype, toutes les classes persistantes connues à ce moment-là : celles obtenues lors de la conception globale et celles qui auront été rajoutées lors de la conception détaillée du prototype.