Procédé d'enregistrement 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.

Le domaine de l'invention est inclus dans celui de la mise en œuvre 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 logicielles. Parmi les nombreux framework existants, on peut citer 'Qt'™ pour le langage C++, Spring™ pour le langage Java et Symfony™ pour le langage PHP. Cette liste est loin d'être exhaustive. De nombreux frameworks 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

Les projets de développements d'applications informatiques ont bénéficié à partir des années 70 de la méthode Merise qui fournissait un cadre intégré d'analyse de conception et de réalisation des systèmes d'informations, permettant notamment de formaliser la structure des données. Puis, dans les années 90, la méthode UML a fourni un cadre pour la modélisation des classes pour la conception d'applications orientées obj et. Les frameworks de développement d'applications développés et utilisés aujourd'hui s'appuient sur ces méthodes et suivent donc une ingénierie logicielle orientée modèle (MDE : model-driven engineering). Malgré la profusion actuelle de frameworks MDE, 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 des outils d'aide au développement montre qu'il existe différentes solutions de frameworks MDE qui offrent la possibilité de générer les données. Certains d'entre eux 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 telles méthode de génération de code source d'application soient intéressantes, il n'est reste pas moins qu'ils 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 :

l'apparition d'anomalies d'impédance (« object-relational impédance mismatch »), dues au fait que les couches de stockage des frameworks actuels miment le modèle de données, lorsque le SGBD utilisé (Oracle, MySQL par exemple) ne permet pas d'exprimer des contraintes d'intégrité de la couche objet (accessibilité publique/privée des attributs, notion d'interface, d'héritage, de polymorphisme, la granularité des modifications de données, relations élaborées entre des données - à 3 extrémités, avec certains obligatoires et d'autres facultatifs -, navigabilité d'une relation entre données, etc.) ;

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 du nouveau modèle de 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 le modèle de données et la structure de la base de données correspondante. En d'autres termes, les méthodes actuelles ne tiennent pas compte de 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. Ceci est principalement du à la manière dont les données sont enregistrées au sein de la structure d'enregistrement des données.

L'invention permet de résoudre ces problèmes associés à l'art antérieur en proposant une méthode d'enregistrement des données qui ne présente pas ces inconvénients de l'art antérieur. 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é d'enregistrement de données destinées à être utilisé dans le cadre du développement et de la maintenance d'applications logicielles. Selon l'invention, ce procédé comprend d'une part une phase de définition des données - et des relations qui les relient - et d'autre part une phase de gestion 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. L'invention amène un nouveau paradigme de description du modèle de donnée qui, en étant mutualisé à travers les différentes couches de l'application (stockage, modèle objet, vue, etc.) permet de s'affranchir des problèmes d'inadéquations d'impédance.

En d'autres termes, l'invention aboutit à une déstructuration de l'enregistrement des données afin de les traiter et de faire évoluer leur organisation 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 la structure du stockage des données enregistrées ne dépend pas de la structure des donné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 peuvent être enregistrées par exemple dans des tables indépendantes.

Plus particulièrement, l'invention concerne un procédé d'enregistrement d'une pluralité de données constituant au moins une entité,

Selon l'invention, un tel procédé comprend :

une phase de création d'une définition de donnée pour chaque donnée de ladite pluralité de données ; une phase de création d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement créées ;

une phase de création 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ées 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 de créationd'une définition de relation comprend, pour une relation :

une étape de création 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 de création d' une deuxième extrémité de relation comprenant chacune une cardinalité de relation associée à une définition de données.

Selon une caractéristique particulière de l'invention, une définition de données comprend :

un nom de code ;

un type.

Selon une caractéristique particulière de l'invention une définition de relation comprend :

un nom de code ;

un type ;

au moins une extrémité.

Selon un autre aspect, l'invention concerne un dispositif d'enregistrement d'une pluralité de données constituant au moins une entité. Selon l'invention, un tel dispositif comprend :

des moyens de création d'une définition de donnée pour chaque donnée de ladite pluralité de données ;

des moyens de création d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement créées.

des moyens de création 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ées 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é d'enregistrement 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 cœur 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 œuvre de l'invention ;

la figure 7 présente des exemples de modèles construits 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érieure 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 à la base de l'invention 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 est par ailleurs défini de façon mutualisée pour toutes les couches de l'application.

5.2 Moyens mis en œuyre dans le cadre de l'invention

L'implémentation du principe présenté nécessite de mettre en œuvre plusieurs procédés techniques :

- l'atomisation des données ; l'appropriation du modèle de données par l'application ;

une structuration de stockage indépendante du modèle de données ;

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 un é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 une ou plusieurs données (une donnée pouvant être liée à elle- même).

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 l, 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.

Ainsi le jeu de données peut ê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ées manipulées 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 œuvre 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 une seule fois dans le cœur de l'application, ce qui évite la réexpression de sa structure et de ses contraintes dans toutes les couches applicatives.

Ainsi, l'inventeur a 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é facultatif (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 au moins deux définitions de données avec un nom de code, un libellé facultatif, le type et la cardinalité de la relation (au sens UML) pour chacune des définitions de donnée.

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 couplages forts 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 celles à laquelle elle est liée ? sa visibilité : dans le cas d'une relation de composition (1<->0..1), la donnée liée peut correspondre à un attribut « public », « protégé » ou « privé ».

5.2.3 Structure du stockage indépendant du modèle

A la différence des moteurs de persistance MDE (approche ORM c'est-à-dire utilisation du mappage objet 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.3 Avantages de la mise en œuyre 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 sto ckage et les autres fonctionnalités reposant sur le modèle de données sont automatisables (statistiques, import-export, etc.).

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 œuvre 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 cœur de l'architecture ;

du module de stockage du contenu (données et relations) et du modèle (définitions) ; du module d'interfaçage avec des classes métier ;

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 (vue et manipulation des données) ;

La plateforme choisie pour cette implémentation est la suivante :

Langage : php (côté serveur), html/javascript (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 de données, qu'elle soit dans un contexte web ou non.

5.5 Le cœur 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 (numéro auto incrémenté, alloué et utilisé par le module de stockage)

l'espace de nom est une chaîne 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), "house" (pour real estate), "débit" (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 extrémités de relations). Il est forcé en minuscule, sans espace et doit commencer im é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ée donne un cadre au contenu, c'est-à-dire aux valeurs des 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 : ca ;

libelle : chiffre d'affaires ;

commentaire : chiffre d'affaires annuel en euros ;

type : entier ;

unité :€.

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 se limiter 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 de 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 extrémités notés A et B. Chaque extrémité 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.

On note que contrairement à la subjectivité purement sémantique qu'induit UML au niveau des 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 peut 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 peut 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 cette extrémité 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 paradigme 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 cœur 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 des extrémités de 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=l" et "max=l". 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 programming" une société. Elle est déclarée comme suit :

définition de donnée : Société (Instance de la classe Définition 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 programming" 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 extrémités de relation notés A et B. On note qu'une relation n'est pas forcément limitée à deux extrémités et qu'il est tout à fait possible de mettre en œuvre des relations n-aires.

5.5.2.2.1 valider()

Appelle la méthode valider() sur chacun des extrémités puis marque la relation comme validée.

5.5.2.2.2 enregistrer()

Appelle la méthode validerQ puis, en cas de succès, enregistre la relation. Si une donnée à une extrémité 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 extrémités de la relation.

5.5.2.2.4 ExtremiteRelation (extremite a et extremite 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 garantit 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é « donnée d » est utile pour gérer l'instanciation tardive, c'est-à-dire de ne pas systématiquement instancier les données aux deux extrémités 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 programming" 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 « Donnée » 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 Donnée correspondant à "Pod programming", 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).

Il est à noter que la couche de stockage peut être implémentée totalement différemment en implémentant les interfaces dédiées. Le cœur 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éritantes définissent les adaptateurs à implémenter pour pouvoir lire et enregistrer les objets du frame work de l'invention : « DefinitionDonnee », « DefinitionRelation », « Donnée » 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 IStockageAdaptateurDonnee

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 PodQL (méthode lire selon requête).

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="l", nom de code- 'contact", type="vide" 2. nom : id="2", nom_de_code="nom", type- 'chaîne", 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="l", nom de code- 'contact nom", type="composition", extremite_a="l", extremite_b="2"

6. Prénom du contact : id="2", nom_de_code="contact_prenom", type="composition", extremite a- Ί", extremite_b="3"

7. Société du contact : id="4", nom de code- 'contact societe", type="association", extremite_a="l", extremite_b ⁼ "4", role extremite a = "employé", role_extremite_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 "données " 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 l, donnees_2 et donnees_3. On remarque que donnees l ne possède pas de champ "valeur", car la définition de donnée "contact" précise un type vide. À 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.

À 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ées

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 les jointures 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.executer_requete_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 programming'. La requête en PodQL sera la suivante :

SELECT contact->nom, contact->prenom WHERE contact->employeur = 'Pod programming' 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_l, donnees_2, donnees_3, donnees_4, relations_l, relations 2, relations 3

WHERE donnees_l . id = relations_l . donnee_a_id AND

relations 1. donnée b id = données 2.id

AND donnees_l.id = relations_2. donnee_a_id AND

relations_2. donnee_b_id = donnees_3.id

AND données l.id = relations 3. donnée a id AND

relations_3. donnee_b_id = donnees_4.id

AND données 4. aleur = 'Pod programming'

ORDER BY donnees_2.valeur

Remarque : On ne se soucie pas de l'ordre des éléments dans la clause « where » car MySQL planifie automatiquement 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 société, count ( societe->employé . id) AS nb_employes

GROUP BY société

On constate ici l'utilisation de l'opérateur "." (dans societe→employé.id), indiquant un 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 'société',

count ( relations_3. data_a_id) AS nb_employes

FROM données 4, relations 3

HERE donnees_4. id = relations_3. data_b_id

GROUP BY donnees_4.valeur

Le PodQL détecte ici que, concernant la table donnee l, seul l'id est demandé. Il évite donc la jointure de relations_3 vers donnees l 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 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 d'utilisation. En conséquence, la méthode MySQLAdaptateurDonnee.lire_selon_requete(), qui implémente IStockageAdaptateurDonnee.lire selon requeteQ, 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 programming.". SELECT contact->nom, contact->prenom

WHERE contact->employeur = ' Pod programming '

ORDER BY contact->nom

La méthode MySQLAdaptateurDonnee.lire selon requete() va générer, ligne pour ligne, le code SQL suivant

SELECT données l.id AS données 1 id, relations l.id AS

relations_l_id, donnees_2.id AS donnees_2_id, donnees_2.valeur AS données 2 valeur,

relations_2. id AS relations_2_id, donnees_3. id AS

données 3 id, données 3. valeur AS données 3 valeur

FROM donnees_l, donnees_2, donnees_3, donnees_4, relations_l, relations 2, relations 3

WHERE donnees_l.id = relations_l . donnee_a_id AND

relations_l . donnee_b_id = donnees_2.id

AND données l.id = relations 2. donnée a id AND

relations_2. donnee_b_id = donnees_3.id

AND données l.id = relations 3. donnée a id AND

relations_3. donnee_b_id = donnees_4.id

AND données 4. valeur = 'Pod programming'

ORDER BY donnees_2.valeur

Seule la clause SELECT a été modifiée par rapport à l'exemple précédent. Son interprétation par « MySQLAdaptateurDonnee » 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 'prénom' 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 de création 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 aux 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 des exemples de modèles construits 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 à 0..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.

5.8 Module d'interfaçage avec des classes métier

L'invention propose de pouvoir s'interfacer avec une application existante, du moment que celle-ci est programmée en objet. Pour ce faire, on déclare une définition « donnée » correspondant à chaque classe à interfacer en la déclarant en type complexe et en lui donnant le nom de classe existante.

Chaque classe à relier au framework de l'invention doit encapsuler une propriété "donnée" et implémenter l'interface IConteneurDonnee qui définit les méthodes suivantes : get donnee : retourne l'objet Donnée correspondant à donnée set donnee : affecter à la propriété "donnée" une Donnée

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é "donnée" 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 de données préalablement décrit :

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)