étude d'une migration de Sybase vers PostgreSQL

10.3 Écriture d'un traducteur en Perl

10.3.1 L'approche utilisée

En vu de structurer la démarche du projet, la solution la plus simple était de le découper en plusieurs phases.

Les choix

Nous avons tout d'abord du déterminer l'approche, la technologie, la méthodologie et l'équipe employés.

Ces choix furent assez rapidement faits:

- Aucun salarié de la CCI n'étant disponible pour ce projet, l'équipe ne pouvait être composée que d'une seule personne.

- Après avoir effectué des recherches sur les solutions existantes, il est apparu qu'aucun outil ne permettait de réaliser une telle migration (voir § 10.2, page 33) et que très peu d'information était disponible pour utiliser une approche systématique. C'est donc l'utilisation d'une méthode empirique qui s'est imposée.

- La technologie utilisée devait permettre de reproduire cette migration même si quelques modifications apparaissaient dans le base (ce qui exclut une traduction manuelle) mais devait être compatible avec les choix déjà faits et le délai imparti. La technique d'un traducteur automatique a donc été retenue.

-

Le travail réalisé

Enfin, ayant très peu de ressources à gérer et beaucoup d'autonomie quant au fonctionnement du traducteur, une méthodologie de gestion de projet "lourde" n'aurait apporté aucun bénéfice par rapport à l'utiisation d'une méthode non formelle.

L'organisation

Le choix d'une approche de type empirique ne dispense pas de structurer la démarche du projet. C'est pourquoi chaque type d'élément de la base (tables, index, données,...) a été traité indépendamment.

En outre, le fonctionnement même des bases de données a imposé un certain ordre de traitement. Il faut réaliser tout d'abord la transformation de la structure puis des données et enfin des traitements.

Les iterations

Pour chacun des types d'élément, une approche empirique peut se traduire par une suite d'itérations comprenant:

- La tentative d'utiliser le Script SQL "tel-quel";

- La recherche des problèmes empêchant le bon fonctionnement;

- L'écriture en Perl d'un programme permettant de régler le problème.

Une fois toutes les itérations effectuées pour tous les types d'éléments, on dispose d'un programme Perl permettant de résoudre tous les problèmes et d'effectuer la migration.

10.3.2 Fonctionnement de l'application

L'un des ojectifs de ce projet était de réaliser un outil de migration de la base de données qui soit facilement réutilisable. Il fallait donc que son uilisation soit simple et que son fonctionnement soit aisément compréhensible et modifiable par une autre équipe.

Le traducteur appelé sybase2postrgesql propose donc plusieurs modes de fonctionnement (voir Annexe J, page 60):

- Utilisation avec passage de paramètres en ligne de commande ou par un fichier de configuration.

- Possibilité de traduire chaque fichier individuellement ou d'automatiser l'ensemble du fonctionnement.

Par ailleurs, le programme a été documenté (voir Annexe I, page 58) et le code commenté afin de rendre leur réutilisation plus simple.

10.4 Estimation du travail restant a effectuer

La migration qui semblait relativement simple à ses débuts s'est révélée beaucoup plus complexe que prévue et la charge de travail sous-estimée. En cours de projet, les délais ont donc du être réévalués et il s'est avéré que la migration des procédures ne pouvait être réalisée dans le temps restant.

Suite à ce constat, nous avons déterminé qu'il était préférable de réaliser un ensemble de mesures afin d'estimer le temps nécessaire à l'achèvement du projet.

Le travail réalisé

10.4.1 Méthode d'estimation

Comme l'approche que nous avons employé est de type empirique, il est difficile d'avoir, avant d'avoir effectuer le traducteur, des indicateurs fiables concernant les points bloquants de la migration. Cependant, certains problèmes sont proches de ceux rencontrés lors de la migration de la structure de la base (et tout particulièrement des vues) et d'autres peuvent être assez facilement repérés (nombre de lignes de code, nombre de structures de boucles et de choix, . . .).

Ainsi, il n'est pas réellement possible de mesurer précisément la complexité de la migration mais on peut en faire une estimation.

Le travail à effectué ici s'apparente à une mesure de complexité informatique [35] hormis que le but n'est pas d'évaluer la performance d'un algorithme mais la difficulté à le comprendre et le traduire et que les indicateurs disponibles sont un peu plus "approximatifs".

Les outils de mesure de complexité sont assez rares et ne permettent généralement de réaliser des tests que pour des langages courants (C, java, .. .). Il était donc très improbable de trouver un outil répondant à nos attentes (fonctionnant pour du Transac SQL et réalisant des mesures permettant d'évaluer la complexité de "compréhension").

Il a donc fallu mettre au point une méthode assez proche d'une mesure de complexité. Cette dernière peut être décomposée en trois grandes phases : la planification, la réalisation et l'analyse. Et même si la méthode est généralement présentée sous forme d'étapes, en réalité, celles-ci ne sont pas forcément effectuées séquentiellement et il y a habituellement plusieurs itérations avant d'obtenir des résultats probants.

Nous allons donc suivre les points suivants:

1. Planification (déterminer quelles mesures vont être réalisées):

- Sélectionner les variables qui vont être observées.

- Indiquer la signification des plages de valeurs dans lesquelles vont se trouver les variables.

- Spécifier le modèle qui va être observé.

- Définir un ensemble de données d'entraînement et de test pour évaluer le modèle.

2. Réalisation (effectuer les mesures):

- Tester le modèle sur les données de test et les comparer aux résultats attendus.

- Obtenir les valeurs des différents indicateurs sur des données réelles et complètes.

- Regrouper et présenter ces valeurs de manière à ce qu'elles soient exploitables.

3. Analyse (traitement et interprétation des résultats):

- Traitement des données afin de les rendre compréhensibles.

- Recoupement des informations afin de faire ressortir les éléments importants.

- Interprétation et analyse des résultats obtenus.

10.4.2 Réalisation des mesures

Afin d'effectuer les mesures permettant d'évaluer le travail restant, la première étape a été de définir un ensemble d'indicateurs:

- nombre de lignes de codes par procédure

-

Le travail réalisé

nombre d'instructions SQL par procédure

- nombre de conditions et de boucles par procédure

Il a ensuite fallu développer une application en Perl pour effectuer les mesures qui correspondent à ces indicateurs.

En observant les résultats, il a été possible d'ajouter quelques indicateurs pour affiner les mesures:

- nombre de curseurs par procédures

- nombre d'exécutions d'autres procédures par procédure

De ces résultats, il a également été possible de déterminer des catégories dans lesquelles se trouvent les procédures.

Moins de 10 lignes	simple		Une seule instruction SQL, pas de curseur, pas de condition, pas de boucle, pas d'instruction "exec" OU que des instructions "exec" (et rien d'autre)
	Un seul type d'instruction (par exemple que des updates), pas de curseur, pas de condition, pas de boucle, pas d'instruction "exec"
	Celles qui n'entrent pas dans les catégories précédentes		Entre 10 et 40 lignes
Mêmes catégories que moins de 10 lignes	Entre 40 et 150 lignes
simples	Pas de condition, pas de boucle et pas de curseur
	Celles qui n'entrent pas dans la catégorie précédente		Plus de 150 lignes
Transformation manuelle (estimation du temps en fonction du nombre de lignes : 150 lignes par jour/homme)

TAB. 10.2 - Catégories de procédures

Enfin, il a été possible de réaliser les mesures définitives (voir Annexe K, page 66) qui seront exploitables pour donner une évaluation du temps de travail nécessaire à l'achèvement de la migration.

10.4.3 Résultats de l'estimation

Estimation grossière pour une traduction manuelle

Afin d'évaluer la charge de travail que représenterait la traduction manuelle des procédures, il convient tout d'abord de mesurer le volume d'information à traiter. Nous avons donc mesuré le nombre de lignes de code total que représentent les procédures (environ 150 000 hors commentaires).

Une évaluation approximative permet d'atteindre un volume de travail d'environ 1000 jours/homme (en comptant environ 150 lignes écrites par jour/homme).

Le travail réalisé

La conversion manuelle des procédures n'est donc que difficilement envisageable. C'est pourquoi, il serait nécessaire de disposer d'un outil permettant la migration automatique de la plus grande partie des procédures.

Estimation affinée

À l'aide de l'ensemble des indicateurs, il est possible de répartir les procédures en différents niveaux de complexité et de calculer le nombre de jours de développement nécessaires pour terminer l'application.

	Nb. de procs.	% du volume	Nombre de jours par niveau de complexité			Nb. total de jours		% du temps total
			Moyen	Complexe
1379	31,61	10	12	15	37	8,54		De 10 à 40 lignes
2103	48,2	12	15	20	47	10,85		De 40 à 150 lignes
709	16,25	15		25	40	9,23		Plus de 150 lignes
172	3,94	Nb. total de lignes : 46376	309,17			71,37

TAB. 10.3 - Estimation du temps de développement par catégorie de procédures

On peut constater que, comme dans la plupart des projets, 80% du volume des procédures peuvent être migrées pour 20% du temps de travail.

Pour les procédures les plus difficiles à migrer (celles qui prennent 80% du temps de développement), il faut s'assurer de la pertinence et de l'utiité de chacune d'elle afin de ne pas perdre de temps inutilement.