Brevet FR2963123A1 — publié le 20120127

Procédé de gestion de données, dispositif, et produit programme d'ordinateur correspondant. 1 DOMAINE DE L'INVENTION La présente invention se rapporte au domaine de la gestion de données. La présente invention se rapporte plus particulièrement à la gestion de données par des applications logicielles de traitement de données. Le domaine de l'invention est inclus dans celui de la mise en oeuvre de cadres de développement adaptés à la création d'applications logicielles. De tels cadres de développement sont généralement appelés «framework». En programmation informatique, un framework comprend un ensemble de composants logiciels structurels, qui définissent les fondations ainsi que les grandes lignes de l'organisation de tout ou partie d'un logiciel (architecture). En programmation orientée objet un framework comprend plus particulièrement un ensemble de classes mères qui seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui utilise le framework. Avec l'augmentation des fonctionnalités offertes par les langages de programmation, les frameworks sont devenus des pièces maîtresses pour le développement des applications logiciels. Parmi les nombreux framework existants, on peut citer `Qt'TM pour le langage C++, SymfonyTM pour le langage PHP. Cette liste est loin d'être exhaustive. De nombreux framework sont créés tous les jours par des groupes de développeurs en fonction des besoins qu'ils rencontrent. De manière synthétique, on peut affirmer qu'en règle générale un framework correspond à une vision particulière de la manière dont une application logicielle résultante doit être architecturée et à une vision particulière dont un développement d'une application logicielle doit être conduit. 2 SOLUTIONS DE L'ART ANTERIEUR Malgré la profusion actuelle de framework, la gestion des données au sens large est une peine pour le développement logiciel. La structure, l'intégrité, la persistance, la saisie, l'affichage, l'import, l'export, l'interfaçage, la synchronisation des données sont autant de problématiques communes à tous les logiciels qui manipulent des données. L'état de l'art, par l'intermédiaire des frameworks, nous propose des solutions, des paradigmes et des outils pour gérer les données. Ainsi, par exemple, certains frameworks offrent la possibilité de générer, à partir d'un unique fichier de description, une base de données et des classes permettant de manipuler ces données, éventuellement en se basant sur une approche dite « métier », quand le fichier de description est capable de prendre en compte ces aspects. Bien que de tels méthode de génération de code source d'application soient intéressantes, il n'est reste pas moins qu'il ne permettent pas de gérer les données de manière optimale. En effet, les structures des données sont trop rigides et déconnectées des couches applicatives hautes (couches manipulant les objets métier). Ceci implique : - la nécessité de « casser » l'application lorsque le modèle de données évolue, par exemple lorsque il est nécessaire de créer une nouvelle donnée ou une nouvelle entité représentative d'une ensemble de données existant ou non ; - la ré-expression des données qui ont évoluées dans toutes les couches applicatives. Ainsi, en définitive, les bénéfices initialement apportés par l'utilisation d'un cadre de développement sont perdus lorsqu'il est nécessaire de modifier la structure de la base de données. En d'autres termes, les méthodes actuelles ne permettent pas de prendre en compte l'évolution naturelle des structures de données dans le temps et il est toujours nécessaire de modifier en profondeur les couches applicatives de l'application lorsque le modèle de données évolue. 3 RESUME DE L'INVENTION L'invention ne présente pas ces inconvénients de l'art antérieur. Plus particulièrement, l'invention concerne un procédé de gestion de données destinées à être utilisées dans le cadre d'applications logicielles. Selon l'invention, ce procédé comprend d'une part une phase de définition de relations liant les données entre elles et d'autre part une phase d'enregistrement de ces données de manière séparée. Selon l'invention, chaque donnée est identifiée et indépendante à la manière d'une entité (table ou classe) et peut donc être liée à n'importe quelle autre donnée. Par comparaison avec l'approche classique « entité » où les données sont des valeurs finales, la décapsulation des données permet au développeur de créer une classe métier à partir de chaque donnée du modèle objet. En d'autres termes, l'invention aboutit à une déstructuration des données afin de les organiser et de les traiter plus facilement. Ainsi, l'invention permet de : - limiter les cas de mises à jour dites "cassantes" du modèle de données ; - automatiser le stockage, la génération de vues et d'autres fonctionnalité qui reposent sur le modèle de données (statistiques, import-export, etc.) L'invention se positionne à contre courant des techniques antérieures puisque au lieu de regrouper les données de manière à les rendre plus accessibles plus rapidement, l'invention organise les données de manière indépendante. L'enregistrement des données, en tant que tel, est indépendant d'une quelconque base de données : l'enregistrement peut être réalisé dans un fichier dit «plat », dans un document XML ou dans une base de données relationnelle classique. L'important, du point de vue de l'invention, est que les données sont déstructurées. Par exemple, les données constitutives d'un contact (nom, prénom, adresse), ne seront pas placées dans un unique enregistrement, sous une forme tabulaire, mais seront enregistrées par exemple dans une unique table, en colonne. Plus particulièrement, l'invention concerne un procédé de gestion d'une pluralité de données constituant au moins une entité, Selon l'invention, un tel procédé comprend : - une phase d'instanciation d'une définition de donnée pour chaque donnée de ladite pluralité de données ; - une phase d'instanciation d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement instanciées ; - une phase d'instanciation de chaque donnée et relation de ladite pluralité de données; - une phase d'enregistrement de chaque donnée de ladite pluralité de donnée de sorte qu'une donnée enregistrée soit associée à une définition de donnée correspondante ; - une phase d'enregistrement d'au moins une relation de sorte qu'une relation enregistrée corresponde à une définition de relation et soit associée à au moins une donnée préalablement enregistrée. Selon un mode de réalisation particulier de l'invention, ladite phase d'instanciation d'une définition de relation comprend, pour une relation : - une étape d'instanciation d'une première extrémité de relation comprenant une première cardinalité de relation et associée à une première définition de données. - une étape d'instanciation d'une deuxième extrémité de relation comprenant une deuxième cardinalité de relation et associée à une deuxième définition de données. Selon un autre aspect, l'invention concerne un dispositif de gestion d'une pluralité de données constituant au moins une entité. Selon l'invention, un tel dispositif comprend : - des moyens d'instanciation d'une définition de donnée pour chaque donnée de ladite pluralité de données ; - des moyens d'instanciation d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement instanciées. - des moyens d'instanciation de chaque donnée et relation de ladite pluralité de données; - des moyens d'enregistrement de chaque donnée de ladite pluralité de donnée de sorte qu'une donnée enregistrée soit associée à une définition de donnée correspondante ; - des moyens d'enregistrement d'au moins une relation de sorte qu'une relation enregistrée corresponde à une définition de relation et soit associée à au moins une donnée préalablement enregistrée. Selon un autre aspect, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de gestion tel que décrit préalablement. 4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 illustre le principe de la gestion de données selon l'invention ; - la figure 2 illustre le coeur de la gestion de données selon l'invention ; - la figure 3 est un diagramme des classes manipulant le modèle de données dans un mode de réalisation de l'invention - la figure 4 est un diagramme UML des classes manipulant le contenu dans un mode de réalisation de l'invention - la figure 5 décrit une version simplifiée des interfaces déclarées pour gérer la couche d'abstraction à la base de données dans un mode de réalisation de l'invention ; - la figure 6 est un modèle physique des tables de stockage résultant d'un exemple pour la mise en oeuvre de l'invention ; - la figure 7 présente un exemple de modèle construit avec le modeleur de l'invention. 5 DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention Le constat dressé par l'état de l'art de la technique antérieur est que les entités (tables de bases de données et classes métier) sont des "boîtes" qui induisent une rigidité quant à l'évolution de l'application. L'idée est de casser le principe d'entité pour rendre indépendant chaque élément (champ de données ou attribut de classe métier), de les lier à l'aide de relations pour constituer un modèle de données qui sera par ailleurs défini de façon mutualisée pour toutes les couches de l'application. 5.2 Moyens mis en oeuvre dans le cadre de l'invention L'implémentation du principe présenté nécessite de mettre en oeuvre plusieurs procédés techniques : - l'atomisation des données ; - l'appropriation du modèle de données par l'application ; - une structure de stockage indépendante du modèle de données ; - une génération sémantique des classes métier et des vues. 5.2.1 Atomisation des données Qu'elles soient structurées de façon hiérarchique, tabulaire ou relationnelle, les informations manipulées par tout système peuvent être décrites avec des données et des relations. Dans le cadre de l'invention, ces deux concepts ont été définis de la façon suivante : - donnée : représente une élément atomique d'information (ex-propriété ou champ). Une donnée est identifiée par un nom de code et une valeur. - relation : lie deux données. Du fait de leur caractère atomique, une donnée selon l'invention est monovaluée et non décomposable (figure 1). Une Donnée peut être isolée ou être connectée à un nombre indéfini de données par des relations. Une relation lie au moins deux données entre elles. La description de la relation est simplifiée dans le schéma de la figure 1, mais elle pourrait être qualifiée d'un type sémantique au sens UML (référence, agrégation, composition, héritage), mais également par le concepteur de l'application par : un nom de code de relation, le rôle joué par chaque extrémité de la relation (i.e., le rôle de chaque donnée vis-à-vis de l'autre). Ainsi le jeu de données pourra être composé de différentes données du nom de code contact, chacune associée à leurs données prénom et nom respectives, les associations étant concrétisées par des relations. 5.2.2 Appropriation du modèle de données par l'application Puisque les données et les relations permettent de construire le jeu de donnée manipulé par l'application et de le modifier à loisir, il est nécessaire pour une application de gestion de données de lui définir le modèle de données afin que l'application "sache" ce qu'elle manipule. Le fonctionnement induit par la mise en oeuvre de l'invention permet de décrire le modèle de données à l'aide de définitions de données et de définitions de relations. Le modèle est décrit dans une seule fois dans le coeur de l'application, ce qui évite la réexpression de sa structure et de ses contraintes dans toutes les couches applicatives. Ainsi, les inventeurs ont eu l'idée d'ajouter deux notions correspondant respectivement aux notions précédentes (figure 2) : - définition de donnée : déclare une donnée avec un nom de code (pour l'application) et un libellé (destiné à l'affichage utilisateur) en spécifiant son type (chaîne, numérique, booléen, etc.), sa taille maximale, etc. - définition de relation : déclare une relation possible entre deux définitions de données avec un nom de code, un libellé, le type et la cardinalité de la relation (au sens UML). Les définitions décrivent le modèle de données manipulé par l'application mais elles n'ont pas connaissance des données existantes en cours d'utilisation de l'application. Par contre, chaque donnée connaît : - ses relations aux autres données du jeu de données manipulées ; - sa définition de donnée, et de fil en aiguille les types de relation possibles aux autres données (via les définitions de relations). La figure 2 illustre de manière simple les liens intimes et explicites entre le modèle et le jeu de données. Nous montrerons dans l'implémentation préférée de l'invention que les extrémités de relation (chacune des deux définitions de donnée liées) peuvent être caractérisés plus finement selon : - sa navigabilité (oui, non) : une donnée connaît-elle celle à laquelle elle est liée ? - sa visibilité : dans le cas d'une relation de composition (1H0..1), la donnée liée peut correspondre à un attribut «public », «protégé» ou «privé» (pour la génération des classes métiers et des vues). 5.2.3 Structure du stockage indépendant du modèle A la différence des moteurs de persistance MDE (utilisant du mappage relationnel objet-entité de données), le moteur de stockage de l'invention ne manipule que les quatre notions préalablement définies (définition de donnée, définition de relation, donnée et relation). La structure de ce moteur de stockage n'a donc aucun besoin d'évoluer pour suivre les évolutions du modèle de données. La modification du modèle de données selon l'invention implique une modification d'enregistrements de définitions de donnée et de relation, alors que la modification du jeu de données implique la modification d'enregistrements de données et de relations. 5.2.4 Approche sémantique des autres couches applicatives La déclaration du modèle de données au sein de l'application permet d'automatiser. 5.2.4.1 Génération des classes métier Les classes métier sont générées par POD en suivant les relations sémantiques (type UML des relations, cardinalités, etc.) du modèle de données. L'utilisation de marqueurs de début et de fin de code généré dans le code source des classes métier permet de les isoler du code écrit par le développeur pour éviter de l'écraser à la prochaine génération. 5.2.4.2 Interfaces utilisateur Les interfaces utilisateurs de consultation ou d'édition peuvent être générées à la volée en spécifiant la définition de donnée traitée et les relations à exploiter pour constituer la liste des colonnes de valeurs à afficher à l'utilisateur. Cette interface peut éventuellement être dynamique en proposant à l'utilisateur les libellés de définition de donnée correspondant aux relations : - de composition 1 H0..1 ; - agrégées; - associées. 5.3 Avantages de la mise en oeuvre de l'invention Chaque donnée est identifiée et indépendante à la manière d'une entité (table ou classe) et peut donc être liée à n'importe quelle autre donnée : - ceci limite drastiquement les cas de mise à jour "cassantes" du modèle de données; - le stockage, la génération de vues et d'autres fonctionnalité reposant sur le modèle de données sont automatisables (statistiques, import-export, etc.) Le stockage ayant une structure indépendante du modèle de données, l'exploration de données (pour le développeur) nécessite un outil spécifique qui se base sur la génération automatisée de vues. Par la suite, on présente un mode de réalisation de l'invention. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en oeuvre dans de nombreux autres domaines. 5.4 Description d'un mode de réalisation On présente dans ce mode de réalisation, une implémentation possible : - du coeur de l'architecture ; - du module de stockage du contenu (données et relations) et du modèle (définitions) ; - du module de génération / interfaçage avec des classes métier ; - du module de génération d'IHM ; - du module de génération de statistiques - du module d'import/export - du module de synchronisation - du modeleur (vue et manipulation du modèle) - de l'explorateur de données pod (vue et manipulation des données) La plateforme choisie pour cette implémentation est la suivante : - Langage : php (côté serveur), htmUjavascript (IHM côté client) ; - Serveur HTTP : apache ; - Base de données : MySQL, Moteur InnoDB. Bien entendu, toute autre implémentation dans un autre langage orienté objet est possible, l'invention pouvant s'appliquer à toute application de gestion, qu'elle soit dans un contexte web ou non. Utilisation de MySQL pour les définitions de données, de relations, les données et les relations 5.5 Le coeur de l'architecture 5.5.1 Le modèle de données On présente, en relation avec la figure 3, le diagramme des classes manipulant le modèle de données dans ce mode de réalisation de l'invention : les définitions de données et de relations. 5.5.1.1 Définition La notion de Définition est mutualisée entre une Définition de donnée, une Définition de relation et une définition de l'extrémité de relation : - une définition est identifiée par un id (N° auto incrémenté, alloué et utilisé par le module de stockage) - l'espace de nom est une chaine code indiquant le domaine métier de la définition. Exemples : "crm", "real_estate", "financial", "math". Il est forcé en minuscule, sans espace et doit commencer impérativement par une lettre. - le nom de code, unique dans un espace de nom, identifie la définition. Exemples : "contact" (pour crm), "bouse" (pour real_estate), "debit" (pour financial), "digit" (pour Math). Le nom de code est systématiquement utilisé dans le programme pour manipuler les définitions et les instances correspondant à ces définitions (données, relations et bouts de relations). Il est forcé en minuscule, sans espace et doit commencer impérativement par une lettre. - libellé et commentaire ne sont présents qu'à des fin d'auto documentation du modèle, dans la langue du concepteur. L'affichage multilingue est géré au niveau de la couche « vue ». 5.5.1.2 Définition de donnée Une définition de donnée peut être comparée à une entrée dans un dictionnaire de données à ceci prêt qu'elle n'appartient à aucune entité (ou table dans une base de données). La définition de données donne un cadre au contenu (valeurs de Données) qui sont admises dans un système d'information. Elle hérite de la notion de Définition et se concrétise avec : - un type de donnée qui peut être simple (chaîne, booléen, etc.) ou Complexe (représenté par une classe dédiée). L'énumération des types simples présentée dans le schéma n'est pas exhaustive (ex: entier long, entier court, double, etc.). Le type vide permet de gérer des données que ne peuvent s'exprimer en une valeur simple (ex : un contact ne peut se décrire une seule donnée, il se concrétisera donc en composant d'autres données comme nom et prénom, dans la mesure où l'on souhaite manipuler ces deux information séparément). - une longueur (pour borner le type chaîne). - un nom de classe (précise la classe à employer pour les types complexes). - une unité (pour les types numériques). Utilisé à des fins d'auto documentation du modèle dans la langue du concepteur. L'affichage multilingue est géré au niveau de la couche « vue ». 5.5.1.2.1 Exemple d'une définition de données Cette donnée représente le chiffre d'affaire d'une société. - espace de nom : crm ; - nom de code : ça ; - libelle : chiffre d'affaires ; - commentaire : chiffre d'affaires annuel en euros ; - type : entier ; - unité : C. 5.5.1.3 Définition de relation Une définition de relation met en relation deux Définitions de données. Elle encadre les relations possibles dans un système d'information. Le choix a été fait, dans ce mode de réalisation, de ne se limiter qu'aux relations binaires pour imposer au concepteur la création d'une entité (ici une Définition de donnée) au confluent de la relation. Ceci est perçu comme une meilleure pratique car une Définition de donnée est plus évolutive qu'une définition relation. Cependant le système peut gérer les relations n-aires avec la même facilité (y compris au niveau du stockage). Une définition de relation possède donc deux bouts notés A et B. Chaque bout pointe sur une définition de donnée. La définition de relation est typée en réutilisant les termes UML : - association : relation simple entre deux définitions de données, sans interdépendance. - agrégation : association non symétrique, qui exprime un couplage fort et une relation de subordination (ensemble / élément). Dans ce type de relation, A est l'agrégat et B est l'agrégé. - composition : agrégation forte où le cycle de vie des composants sont liés au composé, un composé ne peut avoir qu'un seul composant. Dans ce type de relation, A est le composant et B est le composé. - héritage : Permet à une donnée B d'hériter des relations définies au niveau d'une donnée A. Dans ce type de relation, B spécialise A et doit avoir une définition de données du même type que A. Dans le cas ou A est un type Complexe (classe), le type complexe de B doit être une classe héritant du type complexe de A. A noter : contrairement à la subjectivité qu'induit UML aux relations de types agrégation et composition, l'invention les emploie dans ses différents modules pour en déduire les comportements adéquats au niveau du stockage, de la persistance, de la génération des objets métier, des IHM, etc. Les extrémités de relation achèvent la définition de la relation en donnant : - la notion de navigabilité, qui répond à la question : "Est-ce que A connaît B" et vice-versa. Par défaut, une relation est navigable dans les deux sens. Exemple : si "navigable" vaut "false" du côté A, alors une donnée correspondant à la définition de donnée côté B ne pourra pas parcourir les relations menant aux données correspondant à la définition de donnée côté A. Autrement dit : toute donnée du côté B ne pourra pas connaître les données du côté A (les B ignoreront simplement les relations existantes). - la visibilité de données correspondant à l'extrémité : privé, protégé, public. Ceci est utile dans les modules de génération des objets métier (visibilité des accesseurs), d'IHM (données qui peuvent être affichées), de statistiques, etc. - le nom de code est ici spécialement utile pour qualifier l'extrémité de la relation, au sens du "rôle" en UML. Ceci est utile pour naviguer d'une donnée à d'autres sans nécessairement nommer la relation. - la cardinalité indique le nombre minimum et maximum d'instances de données de ce bout qui peuvent être mise en relation avec une donnée de l'extrémité opposée. 5.5.1.3.1 Exemple de définition de relation Soient deux définitions de données "Société" et "Contact", on déclare la définition de relation suivante : - espace de nom : crm ; - nom de code : contact travaille societe ; - libellé : travaille ; - commentaire : relation indiquant les contacts qui travaillent dans une société ; - type : association ; Définition de l'extrémité A - espace de nom : crm ; - nom de code (définit le rôle) : employé (car du point du vue de la société, le contact est un employé) ; - libellé : employé ; - commentaire : indique les contacts employés par cette société (facultatif) ; - extrémité : 'A' ; - définition de donnée : Contact (Instance de la classe DefinitionDefinition correspondante) ; - navigable : oui (une société peut en effet accéder à ses employés) ; - visibilité : public ; - cardinalité min : 0 (Une société n'a pas nécessairement d'employés) ; - cardinalité max : null (pas de limite maximum sur le nombre d'employés) ; Définition de l'extrémité B - espace de nom : crm ; - nom de code (définit le rôle) : employeur (car du point du vue du salarié, la société est son employeur) ; - libellé : employeur ; - commentaire : indique la société qui emploie ce contact (facultatif) ; - extrémité : 'B' ; - définition de donnée : Société (Instance de la classe DefinitionDefinition correspondante) ; - navigable : oui (un contact peut en effet accéder à la société dans laquelle il travaille) ; - visibilité : public ; - cardinalité min : 0 (si un contact ne travaille pas systématiquement dans une société) ; - cardinalité max : 1 (si un contact ne peut travailler que dans une société au maximium) ; 5.5.1.4 Déclaration du modèle Dans ce mode de réalisation de l'invention, le modèle doit être déclaré sous la forme d'un script créant les définitions de données et de relations. A l'issu du script, ces définitions sont enregistrées en base de données. Ce script n'est à exécuter que lorsque l'on souhaite modifier le modèle. Il est toutefois possible de créer un schéma XML pour la déclaration du modèle, dérivé du XMI pour être adapté à au framework de l'invention. En fin de compte, l'outil le plus facile pour déclarer et manipuler le modèle avec une interface graphique sera le modeleur. Quoiqu'il en soit, lors de l'initialisation du programme, les définitions sont lues en base de données et gardées en mémoire. Contrairement aux approches MDA, le modèle n'est donc pas utilisé uniquement pour générer du code mais il constitue véritablement le coeur de l'application. 5.5.2 Les données (contenu) On présente, en relation avec la figure 4, le diagramme UML des classes manipulant le contenu : Données et relations. On y place pour rappel les objets de définition auxquels sont connecté les objets accueillant le contenu. 5.5.2.1 Donnée Une donnée peut simplement s'exprimer par une définition de donnée (qui donne le contexte) et une valeur (qui donne le contenu). 5.5.2.1.1 id C'est un numéro auto incrémenté, alloué et utilisé par le module de stockage. Chaque donnée possède un numéro unique pour sa définition de donnée. Ceci lui fournit son indépendance et sa capacité d'évolution, lui permettant d'être liée à n'importe quelle autre donnée par l'entremise des relations. Cet attribut est vide si la donnée n'a pas encore été enregistrée. 5.5.2.1.2 définition de donnée Une donnée est connectée à une et une seule Définition. Cette dernière lui confère son contexte d'existence et de validation. 5.5.2.1.3 valeur Le propre d'une donnée est de contenir une valeur : celle-ci est de type variable, dépendant du type de la définition de donnée. Lorsqu'une valeur est modifiée, la donnée est notée comme non validée et non enregistrée. 5.5.2.1.4 valider() Utilise la définition de donnée pour vérifier si la valeur correspond au type défini. Demande à chaque relation de se valider puis vérifie que les cardinalités déclarée dans les définitions de bout relations sont respectées (min et max). La donnée est dès lors notée comme validée (pour éviter sa revalidation lors d'un appel ultérieur) Exemple : Soient A et B respectivement deux définitions de donnée "Contact" et "Nom" ayant en commun une définition de relation avec, du côté B, la cardinalité "min=1" et "max=1". Dans ces conditions, une donnée de la définition "Contact" qui n'est pas reliée à exactement une donnée de la définition "Nom" sera déclarée non valide. 5.5.2.1.5 enregistrer() Valide la donnée et, en cas de succès, délègue à la couche de stockage son enregistrement. Si la valeur est vide alors que sa définition précise un type non vide, la donnée est supprimée. Ceci garantit de ne gérer que des données consistantes, c'est à dire nanties d'une valeur. La donnée est alors notée comme enregistrée pour éviter son réenregistrement en cas d'appel ultérieur. 5.5.2.1.6 supprimer() Supprime les relations liées à la donnée puis supprime la donnée. La suppression des relations a pour effet de supprimer en cascade les données dans le cadre de relation de composition ou d'héritage (cf suppression d'une relation). 5.5.2.1.7 Exemple de donnée Soit "Pod Inc." une société. Elle est déclarée comme suit : - définition de donnée : Société (Instance de la classe DefinitionDefinition correspondante, de type chaîne) - id = 1 (cette société a été la première enregistrée dans le système d'information) - valeur = "Pod Inc." 5.5.2.2 Relation Une relation réunion deux données dans le cadre d'une définition de relation. A l'instar de cette dernière, elle possède deux bouts de relation notés A et B. 5.5.2.2.1 valider Appelle la méthode valider sur chacun des deux bouts puis marque la relation comme validée. 5.5.2.2.2 enregistrer() Appelle la méthode valider puis, en cas de succès, enregistre la relation. Si une donnée à un bout n'a pas d'id, son enregistrement est demandé au préalable. Si cette relation est de type composition, appel de enregistrer sur la donnée côté B. La relation est alors notée comme enregistrée pour éviter son ré-enregistrement en cas d'appel ultérieur. 5.5.2.2.3 supprimer() Supprime la relation. Si cette relation est une relation de composition, supprime en cascade la donnée du côté B. Si cette relation est de type héritage, supprime les données aux deux extrémités de la relation. 5.5.2.2.4 BoutRelation (bouta et bout b) Chaque extrémité de relation est connectée à la relation correspondante et à une donnée. Une donnée ne peut être affectée à une extrémité que si sa définition de donnée correspond à celle déclarée dans la définition de l'extrémité de relation correspondante. Ceci garanti l'intégrité des relations. Lorsqu'une extrémité de relation est modifiée, la relation correspondante est notée comme non validée et non enregistrée. La propriété « donnee_id » est utile pour gérer l'instanciation tardive, c'est-à-dire de ne pas systématiquement instancier les données aux deux bout d'une relation. La donnée correspondante n'est donc instanciée que lors de son premier appel. 5.5.2.2.5 Exemple de relation Soient deux données "Pod Inc." et "Dominique Péré" correspondant respectivement aux définitions de données "Société" et "Contact", on déclare la relation suivante : - définition de relation : travaille (instance de la classe «DefinitionRelation» correspondante, définie ci-avant) - extrémité A : o donnée : Instance de la classe « Donnee » correspondant à "Dominique Péré", d'id 1, avec la définition de donnée "Contact" o donnee id : 1 extrémité B : o donnée : Instance de la classe Donnee correspondant à "Pod Inc.", d'id 1, avec la définition de donnée "Société" o donnee id : 1 5.6 Module de stockage 5.6.1 Stockage La base de données choisie est MySQL avec le moteur de stockage InnoDB pour ses capacités relationnelles et transactionnelles. On distingue le stockage des données et relations (contenu) du stockage des définitions (modèle). I1 est à noter que la couche de stockage peut être implémentée totalement différemment en implémentant les interfaces dédiées. Le coeur du framework de l'invention ne fait appel qu'à des interfaces. Un simple paramétrage de l'application (moteur de stockage et chaîne de connexion) permet de passer d'une couche de stockage à une autre. D'autre part, une unique couche de stockage implémentée avec les objets PDO (« Php Data Objects ») permet de faire abstraction de la base de données effectivement employée. 5.6.1.1 interfaces déclarées Une version simplifiée des interfaces déclarées pour gérer la couche d'abstraction à la base de données est ci-après présentée en relation avec la figure 5. 5.6.1.1.1 IStockageConnexion Représente une connexion à une base de donnée. Cette classe déclare les méthodes permettant d'ouvrir et fermer une connexion. Elle permet également d'exécuter une requête en PodQL (dérivé du langage SQL adapté au framework de l'invention). Tous les objets accédant au stockage l'utilisent pour obtenir la connexion ou exécuter du PodQL. Une requête PodQL retourne un objet implémentant l'interface IStockageJeuResultats, que l'on peut parcourir à la manière d'un «fetch » pour explorer le résultat. Chaque ligne de résultat (IStorageLigneResultat) exprime les valeurs retournées en indexant par nom de code de définition de donnée de d'extrémité de relation en fonction de la requête posée (cf. section PodQL pour plus de détails sur son fonctionnement). 5.6.1.1.2 IStockageAdaptateur Les interfaces IStockageAdaptateur et héritants définissent les adaptateurs à implémenter pour pouvoir lire et enregistrer les objets du frame work de l'invention : « DefinitionDonnee » , « DefinitionRelation », « Donnee » et « Relation ». Elles permettent de créer un adaptateur sur une connexion donnée et de lire, écrire et supprimer n'importe quel objet depuis la base de données. Les interfaces manipulant les données et relations nécessitent en sus de préciser quelle définition de donnée ou de relation est concernée. 5.6.1.1.3 IStockageAdaptateurponnee Cet adaptateur est le plus important car il gère toutes les instanciations (lectures) des données. La lecture par id ne peut évidemment suffire. C'est à ce niveau que l'on peut préciser quelles données lire en fonction de leur valeur ou de la valeur d'autres données directement liées (méthode lire_selon_valeur). Pour les cas plus complexes, on écrit la clause where d'une requête en [#PodQLlPodQL]] (méthode lire_selon requete). 5.6.1.2 Structure de la BDD pour MySQL Pour l'implémentation en MySQL/InnoDB dans ce mode de réalisation, on propose une structure de BDD avec une table par définition de donnée et une table par définition de relation, chacune stockant les valeur des données et relations. Chaque table de données et nommée avec l'id de la définition de donnée et nantie d'un id et d'une valeur. L'id est un entier auto incrémenté, clé primaire de la table. Chaque table de relations et nommée avec l'id de la définition de relation et nantie d'un id, de l'id de la donnée de l'extrémité A et de l'id de la donnée de l'extrémité B. L'id est un entier auto-incrémenté, clé primaire de la table. Les champs donnee_a_id et donnee_b_id sont indexés sur deux index distincts, permettant d'optimiser les jointures avec les tables de relation. Enfin, une l'intégrité référentielle est activée entre chaque clef étrangère de relation et chaque id de donnée, garantissant que les deux extrémités d'une relation font référence à des données existantes, avec mise à jour et suppression en cascade. A titre d'exemple, soient les définitions de données suivantes : 1. contact : id="1", nom_de_code="contact", type="vide" 2. nom : id="2", nom_de_code="nom", type="chaine", longueur="50" 3. prénom : id="3", nom_de_code="prenom", type="chaine", longueur="50" 4. société: id="4", nom_de_code="societe", type="chaine", longueur="50" Soient les définitions de relations suivantes : 5. Nom du contact : id="1", nom decode="contact nom", type="composition", bout a="1", bout b="2" 6. Prénom du contact : id="2", nom decode="contact_prenom", type="composition", bout a="1", bout b="3" 7. Société du contact : id="4", nom decode="contact societe", type="association", bout a="1", bout b="4", role bout a = "employe", role bout b="societe" Voici le modèle physique des tables de stockage qui en découlent est présenté en relation avec la figure 6. Les noms des tables de données sont préfixés de "donnees " suivi de l'id de la définition de donnée correspondante. Les données correspondant aux définitions de données (notées après DD) contact, nom et prénom sont donc respectivement stockées dans donnees 1, donnees_2 et donnees_3. On remarque que donnees_I ne possède pas de champ "valeur", car la définition de donnée "contact" précise un type vide. A l'inverse, donnees_2 et donnees_3 ont un champ "valeur" de type varchar(50) correspondant au type de la définition de données. A l'identique, les noms des tables de données sont préfixés de "relations_" suivi de l'id de la définition de relation correspondante. La table « relations 1 » relie un contact à son nom et « relations_2 » relie un contact à son prénom. Il est à noter que ces tables sont créées automatiquement, si nécessaire, lors de l'initialisation de l'application, au regard des définitions de données existantes. 5.6.2 PODQL Suite à l'exposé du de la structure physique de la BDD, on voit que les requêtes sur cette structure de données s'avère particulièrement laborieuse à exploiter en SQL, du fait de l'explosion des données, du nommage des tables et du nombre important de jointures à effectuer (parcourt des relations). 5.6.2.1 Jointures automatisée On décrit donc un langage de requête dérivé du SQL, permettant de faire abstraction de la structure physique de la base de données. L'intérêt principal du PodQL est d'automatiser les jointures. Les données valeurs à atteindre sont exprimées à partir du nom de code de la donnée ou du nom de rôle par rapport une donnée centrale. Grâce à cette traduction de requête et au fait que le framework de l'invention "connaisse" le modèle de données, on économise purement et simplement l'expression de la clause "FROM" ainsi que le jointure traditionnelles. On introduit la notion la notion d'opérateur de parcourt de relation, noté "-" (un tiret suivi du signe supérieur, représentant une flèche). On présente deux explications par l'exemple d'utilisation du PodQL tel qu'il est interprété par la méthode « MySQLConnexion.executer requete_pod() » qui implémente « IStockageConnexion.executerrequete_pod() ». 5.6.2.1.1 Exemple de select avec valeurs En reprenant les définitions de données et de relations définies lors de l'exposé de la Structure de la BDD pour MySQL, admettons que l'on souhaite exécuter une requête qui donne les contacts de la société 'pod inc.'. La requête en PodQL sera la suivante : SELECT contact->nom, contact->prenom WHERE contact- >employeur = 'pod inc.' ORDER BY contact->nom Ici, "contact" est vu comme la donnée centrale, les autres données sont exprimées comme relation à partir de cette dernière. La requête précédente se traduit en SQL, sur notre implémentation physique décrite plus haut, comme suit : SELECT donnees 2.valeur AS 'contact->nom', donnees 3.valeur AS 'contact->prenom' FROM donnees 1, donnees 2, donnees 3, donnees 4, relations 1, relations 2, relations 3 WHERE donnees 1.id = relations 1.donnee a id AND relations 1.donnee b id = donnees 2.id AND donnees 1.id = relations 2.donnee a id AND relations 2.donnee b id = donnees 3.id AND donnees 1.id = relations 3.donnee a id AND relations 3.donnee b id = donnees 4.id AND donnees 4.valeur = 'pod inc.' ORDER BY donnees 2.valeur Remarque : On ne se soucie pas de l'ordre des éléments dans la clause « where » car MySQL planifie automatique la requête et détermine l'ordre d'exécution optimal. 5.6.2.1.2 Exemple de select avec id et regroupement Voici un autre exemple qui permet de comptabiliser le nombre d'employés par société : SELECT societe, count(societe->employé.id) AS nb employes GROUP BY societe On constate ici l'utilisation de l'opérateur "." (dans societe-employé.id), indiquant une champ d'une table comme en SQL traditionnel. Par défaut, c'est la valeur qui est retournée mais ici la valeur d'une donnée contact n'existe pas. L'application du ".id" permet de préciser que l'on souhaite obtenir l'id dans cette colonne. La requête précédente se traduit en SQL, sur notre implémentation physique décrite plus haut, comme suit : SELECT donnees 4.valeur AS 'societe', count(relations 3.data a id) AS nb employes FROM donnees 4, relations 3 WHERE donnees 4.id = relations 3.data b id GROUP BY donnees 4.valeur Le PodQL détecte ici que, concernant la table donnee_1, seul l'id est demandé. Il évite donc la jointure de relations_3 vers donnees_I n'apportant aucune information supplémentaire utile. 5.6.2.2 Instanciation en série On a vu que le PodQL pouvait remonter des valeurs et des identifiants de donnée en automatisant les jointures. Une autre de ses intérêts est de pouvoir instancier "en chaîne" des données correspondant à différentes définitions de données, évitant de d'effectuer une requête sur la base de données à chaque parcourt de relation. Par défaut, on utilise les types de relations définis précédemment. A l'instanciation de toute donnée ayant des relations de type agrégation ou composition dont elle est l'agrégat, entraîne l'instanciation "en chaîne" des données. Cependant ce comportement par défaut peut amener à lire trop de données ou pas assez selon les contextes des applications. En conséquence, la méthode MySQLAdaptateurponnee.lire_selon requeteQ, qui implémente IStockageAdaptateurponnee.lire_ selon_requete9, permet d'interpréter une requête PodQL précisant les données à retourner (SELECT) en gérant l'instanciation de toutes les données et relation concernées. Le colonnes retournées ne sont donc non plus seulement les valeurs mais également les id et données et des relations à instancier à partir résultat de la requête. Reprenons l'exemple de la recherche des employés de la société "pod inc.". SELECT contact->nom, contact->prenom WHERE contact->employeur = 'pod inc.' ORDER BY contact->nom La méthode MySQLAdaptateurponnee.lire_selon requete() va générer, ligne pour ligne, le code SQL suivant SELECT donnees 1.id AS donnees 1 id, relations 1.id AS relations 1 id, donnees 2.id AS donnees 2 id, donnees 2.valeur AS donnees 2 valeur, relations 2.id AS relations 2 id, donnees 3.id AS donnees 3 id, donnees 3.valeur AS donnees 3 valeur FROM donnees 1, donnees 2, donnees 3, donnees 4, relations 1, relations 2, relations 3 WHERE donnees 1.id = relations 1.donnee a id AND relations 1.donnee b id = donnees 2.id AND donnees 1.id = relations 2.donnee a id AND relations 2.donnee b id = donnees 3.id AND donnees 1.id = relations 3.donnee a id AND relations 3.donnee b id = donnees 4.id AND donnees 4.valeur = 'pod inc.' ORDER BY donnees 2.valeur Seule la clause SELECT a été modifiée par rapport à l'exemple précédent. Son interprétation par « MySQLAdaptateurponnee » permet d'instancier pour chaque contact correspondant : - les données de définition 'contact' - les relations de définition 'contact nom' liées au contact - les données de définition 'nom' liées au relations 'contact nom' - les relations de définition 'contact_prenom' liées au contact - les données de définition 'prenom' liées au relations 'contact_prenom' Grâce à ce procédé, une seule requête a été posée à la base de données, permettant d'instancier l'ensemble des données et relations concernées. 5.6.2.2.1 opérateur "*" Pour simplifier encore le processus d'instanciation des données en série, on introduit l'opérateur "*" dans la clause SELECT, déjà présent en SQL, pour le traduire en son équivalent en PodQL de la manière suivante : "A_*" est équivalent toutes les données B liée à une donnée A par une relation de composition, dont A est le composé. Ainsi, étant donné que "contact nom" et "contact_prenom" sont des relations de compositions les deux requêtes PodQL suivantes sont similaires et produiront le même code SQL : SELECT contact->*; SELECT contact->nom, contact->prenom; 5.7 Modeleur Basée sur UML, la modélisation avec le framework selon l'invention est très similaire aux diagrammes de classes à quelques différences près. Les différences sont les suivantes : 1. On ne représente pas des classes mais des définitions de données, représentée par des bulles. 2. les définitions de données contiennent une propriété unique : la valeur (à typer) 3. les définitions de données ne contiennent pas de méthodes (ou opérations) En revanche les relations UML sont en tout point similaires au définitions de relations du framework de l'invention. Comme la notion de propriété n'existe plus, on doit tout modéliser en définitions de données et de relations, comme si on modélisait un modèle objet en s'astreignant à ce que chaque propriété soit un objet métier. La figure 7 présente un exemple de modèle construit avec le modeleur. Un fois le modèle validé, le modeleur propose les fonctions suivantes : - la génération du fichier XMI représentant le modèle - la génération des instructions PodQL nécessaires à du dé-doublonnage (cas du passage d'une cardinalité de relation de 0..1 à O..N) - la génération des instructions PodQL nécessaires à faire migrer une relation vers une donnée. Ex : relation 'est marie a'; entre deux définitions de données 'personne'; qui devient une donnée 'mariage', permettant ensuite de le qualifier par la date, le lieu, etc. - la génération de classes métier sur une sélection de définitions de données : Cf Génération de classes métier 5.8 Module de génération et d'interfaçage avec des classes métier 5.8.1 Génération de classes métier Dans le modeleur, l'utilisateur marque les définitions de données qu'il souhaite voir générer en objets métiers, indique le répertoire à employer pour les modèles de générations (ou "templates") ainsi que le répertoire ou écrire les classes générées. Les modèles de génération définis sont les suivants : - classe : déclaration de la classe avec implémentation de l'interface IConteneurponnee (Intégration dans une application existante) - contenu de la classe: avec constructeur, méthodes d'accès, de lecture, d'enregistrement, de suppression de la donnée - un template par type d'accesseur correspondant au type de relation. cf Accesseurs Ils peuvent être modifiés pour répondre au mieux aux conventions de codage de chaque organisation. Le template de la classe inclut également une zone protégée que le générateur conserve en cas de ré-génération de la classe. Ceci permet aux développeurs d'implémenter les méthodes métier propres aux traitements de son application. 5.8.2 Accesseurs Chaque accesseurs (get_xxx, set_xxx) utilise les noms de code des rôles de l'extrémité de relation opposé pour dénommer les accesseurs. Par défaut, on génère un accesseur get/set pour chaque définition de relation qui est navigable dans le sens approprié, avec la visibilité donnée par la définition de relation (privé, protégé, public). Les accesseurs sont générés par défaut avec les noms suivants (personnalisables par template) : - [get/set]_valeur_[nom de code de role] : pour une relation dont la cardinalité max est 1, "get" retourne une valeur de donnée ou null - [get/ajouter/supprimer]_valeur[s]_[nom de code de role] : pour une relation dont la cardinalité max est > 1, "get" retourne un tableau de valeurs (array php) - [get/set]_donnee_[nom de code de role] : pour une relation dont la cardinalité max est 1, "get" retourne l'objet Donnee lié ou null - [get/ajouter/supprimer]_donnee[s]_[nom de code de role] : pour une relation dont la cardinalité max est > 1, "get" retourne un tableau des objets Donnee liés Les deux accesseurs suivants sont générés uniquement les définitions des données à accédé ont été générées ou dont le type est complexe (cf. Intégration dans une application existante). - [get/set]_objet_[nom de code de role] : pour une relation dont la cardinalité max est 1, "get" retourne un objet métier (classe existante ou générée) ou null - [get/ajouter/supprimer]_objet[s]_[nom de code de role] : pour une relation dont la cardinalité max est > 1, "get" retourne un tableau des objets métier (classe existante ou générée) ou null 5.8.3 Intégration dans une application existante Pod propose également de pourvoir s'interface avec une application existante, du moment que celle-ci est programmée en objet. L'idée est de déclarer une définition donnée correspondant à chaque classe à interfacer et de la déclarer en type complexe en précisant le nom de classe existante. Chaque classe à relier à pod doit encapsuler une propriété "donnee" et implémenter l'interface IConteneurponnee qui définit les méthodes suivantes : - get_donnee : retourne l'objet Donnee pod correspondant à donne - set donnee : affecter à la propriété "donnee" une Donnee pod - get_id : retourne un identifiant unique de cette instance. Cet id est stocké en bdd dans le champ valeur de la table de données correspondante - enregistrer : permet d'enregistrer à fois l'instance en cours et la donnée encapsulée - supprimer : supprimer l'instance en cours et la donnée encapsulée - Instancier(id) (méthode statique) : permet d'instancier une instance de cette classe à partir d'un id, ainsi de d'instancier et affecter la donnée correspondante à la propriété "donnee" encapsulée. A l'instar des classes générées, l'utilisateur peut générer avec le modeleur une série d'accesseurs dans cette classe afin de pouvoir accéder aux valeurs, données (et objets) directement liés à la données, sans avoir besoin d'interroger les relations de la donnée encapsulée. Ce code est généré en fin de classe dans une zone réservée, et ré-générée le cas échéant dans cette même zone. 5.9 Module IHM Le modèle utilisé par l'interface est le modèle POD : - connaissance du modèle de données + définitions : contrôle de saisie - génération dynamique (possible aussi à l'exécution) d'écrans d'affichage/saisie adaptés au modèle - contrôle de saisie automatisé : expliquer comment ça marche Options de génération (pour chaque écran) : - déclaration de la DD centrale (affichée ou non) - déclarations explicites des relations et données à afficher, ou par exclusion - templates - définition des données et relations affichables (de celles dédiées à l'application)10 REVENDICATIONS1. Procédé de gestion d'une pluralité de données constituant au moins une entité, caractérisé en ce qu'il comprend : - une phase d'instanciation d'une définition de donnée pour chaque donnée de ladite pluralité de données ; - une phase d'instanciation d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement instanciées ; - une phase d'instanciation de chaque donnée et relation de ladite pluralité de données; - une phase d'enregistrement de chaque donnée de ladite pluralité de donnée de sorte qu'une donnée enregistrée soit associée à une définition de donnée correspondante ; - une phase d'enregistrement d'au moins une relation de sorte qu'une relation enregistrée corresponde à une définition de relation et soit associée à au moins une donnée préalablement enregistrée. 2. Procédé de gestion d'une pluralité de données selon la revendication 1, caractérisé en ce que ladite phase d'instanciation d'une définition de relation comprend, pour une relation : - une étape d'instanciation d'une première extrémité de relation comprenant une première cardinalité de relation et associée à une première définition de données. - une étape d'instanciation d'une deuxième extrémité de relation comprenant une deuxième cardinalité de relation et associée à une deuxième définition de données. 3. Dispositif de gestion d'une pluralité de données constituant au moins une entité, caractérisé en ce qu'il comprend : - des moyens d'instanciation d'une définition de donnée pour chaque donnée de ladite pluralité de données ; - des moyens d'instanciation d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement instanciées.- des moyens d'instanciation de chaque donnée et relation de ladite pluralité de données; - des moyens d'enregistrement de chaque donnée de ladite pluralité de donnée de sorte qu'une donnée enregistrée soit associée à une définition de donnée correspondante ; - des moyens d'enregistrement d'au moins une relation de sorte qu'une relation enregistrée corresponde à une définition de relation et soit associée à au moins une donnée préalablement enregistrée. 4. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de gestion selon l'une au moins des revendications 1 à 2, lorsqu'il est exécuté sur un ordinateur.15