La présente invention porte sur un procédé et un système de génération d 'une application logicielle manipulant des données structurées.

Dans un langage de programmation, une donnée est élémentaire quand elle est directement représentée par un mot clé du langage de programmation. Par opposition, une donnée structurée est composée de une ou plusieurs données élémentaires ou structurées du langage de programmation.

Aussi, dans la présente invention, une donnée est élémentaire, quand son type est défini dans le système de génération, et une donnée structurée est composée de une ou plusieurs de ces données élémentaires ou structurées.

Il existe de nombreux cycles de développement d 'une application logicielle, tels que les cycles de développement en cascade, de développement en V, ou encore des cycles de développement itératifs. Ces concepts de programmation ont permis une formalisation de niveau de plus en plus élevée des structures et des fonctions à implémenter. Il existe des langages de modélisation permettant de décrire ces structures et ces fonctions, ainsi que des générateurs de code, ou série d' instructions, permettant de produire automatiquement, dans un langage donné, une fonction ou structure modélisée. UML (« Unified Modeling Language ») est un exemple connu et de plus en plus répandu de langage de modélisation.

A partir d'une telle modélisation, il est possible d' automatiser la production d' au moins une partie d'une application. Une fois l ' application mo délisée, les outils de génération de code permettent de générer les morceaux d' application concernés . Toutefois, aucun de ces procédés ou de ces systèmes de développement d'une application logicielle ne permet de s ' affranchir des causes principales d' échec de la réalisation d'une application logicielle, à savoir des besoins manquant de clarté, ou mal traduits lors de la modélisation de l ' application. En outre, le code applicatif produit doit être modifié manuellement et l ' application logicielle n' est donc pas opérationnelle après les étapes de génération automatique.

Un but de la présente invention est de pallier ces problèmes .

Selon un aspect, il est proposé un procédé de génération d 'une application logicielle manipulant des données structurées, en fonction d'un ensemble de scénarii correspondant chacun à une action sur une donnée structurée manipulée par l ' app lication lo gicielle .

Selon une caractéristique générale, le procédé comprend :

- une élaboration automatique d'une spécification complète de l ' application logicielle en fonction desdits scénarii au moyen d' au moins un parcours de l ' ensemble de scénarii et d' au moins une étape de complétion desdits scénarii,

- une compilation de ladite spécification complète de manière à obtenir l ' application logicielle.

Ainsi, la présente invention permet de générer une application logicielle directement à partir de scénarii associés à des manipulations des données structurées de l ' application logicielle, ce qui permet de réduire le coût et le temps de développement de l ' application logicielle. En outre, l' application logicielle est opérationnelle après l ' étape de compilation.

L ' action d'un scénario peut comprendre des étapes comprenant chacune une action effectuée sur un élément de la donnée structurée manipulée par un scénario . Chaque scénario agissant sur une donnée ne décrit pas nécessairement des étapes comprenant des actions sur tous les éléments de la donnée structurée.

Ainsi, en parcourant l ' ensemble des scénarii, on peut par exemple obtenir par l ' ensemble des étapes, l ' ensemble des éléments qui forment une donnée structurée. Un parcours permet ainsi de compléter les scénarii. Les scénarii complétés, éventuellement après une pluralité d' étapes de parcours et de complétion, sont suffisant pour obtenir une spécification complète de l ' application logicielle ainsi que l ' application logicielle . Cette application logicielle est apte à mettre en œuvre tous les cas d'utilisation décrits par les scénarii.

A titre d' exemple non limitatif, un premier scénario peut correspondre à un ajout par un utilisateur d'une personne dans une base de données, ce scénario comprend un ajout par un utilisateur d 'un prénom et d'un nom lors de deux étapes du scénario . Si un deuxième scénario correspond également à un ajout d'une personne, mais avec deux étapes, un ajout d'un nom et un ajout d'une adresse, alors un parcours automatique du premier scénario puis du deuxième scénario permet de déterminer que la donnée structurée relative à une personne comprend un nom, un prénom, et une adresse.

On notera que l 'obtention des données structurées met en œuvre des étapes de déduction desdites données structurées lors des parcours des scénarii.

Dans l ' exemple présenté ci-avant, les données structurées comprennent des données élémentaires de type chaîne de caractère pour le nom et le prénom mais de type structurée pour l ' adresse.

La possibilité de générer l ' application logicielle à partir de scénarii dont les actions ne portent par exemple pas sur tous les éléments d'une donnée structurée permet de simplifier l ' élaboration des scénarii et d' obtenir un gain de temps. Par ailleurs, la réalisation de l ' application est simplifiée, car on s ' intéresse directement à ce que doit faire l ' application et non à comment elle doit le faire.

Avantageusement, la génération de l ' application lo gicielle comprend une génération d' au moins une interface utilisateur, d' au moins un schéma de base de données relationnelle apte à contenir lesdites données structurées manipulées par l' application logicielle et d' au moins une couche de traitement apte à manipuler lesdites données.

L 'interface utilisateur permet de manipuler les données des scénarii.

L ' élaboration de la spécification complète comprend une élaboration de données relatives aux écrans de ladite au moins une interface utilisateur à générer, chaque scénario correspondant à un écran de ladite au moins une interface utilisateur, et une élaboration de données relatives à la couche de traitement apte à manipuler lesdites données.

On peut former préalablement à la compilation des fichiers sources à partir de la spécification complète et d'un ensemble de modèles de fichier source réalisés préalablement.

Les modèles de fichier source sont des fichiers sources comprenant des éléments à compléter et possédant une structure prédéfinie . La lecture de la spécification complète élaborée automatiquement à partir des scénarii, par des étapes de complétion et de déduction, permettra d'obtenir les informations nécessaires pour compléter les modèles de fichier source.

On pourra par exemple utiliser des modèles de fichiers sources en langage Java, par exemple au moyen d'un moteur de modèles de fichiers sources bien connu de l 'homme du métier sous le nom de moteur de template, tel que, par exemple, Velocity.

En outre, les actions sur une donnée structurée des scénarii peuvent être choisies dans le groupe formé par l ' action de créer, l ' action de lire, l ' action de rechercher, l ' action de mettre à jour et l ' action de supprimer une donnée structurée.

Ces actions sont connues de l' homme du métier sous l ' acronyme anglais « CRUD : Create, Read (or Retrieve), Update, Delete » .

Chaque scénario peut comprendre en outre une pluralité d' étapes correspondant chacune à une manipulation d'un élément de la donnée structurée manipulée par le scénario . Chaque élément peut être une donnée élémentaire ou bien une donnée structurée en désignant un autre scénario .

Avantageusement, on obtient lesdites données structurées manipulées par l ' app lication logicielle au moyen de parcours de l ' ensemble des scénarii dans lesquels si un élément d'une donnée structurée apparaît dans un scénario il est rajouté à ladite donnée structurée manipulée par l ' application. Si un élément d'une donnée structurée a déj à été rajouté à une donnée structurée manipulée par l ' application logicielle lors du parcours d 'un premier scénario et si ledit élément apparaît au cours d'un parcours d 'un deuxième scénario avec une définition différente alors la définition dudit élément dans la donnée structurée manipulée par l ' application est choisie en fonction des deux définitions différentes. On notera que la définition dudit élément dans la donnée structurée manipulée par l ' application correspond à la définition utilisée par exemple dans le schéma de base de données généré.

Bien entendu, lors de la mise en œuvre d'un des scénarii à travers un écran d 'une interface utilisateur, par l ' application logicielle, la définition de l ' élément sera celle du scénario .

Il est également possible d' avoir une pluralité de définitions différentes .

A titre d' exemple non limitatif, si dans un premier scénario manipulant une donnée structurée correspondant à une personne, l ' élément nom est limité à cinquante caractères, et si dans un deuxième scénario manipulant la même donnée structurée, l ' élément nom est limité à quarante caractères, alors on pourra par exemple, définir l ' élément nom dans la donnée structurée manipulée par l ' application logicielle, c'est-à-dire dans le schéma de base de données, comme étant limité à cinquante caractères. En revanche, les deux écrans de l' interface utilisateur correspondant aux deux scénarii auront respectivement des champs nom de 40 et 50 caractères.

Ainsi, l ' ensemble de l' intention exprimée dans les deux scénarii est respectée et l ' application générée, par le truchement du schéma de la base, est capable de manipuler une donnée structurée Personne avec un Nom compatible avec les deux écrans produits.

Avantageusement, l ' élaboration de la spécification complète de l ' application comprend au moins une étape de vérification automatique.

Ainsi, il est par exemple possible de vérifier les types des données élémentaires ou encore la faisabilité d' éventuelles contraintes . Par exemple si deux scénarii manipulant une donnée correspondant à une personne comportent respectivement une définition du nom comme étant une chaîne de caractères et une définition du nom comme étant un chiffre, une alerte ou message d' erreur précis sera élaboré et l ' application ne sera pas générée ou bien sera générée en excluant cet élément.

Chaque scénario de l ' ensemble des scénarii peut être associé à une catégorie d'utilisateurs autorisés à effectuer l ' action sur une donnée structurée du scénario . Une interface utilisateur peut ainsi être générée pour chaque catégorie d'utilisateur.

On notera qu'un système extérieur peut correspondre à une catégorie d'utilisateur, de manière par exemple à automatiser des manipulations de données au moyen de systèmes extérieurs .

L ' application logicielle peut être générée à distance, par l' intermédiaire d'un réseau de communication.

En outre, l' application logicielle générée peut être mise à disposition à distance au moyen d 'un réseau de communication.

Ainsi, un utilisateur peut par exemp le, depuis un premier terminal, envoyer un ensemble de scénarii à une plate forme de génération disposée à distance, et une fois l ' application générée, un deuxième utilisateur peut utiliser ladite application depuis un deuxième terminal.

Selon un autre aspect, il est proposé un système de génération d'une application logicielle manipulant des données structurées, en fonction d 'un ensemble de scénarii correspondant chacun à une action sur une donnée structurée manipulée par l' application logicielle.

Le système comprend :

- des moyens d' élaboration automatique d'une spécification complète de l ' application lo gicielle en fonction desdits scénarii comprenant des moyens de parcours de l ' ensemble des scénarii et de complétion desdits scénarii,

- des moyens de compilation de ladite spécification complète aptes à générer l ' application logicielle.

Le système de génération peut être disposé à distance et être accessible par l 'intermédiaire d 'un réseau de communication. En outre, l ' application logicielle peut être accessible à distance au moyen d'un réseau de communication.

D'autres avantages et caractéristiques de l'invention apparaîtront à l'étude de la description détaillée de modes de mise en œuvre et de réalisation, pris à titre d'exemples non limitatifs et illustrés par les dessins annexés sur lesquels :

- la figure 1 illustre schématiquement un ensemble de scénarii selon un aspect de l ' invention,

- la figure 2 illustre schématiquement des étapes d'un procédé selon un mode de mise en œuvre selon l' invention, et

- la figure 3 illustre schématiquement un système selon un mode de réalisation de l' invention.

Sur la figure 1 , on a représenté schématiquement un ensemble de scénarii 1 . L ' ensemble de scénarii 1 peut être élaboré par un utilisateur, et comprend les différents cas d'utilisation d'une application logicielle à générer.

L ' ensemble de scénarii 1 comprend une pluralité de scénarii 2a, 2b et 2c, représentés ici au nombre de trois.

Chaque scénario 2a, 2b ou 2c possède un titre 3 a, 3b ou 3 c. Chaque titre 3 a, 3b ou 3 c doit être unique. Il ne peut exister deux scénarii avec le même titre. Ce titre peut par exemple être choisi par l 'utilisateur élaborant les scénarii.

Chaque scénario 2a, 2b ou 2c possède un type d' action sur une donnée structurée 4a, 4b ou 4c, avantageusement choisi dans l ' ensemble formé par le groupe formé par l' action de créer, l ' action de lire, l' action de rechercher, l ' action de mettre à jour et l ' action de supprimer une donnée structurée . Ces actions sont notamment celles utilisées pour manipuler les bases de données bien connues de l' homme du métier sous le nom de SQL. Lors de la génération de l ' application logicielle et notamment des interfaces utilisateur, l ' action indique notamment le type d'interface à produire. De manière classique, une interface de recherche d'une donnée structurée diffère par exemple d'une interface de mise à jour. On notera que d' autres types d' actions peuvent être utilisées, par exemple des actions définies au sein d' interfaces de programmation (« API : Application Programming Interface » en langue anglaise) .

La donnée manipulée 5 a, 5b ou 5 c respectivement par les scénarii 2a, 2b ou 2c est également présente dans chaque scénario . Cette donnée manipulée 5 a, 5b ou 5 c correspond au nom d'une donnée structurée. A titre d' exemple, tous les scénarii manipulant la donnée structurée « personne » utiliseront un même nom pour décrire cette donnée. Ainsi, lors de la génération de l ' application logicielle, les parcours de scénarii permettent d' obtenir toutes les cas d'utilisation portant sur une même donnée structurée.

Dans chaque scénario 2a, 2b ou 2c, une catégorie d 'utilisateur 6a, 6b ou 6c est respectivement inscrite. Les catégories d'utilisateurs 6a, 6b ou 6c peuvent notamment être des catégories d'utilisateurs autorisés ou non à mettre en œuvre l ' action du scénario . Ainsi, certaines parties de l ' application lo gicielle peuvent être interdites d' accès à certains utilisateurs . Ainsi, certains éléments de données structurées ne peuvent par exemple pas être modifiés par certaines catégories d'utilisateurs, et certains écrans d 'une interface utilisateur peuvent être interdits à certaines catégories d'utilisateurs .

Chaque scénario 2a, 2b ou 2c comporte ici respectivement une pluralité d' étapes 7a, 7b ou 7c, ces étapes sont des interactions sur les éléments de la donnée structurée manipulée par le scénario . On notera qu' il est possible d' avoir un scénario sans étapes . Par exemple, lors d'un scénario d' ajout d 'une personne, deux étapes peuvent être mises en œuvre, une étape d' ajout d'un nom et une étape d' ajout d' un prénom. On notera que dans cet exemple, le parcours d'un tel scénario et plus précisément de ses étapes permet de déduire que la donnée structurée correspondant à une personne contient un nom et un prénom.

Les étapes d'un scénario peuvent être ordonnées, par exemple successives . Les étapes 7a, 7b ou 7c peuvent également avoir d' autres paramètres. A titre d ' exemple, on peut associer à chaque étape une cardinalité, c'est-à-dire le nombre de fois que l ' étape peut être mise en œuvre lors du déroulement du scénario . On peut également préciser quelles sont les contraintes portant sur une étape. Le type de l ' élément sur lequel porte l ' étape peut être indiqué, on pourra par exemple utiliser les chaînes de caractère, les entiers, les booléens, et éventuellement des types étant des données structurées ou encore des titres de scénarios .

Si par exemple une étape porte sur un autre scénario , alors le scénario comportant cette étape peut être considéré comme incomplet. Lors de la génération de l' application logicielle, une étape de complétion peut permettre de compléter l ' étape en utilisant le scénario sur lequel l ' étape porte. Des parcours de l ' ensemble des scénarii permettant d 'obtenir l ' ensemble des informations nécessaires à la complétion.

On peut également, pour chaque étape 7a, 7b ou 7c, définir un certain nombre de contraintes portant sur l ' élément, par exemple l'obligation d' avoir un élément non nul (par exemple lors d'un ajout d'un élément) .

En outre, on peut également, pour chaque étape 7a, 7b ou 7c préciser une catégorie d'utilisateur, par exemple une catégorie d'utilisateur 6a, 6b ou 6c.

Ces contraintes sont notamment prises en considération lors de la génération d' interfaces utilisateurs . Par ailleurs, lors de la génération de l ' application logicielle, on pourra vérifier que les contraintes peuvent être mises en œuvre . Ainsi, un scénario pouvant être mis en œuvre pour deux catégories d'utilisateur peut comprendre des étapes pouvant être mises en œuvre pour une seule catégorie d'utilisateur.

Par ailleurs, une même étape peut apparaître dans différents scénarii.

Les scénario s 2a, 2b et 2c ainsi que les pluralités d' étapes 7a, 7b et 7c peuvent comprendre d' autres éléments. Il est possible de mettre en œuvre des sauts depuis un scénario ou une étape vers un autre scénario . On peut ainsi déclencher un scénario depuis un autre scénario ou une étape. L 'utilisation d'un titre unique par scénario est ainsi particulièrement avantageuse.

Bien entendu, ces sauts peuvent être mis en œuvre avec des contraintes . Lors de la génération de l ' application logicielle, on pourra par exemple vérifier que les sauts sont valides et qu' ils portent sur un scénario existant.

On notera que les étapes peuvent correspondre à des champs sur les écrans d'une interface utilisateur. Ces champs sont caractérisés de manière classique par des contraintes sur le type de données utilisées par le champ .

Enfin, l ' ensemble de scénarii 1 peut également comprendre un ensemble de données fixé par l 'utilisateur élaborant les scénarii. Une étape d'un scénario peut par exemple utiliser un tel ensemble de données fixe, par exemple lors d'un scénario d' ajout de personne, dans lequel l 'utilisateur final pourrait être amené à faire un choix sur la civilité de la personne en choisissant un élément dans l ' ensemble fixé comprenant par exemp le « Mme. , M . , Mlle. » .

La structure des scénarii et des étapes décrite ci-avant permet avantageusement d' obtenir une application logicielle au moyen des différentes étapes du procédé selon l' invention.

Sur la figure 2, on a représenté les étapes d'un procédé selon un mode de mise en œuvre selon l' invention.

Lors d 'une première étape E01 , un utilisateur élabore un ensemble de scénarii, par exemple l ' ensemble de scénarii 1 décrit ci- avant.

Lors d'une deuxième étape E02, l 'utilisateur se connecte à distance, par exemple au moyen d 'un réseau de communication, à une plateforme de génération d'une application logicielle selon l' invention. L 'utilisateur peut ainsi envoyer ses scénarii.

Lors d'une étape E03 , les scénarii sont parcourus de manière automatique. Au cours de cette étape de parcours, les scénarii sont analysés, les données structurées apparaissant dans ces scénarii sont analysées, ainsi que les différents éléments formant les scénarii tels que les étapes, les données structurées manipulées, les catégories d'utilisateurs. Les scénarii semblants incomplets, par exemple ceux rattachés à d' autres scénarii, sont trouvés lors de l ' étape E03. Les parcours permettent également de trouver les éléments permettant de compléter des scénarii incomplets. Les parcours permettent de vérifier si les éventuels sauts sont réalisables, de vérifier si les types des éléments des données structurées manipulés dans les étapes sont des types connus (par exemple des types connus par un langage de programmation) ou alors s ' ils sont définis dans un autre scénario , ou encore de vérifier si les contraintes sont réalisables .

Une étape de complétion des scénarii est ensuite mise en œuvre (étape E04) . Cette étape peut comprendre des complétions des scénarii dans lesquels une étape porte sur un scénario (ledit scénario est alors copié dans l ' étape), des étapes d' élaboration des données structurées manipulée par l ' application logicielle, des étapes d' élaboration de relations hiérarchiques entre par exemple les données structurées, ou encore d' autres étapes de complétion.

Cette étape de complétion consiste à utiliser les résultats de l ' étape E03. L ' étape E03 permet de déterminer quels sont les scénarii incomplets, et également quels sont les éléments permettant de compléter ces scénarii, par exemple par déduction. Des étapes de copie sont alors mise en œuvre pour compléter les scénarii au cours de l ' étape E04.

Lors de l ' élaboration des données structurées manipulées par l ' application logicielle à générer, si un élément d'une donnée structurée apparaît dans un scénario il est rajouté à ladite donnée structurée manipulée par l ' application.

Si un élément d'une donnée structurée a déj à été rajouté à une donnée structurée manipulée par l ' application logicielle lors du parcours d 'un premier scénario et si ledit élément apparaît au cours d'un parcours d 'un deuxième scénario avec une définition différente alors la définition dudit élément dans la donnée structurée manipulée par l ' application est choisie en fonction des deux définitions différentes. Ainsi, l ' élément de la donnée structurée manipulée par l ' application peut avoir une définition par exemp le peu restrictive au sein d'un schéma de base de données généré, mais la définition de l ' élément lors de la mise en œuvre du scénario, c'est-à-dire sur l ' écran correspondant au scénario, sera celle du scénario .

Les étapes E03 et E04 peuvent être mises en œuvre une pluralité de fois (boucle BCL) de manière à obtenir lors de l ' étape E05 une spécification complète de l ' application logicielle à générer. Cette spécification complète comprend l ' ensemble de scénarii 1 après des étapes de complétion, les données structurées manipulées par l ' application, et des données relatives aux écrans d' au moins une interface utilisateur de l ' application logicielle et également des données relatives à la couche de traitement apte à manipuler les données structurées de l ' application logicielle.

Les données relatives à la couche de traitement peuvent notamment décrire le fonctionnement d'un serveur, par exemple les appels de l ' interface utilisateur vers le serveur.

On notera que les résultats des étapes E03 et E04 peuvent être stockés dans des fichiers informatiques .

Enfin, lors de l ' étape E06, on forme des fichiers source à partir de cette spécification complète. L 'homme du métier saura choisir des moyens de formation de ces fichiers sources à partir de la spécification complète formée au cours de l ' étape E05. Ces fichiers sources peuvent être des fichiers Java (par exemple une classe pour chaque donnée structurée), des fichiers j avascript, XML et Bash ou encore d' autres types de fichiers sources. On pourra notamment utiliser des mo dèles de fichiers sources et par exemple l ' outil Velocity. Les modèles de fichier source sont complétés grâce aux informations obtenues lors des étapes E03 et E04.

Les fichiers sources sont compilés au cours de l ' étape E07 de manière à obtenir notamment une pluralité d' interfaces utilisateurs 8 , un schéma de base de données 9, ou encore une couche de traitement 10.

D ' autres éléments peuvent être générés par l ' application, notamment des éléments permettant de tester l ' application. Tel qu' illustré sur la figure 3 , un système de génération d'une application logicielle manipulant des données structurées selon un aspect de l ' invention comprend une plate-forme de génération 1 1 reliée au réseau de communication Internet 12, et comprend un module d' entrée 13 d 'un ensemble de scénarii 1 , accessible depuis un terminal 14 par l 'intermédiaire du réseau Internet 12. La plate-forme de génération 1 1 comprend un système de génération de l ' application logicielle 15 en fonction de l ' ensemble de scénarii 1 , ainsi qu'un module de mise à disposition instantanée 16 de l' application logicielle générée pour le terminal 14 ou un autre terminal 17, muni d'un écran 1 8 et relié audit réseau Internet 12. Le module d' entrée 13 comprend une interface graphique 19 affichable sur un terminal, par exemple le terminal 14, par l ' intermédiaire du réseau internet 12 et de l ' écran 20 du terminal 14.

La plate-forme 1 1 comprend un module de mémorisation ou mémoire 21 pour mémoriser les scénarii 1 entrés par un utilisateur au moyen du terminal 14.

En outre, la plate-forme de génération 1 1 comprend un module d' authentification 22 pour authentifier l 'utilisateur, par exemp le un identifiant et un mot de passe, ou par données biométriques, et permettre la génération, l 'utilisation ou la modification de l ' application logicielle . Ainsi, seules les personnes autorisées peuvent avoir accès à la génération, l'utilisation ou la modification de l ' application logicielle.

Le système de génération 15 comprend un module d ' élaboration automatique 23 d'une spécification complète de l ' application et un module de compilation 24 de ladite spécification complète.

Le module d' élaboration automatique peut par exemp le mettre en œuvre les étapes E03 , E04 et E05 , et le module de compilation peut par exemple mettre en œuvre les étapes E06 et E07.

Les modules d' élaboration 23 et de compilation 24 peuvent par exemple être réalisés au moyen d'une application logicielle Java.

Les moyens d' élaboration 23 comprennent notamment des moyens de parcours de scénarii et de complétion des scénarii de manière à obtenir une spécification complète, par exemple contenue dans des fichiers informatiques. On pourra par exemple utiliser un ensemble de scénarii formés selon la structure décrite ci-avant. Des fichiers sources formés dans un langage de programmation connu peuvent également être formés par les moyens d' élaboration 23.

Les moyens de compilation 24 peuvent, à partir d 'une spécification complète et notamment à partir de fichier sources, générer une application logicielle.

En outre, la plate-forme 1 1 comprend une base de données 25 apte à contenir les données structurées manipulées par l ' application, ainsi qu'un module de mémorisation de l ' application logicielle générée 26. Le module de mémorisation 26 peut être organisé, par exemple sous forme de base de données, de manière à pouvoir mémoriser une multitude d' applications logicielles diverses générées indépendamment les unes des autres. Le module de mémorisation 26 peut mémoriser les différentes versions successives générées d'une application lo gicielle, ainsi que des références permettant d' identifier les scénarii du module de mémorisation 21 . En outre, le module de mémorisation 26 peut mémoriser la couche de traitement générée de l ' application logicielle. On notera qu' il est possible de mémoriser les scénarii pour générer l ' application uniquement lors de son utilisation.

La p late-forme de génération 1 1 comprend, en outre, un module de transfert 27 pour transférer l ' application logicielle générée au terminal 14, par l 'intermédiaire du réseau de communication internet 12 ou au terminal 5 après authentification des droits de l'utilisateur. En variante, le module de transfert, ou de téléchargement, peut être remplacé par l ' inscription de l ' application logicielle sur un support de données numériques, tel qu'un CD ou un DVD .

La plate forme 1 1 peut également comprendre un module de paramétrage 28 permettant de paramétrer la génération de l ' application logicielle de la plate-forme d' exécution sur laquelle est exécutée l ' application logicielle.

Grâce à l ' invention, on peut générer une application logicielle manipulant des données structurées et ce au moyen de scénarii, c'est-à- dire une description semblant être incomplète de l ' application logicielle à générer.

Selon un aspect de l 'invention, on pourra obtenir des applications logicielles de gestion commerciale, de gestion de la relation client, de gestion des ventes, des devis, des bons de commande.

On peut également former des applications de gestion des ressources humaines ou encore un lo giciel comprenant l ' ensemble des modules mentionnés ci-avant.