FR 3102594 A1 20210430 FR 1912153 A 20191029 L’invention concerne un ensemble de génération d’application comprenant - un système de configuration qui comprend : . un module de manipulation de données d’utilisation de l’application (4a, 4b), et comprenant des moyens pour définir des listes de données à parcourir ; . un module de définition de l’interface graphique d’application comprenant des éléments graphiques modifiables, et des éléments de parcours de liste, pour parcourir la liste et mettre en œuvre les requêtes de programme correspondantes ; - un système de génération de l’application (G.V.) comprenant des modules d’analyse des données saisies dans le système de configuration et configurés pour mettre en œuvre automatiquement les requêtes de programme pour générer l’application, caractérisé en ce qu’une modification des éléments graphiques modifiables entraine une mise en œuvre des requêtes de programme selon la liste et une modification correspondante de l’application. L’invention porte en outre sur une méthode et un programme associés. Figure de l’abrégé : Fig. 1 Ensemble de génération d’application, méthode et programme associés La présente invention a trait au domaine de la réalisation d’applications, en particulier d’applications web telles que des sites internet ou toute application utilisant un système centralisé contenant notamment des données quel que soit la technologie de stockage des données. L’invention concerne plus particulièrement un système et une méthode mise en œuvre par ordinateur, pour la réalisation d’applications telles que des sites internet. Dans ce domaine, une solution connue est le développement sur-mesure avec ou sans framework. Il s’agit de produire un logiciel spécialement conçu pour apporter une solution adaptée aux attentes pour l’application. Il nécessite donc l’intervention d’un ou de plusieurs développeurs qui, selon les besoins, vont déployer une application unique répondant spécifiquement aux fonctionnalités formulées. De plus, la notion de framework inclus un ensemble cohérent de composants logiciels structurels servant à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d'une architecture logicielle. Ainsi, la réalisation d’applications telles que des sites internet, comprend plusieurs aspects techniques relatifs aux hardwares et modules logiciels, interagissant de manière digitale pour réaliser une intégration de charte graphique spécifique identitaire, reproductible sur des ordinateurs par le biais de l’internet, et inclus également l’insertion d’informations données, relativement faciles à retrouver dans le monde par le biais de l’internet. L’invention tente par ailleurs de mettre en place des solutions contre les risques de sécurité connus. Malheureusement, le développement de ces applications et sites internet sur mesure s’avère long, fastidieux et par conséquent très couteux. Une autre solution connue dans l’art antérieur est d’utiliser un CMS, ou Content Management System, à savoir un logiciel spécialement conçu pour la création et l’édition de sites internet. Les systèmes CMS proposent une interface graphique permettant de créer son site web de manière graphique mais limité aux fonctionnalités proposées. Si l’utilisateur a besoin de plus de fonctionnalités, alors il est obligé de passer en codage traditionnel. Une autre solution est d’utiliser une architecture MVC (Model – View – Controller ; ou Modèle-Vue-Contrôleur). Il s’agit d’une préconisation d’architecture logicielle pour permettre un découpage clair du code. Classiquement, le contrôleur est composé de 2 parties : - le routeur qui est le point d’entrée unique des sollicitations du navigateur au système centralisé tel qu’un serveur. Cela permet de rendre du code commun entre les différentes pages web. - le contrôleur spécifique gérant les spécificités de la page web. De plus, la mise en place d’une architecture type MVC s’accompagne d’une arborescence des différents fichiers composant le code. Un premier objectif est de proposer un système et une méthode permettant de réaliser une application telle qu’un site internet de manière rapide et aisée en comparaison au développement sur mesure. Un deuxième objectif est de proposer un système et une méthode permettant de réaliser un site internet ayant davantage de possibilités de personnalisation en référence aux systèmes de type CMS, en permettant notamment de mettre en place facilement ses propres fonctionnalités. Pour atteindre ces objectifs, l’invention propose un ensemble de génération d’application comprenant : - un système de configuration qui comprend : . un module de manipulation de données d’utilisation de l’application, et comprenant des moyens pour définir des listes de données à parcourir ; . un module de définition de l’interface graphique d’application comprenant des éléments graphiques modifiables, et des éléments de parcours de liste, pour parcourir la liste et mettre en œuvre les requêtes de programme correspondantes ; . un module de gestion d’événements, configuré pour définir pour chaque type d’événements liés aux éléments graphiques possibles le comportement attendu ; . un module d’éléments de cardinalité configuré pour encadrer le comportement des éléments de parcours de liste ; - un système de génération de l’application comprenant des modules d’analyse des données saisies dans le système de configuration et configurés pour mettre en œuvre automatiquement les requêtes de programme pour générer l’application. Selon un premier aspect, l’ensemble est configuré de sorte qu’une modification des éléments graphiques modifiables entraine une mise en œuvre des requêtes de programme selon la liste et une modification correspondante de l’application. Avantageusement, l’invention facilite la déclaration de ces fonctionnalités en permettant notamment une manipulation aisée des données et une aide à la gestion de problématique technique (sécurité, conflit d’accès). De préférence, l’ensemble comprend un système d’utilisation de l’application, permettant à l’utilisateur de l’application d’avoir accès à l’interface graphique, avec une gestion des données souhaitées (Sur le serveur, en mémoire du poste sur lequel fonctionne l’application, ou bien à l’interface graphique), et avec le comportement dynamique attendu. Selon d’autres aspects pris isolément ou combinés selon toutes les combinaisons techniquement réalisables : - le module de définition de l’interface graphique comprend des éléments graphiques standards tels que des cases à cocher, champ texte, vidéo, image, forme graphique, champ de date/heure, champ numérique, et/ou des éléments pré réalisés proposés tels que des menus, évaluation par des étoiles, et/ou des éléments programmés par l’utilisateur ; et/ou - l’ensemble est configuré de sorte qu’une fois l’élément de cardinalité défini dans le système de configuration, alors le système de génération pourra créer une table en base de données qui correspondra à l’élément de cardinalité, et les relations de cette table avec les autres tables de la base de données, étant également déterminé depuis ce qui a été saisi dans le système de configuration ; et/ou - l’ensemble est configuré de sorte qu’un rajout d’un champ dans un élément de cardinalité à l’aide du système de configuration ; pourra entrainer un rajout de colonne dans la table en base de données par le système de génération ; et/ou - l’ensemble comprend un module de détection de non-conformité configuré pour enregistrer l’interface et les évènements ayant eu lieu et pour vérifier que cela correspond à l’interface modifiée ; et/ou - le module de détection de non-conformité est configuré pour comparer l’interface obtenue avec une simulation de l’interface initiale à laquelle est ajoutée les modifications de l’utilisateur. L’invention concerne en outre une méthode de création d’une application au moyen d’un ensemble selon l’une des revendications précédentes comprenant des étapes suivantes : - définition de la charte graphique générale de l’application, comprenant des éléments graphiques modifiables, - création, nommage de la page d’application telle qu’une page web, de ses entrées, caractérisée par les étapes - définition d’une liste à parcourir et d’un l’élément de « parcours de liste », et en ce qu’une modification des éléments graphiques modifiables entraine une mise en œuvre de requêtes de programme selon la liste et une modification correspondante de l’application. Un autre objet de l’invention concerne un produit programme d’ordinateur comprenant des portions de code de programme enregistré sur un support utilisable dans une unité de commande, pour mettre en œuvre les modules d’un ensemble selon l’invention ou les étapes d’une méthode selon l’invention, lorsqu’il est exécuté par l’unité de commande. L’invention sera davantage détaillée par la description de modes de réalisation non-limitatifs, et sur la base des figures annexées illustrant des variantes de l’invention, dans lesquelles : est un schéma global de fonctionnement d’un site internet ; est un schéma des différentes étapes de définition d’une application en utilisant l’invention ; est un schéma d’une architecture MVC (modèle-vue-contrôleur) ; est une illustration d’un lien de dépendance entre des tables ; est un schéma des actions du contrôleur de la page l’application ; est un schéma de l’automatisation de la sécurité. L’invention concerne la réalisation d’applications telles que des sites internet notamment, en particulier en utilisant des moyens informatiques. L’invention concerne plus particulièrement un système 1 et une méthode mise en œuvre par ordinateur, pour la réalisation d’applications. La réalisation d’applications, telles que les sites internet par exemple, comprend plusieurs aspects techniques relatifs aux hardwares et modules logiciels, interagissant de manière digitale pour réaliser une intégration de charte graphique spécifique identitaire, reproductible sur des ordinateurs par le biais de l’internet, et incluant également l’insertion d’informations données, relativement faciles à retrouver dans le monde par le biais de l’internet. L’invention ne se limite pas aux moyens présentés. - le terme « Javascript » peut être interverti avec un autre langage ou code client. - les « Base de données » peuvent être plus généralement des « systèmes de gestion des données » - une « Page web » peut aussi être plus généralement une « IHM ». Il est possible de créer une page web à partir une interface web, cela concerne surtout la définition des éléments d’IHM (Ex. en technologie web : HTML), et le style (Ex. en technologie web : CSS). Or un site web est constitué de : - IHM : Code client : par exemple pages web : HTML + CSS + Javascript (Code client dynamisant la page), - Logiciel serveur pour gérer les transitions entre les pages web et gérer les chargements/enregistrements des données, - Requêtes d’accès aux données (généralement en SQL). (On pourrait envisager d’autres systèmes de stockage de données que des bases de données, comme des fichiers par exemple). L'invention détaille comment gérer l'ensemble de ces activités depuis une interface web pour : - Générer du code client et du logiciel serveur - Générer la gestion du chargement/enregistrement des données en base de données, ou tout autre système de gestion des données. Pour cela, un motif d'architecture innovant et une étude théorique exigeante ont été mis en œuvre. A cet effet, l’invention porte sur un ensemble comprenant un système de configuration et un système de génération. Le système de configuration permet à l’utilisateur de l’outil de configuration d’application d’indiquer des informations qui seront utilisées par le système de génération pour définir la structure des données. Le système de configuration permettra ensuite dans un deuxième temps de définir les données. Outre le développement facilité, pouvoir définir la structure des données (plutôt que les données elles-mêmes) puis paramétrer les données permet de : - de préférence, gérer aisément une gestion multilingues de l’application ; - définir des templates d’application ; transférables (par BDD ou par fichier) puis paramétrables par un client ; - connecter des données d’applications différentes. Un schéma global de fonctionnement d’un site internet est illustré en figure 1. De manière simplifiée, le système centralisé 2 tel qu’un serveur web a pour mission de constituer la page web, qui sera ensuite envoyée au navigateur web 3, et donc mise à disposition de l’utilisateur 4. Généralement, c’est l’utilisateur 4 (Ex. : Adresse saisie dans le navigateur web) ou le navigateur web (Ex. : Clic sur un lien vers une autre page web dans une page web) qui demande au système centralisé 2 de fournir la page web, mais, il est possible que le système centralisé 2 envoie des données au navigateur dans le cas de mise en œuvre de web socket par exemple. Le système centralisé 2 peut envoyer l’ensemble de la page web, mais peut aussi envoyer des données qui seront ensuite utilisées par le code client de la page web pour ne mettre à jour qu’une partie de la page web. Le mécanisme de chargement et d’enregistrement de page web (contenant notamment des données) est de préférence protégé, afin d’éviter qu’une personne malveillante puisse accéder à des données auxquelles il ne devrait pas avoir accès ou enregistrer des données qu’il ne devrait pas pouvoir enregistrer ou réaliser toute autre type d’action malveillante (Par exemple, un hacker malintentionné pourrait écraser toutes les données de la base de données). En effet, il est tout à fait possible que la personne malveillante biaise la page web envoyée au système centralisé 2, ainsi un site web ne pourra être réellement sécurisé qu’en cas de protection mise en place au niveau du système centralisé 2. Concernant le fonctionnement logiciel du système centralisé 2, tel qu’un serveur web, le cas général est détaillé selon une architecture trois tiers : Présentation (Navigateur) / Traitement / Accès aux données : Le navigateur web 3 envoie au système centralisé 2 des données qui sont de deux types : - des données saisies par l’utilisateur, - des éléments de contexte permettant au système centralisé 2 de déterminer ce qu’il doit faire des données envoyées. Le système de génération permet de générer l’interface entre l’application et un système centralisé. La structuration des données au niveau du système de configuration permet également de donner assez d’informations pour pouvoir générer ces éléments de contexte. Le système centralisé 2 détermine le traitement à effectuer concernant les données reçues du navigateur 3. Notamment, des contrôles ont lieu pour assurer l’intégrité des données enregistrées. Le système centralisé 2 applique le traitement déterminé ; notamment cela peut être l’enregistrement des données envoyées au serveur. Le système centralisé 2 détermine le traitement à effectuer pour fournir les informations au navigateur 3 en retour. Le système centralisé 2 applique le traitement déterminé ci-dessus, avec la récupération possible des données. Les informations sont envoyées au navigateur 3. Elles sont de 2 types : - les données utilisées pour la page web : HTML, CSS, Code client, et Données - les éléments de contexte d’utilisation permettant d’indiquer au navigateur web 3 comment utiliser les données dans la page web. L’utilisation des éléments de contexte est particulièrement vraie, quand il s’agit de ne mettre à jour qu’une partie de la page web. Dans le cas d’un passage d’une page à une autre, les éléments de contexte correspondent au nom de la page source, et la page destinataire ainsi que ses données d’entrée. la figure 2 illustre une architecture MVC (modèle-vue-contrôleur). Un standard de développement de site web consiste à appliquer une architecture dite MVC : - V : Une vue contient la présentation de l'interface utilisateur, notamment l’aspect graphique. - C : Un contrôleur contient la logique concernant les actions effectuées par l'utilisateur. Pour une meilleure gestion, le contrôleur est composé de deux parties : . Le routeur qui est le point d’entrée unique des sollicitations du navigateur au système centralisé 2. Cela permet de rendre du code commun entre les différentes pages web. . Le contrôleur spécifique gérant les spécificités de la page web. - M : Un modèle contient les données et les traitements à effectuer sur les modèles (Une programmation objet se prête donc bien à cet exercice). Les modèles représentent les concepts utilisés dans l’application (Utilisateurs, mail, …). Une fois l’application générée et utilisée, le flux de données est toujours le même. De façon simplifiée : la page est chargée avec les données issues de la base de données, et les données saisies par l’utilisateur de l’application sont enregistrées en base de données. La particularité de l’invention est de rajouter lors de la description de la vue : - les éléments de parcours de liste, - les éléments des cardinalité, - les mappings à l’enregistrement et au chargement. Ceci permet de définir des tables en base de données, leurs relations (ce qui est un élément fondamental des bases de données relationnelles), ainsi que les requêtes d’enregistrement et de chargement des données. La figure 3 illustre différentes étapes de définition d’une application telle qu’un site web en utilisant l’invention. Les étapes avec une bordure en gras sont spécifiques à l’invention. Les CMS sont des sites proposant des fonctionnalités prêtes avec la possibilité de les personnaliser dans une certaine mesure. L’invention ne rentre de préférence pas dans cette démarche : l’objectif est de fournir un outil pour simplifier et accélérer le développement d’un site web sur-mesure. Le principe général de l’invention consiste à ajouter des compléments d’informations depuis le système de configuration de la vue pour permettre ensuite de générer l’ensemble de l’application, par exemple un site web, coté serveur et coté client. Cette simplification utilisera par contre des méthodes facilitatrices mises en œuvre par exemple par les CMS : - l’utilisation d’interfaces graphiques et notamment WYSIWYG (« whatyouseeiswhatyouget ») ; - l’automatisation de la réalisation d’un certain nombre de traitements techniques coté serveur et navigateur. Le graphique de la figure 3 explique les différentes étapes de définition d’une application en utilisant l’invention. Le HTML/CSS, traitement javascript (=Code client), traitement serveur et modèle de base de données sont des éléments classiques mentionnés ci-dessous. « javascript » est un exemple de langage de programmation. D’autres langages pourraient être utilisés dans le cadre de l’invention tels que l’angular. Une attention est à porter à ces colonnes de la figure 3 : - Modèle VUE : Il permet au créateur de la page web d’indiquer quelle est la structure des données de la page web. C’est cette connaissance qui sera exploitée pour définir le modèle de données du système centralisé, et le modèle logiciel des données locales de l’application générée. - Modèle logiciel (code client/javascript): Utilisant la mémoire locale de la machine de l’utilisateur, il permet à la page web de manipuler les données, comme par exemple pour charger les données issues de la base de données. Les étapes de création d’une application en utilisant l’invention sont : - E1/ Définition de la charte graphique générale de l’application. C’est une fonction classique des CMS. - E2/ Création, nommage de la page d’application telle qu’une page web, et de ses entrées. - E3/ Indication de l’autorisation de se connecter en direct à la page (C’est-à-dire en saisissant l’URL de la page web). - E4/ Définition de la liste à parcourir et de l’élément de « parcours de liste ». C’est un concept propre à cette invention. - E5/ Les comportements des éléments de parcours de liste doivent également être définis, notamment en cas d’ouverture par défaut, et en termes de traitement de fermeture par défaut. - E6/ L’élément de cardinalité est un élément permettant de traiter différents types de fonctionnement lors du parcours de la liste. C’est un concept propre à cette invention. - E7/ Grâce à l’introduction des deux items précédents, il est possible de générer automatiquement les tables en base de données, ainsi que les relations les liant, et de préférence effectuer des déclarations de clés fonctionnelles. Cela diffère des CMS qui associent simplement une table à un formulaire (=Ecriture). Il s’agit là de pouvoir modéliser et utiliser tout type de structure de données par niveau de cardinalité (=Modèle données système), pour une utilisation autant en lecture qu’en écriture de données. Ce format de données est également reporté pour stocker et gérer les données dans le navigateur web (=Modèle logiciel). - E8/ Il s’agit de déclaration de blocs E8a et de champs E8, c'est-à-dire d’éléments IHM tels que HTML et CSS, notamment sous forme d’interface WYSIWYG. - E9/ Ce bloc permet de lier les données de la vue aux données de la base de données. Il peut en outre y avoir un mapping avec des objets associables. L’innovation vient de E4/ E6/ et E9/ notamment qui permettent de définir n’importe quel type de structure de données ; et donc permet de créer tout type d’application. - E10/ L’item précédent permet par un mécanisme de génération automatique de compléter les tables avec les champs liés (notamment par ajout, modification, ou suppression de colonnes), mais aussi de créer les requêtes de récupération de données, de mise à jour, ou de suppression d’élément en base de données. - E11/ Déclaration des comportements en cas de non-conformité, de gestion de conflit d’accès, et de tentative de fraude coté navigateur et serveur, ainsi que les traitements coté navigateur et serveur. L’invention propose une méthode de détection générique de ce type de problème. E12/ La dernière partie consiste à définir des traitements associés à des événements sur la page web (=Actions sur la page web par l’utilisateur principalement ou réception de signaux externes par websocket par exemple). Alternativement ou en combinaison, la réalisation de l’application peut être faite sur la base d’un ou plusieurs modèles (template) prédéveloppés ou réalisés suivant les étapes de la méthode de l’invention. On pourra parler de données de modèles. Les modifications sont alors faites à partir de la vue du modèle en cause. La création de l’application est mise en œuvre par un ensemble de systèmes particuliers (ou kit). L’invention est mise en œuvre dans un système centralisé 2 tel qu’un serveur web connecté à des unités de commandes telles que des ordinateurs d’utilisateurs de l’application. L’ensemble comprend un système de configuration d’application, qui comprend : - un module de manipulation des données. Ces données pourront être situées lors de l’utilisation de l’application sur un système centralisé tel qu’un serveur, au niveau du poste de l’utilisateur de l’application, ou bien directement saisies dans l’interface graphique de l’utilisateur. Ce module peut permettre, entre autre, de définir des données à parcourir, - un module de définition de l’interface graphique de site modifiable, permettant de définir plusieurs types d’éléments : o des éléments graphiques standards (Ex. Cases à cocher, champ texte, vidéo, image, …) ; o des éléments pré réalisés proposés par le site internet (Ex. : Menu, évaluation par des étoiles, ..) ; o des éléments de parcours de liste, pour parcourir la liste et mettre en œuvre les requêtes de programme correspondantes ; o des éléments de cardinalité, qui seront appelés par les éléments de parcours de liste à bon escient en fonction de leurs caractéristiques ; - Un module de gestion d’événements, permettant de définir à chaque type d’événements possibles (Ex. Clic sur un bouton) le comportement attendu. Ainsi, l’invention facilite la déclaration de ces fonctionnalités en permettant notamment une manipulation aisée des données, une aide à la gestion de problématiques techniques (sécurité, conflit d’accès). L’ensemble comprend en outre un système de génération de l’application : L’analyse des données saisies dans le système de configuration d’application permet de mettre en œuvre automatiquement plusieurs éléments, notamment : - la structure et les requêtes d’accès à la base de données, - l’interface entre l’application et le serveur, - le contrôleur. L’ensemble comprend en outre un système d’utilisation de l’application : Le système permet ensuite d’utiliser le système pour que l’utilisateur de l’application ait accès à l’interface graphique, avec une gestion des données souhaitée (sur le système centralisé 2, au niveau du poste sur lequel fonctionne l’application, ou bien à l’interface graphique), et avec le comportement dynamique attendu. L’invention est basée sur des modules informatiques de réalisation de site web, permettant d’optimiser ladite réalisation en gain de temps par rapport au développement sur mesure, et en capacité de personnalisation par rapport aux systèmes CMS classiques. Parmi ces modules, l’invention comprend un module de configuration de données de vues modifiables à afficher. Ce module permet de mettre en œuvre une définition de la charte graphique générale de l’application. Il s’agit en particulier du clavier et de la souris 4a, et du code serveur et données de l’application 4b. Ce module peut comprendre en outre des moyens pour la création, et le nommage de la page web, de ses entrées. De plus, ce module peut comprendre en outre des moyens d’indication de l’autorisation de se connecter en direct à la page web (C’est-à-dire en saisissant l’URL de la page web). L’invention comprend un module de vue pour afficher une interface graphique modifiable. L’interface sera davantage détaillée plus bas. L’invention comprend en outre un module de liste à parcourir, pour définir des données à parcourir, et les associer à des requêtes de programme correspondantes. Ces modules font partie du système de configuration. L’invention comprend en outre un système de gestion des données tel qu’une base de données relationnelle, pour associer des données de liste de vue à des données correspondantes de liste de serveur, L’invention comprend en outre un module de parcours de liste, pour parcourir la liste et mettre en œuvre les requêtes de programme correspondantes. Le module de parcours de liste et de la liste à parcourir et le module d’élément de cardinalité ont été conçus pour mettre en place un système permettant d’identifier de manière unique les données d’une page web, cela quel que soit la fonctionnalité de l’application. La mise en place de ce système permettra par la suite de pouvoir gérer la lecture/écriture des données de la vue à la base de données. Les constitutions classiques des requêtes de bases de données soulèvent certaines incertitudes et des ambigüités. En particulier, dans le cas d’un site de réservation d’hôtel avec une requête SQL permettant de récupérer les données afin d’associer une note à sa réservation serait du type : « SELECT hotel.adresse , reservation.datereservation , reservation.note FROM reservation JOIN hotel ON hotel.id = reservation.hotel _id WHERE reservation.utilisateur _id = ». L’analyse de la requête SQL ne permet pas de déterminer à quelle(s) donnée(s) fonctionnelles se rapporte(nt) la note sur la réservation : l’hôtel, la réservation, ou les deux (Dans notre cas, la note sur la réservation se rapporte bien entendu à la réservation). L’invention propose de lever cette ambiguïté, de telle sorte que l’utilisateur n’ait pas à déclarer, dans la requête SQL, la manière de récupérer les données informatives, mais juste de définir les données à parcourir : C’est la liste à parcourir. Dans l’exemple précédent, cela donnerait la requête de base de données suivante : « SELECT id FROM reservation WHERE utilisateur_id = technique d’utilisateur> ». L’implémentation de l’invention propose une interface graphique pour définir les requêtes SQL ; et un système complémentaire permettant de définir la manière de récupération des éléments informatifs complémentaires nécessitant de solliciter d’autres tables (ce que permettait la jointure avec le JOIN supprimé dans l’exemple). Ce système sera décrit plus bas. En complément, un moyen est mis en place pour pouvoir parcourir la liste définie, mais aussi pour pouvoir couvrir les besoins réels de réalisation de jointure : C’est l’élément de parcours de liste. Par exemple, dans le cas où les champs d’une page web sont associés aux éléments à la requête suivante : « SELECT liste1.id , liste2.id FROM nom AS liste1 JOIN date AS liste2 ON liste 2 .valeur = liste 1 .datecreation WHERE liste1.texte LIKE ’%a%’ AND liste2.valeur >’2019-01-02’ » ; Alors, cela sera défini dans l’invention avec ce type de forme: « Elément de parcours de liste nommé liste 1 » tel que « liste 1 : SELECT id FROM nom WHERE nom. texte LIKE ’ %a%’ » « Elément de parcours de liste nommé liste 2 » tel que « liste 2 : SELECT id FROM date WHERE date.valeur >’2019-01-02’ ANDdate.valeur =liste1.datecreation » Il est donc possible ici de faire appel aux données de liste 1 ou de liste 2 tout en ayant une dépendance entre la liste 1 et la liste 2. L’utilisateur définit la récupération des données sous forme de 2 requêtes plutôt qu’une seule. Par contre, l’implémentation des 2 requêtes pourra être faite en une seule requête (Ce qui est beaucoup plus performant en temps de calcul). Comme mentionné précédemment, il est nécessaire d’arriver à déterminer quels sont les identifiants d’une liste à parcourir, afin de pouvoir ensuite identifier les éléments de cardinalité qui seront associés à l'élément de liste à parcourir. Ainsi, il est nécessaire de connaitre les différentes formes possibles de constitution des listes à parcourir pour déterminer l’identifiant de la liste. Généralement, l’identifiant d’une liste à parcourir est un identifiant d’une table ; mais il existe quelques singularités par exemple : - L’utilisation de UNION nécessite de distinguer la requête - L’utilisation de GROUP BY fait que les identifiants sont les éléments utilisés dans le « GROUP BY ». Exception faite si la requête est de type « SELECT MAX/MIN(identifiant) FROM table WHERE … GROUP BY … », où dans ce cas précis l’identifiant est de type identifiant de la table - Il est possible de constituer une liste de manière mathématique ou algorithmique : par exemple tous les éléments allant de 1 jusqu’à 10. En synthèse, la détermination des identifiants fonctionnels d’un élément de cardinalité s’obtient grâce à la connaissance des données suivantes : - La définition et l’analyse (détaillées ci-dessous) de l’arborescence des éléments à parcourir et des éléments de cardinalité ; - Les identifiants fonctionnels des listes d’éléments à parcourir ; - L’obligation ou pas d’associer l’élément de cardinalité à son rédacteur ; - L’obligation ou pas d’associer l’élément de cardinalité à son instant d’enregistrement ; - La cardinalité de l’élément de cardinalité (détaillé ci-dessous). Cela permet donc de : - Identifier de manière unique chaque élément de cardinalité appelé dans la page web ; donc tous les éléments contenus dans les éléments de cardinalité (C’est-à-dire tous les éléments de la page); - Définir les tables de bases de données ainsi que les liens de type « clefs fonctionnelles » ; - Identifier en base de données l’élément à lire, mettre à jour, ou à supprimer. Le système comprend en outre un module d’élément de cardinalité pour préciser le comportement de champs contenus dans le module de parcours de liste. Lors du parcours des différents éléments de la liste, il peut être intéressant de préciser le comportement des champs contenus dans l’élément de parcours de liste. Dans une variante, il y a une alternance hiérarchique entre les éléments de parcours de liste et les éléments de cardinalité. Ainsi, les éléments de parcours de liste peuvent contenir des éléments de cardinalité, et les éléments de cardinalité peuvent contenir des éléments de parcours de liste. Ainsi, on peut distinguer plusieurs comportements possibles. Ces comportements seront définis à l’aide de nouveaux blocs : ce sont les éléments de cardinalité. Les différents comportements des éléments de cardinalité sont : - Le bloc n’est appelé qu’une seule fois ET que s’il existe au moins un élément dans la liste à parcourir ; - Le bloc n’est appelé qu’une seule fois ET que s’il n’existe pas d’élément dans la liste à parcourir ; - Le bloc n’est appelé qu’une seule fois (quel que soit le nombre d’éléments dans la liste à parcourir) ; - Le bloc est appelé 1 fois par élément de la liste à parcourir ; - Le bloc est appelé 1 fois par élément de la liste à parcourir ou 1 fois s’il n’existe pas d’éléments dans la liste à parcourir. Ces mécanismes permettent de donner de la latitude pour gérer les différentes fonctionnalités que l’on pourrait avoir besoin. L’invention vise à dissocier les requêtes d’accès aux données entre celles qui définissent les données à parcourir et le parcours de la structure de la table de données pour pouvoir récupérer des informations. Prenons comme exemple une application contenant - Un élément de parcours de liste nommé listeA associé à une liste construite mathématiquement allant de 1 jusqu’à 10 par pas de 1 ; contenant un élément de cardinalité nommé cardinaliteA de type« appel à chaque élément de la liste à parcourir » ; contenant lui-même un bloc IHM nommé texteA de type « texte à saisir » ; - Un élément de parcours de liste nommé listeD ; contenant un élément de cardinalité nommé cardinaliteD de type « appel à chaque élément de la liste à parcourir » ; contenant lui-même un bloc IHM nommé texteD de type « texte à saisir », - Un élément de parcours de liste nommé listeE ; contenant un élément de cardinalité nommé cardinaliteE de type « appel à chaque élément de la liste à parcourir » ; contenant lui-même un bloc IHM nommé texteE de type « texte à saisir ». Puis un élément de parcours de liste nommé listeB associé à une liste à parcourir constituée de données de l’élément de cardinalité cardinaliteA. listeB contient un élément de cardinalité nommé cardinalitéB de type « appel à chaque élément de la liste à parcourir ». L’élément de cardinalité cardinaliteB contient : -un bloc IHM nommé texteB de type texte à saisir. - un élément de parcours de liste nommé listeC associé à une liste à parcourir de type SQL utilisant un « GROUP BY » groupé avec un champ texteF et avec un champ nommé maxdate issu d’une fonction d’agrégat dans la requête SQL. listeC contient un élément de cardinalité nommé cardinalitéC de type « appel à chaque élément de la liste à parcourir ». L’élément de cardinalité cardinaliteC contient à la fois - un bloc IHM nommé texteC de type texte à saisir ; - un bloc IHM nommé lienD de type lien vers un élément de cardinalité faisant référence un élément à l’élément de cardinalité D ; - un bloc IHM nommé listederoulanteE de type liste déroulante dépendant de E du type. Le tableau ci-dessous détaille les données disponibles depuis l’élément de cardinalité C: n° Table accessible Elément disponible Attributs accessibles 1 B texteB "value" (Sauf pour graduation et icur) Si présent Date création, date de dernière modification, et utilisateur ayant créé l'information Autres caractéristiques HTML du champ (disabled hidden, …) si existants et présent dans la page WEB 2 B.parcours=>A texteA 3 B.parcours=>A.parcours graduation 4 C texteC 5 C.parcours texteF 6 C.parcours maxdate 7 C.lienD=>D texteD 8 C listederoulanteE 9 C.listederoulanteE=>E texteE 10 C icur 11 B icur Les raisons qui expliquent l’accès aux données sont : - n°4 et 8 : Les données sont présentes dans l’élément de cardinalité ; - n°7 : Les liens vers d’autres tables sont définis dans l’élément de cardinalité ; - n°9 : La liste déroulante fait référence à cette table ; - n°5 et 6 : Ceux sont les données associées à l’élément parcouru ; - n°1 : Il est possible d’obtenir les données présentes dans les éléments de cardinalité amont ; - n°2 : Les données associées aux éléments parcourus amont sont accessibles ; - n°3 : Capacité de cheminement dans la structure (Enchainement de « .parcours »), et la récupération de données de type liste constituée avec le nom « graduation » dédié ; - n°10 et 11 : Les numéros d’incrément des listes parcourues au sein d’un bloc de cardinalité. Ainsi, le lien aux données est très adhérent à la vue, ce qui montre une nouvelle fois que le schéma de modèle des données (dont la base de données) est donc complètement défini par la forme de la vue dans cette invention, et permet de naviguer aisément au sein de ce modèle de données. Il est possible si besoin d’insérer des requêtes de lecture de données si besoin de récupérer d’autres informations. Le graphique de la figure 4 montre qu’il est possible d’associer de manière unique : - un élément de la table A à un élément de la table B en suivant le lien de B vers A (Parcours, lien, liste déroulante), cf flèche du haut sur la figure 4, possible pour toutes les données de B pointant vers la table A ; - ET Un élément de la table C à un élément de la table B si l’unicité est assurée : un élément C ne peut être associé qu’à un seul élément B cf flèche du bas sur la figure 4, où la table C n’est associée qu’à l’identifiant technique de B (= 1 clef unique et pas de sauvegarde par utilisateur ou par enregistrement). Un mapping des données en base de données est effectué. En reprenant le champ nommé texteC dans l’exemple précédent, le mapping par défaut aurait la forme indiquée ci-dessous ; mais il serait possible de préciser le fonctionnement autrement comme cela est montré dans le deuxième bloc ci-dessous : Mapping par défaut « Enregistrement et chargement : C.texteC Valeur par défaut si chargement indéfini : " " » « Enregistrement : C.texteC Chargement : B .texteB Valeur par défaut si chargement indéfini : "Bonjour" » Les éléments de parcours de liste, de cardinalité, et IHM (par exemple HTML) peuvent être utilisés pour réaliser des tableaux. La navigation facilitée des données permet donc de pouvoir s’approcher d’un fonctionnement proposé par les tableurs bureautiques. Au moins 5 fonctionnalités sont mises à disposition pour pouvoir reconstituer un fonctionnement s’approchant de celui proposé par des tableurs : - Connaître les valeurs d’incrément courant au sein d’élément ; - Parcourir les données au sein de la structure des données ; - Définir des variables pouvant être des tableaux de valeurs ; - Mettre à disposition des fonctions de manipulation de liste pour pouvoir manipuler la vue (Ajout d’un élément dans une liste en précisant l’index, dimension d’une liste, suppression d’un élément dans une liste) ; - Effectuer des calculs permanents, et également sur des tableaux de valeurs. En appelant « icur » le numéro d’incrément dans la liste parcourue de l’élément de cardinalité, dans l’exemple précédent : la référence « C.texteC » est en réalité un abrégé de « C[ B .icur , C.icur ]. texteC ». Avec ce type de rédaction, il devient possible de faire référence à l’élément précédent de cette manière : « C[B.icur - 1 , C.icur ].texteC » Mais, il serait aussi possible de faire appel à tous les éléments entourant la valeur (Si vue tableau) : C[ De (B.icur-1) à (B.icur+1) , De (C.icur-1) à (C.icur+1) ].texteC De manière plus générale, il est possible que la récupération des éléments du modèle logiciel puisse être effectuée par des listes pour ne pas limiter l’utilisation des données : Tableau = Elément de parcours de liste [ , ] Concernant la manipulation des éléments de la vue, étant donné le principe des éléments de parcours de bloc, l’ajout d’un élément dans une liste a pour conséquence de rajouter des éléments dans la vue. Dans un exemple du type : - date ="01/01/2019 ; 02/01/2019 ; 03/01/2019 ; 04/01/2019 " - nom =" Alfred ; Bob ; Gérard ; Roger " Le tableau correspondant est le suivant : Date 01/01/19 02/01/19 03/01/19 04/01/19 Nom Alfred ________ ________ ________ ________ Bob ________ ________ ________ ________ Gérard ________ ________ ________ ________ Roger ________ ________ ________ ________ Un rajout de valeur dans : - la liste "nom" a pour conséquence d’ajouter une ligne au tableau ; - la liste "date" a pour conséquence d’ajouter une colonne au tableau. Ainsi, si : -date ="01/01/2019 ; 02/01/2019 ; 03/01/2019 ; 04/01/2019 ; 05/01/2019 " -nom =" Alfred ; Bob ; Gérard ; Roger ; Néo " Alors le tableau deviendra : Date 01/01/19 02/01/19 03/01/19 04/01/19 04/01/19 Nom Alfred ________ ________ ________ ________ _______ Bob ________ ________ ________ ________ ________ Gérard ________ ________ ________ ________ ________ Roger ________ ________ ________ ________ ________ Néo ________ ________ ________ ________ ________ Par ailleurs, comme pour certains Framework javascript (AngularJS ou autres), il est possible de définir une formule à un champ et une réactualisation automatique en cas de changement sur une donnée d’entrée. Il est important que les calculs soient possibles sur des données de type tableau de valeurs. On pourra parler de calcul permanent. Dans le cadre de la création de la page web, le système comprend une interface graphique aboutie. Cette interface permet : - (de manière classique pour les CMS) de définir du HTML, du CSS, et la charte graphique de l’application ; - (de manière classique pour les frameworks des codes client du navigateur web) de définir les champs de calcul basé sur les données de la page web et remis à jour en temps réel. Mais l’invention propose aussi de définir depuis une interface graphique : - De nouveaux éléments : Notamment les « Eléments de parcours » et les « Eléments de cardinalité », détaillés plus haut, - Des requêtes de bases de données, - Des fonctions de code client (par exemple javascript), - D’associer un traitement à un événement de la page web (Arrivée d’un flux ou action utilisateur). A noter, que l’initialisation du bloc est un événement en tant que tel. - De préférence, afin de pouvoir faciliter l’utilisation de l’outil, l’utilisation de bouton pictogramme ou de clavier numérique est mise en place. Les avantages d’une utilisation graphique sont multiples. Cela permet de : - Structurer naturellement le code, ce qui donne de la facilité pour lier et retrouver ce qui est associé à une fonctionnalité donnée d’IHM (par exemple HTML/CSS/Javascript/SQL/Code serveur) ; - Contrôler les saisies de l’utilisateur. Ainsi, l’outil est plus intuitif, donc plus facilement pris en main et avec moins de possibilité de coquille dans le code ; - Rendre l’information plus lisible et de prendre à la charge de l’outil la rédaction de syntaxe technique, de sorte que le temps de formation est diminué. L’outil peut permettre à l’utilisateur d’écrire directement du code pour que les possibilités offertes par l’outil ne limitent pas les fonctionnalités utilisables. La figure 5 détaille les actions possibles du contrôleur de la page web. En fonction des évènements, signaux, timers, données de la vue, le contrôleur C envoie au système centralisé une demande de chargement d’une page vers le système centralisé 2 (S1) ; Les données sauvegardées sont ensuite chargées en local côté client (S2) ; Le navigateur local envoie un appel au générateur de vue G.V.(S3) qui réalise un changement des caractéristiques de la vue V (S4) ; Le changement correspondant des données est enregistré en local (S5), puis transmis au système centralisé 2 pour y être enregistré (S6) ; Il s’en suit un appel de réalisation d’un calcul côté serveur (S7). Le contrôleur a 2 fonctions principales. Sa première fonction consiste à mettre en place le socle technique, et ainsi alléger la quantité de code à produire par le développeur utilisant l’outil : - Mettre en place une structure de données issue de la récupération des données en base de données notamment ; - Appeler le générateur de vue pour utiliser ces données et afficher la vue ; - Faire appel à des fonctions techniques existantes (Détection de non-conformité par exemple). Sa deuxième fonction principale consiste à réunir l’ensemble des traitements fonctionnels définis par le développeur web : - Traitement coté navigateur en cas d’obligation de saisie de données ; - Traitement coté navigateur en cas de non-conformité de saisie de données ; - Traitement en cas d’événements, notamment il est possible de : o Modifier les données en appelant de nouveaux chargements depuis la base de données ou en modifiant les données déjà chargées en interne ; o Réactualiser des éléments de la vue (En particulier des éléments de cardinalité) ; o Fournir à la base de données lors d’un enregistrement les données pour se synchroniser avec les données locales. Notamment, cela implique d’indiquer quelles données constituent les données en local de la page web ; o La demande de chargement de page se gère de manière spéciale. En effet, il est possible de quitter la page en cours de saisie de données. Ainsi, l’outil propose un traitement dédié de départ/chargement de page, afin d’éviter de la redite de code. La figure 6 illustre l’automatisation de la sécurité. Une tentative de fraude depuis l’application consiste pour un utilisateur à faire quelque chose qu’il ne pourrait pas pouvoir faire en utilisant normalement la page web (=Utilisation du clavier souris classiquement au sein de la page web). Ainsi, l’idée générale consiste à enregistrer les événements provoqués par les manipulations de clavier/souris sur la vue et de s’assurer que le formulaire reçu correspond bien à ces opérations. On pourra parler de module de détection de non-conformité. Différentes manières de faire sont possibles, la figure 6 en précise une. Les étapes sont : - C1/ Envoi de la page web au navigateur. Le système centralisé 2 enregistre une sauvegarde de la page web. Une base de données est associée. - C2/ Des événements se produisent sur la page et sont enregistrées au niveau du navigateur. Dans la vue il y a notamment la visibilité, cessibilité, restriction de valeur. L’historique des évènements est enregistré. - C3/ Lors de l’envoi de la page web au système centralisé, le système centralisé vérifie qu’il n’y a pas de problème. Notamment : o Tentative de forçage de données o Conflit d’accès (En vérifiant s’il y a eu un enregistrement de données durant la saisie utilisateur) L’invention proposée permet de réaliser des applications telles que des sites web. Notamment, les données utilisateurs sont renseignées à partir de listes. Ainsi, il est possible de générer des applications qui pourraient être copiées ou clonées, et personnaliser à l’aide du renseignement des données utilisateurs. En d’autres termes, l’outil proposé permet de générer des applications telles que des sites web applicatifs, mais aussi des sites web de type SAAS. L’invention proposera un système d’optimisation des clefs fonctionnelles dans le cas où il y aurait un enchaînement d’éléments de parcours de liste. Par exemple : Cas 1: On veut constituer une vue permettant de saisir le total de vente de produit par jour, par vendeur. Dans ce cas, il est indispensable de faire référence au jour et au vendeur pour pouvoir enregistrer la donnée (=Saisie du total de vente). Cas 2 : On veut constituer une vue avec un bloc par magasin, qui contiendra la liste des vendeurs du magasin. Il est possible d’associer un commentaire libre pour chaque vendeur. Ici, il ne serait pas pertinent de faire référence au magasin et au vendeur pour enregistrer la donnée (=Saisie du commentaire), car la connaissance du vendeur permet de retrouver l'information du magasin. Ce serait un problème de le faire, car cela revient à créer de l’information en double, ce qui complexifie ensuite la gestion des données, voire crée des incohérences (si les 2 informations se contredisent). Ainsi, une analyse complémentaire est faite, afin de déterminer les clefs indispensables, et identifier les clefs potentiellement redondantes. Voici un exemple de procédé : 1/ Détermination "naive" de toutes les clefs Cas 1 : clef de la liste1 : Identifiant du vendeur / clef de la liste2 : Valeur du jour ; Cas 2 : clef de la liste1 : Identifiant du magasin / clef de la liste 2 : Identifiant du vendeur ; 2/ Vérification en remontant les listes, que le système ne fait pas référence à une clef d’une liste plus en amont. Dans le cas 2, un vendeur est associable à un magasin (On retrouve la clef de la liste 1 en remontant les identifiants de la liste 2). Ainsi, « magasin » est une référence potentiellement redondante. Plus généralement, l’invention mise en place permet d’obtenir les caractéristiques de référence très probable (ce qui permet notamment de constituer une structure de modèle de données sans avoir de vraies compétences en la matière) ; mais il reste possible pour un utilisateur du système de configuration d’enlever ou de rajouter des références s’il le souhaite pour garder une totale liberté sur le modèle. Ensemble de génération d’application mis en œuvre par ordinateur comprenant un système de configuration qui comprend . un module de manipulation de données d’utilisation de l’application (4a, 4b), et comprenant des moyens pour définir des listes de données à parcourir ; . un module de définition (E1) de l’interface graphique d’application comprenant des éléments graphiques modifiables, et des éléments de parcours de liste (E4), pour parcourir la liste et mettre en œuvre les requêtes de programme correspondantes ; . un module de gestion d’événements, configuré pour définir, pour chaque type d’événements liés aux éléments graphiques possibles, le comportement attendu (E5, E7) ; . un module d’éléments de cardinalité (E6, E7) configuré pour encadrer le comportement des éléments de parcours de liste ; un système de génération de l’application (C, G.V.) comprenant des modules d’analyse des données saisies dans le système de configuration et configurés pour mettre en œuvre automatiquement les requêtes de programme pour générer l’application, caractérisé en ce que l’ensemble est configuré de sorte qu’une modification des éléments graphiques modifiables entraine une mise en œuvre des requêtes de programme selon la liste et une modification correspondante de l’application. Ensemble de génération selon la revendication précédente, dans lequel le module de définition de l’interface graphique (E1) comprend des éléments graphiques standards tels que des cases à cocher, champ texte, vidéo, image, forme graphique, champ de date/heure, champ numérique et/ou des éléments pré réalisés proposés tels que des menus, évaluation par des étoiles, et/ou des éléments programmés par l’utilisateur. Ensemble de génération selon l’une des revendications précédentes configuré de sorte qu’une fois l’élément de cardinalité défini dans le système de configuration, alors le système de génération créera une table en table en base de données qui correspondra à l’élément de cardinalité, et les relations de cette table avec les autres tables de la base de données, étant également déterminées depuis ce qui a été saisi dans le système de configuration. Ensemble de génération selon l’une des revendications précédentes configuré de sorte qu’un rajout d’un champ dans un élément de cardinalité à l’aide du système de configuration ; entrainera un rajout de colonne dans la table en base de données par le système de génération. Ensemble de génération selon l’une des revendications précédentes, comprenant un module de détection de non-conformité configuré pour enregistrer l’interface et les évènements ayant eu lieu et pour vérifier que cela correspond à l’interface modifiée. Ensemble de génération selon la revendication précédente, dans lequel le module de détection de non-conformité est configuré pour comparer l’interface obtenue avec une simulation de l’interface initiale à laquelle est ajoutée les modifications de l’utilisateur. Méthode de création d’une application au moyen d’un ensemble de génération d’application mis en œuvre par ordinateur selon l’une des revendications précédentes comprenant des étapes suivantes (E1) Définition de la charte graphique générale de l’application, comprenant des éléments graphiques modifiables, (E2) Création, nommage de la page d’application telle qu’une page web, de ses entrées, caractérisée par les étapes (E4) Définition d’une liste à parcourir et d’un l’élément de « parcours de liste », et en ce qu’une modification des éléments graphiques modifiables entraine une mise en œuvre de requêtes de programme selon la liste et une modification correspondante de l’application. Produit programme d’ordinateur comprenant des portions de code de programme enregistré sur un support utilisable dans une unité de commande, pour mettre en œuvre les modules d’un ensemble selon l’une des revendications 1 à 6, ou une méthode selon la revendication précédente, lorsqu’il est exécuté par l’unité de commande.