Gestion des versions-révisions pour les objets
Up ! 5GL permet de créer des applications qui équiperont des entreprises pour de nombreuses années. Une fois une application installée et paramétrée, personne ne désire en changer avant un moment, en particulier les utilisateurs (ils n'aiment pas changer leurs habitudes souvent) et le directeur financier (il apprécie les investissements amortis sur une longue période).
Pourtant, la concurrence pousse les éditeurs de progiciels à faire évoluer leurs applications, ce qui motivent périodiquement ses clients :
- Apport de nouvelles fonctionnalités.
- Nouveaux logiciels connexes ou nouvelles versions de ceux-ci.
- Nouveaux matériels informatiques plus performants.
- Nouveaux systèmes d'exploitation ou nouvelles versions de ceux-ci.
- Nouvelles bases de données ou nouvelles versions de ceux-ci.
- Nouvelles architectures ou nouvelles technologies.
Lorsqu'une entreprise utilise des progiciels basés sur Up ! Application System, le problème de changer de versions d'applications imposent plusieurs problèmes :
- Savoir changer une partie des applications sans devoir changer les autres.
- Faire en sorte que les applications soient toujours capables de communiquer et de s'échanger des données.
- Si les applications reposent sur un noyau fonctionnel partagé, permettre à la nouvelle version du noyau d'émuler le fonctionnement de l'ancienne version pour les modules qui restent inchangés.
Ce principe de transition douce est la garantie d'assurer la pérennité des applications et des données des clients de progiciels. Up ! Application System comporte un gestionnaire de versions-révisions permettant cela.
Numérotation en version, révision et correction
Principe de la numérotation
Les objets en technologie Up ! Virtual Technical Machine sont numérotés en version, révision et correction. Les modules Up ! Application System étant des objets particuliers, ils sont aussi numérotés en version, révision et correction. Par convention :
- Il y a changement de version lorsque le type de l'objet est totalement refondu.
La définition du type de rattachement de l'objet a donc changé au point de ne pas ressembler à la définition initiale.
Pour un module, son interface a donc changé au point de ne pas ressembler à l'interface initiale.
- Il y a changement de révision lorsque le type de l'objet est étendu.
La définition du type de rattachement de l'objet a donc changé mais nous retrouvons dans la nouvelle définition du type les propriétés et les méthodes à l'identique de l'ancienne définition.
Pour un module, son interface a donc changé mais nous retrouvons dans sa nouvelle interface les types, les variables, les exceptions et les procédures ou fonctions à l'identique de l'ancienne interface.
- Il y a changement de correction lorsque le type de l'objet est modifié en interne.
La définition du type de rattachement de l'objet a donc changé, sauf en ce qui concerne les définitions Public.
Pour un module, son interface a donc changé, sauf en ce qui concerne les définitions Public.
Ainsi :
- Il n'y a pas d'incompatibilité entre deux corrections.
- La compatibilité ascendante doit être assurée pour les traitements et les données d'une révision à l'autre.
- La compatibilité ascendante doit être assurée seulement pour les données d'une version à l'autre.
Version d'Up ! Virtual Business Machine
Ce principe de numérotation s'applique aux modules des applications écrites en technologie Up ! Virtual Technical Machine. Ainsi, nous dirons qu'une application Finances est en version-révision 2.0.1 et qu'une seconde application Commerce est en version-révision 3.1.0. En faisant l'hypothèse que le module Commerce utilise le module Finances, les règles de compatibilité sont les suivantes :
| Modules | Commerce 3.1.0 | Commerce 3.2.0 |
| Finances 2.0.1 | Compatible puisque
compilés avec la
bonne interface. | Compatible puisque
compilés avec la
bonne interface. |
| Finances 2.1.1 | Publication de
l'interface 2.0 par
Up ! Virtual Technical Machine. | Publication de
l'interface 2.0 par
Up ! Virtual Technical Machine. |
Version d'Up ! Virtual Technical Machine
Ce principe de numérotation s'applique également aux modules de Up ! Virtual Technical Machine et nous avons les mêmes règles de compatibilités :
| Modules | Commerce 3.1.0 | Commerce 3.2.0 |
| Up ! VM 1.0.0 | Compatible puisque
compilés avec la
bonne interface. | Compatible puisque
compilés avec la
bonne interface. |
| Up ! VM 1.3.1 | Publication de
l'interface 2.0 par
Up ! Virtual Technical Machine. | Publication de
l'interface 2.0 par
Up ! Virtual Technical Machine. |
Automatismes dus au versionnement
Fichiers de persistance et fichiers de Up ! Objects Files
Lors d'un changement de version-révision de Up ! Virtual Technical Machine, l'utilitaire Up ! Migrate permet de migrer les fichiers de persistance et les fichiers Up ! Objects Files au format de la nouvelle version-révision de Up ! Virtual Machine.
Lors d'un changement de version-révision de l'application Up ! Virtual Technical Machine, l'utilitaire Up ! Migrate permet de migrer les fichiers de persistance. Lors d'un changement de version-révision de l'application, la migration des fichiers Up ! Objects Files est traitée à la volée par la méthode Importer du type Objet.
Fichiers d'exportation d'objets
Lors d'un changement de version-révision de Up ! Virtual Technical Machine, l'utilitaire Up ! Migrate permet de migrer les fichiers d'exportation des objets au format de la nouvelle version-révision de Up ! Virtual Machine.
Lors d'un changement de version-révision de l'application, la migration des fichiers Up ! Object File est traitée à la volée par la méthode Importer du type Objet.
Fichiers journaux
Lors d'un changement de version-révision de Up ! Virtual Technical Machine ou de l'application, l'application est arrêtée proprement, aussi les fichiers de persistance, les fichiers Up ! Objects Files et les fichiers journaux sont synchronisés. Il ne sera donc pas nécessaire de réaliser une opération de reprise faisant intervenir les journaux. Les journaux n'ont donc pas besoin d'être migrés, ils seront écrasés.
Les fichiers journaux sont cependant versionnés pour ne pas tenter d'effectuer une reprise par une version-révision de Up ! Virtual Technical Machine autre que celle ayant créée les les fichiers de persistance, les fichiers Up ! Object File et les fichiers journaux.
Protocole Up ! Network
Le protocole Up ! Virtual Technical Machine est versionné de la sorte à pouvoir gérer une communication entre deux applications ou deux Up ! Virtual Machine de version-révision hétérogène. Cependant, la version-révision du serveur doit être supérieure à la version-révision du client, tant pour l'application que pour Up ! Virtual Machine.
Contrôle de la compatibilité entre les versions-révisions
Up ! Virtual Technical Machine est capable d'interroger un module en vue de lui demander de lui retourner l'interface pour une version-révision donnée.
Si la version-révision demandée est indisponible, alors Up ! Virtual Technical Machine envoie l'exception ModuleInconnu au module demandeur. Up ! Virtual Technical Machine assure ainsi que l'application est constituée de modules compatibles.
Déclaration des versions-révisions dans les sources Up ! 5GL
L'instruction Version employée dans l'en-tête d'un fichier source d'un module ou dans l'en-tête de l'interface d'un module permettent de spécifier respectivement la version, la révision et la correction du module.
L'instruction Version employée dans le corps de l'interface d'un module permettent de déclarer les différences d'interface entre les versions-révisions supportées par le module.
Voici un exemple :
Interface Module "Ceci est mon module" Version 1.2.0 ModuleDynamique;
Entrepot
/******/
E1;
Version 1.1 Faire
E2;
Version 1.2 Faire
Fin Version
Fin Version
Type T1 Defaut
/************/
Fin Type
Version 1.1 Faire
Type T2 Defaut
/************/
Fin Type
Version 1.2 Faire
Type T3 Defaut
/************/
Fin Type
Fin Version
Fin Version
Type T4 Defaut
/************/
V1 : Entier;
Procedure M1();
Version 1.1 Faire
V2 : Entier;
Procedure M2();
Version 1.2 Faire
V3 : Entier;
Procedure M3();
Fin Version
Fin Version
Fin Type
Variable
/******/
V1 : Entier;
Version 1.1 Faire
V2 : Entier;
Version 1.2 Faire
Fin Version
Fin Version
Exception
/*******/
E1(E1", 1, TransactionInchangee);
Version 1.1 Faire
E2(E2", 2, TransactionInchangee);
Version 3.2 Faire
E3(E3", 3, TransactionInchangee);
Fin Version
Fin Version
Procedure P1();
Version 1.1 Faire
Procedure P2();
Version 1.2 Faire
Fin Version
Fin Version