FR2941550A1

FR2941550A1 - Systeme informatique de gestion de donnees historiseees dans un outil de gestion de versions

Info

Publication number: FR2941550A1
Application number: FR0950564A
Authority: FR
Inventors: Joris Thomassin
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-01-29
Filing date: 2009-01-29
Publication date: 2010-07-30
Anticipated expiration: 2029-01-29
Also published as: FR2941550B1; WO2010086523A1

Abstract

L'invention concerne un système informatique de gestion de données historisées, les données étant structurées sous forme d'une pluralité d'enregistrements appelés fiches (222, 224), lesdites fiches étant structurées selon une pluralité de modèles (210, 212) telles qu'une fiche est une instanciation d'un modèle, et au moins un premier modèle comportant une relation à un second modèle (226), chaque modèle comportant un ensemble structuré de métadonnées (218, 220) d'un gestionnaire de versions.

Description

SYSTEME INFORMATIQUE DE GESTION DE DONNEES HISTORISEES DANS UN OUTIL DE GESTION DE VERSIONS

La présente invention concerne un système informatique de gestion de données stockées et historisées dans un outil de gestion de versions. Dans les technologies de l'information, les techniques de bases de données, communément appelées Systèmes de Gestion de Base de Données ou SGBD, sont utilisées pour gérer de grande quantité de données structurées. Dans la plupart des applications, on utilise des bases de données relationnelles dans lesquelles les données sont structurées en tables, chaque table comportant un certain nombre de champs. Les champs sont de différents types : booléens, numériques, chaînes de caractères, etc. Chaque table se compose d'un ensemble d'enregistrements, chaque enregistrement correspondant à un ensemble de valeurs particulières des champs de la table. Ainsi chaque table est classiquement représentée par une matrice à deux dimensions dans laquelle chaque colonne représente un champ et chaque ligne un enregistrement. Pour accéder aisément à un enregistrement, la table prévoit en général un champ d'index qui a une valeur unique à chaque enregistrement. Un enregistrement d'une table peut alors faire référence à un enregistrement d'une autre table en incluant dans un champ une référence à la table et à l'index de l'enregistrement référencé. Un langage spécifique de gestion des données dans une base de données relationnelle a été développé et normalisé sous le nom SQL ( Structured Query Language - langage de requête structurée). Le standard est référencé ISO/CEI 9075. La théorie et la pratique des bases de données relationnelles font partie des connaissances générales des étudiants en informatique et ne seront donc pas présentées plus en détail dans le présent document. Les logiciels de bases de données relationnelles sont développés par de nombreuses sociétés. Les plus connues sont la société ORACLE Corporation dont le système de gestion de bases de données se nomme Oracle, MICROSOFT Corporation avec SQL Server et SUN Corporation avec MySqI, cette liste n'étant pas limitative. Les bases de données relationnelles sont utilisées pour stocker et gérer les informations les plus diverses des entreprises : la gestion de la production, les données commerciales et financières, les données du personnel, etc. Dans de nombreuses applications, il existe un besoin d'enregistrer l'historique des modifications apportées à un enregistrement. Par exemple, dans une application de carnet d'adresses, il pourrait être souhaitable, lorsqu'un correspondant change d'adresse, de garder l'ancienne adresse ainsi que des informations sur le changement tel que la date du changement et la personne qui a effectué la modification. Ce type de suivi des modifications devient vite complexe à gérer et nécessite de nombreuses ressources de développement car les systèmes de gestion de bases de données n'ont pas de fonctions natives pour gérer aisément le suivi des modifications. Lorsque le suivi de modifications est mis en oeuvre, celui-ci est géré par les applications elles-mêmes, le plus souvent sous forme de fichiers enregistrant au fil de l'eau les modifications effectuées. Ces fichiers, appelés fichiers log , sont traités par des fonctions de recherche particulières à l'application quand il devient nécessaire de rechercher des informations sur une modification. Bien que relativement simple à mettre en oeuvre, cette technique ne donne pas de résultat satisfaisant quand les besoins de recherche historique sont permanents car les fichiers log deviennent lourds à manipuler et les temps de réponse médiocres. Une amélioration de la technique des fichiers de log consiste à stocker les informations dans des tables historiques . Cette technique améliore en partie les temps de réponse sans que les résultats soient très satisfaisants. Aussi serait-il particulièrement avantageux d'avoir un système informatique de gestion de données dans lequel la gestion des modifications et des historiques soit aisée à mettre en oeuvre tout en gardant la versatilité des gestionnaires de bases de données classiques. Pour résoudre un ou plusieurs des inconvénients cités précédemment, le système informatique de gestion de données historisées, les données sont structurées sous forme d'une pluralité d'enregistrements appelés fiches, lesdites fiches sont structurées selon une pluralité de modèles de telle sorte qu'une fiche est une instanciation d'un modèle, et au moins un premier modèle comporte une relation à un second modèle, caractérisé en ce que chaque modèle comporte un ensemble structuré de métadonnées d'un gestionnaire de versions. Des caractéristiques ou des modes de réalisation particuliers sont : • une fiche correspondant à un fichier généré en versions et historisé pour le gestionnaire de versions. • chaque fiche comporte un fichier vide. Selon un deuxième mode de réalisation, le procédé automatisé de gestion de données historisées comporte les étapes de : - définition d'une pluralité de modèles, chaque modèle comportant au moins un champ correspondant à une métadonnée d'un gestionnaire de 15 versions ; - instanciation d'au moins un modèle sous forme d'un fichier géré en version et historisé par le gestionnaire de versions, la structure des métadonnées associées à ce fichier étant une copie de la structure de métadonnées du modèle correspondant et au moins une métadonnée 20 associée audit fichier comportant une donnée à gérer en historique, le fichier et ses métadonnées étant appelée fiche. Des caractéristiques et modes particuliers de réalisation sont : - au moins un premier modèle de la pluralité de modèles comporte un champ de lien vers un second modèle de telle sorte qu'une fiche instanciant le 25 premier modèle comporte dans sa métadonnée correspondante un pointeur vers une fiche instanciant le second modèle. - le pointeur est l'adresse de la fiche instanciant le second modèle. Selon un troisième mode de réalisation, un produit programme d'ordinateur comporte des instructions de code de programme pour l'exécution des étapes 30 du procédé précédent lorsque ledit programme est exécuté sur un ordinateur.

Ainsi, le système de gestion de données historisées permet avantageusement de structurer les données comme dans une base de données relationnelle classique tout en profitant des avantages du gestionnaire de versions que sont la gestion des versions et des historiques de celles-ci, la gestion de branche en parallèle, le stockage de grande quantité d'information avec des temps de réponse rapides, ces fonctionnalités ayant déjà été bien déboguées par de nombreux usages antérieurs.

L'invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d'exemple, et en référence aux figures en annexe dans lesquelles : - les figures 1A et 1B sont des vues schématiques d'architectures logicielles utilisant des bases de données selon l'art antérieur ; - la figure 2 est une vue schématique d'une architecture logicielle selon un mode de réalisation de l'invention ; - la figure 3A est une vue schématique de deux tables de base de données reliées selon l'art antérieur ; - la figure 3B est une vue schématique de fiches reliées selon un mode de réalisation de l'invention ; - la figure 4 est une vue schématique de lien entre une fiche tâche et une fiche ressource ; et - la figure 5 est une vue schématique des écrans de visualisation des fiches de la figure 4.

En référence aux figures 1A et 1B, deux architectures logicielles classiques d'un système informatique 1 de gestion de données sont représentées : une architecture logicielle de développement d'application, figure 1A, et une architecture logicielle de fonctionnement d'une application utilisant une base de données, figure 1 B. Elles comportent un système de gestion de bases de données 3 gérant des structures de stockage de bas niveau sur des disques durs magnétiques 5. Le système de bases de données 3 est, par exemple, un des systèmes cités en exemple précédemment ou bien un système embarqué tel que Berkeley DB. Dans le cadre d'une architecture de développement, le développeur d'application utilise un environnement de développement 7 connu de l'homme du métier sous la forme d'Environnement de Développement Intégré EDI, ou IDE pour Integrated Development Environment en anglais. A titre d'exemple le logiciel Eclipse (v.eclipse.orq) est un tel EDI. Ce logiciel regroupe sous une interface graphique homogène un certain nombre d'outils de développement de logiciel tels que, par exemple, un éditeur de texte avec coloration syntaxique, un accès à un compilateur et un éditeur de liens, un débogueur, etc. Cet EDI 7 s'interface avec un gestionnaire de versions 9, appelé en 5 anglais Version Control System ou VCS. Le gestionnaire de versions 9 est un outil généralement utilisé par les développeurs de logiciel pour gérer leurs fichiers source dans le cadre d'un projet de développement informatique. Dans le cadre d'un développement de logiciel, le principe général 10 consiste à préparer une base centrale dite reposoir central (en anglais repository ) à laquelle ont accès les développeurs du projet. Avant de travailler, chaque développeur fait classiquement une copie dans un dossier de travail de la totalité ou d'une partie des fichiers contenus dans le reposoir central dans leur dernière version. Il travaille sur cette copie et, quand il a 15 terminé, il envoie les fichiers modifiés dans le reposoir central pour que ses collègues développeurs puissent les utiliser. Le gestionnaire de versions gère en particulier les versions successives des fichiers de développement, c'est-à-dire que chaque fois qu'un développeur fait une modification sur un fichier, lorsque le fichier 20 modifié est intégré dans le reposoir central, le gestionnaire garde la version précédente et incrémente un numéro de version en même temps qu'il stocke le nouveau fichier. Ainsi, en cas d'erreur, il est facile de revenir sur une version antérieure. Le gestionnaire de versions permet également de gérer différentes 25 modifications simultanées de versions globales du logiciel en développement. Par exemple, une modification d'une version stable de production dans laquelle seules des corrections d'erreur sont apportées et une version de développement dans laquelle sont implémentées de nouvelles fonctionnalités. L'homme du métier appelle ces fonctionnalités la gestion des branches ou 30 d'espaces de travail. Il est également possible de mémoriser des états stables de version globale au travers de photos (en anglais baseline , label ou tag ) permettant de garder une vue globale de l'état de développement d'un logiciel à un moment donné.

De nombreux logiciels de gestion de version existent actuellement. Parmi les plus connus, on peut citer CVS et Subversion qui sont des logiciels libres et Synergy, Dimensions et Perforce qui sont des logiciels commerciaux. Certains de ces logiciels gèrent également les demandes de modification du système à faire évoluer ainsi que la mise en correspondance de ces demandes de modification avec les changements apportés au système. L'homme du métier les appelle alors des logiciels de gestion de configuration (en anglais Software Configuration Management ou SCM). Typiquement les logiciels de gestion de versions gèrent donc une arborescence de fichiers qui sont des fichiers de texte ou binaire contenant le code source de l'application développée. A chaque fichier est associé une ou plusieurs métadonnées contenant des informations utiles au gestionnaire comme, par exemple, le nom du développeur ayant modifié et déposé le fichier dans le reposoir central.

Pour stocker l'ensemble de ces informations, fichiers et métadonnées, le gestionnaire de versions 9 utilise la base de données 3. Celle-ci est une base de données libres ou commerciales comme indiquée précédemment ou une base de données développée spécialement pour le gestionnaire de version 9.

En fonctionnement, figure 1B, une application 11 de traitement de données classique utilisant une base de données comporte en particulier une interface 13 permettant de manipuler les données stockées dans la base de données 3. Dans une logique de programmation objet, l'interface 13 transforme typiquement des règles SQL portant sur des objets informatiques de type mots, chaînes de caractères, etc. en objets modélisant les données métier à manipuler et réciproquement. Dans un mode de réalisation de l'invention, figure 2, l'application 11' s'interface à un gestionnaire de version 9' et non, comme dans l'art antérieur de la figure 1B, directement à une base de données. Le gestionnaire de versions 9' utilise ses outils classiques de stockage 3', en général une base de données, pour stocker, lire et écrire les données. L'application 11' de gestion de données utilise donc les fonctionnalités du gestionnaire de versions 9' pour stocker ses données dans la base de données 3' sous-jacentes. L'interface 13' transforme alors les objets modélisant les données métier en objets informatiques manipulables par le gestionnaire de versions 9' et réciproquement. L'organisation des données gérée par l'interface 13' va maintenant être décrite en référence aux figures 3A et 3B.

Cette organisation a pour but de recréer les structures connues des bases de données relationnelles pour permettre les manipulations habituelles et connues des données. A titre illustratif, la figure 3A représente une structure simple de données telle que pouvant être représentée dans une base de données relationnelle classique. Cette structure comporte deux tables 110, 112 comportant chacune plusieurs champs dont un champ d'index 114, 116 en première colonne. Le champ 118 de la table 110 contient des pointeurs sur des enregistrements de la table 112 sous la forme du contenu de l'index de l'enregistrement pointé. Ainsi, par exemple, l'enregistrement 120 contient, pour le champ 118, un pointeur 122 sur un des enregistrements de la table 112 sous la forme du contenu de l'index de l'enregistrement pointé. Cette structure est réalisée dans l'interface 13' en utilisant les métadonnées gérées par le gestionnaire de version 5', figure 3B. La structure d'une table, c'est-à-dire principalement le nombre et la qualité des champs, est décrite dans un modèle 210, 212. Ce modèle 210, 212 correspond à un type de fichier géré par le gestionnaire de versions 9'. Ce modèle 210, 212 est instancié au travers de fichiers versionnés 214, 216, de préférence de taille nulle auquel sont associés des métadonnées 218, 220 à raison d'une métadonnée par champ.

Ainsi, un enregistrement de table, tel que l'enregistrement 120 de la figure 3A, c'est-à-dire un ensemble de données ayant la structure de la table en termes de nombre et de qualité de champs, est une copie du modèle 210 dans laquelle chaque métadonnée a une valeur spécifique à cet enregistrement. Afin de différencier cette copie du modèle, celle-ci est appelée fiche. On comprend donc qu'un modèle est un fichier vide associé à une structure de métadonnées, ces métadonnées n'ayant pas de valeur définie ou bien une valeur par défaut. Et une fiche est un fichier vide associé à une structure identique de métadonnées mais donc chaque métadonnée contient une valeur spécifique à cette fiche.

Ainsi, les enregistrements 120 initialement stockés dans une table 110 d'une base de données relationnelle classique sont maintenant stockés sous la forme d'attributs 218 dans une instance, ou fiche, 222 d'un modèle 210, cette instance ayant un fichier associé 214 vide. De par les fonctionnalités du gestionnaire de versions 9', on comprend que chaque fiche 222 est versionnée : l'historique des changements des différentes valeurs des attributs est géré directement par le gestionnaire de versions 9'. Pour réaliser un lien entre deux fiches, par exemple le lien 122 de la figure 3A, il suffit alors de prévoir dans un modèle une métadonnée 226 qui contiendra, lors de l'instanciation, l'adresse ou l'identifiant de la fiche pointée 224. Le procédé de gestion de données historisées consiste donc à définir, étape S230, dans un premier temps des modèles sous forme d'une structure de métadonnées puis, pour chaque ensemble structuré de données, instancier, étape S232, une fiche correspondant au modèle adaptée pour cet ensemble de données. La manipulation des données ainsi stockées dans les métadonnées d'une fiche étant réalisée par l'intermédiaire des outils du gestionnaire de versions. Ainsi, les structures d'une base de données relationnelle sont reproduites en utilisant un gestionnaire de versions. Cela permet donc avantageusement de structurer classiquement les données, comme dans le cadre d'un développement de bases de données, tout en profitant des fonctionnalités natives du gestionnaire de versions et, en particulier, de sa capacité à gérer et à versionner l'historique des modifications.

On peut comprendre que dans l'utilisation du gestionnaire de versions telle que décrit le rôle et l'importance du fichier et des métadonnées associées sont inversés par rapport à une utilisation classique lors d'un développement de logiciel comme décrit en référence à la figure 1A. Dans une utilisation classique, l'élément important est le contenu du fichier qui contient une partie du code source de l'application en cours de développement. Les métadonnées, comme leur nom l'indique, sont seulement présentes pour qualifier le fichier. Dans l'utilisation décrite ici, les métadonnées contiennent l'information utile de la fiche et le contenu du fichier est vide ou contient éventuellement des données de type texte ou non structurées équivalentes à une structure BLOB dans une base de données relationnelle. Les différents types de fichier pouvant être gérés par un outil de gestion de versions sont appelés par l'homme du métier éléments de configuration (en anglais Configuration Items ou Cl). Ces entités représentent la partie atomique la plus fine pouvant être gérée dans un système de gestion de versions, ou même un système de gestion de configuration. Ces éléments sont aujourd'hui limités à des types de fichier source (comme les *.c, *.h, .java, etc. et les produits de compilation comme les *.exe, *.dll, etc.). L'utilisation des modèles et fiches telle que présentée ci-dessus complète cette liste avec des objets de type fiche au sens des gestionnaires de configuration dont chaque type a ses métadonnées propres. Il faut en effet distinguer la notion de fiche telle qu'expliquée ci-dessus en relation avec les figures 3A et 3B de la notion de fiche telle qu'elle est utilisée dans les gestionnaires de configuration. En effet, dans un gestionnaire de configuration, une fiche est un objet destiné à noter et suivre les demandes de modification. La pratique montre que ces fiches sont gérées classiquement par les logiciels de gestion de configuration en utilisant une base de données, comme illustré, par exemple, sur la figure I B.

On comprend qu'une fiche au sens du mode de réalisation décrit est beaucoup plus versatile qu'une fiche de modification au sens d'un gestionnaire de configuration. A titre illustratif de cette versatilité du système décrit, les bases d'un gestionnaire intégré de données pour une direction des systèmes d'information d'une entreprise vont maintenant être décrites. Un tel gestionnaire doit modéliser différents objets tels que : - avenant représentant une demande de modification d'un périmètre projet, - compétence représentant une description de connaissance et savoir-faire, - décision représentant une décision actée par des décideurs sur un projet, - environnement représentant la description d'un environnement d'une machine, - exigence représentant la description d'une exigence sur un produit, - test représentant la description d'un test à passer pour vérifier une exigence, - res_test représentant le résultat d'un test passé, - ressource représentant des informations sur une personne du projet, - incident représentant la description d'un incident et de sa résolution, - news représentant un évènement marquant ayant eu lieu sur un projet, - projet représentant la description des informations relatives à un projet, - risque représentant la description d'un risque et des actions associées, - tâche représentant l'ensemble des actions à réaliser pour accomplir la tâche, - etc. Cette modélisation se base avantageusement sur des modélisations bien connues de l'homme du métier telles que CMMI (acronyme de Capability Maturity Model Integration ou Intégration de modèle de murissement) pour le développement de logiciels et ITIL ( Information Technology Infrastructure Library ou Bibliothèque d'infrastructures de technologie de l'information) pour la gestion de systèmes informatiques. Par une homogénéisation du vocabulaire et des concepts de ces modèles particuliers, elle permet de modéliser l'ensemble des activités d'une direction informatique.

A titre d'exemple, le modèle de tâche définit les attributs suivants : - identifiant : descripteur unique de référence de la tâche, - titre : description synthétique de la tâche, - description : description complète de la tâche, - réalisation : description de ce qui a été effectivement réalisé, - date début : date de début de réalisation de la tâche, - date fin : date de fin de la tâche, - charge_prévue : charge prévue pour réaliser la tâche, - charge_consommée : charge effectivement consommée par la tâche, - reste à faire : reste à faire sur la tâche, - statut : état reflétant le niveau d'avancement de la tâche, par exemple dans le cadre d'une procédure. - ressource assignée : définie les personnes en charge de la tâche.

Selon le gestionnaire de versions utilisé et en particulier des types de données supportés comme attribut, les attributs ci-dessus seront définis comme chaines de caractères, date, etc... Par exemple, avec le gestionnaire de versions Dimension, les attributs Titre , Description , Réalisation , seront de type Char , les attributs date-début et date-fin , seront de type Date et les attributs concernant la charge de travail de type Number . L'attribut ressource assignée jointe sur une ou des fiche(s) ressource contenant la description de celle-ci. La figure 4 montre sous la même représentation que la figure 3B, le lien entre une fiche tâche 300 et une fiche ressource 302. L'attribut Ressource assignée 304 contient un pointeur sous la fiche Ressource 302 sous la forme du nom de celle-ci. A titre illustratif, la figure 5 montre l'écran de visualisation et de modification d'une fiche tâche avec les attributs ci-dessus et celui de la 20 fiche ressource associée. A partir de cette description, l'homme du métier saura reproduire toutes les liaisons entre tables classiques des bases de données relationnelles telles que les liaisons un-plusieurs et plusieurs-plusieurs . On constate ainsi qu'il est possible d'offrir les mêmes capacités 25 d'enregistrement et de manipulation que pour des données stockées classiquement dans une base de données relationnelle. L'invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d'exemple et non comme limitant l'invention a cette seule 30 description. De nombreuses variantes de réalisation sont possibles. Dans les revendications, le mot comprenant n'exclue pas d'autres éléments et l'article indéfini un/une n'exclue pas une pluralité.

Claims

REVENDICATIONS1. Système informatique de gestion de données historisées, les données étant structurées sous forme d'une pluralité d'enregistrements appelés fiches (222, 224), lesdites fiches étant structurées selon une pluralité de modèles (210, 212) de telle sorte qu'une fiche est une instanciation d'un modèle, et au moins un premier modèle comportant une relation à un second modèle (226), caractérisé en ce que chaque modèle comporte un ensemble structuré de métadonnées (218, 220) d'un gestionnaire de versions (9').
2. Système selon la revendication 1, caractérisé en ce qu'une fiche correspond à un fichier géré en versions et historisé par le gestionnaire de versions.
3. Système selon la revendication 1, caractérisé en ce que la relation avec le second modèle est une métadonnée de telle sorte que, pour toute fiche instanciant ledit premier modèle, la valeur de la métadonnée est un pointeur vers une fiche instanciant le second modèle.
4. Système selon la revendication 1 ou 2, caractérisé en ce que chaque fiche comporte un fichier vide.
5. Procédé automatisé de gestion de données historisées comportant les étapes de - définition (S230) d'une pluralité de modèles, chaque modèle comportant au moins un champ correspondant à une métadonnée d'un gestionnaire de versions ; - instanciation (S232) d'au moins un modèle sous forme d'un fichier géré en version et historisé par le gestionnaire de versions, la structure des métadonnées associées à ce fichier étant une copie de la structure de métadonnées du modèle correspondant et au moins une métadonnée associée audit fichier comportant une donnée à gérer en historique, le fichier et ses métadonnées étant appelée fiche.
6. Procédé selon la revendication 5, caractérisé en ce qu'au moins un premier modèle de la pluralité de modèles comporte un champ de lien vers un second modèle de telle sorte qu'une fiche instanciant le premier modèle comporte dans sa métadonnée correspondante un pointeur vers une fiche instanciant le second modèle.
7. Procédé selon la revendication 6, caractérisé en ce que le pointeur est l'adresse de la fiche instanciant le second modèle.
8. Produit programme d'ordinateur comportant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendication 5 à 7 lorsque ledit programme est exécuté sur un ordinateur.15