FR2934388A1 - Procede de creation de programme informatique - Google Patents

Abstract

L'invention concerne un procédé de création d'un programme informatique écrit dans un langage de programmation de haut niveau. Selon l'invention, un tel procédé comprend : - une phase préalable à l'écriture dudit programme dans ledit langage de programmation de haut niveau comprenant : - une étape de construction d'un langage de base fonctionnel, à algèbre réduite, sans opérations de réaffectation, dit langage PML ; - une étape d'écriture d'au moins une bibliothèque dans un langage préexistant puis, à partir de ladite au moins une bibliothèque, - une étape de construction d'interfaces fonctionnelles à partir de fonctionnalités impératives lesquelles appartiennent au groupe comprenant au moins : - le stockage pérenne d'information sur un support, - l'envoi et la réception de paquets sur un réseau, - l'analyse d'un flux de données ; - une étape de construction d'un langage de haut niveau par liaison des dites interfaces dans des fonctions du langage PML, - une phase de création dudit programme informatique à partir du langage de haut niveau comprenant une étape de compilation.

Description

Procédé de création de programme informatique 1 DOMAINE DE L'INVENTION La présente invention se rapporte au domaine de la création de programmes.

Un programme est, au sens strict une série d'instructions exécutées par un ordinateur sous forme interprétée ou sous forme compilée. Toutefois on entend ici par programme (au sens large), une série d'instructions destinées à tout type de produits incorporant des microprocesseurs ou des microcontrolleurs. En effet, avec des adaptations classiques, le procédé selon l'invention est également applicable à la programmation de composants électroniques programmables ainsi qu'à la conception de composants électroniques classiques. La description du procédé selon l'invention est plus clairement accessible dans sa généralité sur l'exemple des programmes d'ordinateur et le texte de ce document s'appuiera donc principalement sur ce mode de réalisation. Par la suite, on présente notamment le cas de programmes permettant la fourniture de services web. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en oeuvre dans de nombreux autres domaines, et par exemple dans le domaine de la construction de systèmes d'exploitation et plus généralement dans tous les cas où les objectifs listés par la suite û caractère prouvable des programmes, persistance, optimisation avant l'exécution, environnement de développement, utilisation flexible de plusieurs syntaxes équivalentes - sont pertinents. Les problèmes de sûreté informatique liés à des anomalies ( bugs ) des logiciels et les problèmes de sécurité informatique liés à l'exposition de ces logiciels à des attaques malveillantes sur les réseaux prennent une importance grandissante. Ces problèmes de sûreté et sécurité informatique ont un coût de plusieurs milliards d'euros chaque année pour la seule Union Européenne. Ils affectent à la fois les consommateurs, les entreprises et les citoyens. Dans le domaine des serveurs internet, on estime que plus de 80% des sites présentent des failles susceptibles d'affecter des données critiques des utilisateurs. De nombreux acteurs se sont donc investis dans le développement de solutions ayant pour objectif la qualité et la sûreté des applications et la sécurité des réseaux. Ces solutions vont de la définition de procédés de développement qui sont matérialisées par l'obtention de certifications censées prédire un certain niveau de fiabilité, telle que la certification CMMI (de l'anglais Capability Maturity Model Integration ), jusqu'à la mise en oeuvre de logiciels de test censés déceler, par la force brute, une partie significative des innombrables erreurs potentiellement présentes au sein d'une application. Lorsqu'une intégration de programmes informatique doit être faite dans des composants électroniques programmables, les erreurs des programmes se trouvent également intégrées dans les composants électroniques, ce qui peut poser des problèmes de sécurité. 2 ART ANTERIEUR Compte-tenu de l'importance croissante des enjeux de sûreté et de sécurité, le monde de la production d'applications logicielles regorge de méthodes et de logiciels de tests qui sont supposés offrir la production de logiciels plus ou moins dépourvus d'anomalie. La garantie offerte n'est cependant que très relative puisque des travaux universitaires ont mis en évidence l'impossibilité de prouver formellement c'est-à-dire mathématiquement, pour un logiciel quelconque, l'absence d'anomalie d'un logiciel codé dans un langage impératif (Church, Gôdel, Turing). La quasi-totalité des langages utilisés dans l'industrie pour développer des applications sont des langages impératifs (C, C++, Java, Perl, PHP, ASP, Ruby...).

La création d'un programme passe par plusieurs phases. Dans un premier temps, un concepteur de programmes interprète des besoins d'un utilisateur, formulés dans un langage proche du langage naturel pour créer des spécifications. Il retranscrit (code) ensuite ces spécifications dans un langage de création de programmes sous la forme de fonctions qui sont enregistrées dans des fichiers de codes sources. Pour pouvoir obtenir une application exécutable, tous les fichiers de codes sources précédemment créés sont ensuite compilés et liés par l'intermédiaire d'un compilateur et d'un éditeur de lien. Le programme peut alors être exécuté et testé. La création d'anomalie intervient lors de ces étapes de codage et de compilation. Lors du codage, qui est une opération essentiellement manuelle, le programmeur construit sans s'en apercevoir des anomalies en agençant et en définissant des variables ou des fonctions qui, dans des cas d'exécution prévus ou non prévus, ne produiront pas les résultats attendus. La création d'anomalie intervient également lors des étapes de compilation et d'édition de lien. En effet, ces étapes nécessitent l'emploi de programmes informatique qui ont eux-mêmes fait l'objet d'un développement qui pose les mêmes problèmes que ceux générés par le programmeur. Les compilateurs utilisés sont donc fréquemment actualisés, à mesure que des anomalies y sont détectées. Des problèmes d'anomalies sont également rencontrés dans le cas des 15 programmes interprétés qui sont exécutés par un interpréteur ou une machine virtuelle. Il est donc clair qu'il est difficile d'obtenir un programme exempt d'anomalie. Il est quasiment impossible, pour un programme complexe donné écrit à l'aide d'un langage impératif de prouver formellement que celui-ci 20 fonctionne sans anomalies. On parle de preuve formelle quand on peut assurer mathématiquement, sur la base du seul code source d'un programme, que celui-ci est exempt d'anomalie. L' impossibilité d'apporter une telle preuve formelle est due en premier lieu au fait que les langages impératifs usuels comprennent des algèbres d'expression 25 de types trop nombreuses et qu'il est impossible, pour un programme trop complexe, de développer un arbre de syntaxe qui permet de prouver le programme. Il est en outre complexe de modéliser les effets de bord apportés par l'appel de certaines fonctions. Il est en effet fréquent qu'une fonction ait une portée 30 ou une durée de vie supérieure à celle de la structure (procédure, objet, ...) au sein de laquelle elle a été créée. Il arrive dans ce cas que soient modifiées zones de mémoire dans un but qui n'est pas directement lié à la fonction, mais au souci de partager les données, dans un état du programme prévu par le programmeur. On regroupe ces modifications à distance sous le terme générique d'effets de bord.

Liées aux opérations d'affectation qui changent l'état de l'application, ces effets de bord, en programmation impérative, sont à l'origine de nombreuses anomalies. Par exemple, on omet de mettre à jour certaines données partagées, on choisit un ordre chronologique incorrect pour des assignations par différentes portions du programme ou on désaffecte une zone de mémoire à un moment mal choisi et le programme se retrouve dans un état imprévu. La programmation fonctionnelle s'affranchit des effets de bords en interdisant les opérations d'affectation. Le paradigme fonctionnel n'utilise pas de machine d'états pour décrire un programme, mais un emboîtement de fonctions imbriquées les unes dans les autres. Chaque fonction accepte une ou plusieurs valeurs en entrée mais possède une sortie unique et renvoie donc toujours en sortie la même valeur pour chaque n-uplet de valeurs présentées en entrée. Ainsi, les fonctions n'introduisent pas d'effets de bord. En langage fonctionnel, les programmes sont donc des applications, au sens mathématique, qui ne produisent qu'un seul résultat pour chaque ensemble de valeurs en entrée.

Ainsi la structure des programmes écrits dans les langages fonctionnels est proche des mathématiques, contrairement aux programmes impératifs qui sont plus proches de la machine et ceci simplifie l'obtention de preuve et limite les risques d'anomalies liées à des erreurs humaines. Les problèmes d'anomalies sont donc beaucoup moins présents lorsque des langages fonctionnels sont utilisés en lieu et place des langages impératifs. De tels langages fonctionnels sont par exemple le LISP, APL, Haskell, ML, CAML, OCAML, Erlang, APL, J, K, Scheme,.... Ces langages fonctionnels comprennent des algèbres plus réduites et introduisent peu ou pas d'effets de bord. Il s'en suit que les arbres syntaxiques sont plus simples à analyser et que les programmes sont plus facile à prouver automatiquement.

Les atouts majeurs des langages fonctionnels en termes de modularité sont en outre reconnus. Malgré tout, les langages fonctionnels restent assez peu utilisés industriellement car ils présentent deux inconvénients principaux. Premièrement, la relative pauvreté des expressions réduit le nombre de possibilités offertes pour la création de fonctionnalités évoluées dans le cadre d'applications réelles manipulant des objets physiques (disque dur, cartes réseau) ou des interfaces graphiques. Deuxièmement, le degré de compétence élevé qu'ils exigent de la part des programmeurs à cause du caractère au prime abord non intuitif de la programmation fonctionnelle. A titre d'exemple, dans un langage impératif, la somme des entiers de 1 à 4 sera écrite 1+2+3+4 alors qu'en LISP, une telle somme sera écrite (+ 1 2 3 4) ce qui ne correspond pas à la manière de faire naturelle et donc complexifie la lecture des programmes. Pour augmenter les possibilités offertes par les langages fonctionnels tels que LISP, des ensembles de primitives sont ajoutés. Un tel ensemble de primitive est par exemple défini par le CLOS (de l'anglais Common Lisp Object System pour System d'objets du LISP Commun ). Ces primitives appartiennent toujours au langage LISP et il est donc théoriquement possible de prouver formellement un programme écrit à l'aide de cet ensemble de primitive, bien que cela devienne presque impossible. En effet, même avec les langages fonctionnels actuels, il est très difficile de prouver formellement un programme trop complexe car l'arbre syntaxique qui résulte d'un tel programme est également volumineux et le calcul de la preuve augmente de façon exponentielle avec la complexité de l'arbre syntaxique. On recourt donc également aux programmes de test pour rechercher les anomalies dans les programmes écrits avec des langages fonctionnels. Un autre niveau de complexité dans la programmation et une autre source d'anomalie est liée à l'utilisation de plusieurs langages de programmation différents au sein d'une même application. Ainsi, pour réaliser une application web, sont utilisés, en plus du HTML et du CSS qui codent respectivement le contenu et la présentation de la page, un langage pour le serveur (par exemple : Apache), un second langage de requêtes pour la base de données (par exemple : MySQL) et un troisième langage pour coder la logique de l'application web (par exemple : PHP). Pour être complet on notera qu'en pratique on doit utiliser un quatrième langage pour la création de la base de données et des utilisateurs (SQL), un cinquième pour sa configuration (dans le fichier mysql.conf par exemple) et un sixième pour le paramétrage du serveur. Ceci conduit à de nombreuses redondances (par exemple : variables en PHP et tables ou champs correspondants en MySQL) qui nuisent à la lisibilité de l'ensemble et augmentent le temps de développement. En particulier, lorsqu'une modification des spécifications de l'application entraîne la nécessité de modifications de la structure de la base de données, par exemple, rajout d'un champ ou suppression d'une table, les techniques actuelles permettant d'assurer une migration de la base de données sont lourdes et complexes à mettre en oeuvre. 3 RESUME DE L'INVENTION L' invention ne présente pas les inconvénients de l'art antérieur. L'invention se présente sous la forme d'un procédé de création d'un programme informatique écrit dans un langage de programmation de haut niveau. Selon l'invention, un tel procédé comprend : une phase préalable à l'écriture dudit programme dans ledit langage de 20 programmation de haut niveau comprenant : - une étape de construction d'un langage de base fonctionnel, à algèbre réduite, sans opérations de réaffectation, dit langage PML ; - une étape d'écriture d'au moins une bibliothèque dans un langage préexistant puis, à partir de ladite au moins une bibliothèque, - une étape de construction d'interfaces fonctionnelles à partir de fonctionnalités impératives lesquelles appartiennent au groupe comprenant au moins : - le stockage pérenne d'information sur un support, - l'envoi et la réception de paquets sur un réseau, - l'analyse d'un flux de données ; 25 30 - une étape de construction d'un langage de haut niveau par liaison des dites interfaces dans des fonctions du langage PML, - une phase de création dudit programme informatique à partir du langage de haut niveau comprenant une étape de compilation.

Selon une caractéristique particulière de l'invention, la phase de construction d'interfaces fonctionnelles comprend également une étape de stockage d'au moins une instruction dudit langage de haut niveau associant à un nom de commande un ensemble d'au moins deux commandes dudit langage PML et la phase de création dudit programme informatique à l'aide dudit langage de haut niveau comprenant également, une étape de stockage dudit programme informatique, ledit programme compilé appelant au moins une desdites instructions stockées. Selon un mode de réalisation particulier de l'invention, ladite phase de création dudit programme informatique comprend en outre une étape d'intégration, au sein d'un composant électronique ou informatique, dudit programme informatique créé. Ainsi, l'invention permet de garantir une création de composant électroniques qui sont exempts de bug. Ces composants électroniques peuvent par exemple être des diodes numériques ou des diodes électroniques dont l'objet est de fournir un résultat de conformité en fonction d'un paramètre d'entrée. Selon une caractéristique particulière de l'invention, ledit programme informatique écrit dans un langage de programmation de haut niveau est un parseur XML et ladite fonctionnalité impérative d'analyse d'un flux de données est une fonctionnalité d'analyse et de vérification d'un fichier XML.

Selon un mode de réalisation original, l'invention comprend un ensemble de primitives de spécification d'accès aux données d'une base de données au sein du langage de haut-niveau, permettant ledit stockage pérenne d'information sur un support sans qu'une application tierce partie de gestion de base de données ne soit nécessaire.

Selon une caractéristique particulière de l'invention, des données, structures de données et états de l'application dudit programme informatique sont rendus persistants par l'utilisation d'au moins une structures de données qui a la même représentation en mémoire vive et sur un dispositif de stockage de masse.

Selon un mode de réalisation original de l'invention, ladite phase de création dudit programme informatique comprend en outre une étape d'analyse statique du code source dudit programme informatique préalablement à sa compilation de sorte que ledit programme informatique obtenu est optimisé et/ou prouvé formellement.

Selon un mode de réalisation original, le programme détermine automatiquement à la compilation quels indexes générer afin de répondre aux requêtes implicites sur la base de données. Contrairement aux langages actuels pour lesquels des requêtes doivent êtres écrites et optimisées par le programmeur manuellement, le procédé selon l'invention repose sur un langage de haut niveau unifié qui spécifie la logique de l'application et gère de manière naturelle et transparente les accès à la base de données, avec des structures de données similaires en mémoire vive et sur disque. Selon une caractéristique particulière de l'invention, ladite au moins une bibliothèque permet d'implémenter au moins une fonctionnalité(s) absente(s) dudit langage PML et l'utilisation de ladite au moins une bibliothèque par ledit programme informatique permet de conserver des propriétés dudit langage PML, telles que les caractéristiques appartenant au groupe comprenant au moins : - le caractère fonctionnel dudit langage ; - le caractère prouvable dudit langage ; - la persistance des données manipulées. Selon un mode de réalisation original de l'invention, au moins une desdites bibliothèques permet de traiter des échanges réseau en intégrant au moins deux primitives de lecture et d'écriture de données sur des ports de communication et ledit programme informatique produit est une application de type service web.

Dans un mode de réalisation particulier, le procédé comprend la construction d'un binaire unique compilé à partir d'un seul langage source et ledit binaire unique compilé génère du code, notamment du code HTML, CSS et JavaScript ainsi que des requêtes compilées d'accès aux données. Le dit code HTML, CSS et JavaScript généré peut être validé à la compilation. Selon une caractéristique particulière de l'invention ledit procédé comprend en outre une étape de construction d'un langage de spécifications ne présentant pas de caractéristiques fonctionnelles et les programmes codés dans ce langage sont compilés vers ledit langage de haut niveau.

L'invention concerne également un dispositif de création d'un programme informatique écrit dans un langage de programmation de haut niveau. Selon l'invention, un tel dispositif comprend : - des moyens de création dudit langage de haut niveau comprenant : - des moyens de construction d'un langage de base fonctionnel, à algèbre réduite, sans opérations de réaffectation, dit langage PML ; - des moyens d'écriture d'au moins une bibliothèque dans un langage préexistant puis, à partir de ladite au moins une bibliothèque, - des moyens de construction d'interfaces fonctionnelles à partir de fonctionnalités impératives lesquelles appartiennent au groupe comprenant au moins : - le stockage pérenne d'information sur un support, - l'envoi et la réception de paquets sur un réseau, - l'analyse d'un flux de données ; - des moyens de construction d'un langage de haut niveau par liaison des dites interfaces dans des fonctions du langage PML, - des moyens de création dudit programme informatique à partir du langage de haut niveau comprenant une étape de compilation. Ainsi, un tel dispositif selon l'invention permet de créer des programmes informatiques qui peuvent être intégrés au sein de dispositifs électroniques et dont on assure qu'ils seront exempts d'anomalies.

Selon un mode de réalisation particulier de l'invention, ledit dispositif comprend en outre des moyens d'intégration, au sein d'un composant électronique ou informatique, dudit programme informatique de haut niveau créé et des moyens d'association d'une sortie de ce composant électronique à un composant de type filtre ou convertisseur. Selon une caractéristique particulière de l'invention, ledit programme informatique est implémenté au sein d'un composant électronique, tel qu'un composant électronique programmable de type FPGA. Ainsi, l'invention repose notamment sur des mécanismes permettant d'utiliser un même langage pour définir le traitement des données du programme et des données manipulées par le programme, stockées aussi bien en mémoire vive que sur le disque dur ou un autre type de stockage pérenne. L'utilisation d'un langage de haut niveau augmente la cohérence et l'expressivité et réduit la redondance du code. Elle limite les risques d'anomalies au moment du codage et facilite en outre l'analyse automatique des programmes, leur preuve et leur optimisation. Le procédé selon l'invention permet notamment l'obtention de produits ù programmes d'ordinateurs et services internet ù qui exhibent les deux propriétés suivantes : persistance et caractère prouvable. La signification et la valeur technique de ces propriétés ainsi que la façon innovante de les garantir apparaîtront à la lecture de l'exposé du procédé selon l'invention. Nous venons que la construction, par le procédé selon l'invention, de programmes codés dans des langages unifiés, permet de s'affranchir des redondances de variables et de fonctions tout en offrant une flexibilité syntaxique qui permet une bonne expressivité et en permettant un développement particulièrement agile. Le procédé selon l'invention présente un nombre important de caractéristiques nouvelles qui confèrent des avantages techniques majeurs aux divers programmes codés dans un langage de haut niveau en particulier dans leur façon de gérer le stockage de données sur un support pérenne, la transmission de données sur un réseau et la validation d'un flux de données.

Ce procédé permet en particulier à partir d'un code source unique écrit dans un langage de haut niveau, de générer un programme unique en langage machine capable de manipuler des données. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive 5 de la création de programmes informatique. L'invention concerne également un procédé de construction de programmes informatiques caractérisé en ce qu'il comprend les étapes suivantes : - construction d'un langage de programmation et d'une base de données, ladite base de données comprenant des fonctions de gestion d'une 10 persistance de données au sein d'une mémoire physique d'un dispositif ; - intégration d'un ensemble de primitives permettant de spécifier l'accès aux données de la base de données au sein dudit langage de programmation permettant d'obtenir un langage de haut niveau ; - développement, à l'aide dudit langage de haut niveau, d'un programme 15 résultant en une application unique ne nécessitant pas d'accès aux données de ladite base de données par l'intermédiaire d'une application distincte. Dans un mode de réalisation avantageux du procédé de l'invention, les données, structures de données et états de l'application sont rendus persistants par l'utilisation de structures de données du même type en mémoire vive et sur un 20 mode de stockage pérenne. Le langage de programmation servant de base au langage de haut niveau est notamment un langage fonctionnel, tel qu'un langage à algèbre réduite et sans effet de bords. L'utilisation d'un tel langage fonctionnel facilite l'obtention de preuves mais il faut noter qu'il existe, d'un point de vue fondamental, une forme 25 d'équivalence entre un langage fonctionnel et un langage impératif et que l'homme de métier pourra appliquer le procédé selon l'invention en adaptant un langage impératif. Dans un mode de mise en oeuvre avantageux, les programmes construits sont compilés et non interprétés. Le code source du programme est analysé 30 statiquement avant la compilation et, par le biais de cette analyse, le programme obtenu est optimisé et / ou prouvé. Afin d'ajouter des fonctionnalités aux programmes écrits dans un langage de haut niveau, l'invention fait appel à la construction de modules. Ces modules précompilés codent et encapsulent notamment des fonctionnalités impératives. Par ce biais, le programme résultant conserve certaines caractéristiques essentielles du langage de haut niveau (le cas échéant son caractère fonctionnel et / ou son caractère prouvable et / ou la persistance) tout en étendant son champ d'application. Un exemple d'une telle extension des capacités du programme par incorporation d'un module concerne un module réseau, qui est construit en intégrant au moins deux primitives élémentaires de type read socket et write socket. Le programme produit est une application de type Software as a Service ( SaaS pour Logiciel en tant que Service ). L'invention permet donc la réalisation de services internet.

Selon un mode de mise en oeuvre particulier, l'invention porte sur la construction d'un langage de spécifications (SL). Ce langage ne présente pas de caractéristiques fonctionnelles ce qui simplifie son utilisation par des non-programmeurs. Le langage est cependant construit à partir de langages fonctionnels comme QML et les programmes écrits en SL sont vérifiés et compilés vers un langage applicatif AML (puis vers le langage QML) ce qui permet de conserver un caractère prouvable et persistant aux programmes bien que ceux-ci soient codés de manière très lisible. L'invention concerne également la fabrication d'un parseur. En particulier, un parseur XML est formé sur la base d'un langage PML. Sous cet aspect particulier, l'invention ne fait pas appel à une base de données et la persistance n'est pas une propriété recherchée des programmes qui sont construits. La propriété essentielle qui est désirée est le caractère prouvable. Ce caractère prouvable est obtenu par construction. Partant d'un langage fonctionnel à algèbre réduite et en utilisant une 30 grammaire, une grammaire de grammaire, des parseurs et compilateurs et une représentation intermédiaire du XML, par exemple sous forme de pile, on construit un parseur XML avec moins de 500 lignes de code. De tels programmes parseurs, qui sont facilement prouvables de part leurs nombres de lignes réduits, peuvent être utilisés au sein d'ordinateurs ou dans des dispositifs électroniques, par exemple des circuits électroniques programmables de type FPGA (field processor gate array) ou CLPD (complex programable logic device). Ils peuvent être utilisés seuls ou associés à d'autres composants, notamment des filtres ou des convertisseurs. Tout programme produit par le procédé selon l'invention est, par construction, adapté à des analyses automatiques. Selon un aspect particulier de l'invention, ces analyses ne portent pas seulement sur la preuve de la correction du code mais portent également sur le calcul de caractéristiques de la réponse temporelle du programme. Les résultats obtenus par ces analyses ù par exemple la distribution statistique de la durée de traitement d'un type de signal d'entrée quelconque sont particulièrement utiles dans le cadre d'application temps réel. Les programmes produits ne sont pas limités à une utilisation sur un ordinateur. En effet, avec des adaptations évidentes pour l'homme de métier, les produits ou machines comportant un microprocesseur, par exemple les téléphones mobiles, les boitiers de type triple play permettant la fourniture de contenus vidéos, voix, audio et données sur la télévision, le téléphone et l'ordinateur, les ordinateurs de bord des voitures, des trains ou des avions, les ordinateurs de contrôle de machine-outil ou d'usine sont, sans que cette liste puisse être considérée comme exhaustive, autant de supports sur lesquels les programmes produits de l'invention peuvent être utilisés et sur lesquels sont valorisées les propriétés avantageuses de ces programmes, notamment le caractère prouvable et la persistance. L'invention concerne encore un procédé de création d'un langage de programmation fonctionnel LH, permettant l'obtention d'applications logicielles. Selon l'invention, un tel procédé comprend : - une étape de définition d'un prototype de base de données fonctionnelle, ledit prototype étant conçu pour être vérifié par des méthodes de vérification formelles ; - une étape de définition d'un langage fonctionnel typé spécifique QML ; - une étape d'intégration dudit prototype de base de données au sein dudit langage fonctionnel typé QML par le biais d'une interface spécifique dudit prototype de base de données fonctionnelle et d'un type spécifique dudit langage fonctionnel typé QML, ladite étape d'intégration délivrant ledit langage de programmation fonctionnel LH. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la création de programmes informatique, en permettant l'écriture d'un programme à l'aide d'un langage fonctionnel possédant une algèbre très réduite et la possibilité d'intégrer une base de données directement au sein du langage. L' invention permet donc d'établir une preuve formelle du programme de part l'utilisation d'un langage fonctionnel dont l'algèbre est réduite. Il est ainsi plus simple de prouver, avant même la compilation ou l'édition de lien, que le programme fonctionne sans anomalie. L' invention permet donc de ne plus avoir à tester le programme une fois que celui-ci a été compilé. Selon un mode de réalisation particulier de l'invention, ledit procédé comprend en outre une étape de génération d'un compilateur dudit langage de programmation fonctionnel LH vers un langage existant préalablement définit. Selon une caractéristique particulière de l'invention, ledit procédé comprend en outre une étape d'intégration, au sein dudit langage fonctionnel typé spécifique QML, d'au moins un module de vérification formelle dudit langage de programmation fonctionnel LH.

Selon un mode de réalisation particulier de l'invention, ledit procédé comprend en outre une étape d'intégration, au sein dudit langage fonctionnel typé spécifique QML, d'au moins un module d'aide à création d'une application spécifique. Ainsi, l'invention permet de faire appel à des bibliothèques de code 30 précompilé présentes au sein du langage pour mettre en oeuvre certaines fonctionnalités qui sont soit trop complexes pour le langage fonctionnel soit qui ont fait l'objet d'une implémentation sous la forme d'une autre grammaire du langage fonctionnel et qui peuvent être intégrées ainsi au langage fonctionnel final. Il s'agit par exemple de parseur spécifiques, tels que des parseurs HTML ou XML. Selon une caractéristique particulière de l'invention, ledit prototype de base de données fonctionnelle comprend des mécanismes de gestion d'une persistance de données. Ainsi, l'invention permet, du fait de l'intégration du prototype de base de données au sein du langage fonctionnel de type QML, d'offrir nativement une persistance des données. L'invention ne permet pas seulement d'offrir des mécanismes de persistance pour les données en relation avec l'application (par exemple une persistance des données d'un Wiki), mais également une persistance de l'application en tant que telle, c'est-à-dire de son état (ses données internes, variables, etc.) 4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de quatre modes de réalisations préférentiels, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : - la figure 1 illustre les différences entre l'état de l'art et le développement d'une application web en AML. On observe qu'un seul langage est utilisé contre au moins 3 actuellement. Ceci facilite l'apprentissage, la lecture et la cohérence du code. En outre l'utilisation d'AML, qui est compilé en QML puis en PML, conduit à partir d'un unique fichier source très réduit à un binaire également unique et de taille réduite, généré automatiquement et prouvé. Au contraire, les techniques actuelles utilisent plusieurs fichiers sources assez longs et conduisent à des exécutables également lourds ; - la figure 2 résume les principales étapes de construction, par incorporation de modules, de langages évolués (QML, AML puis SL) à partir d'un langage fonctionnel à algèbre réduite (PML). A chaque fois le nouveau langage est compilé dans l'ancien langage et une vérification automatique a lieu ; - la figure 3 illustre le flux du code écrit en langage de spécification SL puis vérifié et compilé en AML, QML puis PML ; - la figure 4 illustre le principe de la construction d'un parseur XML, à partir, notamment du langage PML, d'une grammaire et d'une grammaire de grammaire et en utilisant deux compilateurs différents ainsi qu'une structure de donnée conçue pour permettre des calculs efficaces XMLint. 5 DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention L'invention concerne un nouveau procédé permettant de créer des programmes informatiques qui contiennent moins ou ne contiennent pas d'anomalie. Pour ce faire, le procédé repose notamment, dans un mode de réalisation spécifique de l'invention, sur l'unification au sein d'un seul langage d'une base de données spécifiquement construite pour répondre à des problématiques fonctionnelles et impératives ainsi que du langage d'interrogation de cette base de données et d'un langage généraliste à algèbre réduite qui permet de coder la logique de l'application.

On notera que certains projets récents comme le projet LINQ de Microsoft visent également à offrir une syntaxe native Visual Basic ou C pour effectuer des requêtes sur une base de données. La similarité avec l'invention est toutefois très superficielle. En effet, les instructions LINQ dans un programme Visual Basic sont retranscrites en SQL ou en un autre langage de requête classique. La base de données n'est pas incluse dans le langage et le programme n'est pas unifié : il y a une application principale qui gère des variables, des fonctions, ... et une application dédiée à la gestion de la base de données, de ses tables, relations et champs. Si la coexistence des deux applications est rendue plus discrète par LINQ, ce type de construction ne permet pas une réelle intégration de la base de donnée dans le programme et n'offre pas les nombreux avantages liés à l'intégration totale de la base de donnée dans le programme produit du procédé selon l'invention, en particulier le caractère prouvable du programme, la possibilité d'optimiser les structures de données en fonction de l'utilisation qui est faite des données et la persistance des données et structures de données.

Pour bien comprendre l'apport de l'invention, il convient d'expliquer ce qu'est la persistance des données. La persistance des données se réfère au mécanisme responsable de la sauvegarde et la restauration de données, afin qu'un programme puisse se terminer à tout moment sans que ses données soient perdues. De manière classique, la persistance des données est gérée par l'intermédiaire de standards et de logiciels spécifiques qui sont interfacés avec des bases de données. Il s'agit par exemple de Toplink, JDO ou Hibernate pour le monde Java. L'invention permet d'apporter un mécanisme de persistance des structures de données directement au sein d'un langage de programmation unifié. Ce langage de programmation fonctionnel unifié est ensuite utilisé pour écrire des programmes spécifiques, tels que des applications Web, des programmes de gestion de stock ou toute autre application informatique. Ces applications informatiques résultantes intègrent alors directement la persistance, au sens large de persistance des données, des structures de données et des états du programme - qui sont eux-mêmes stockés dans la base de données - ainsi que d'autres propriétés associées à d'autres caractéristiques de l'invention décrites par la suite. Dans un mode de réalisation préféré, le procédé selon l'invention utilise un langage fonctionnel, dont l'algèbre est réduite et différents modules précompilés qui ont été prouvés au préalable. Le procédé selon l'invention, dans au moins un mode de réalisation, est caractérisé par l'identité entre les structures de données utilisées pour le stockage et la manipulation des données en mémoire et le stockage des données sur le disque dur. Il n'est pas systématiquement fait usage de tables et des structures plus complexes, notamment des mêmes structures arborescentes sont utilisées en mémoire et sur le disque. Des optimisations sont possibles pour tenir compte des espaces de stockage, des temps de lecture de données contigües, et des temps d'accès à des données non contigües sur les différents types de support (mémoire vive, mémoire flash, disque dur, dvd, ...). Cette caractéristique innovante du procédé selon l'invention permet de garantir la persistance des données. Plusieurs types de structures de données arborescentes sont utilisables, notamment des structures de type Patricia maps, connues de l'homme du métier. La figure 1 illustre le flux de production du code source d'un programme d'une application web écrit dans deux cas de figure (10 et 11). Dans le premier cas de figure (10), le programme est écrit à partir du langage de spécification SL. Dans le deuxième cas de figure (11), le programme est écrit avec des outils classiques. Dans le premier cas de figure (10), un programme (1), qui exprime dans un langage proche du langage naturel les spécifications des données et de l'application est d'abord vérifié (2) puis compilé (3) en langage d'application AML. Le code AML est également vérifié, ainsi que le code HTML, CSS et JavaScript automatiquement généré à partir d'AML et compilé (4) en langage QML avec base de données intégrée. Le code QML est vérifié et compilé (5) en langage fonctionnel à algèbre réduite PML. Ce dernier code est vérifié et compilé (6) directement ou indirectement (via OCAML ou C par exemple) en un programme exécutable.

Dans le deuxième cas de figure (11), une application web est produite avec les techniques de l'état de l'art : dans ce cas on part d'un ensemble d'au moins trois langages, le code n'est pas vérifié (8) et n'est pas successivement compilé. Un patchwork de langage et de fichiers de configuration (7) est utilisé pour produire (9) un exécutable qui contient de nombreuses anomalies.

Comparé à l'état de l'art, un programme écrit en langage de spécifications SL est particulièrement court (peu de lignes de codes). Un autre avantage de ce mode de réalisation du procédé selon l'invention est que l'application web créée est beaucoup plus légère (elle occupe moins de place mémoire). La figure 2 représente la construction de langages de haut niveau (de type SL, qui est utilisé par la suite) à partir d'un langage fonctionnel à algèbre réduite PML (langage de base). Tout d'abord un module encodant les fonctionnalités impératives (notamment deux primitives de type get data et set data) permettant l'intégration d'une base de données dans le langage est incorporé (1). Une étape de bootstraping est nécessaire pour l'imbrication complète de la base de données dans le langage (2). On obtient ainsi, selon l'invention, un langage fusionné avec une base de données (QML). Par ajout (3) d'un nouveau module encodant les fonctionnalités impératives (notamment deux primitives de type read socket et write socket ) permettant la communication sur le réseau, on obtient, toujours selon l'invention, un langage d'application web (AML). En modifiant (4) la syntaxe de ce langage AML par le biais de mécanismes de réécriture, on obtient un langage de haut niveau proche du langage naturel (SL) qui permet à un non programmeur de décrire les spécifications de l'application. La figure 3 illustre de manière plus précise le flux de production du code source du programme d'une application web écrit en langage de spécification SL de la figure 1. Les phases de vérifications et de compilation sont réalisées par l'intermédiaire de typeur et de traducteur. A chaque étape, le typeur permet de détecter la présence d'erreur, telles que des erreurs de codage et de produire une sortie en erreur dans les cas, par exemple, où les arbres syntaxiques ne sont pas corrects. Si aucune erreur n'est rencontrée, un traducteur est utilisé pour produire un code source dans un langage intermédiaire (AML, puis QML) puis dans le langage de base PML. Ce dernier code est vérifié et compilé pour produire un programme exécutable ou un code qui peut être inséré dans un composant électronique programmable.

Du fait des vérifications successives et du caractère prouvable du code source dans chaque langage intermédiaire et dans le langage de base, l'invention permet d'assurer que le programme exécutable final sera exempt de bug et d'anomalies, à la différence des programmes produits selon les techniques de l'état de l'art. Ainsi, l'invention permet d'assurer qu'un programme qui est inséré dans un composant logiciel programmable ne contiendra pas de bug et ne sera pas fragilisé ou attaquable par le biais de défaillances de programmation. 5.2 Mode de réalisation : création de programmes de type SaaS avec le langage AML 5.2.1. Construction d'un prototype de base de données Une partie significative de l'intérêt technique de l'invention découle de l'intégration entre programme et base de données. On décrit ci-dessous une façon de construire un prototype de base de données qui sera ensuite intégré au sein d'un langage de haut niveau. Dans un mode de réalisation particulier, la base de données fonctionnelle selon l'invention est constituée par un ensemble de graphes et de tables traduisant un chemin bas-niveau interne p en un eid, qui est un identificateur d'un élément de la base de données. Chaque eid est traduit en un uid via une table de traduction séparée. Lors d'une mise à jour d'une donnée de la base, l'eid ne change pas, mais un nouvel uid est créé. Chaque uid permet d'accéder à une donnée d de la base de données. Le chemin de recherche d'une donnée est donc le suivant : p -*Ieid-*2 uid-*3d. Les fichiers constitutifs de la base de données sont pour stockés en mémoire vive mais, selon l'invention, ils peuvent également être écrits directement sur le disque dur. La nature fonctionnelle du langage QML se prête particulièrement à une forme de stockage pérenne dans laquelle les données sur le disque sont persistantes. Une des techniques utilisables afin de réaliser ce stockage persistant sur disque est précisée ci-dessous. Pour chaque base de données, au minimum quatre fichiers sont écrits en mode append-only (ajout seulement), c'est-à-dire que les données sont seulement ajoutées et non pas remplacées. Les données supprimées ne sont donc jamais physiquement effacées, ce qui est un gage de sécurité supplémentaire et permet en particulier l'utilisation efficace de périphériques matériels limitant l'écriture (firmware append-only du disque dur, ...). Les quatre types de fichier sont les suivants : - un fichier . dbc, stockant le compteur d' uid, - un fichier .dbu, stockant les arbres nécessaire à la détermination de eid-*2uid, - un fichier .dbt, stockant les noeuds contenant les données uid-*3d, - un fichier .dbr, stockant les numéros de révision, Il est possible d'écrire la même information avec plus ou moins de redondance (par exemple sans le dbc ou en répartissant les données contenues dans les fichiers dbr sur les autres fichiers) sur un ensemble de fichiers différents sans modifier l'esprit de la base. La structure en patricia map est particulièrement souple et expressive et peut être directement utilisée pour l'association uid, eid. Dans un souci de performances, l'homme de métier pourra procéder à diverses optimisations. Suivant les applications, pourront également être utilisées des structures plus classiques comme les patricia tries ou les structures BRT (binary recursive trees). 5.2.2. Intégration de la base de données au sein d'un langage fonctionnel à algèbre réduite PML et construction d'un nouveau langage de haut niveau QML. Selon l'invention il est nécessaire, pour pouvoir produire un langage de programmation de haut niveau permettant la création de programmes exempts d'anomalies, de disposer d'un langage fonctionnel noté PML qui sera couplé à la base de données pour produire le langage QML. Le langage PML selon l'invention est un langage de la famille ML (Damas, L. et Milner, R., Principal type-schemes for functional programs, Annual Symposium on Principles of Programming Languages, 1982). Les inventeurs ont eu l'ingénieuse idée d'étendre la richesse d'expression et de réaliser une simplification interne du langage. Ainsi, le langage PML apporte des innovations par rapport à ML dont : - une gestion d'enregistrements polymorphes et extensibles ; - une implantation des types sommes comme des enregistrements via l'utilisation de types nommés, - une suppression des constructions redondantes (booléens, conditionnelles, Const of K.expr Ident of ident Coerce of expr * typeexpr Lambda of ident * expr Apply of expr * expr Letln of ident * expr * expr LetRecln of (ident * expr) list * expr ExtendRecord of string * expr * expr Dot of string Match of expr * (pattern * expr) list and typeexpr = 15 I TypeConst of K.typeexpr TypeVar of typevar TypeName of string * typeexpr list TypeArrow of typeexpr * typeexpr TypeRecord of typeexpr Records.t 20 and pattern = PatField of string * pattern * pattern PatConst of K.expr PatVar of string PatAny 25 Ce langage PML possède une algèbre réduite car les types d'expression (type expr =) sont limités. Dans le cas précédent, les types d'expression sont au nombre de dix. On peut dire qu'une algèbre est réduite à partir du moment où le nombre de types d'expression est inférieur à vingt. On ne détaille pas les expressions des enregistrements qui reposent sur des 30 arbres binaires, ni l'implantation du module constantes K, notamment entiers, 10 modules). Les algèbres et les expressions de ce langage PML se réduisent à : type expr = flottant, chaînes de caractères et valeurs nulles. Les identifiants pourraient se limiter à des chaînes de caractères, comme cela est fait classiquement (nom des valeurs, fonctions, etc.). Ce n'est notamment pas le cas puisque l'invention introduit une technique nouvelle au niveau des identifiants qui sont introduits dans les algèbres d'expression et de type, ce qui permet de mieux garantir la sécurité de l'implantation. Pour cela, le type des identifiants devient : type ident = I Source of string I Internal of abstract où abstract est un type abstrait (par exemple d'entiers) qui compte de manière unique les différentes valeurs. L'utilisation de ces types permet d'adresser certains des problèmes d' a-conversion. Selon l'invention, l'intégration du langage PML avec la base de données préalablement décrite est un mécanisme complexe et inédit. Une telle intégration permet d'unifier le langage utilisé pour décrire les programmes et celui utilisé pour décrire la base de données . Ceci assure une plus grande cohérence, évite les redondances et limite les risques d'erreurs dans le codage. Le but est donc d'incorporer totalement la base de données au langage pour n'avoir qu'un seul langage, au lieu de deux habituellement. Dans un mode de réalisation préféré, cette incorporation passe par un enrichissement du type identifiant présenté préalablement. Modification des identifiants Les types des identifiants du langage deviennent alors : - Nom de valeur (Source of String) ; - Nom interne ((Internal of abstract) ; - Chemin haut-niveau de base de données (External of path) tel que défini préalablement. L'utilisation, en tant que type, du chemin de haut-niveau de la base de données permet d'assurer l'intégration de cette dernière et de toutes les fonctionnalités qui y sont associées, telles que l'historisation. En effet, ce mécanisme permet des constructions telles que : - let [1 /chemin/vers/donnee 1] = valeur in ... - let resultat = calcul [I/chemin/vers/donnee 1] in ...

Ces expressions généralisent de manière simple les besoins d'accès aux données. L'ensemble des calculs (par exemple du filtrage, du tri, ou la conjonction de requêtes) peut être spécifié à l'aide du langage généraliste spécifié. Par exemple, soit un chemin représentant une table d'association entre chaînes de caractères. On note dans le langage val table : string stringmap cette table. Pour filtrer cette association d'association en sélectionnant toutes les clés qui commencent par la lettre 'a', on utilisera : val select = fold (fun x y acc -> if x[O] = 'a' then y :: acc else acc) [1 table 1], que l'on peut écrire avec une syntaxe abrégée : val select = filter [1 table 1] (fun x y -> x[O] = 'a') L'exécution sur un ordinateur de ce code tel quel suppose qu'à l'exécution (et non à la compilation) se produisent les étapes suivantes : - l'ensemble de la table d'association est chargée en mémoire vive, donc transmise du disque dur vers la mémoire vive, via le bus - ces données sont ensuite examinées par le processeur une à une pour savoir QML si elles figurent dans la structure de donnée construite en mémoire vive. Ce schéma est inefficace, car il est plus rapide de ne pas charger l'ensemble de la table en mémoire. Pour cela, il est nécessaire à la compilation de déterminer que seules les valeurs vérifiant le filtre soit chargées du disque dur vers la mémoire vive. L'invention introduit donc un mécanisme complexe et innovant, exploitant les algèbres réduites pour déterminer à quel niveau le filtre doit être effectué. Le code précédent est alors traduit de telle manière que les étapes suivantes se produisent à l'exécution : - l'ensemble des données est parcouru sur disque dur, de manière à sélectionner une à une celles qui vérifient le crible, et seules celles-ci sont stockées en mémoire ; les autres transitant de manière temporaire ; - la structure construite est exploitée par la suite du programme. Le mécanisme précédent est alors étendu pour construire les index automatiquement, de manière à accélérer le filtrage et le tri des données. L'invention est ingénieuse car elle permet de spécifier naturellement l'utilisation des données sans avoir à se préoccuper de la manière dont les données transitent à l'exécution d'un programme sur un ordinateur entre la mémoire vive et le disque dur. Or, ces transferts par le bus sont longs.

Pour chaque type de traitement pouvant être automatisé, on produit à la compilation un mécanisme de construction automatique d'index. Dans l'exemple précédent, on construira automatiquement un index contenant toutes les entrées de ladite association dont la clé commence par la lettre 'a'. A l'exécution, on appellera les mécanismes de construction automatiques précédents si les opérations de filtrage ou de tri sont fréquemment appelées. Pour cela, on introduira un compteur des appels aux données filtrées ou triées. Dès que ce compteur dépasse une valeur prédéfinie, on construira et conservera l'index correspondant. Dans l'optique d'une extension à un système comprenant plusieurs serveurs redondants ou coopérants, les inventeurs ont ajouté une information sur la source des données sous forme d'une liste de machines associée aux chemins. L'invention apporte donc une solution au problème des applications distribuées. L'homme du métier comprendra aisément, à la lecture de la description précédente que l'écriture de l'ensemble base de données et langage pose un problème d'initialisation, car il s'agit bien de concevoir un langage de programmation qui se base lui-même sur un langage de programmation du même type. Il s'agit donc d'un problème similaire à celui de l'oeuf ou de la poule. Les inventeurs ont résolu ce problème grâce à la mise en oeuvre de la succession des étapes suivantes : 1. Définition du langage PML, tel que présenté préalablement et implantation d'un parseur et d'un vérifieur de types pour ce langage ; 2. Définition d'une interface donnée du langage pour l'interface à la base de données, sous la forme d'un module ; 3. Application du foncteur de base de données avec le module défini à l'étape 2 pour obtenir une base de données pouvant stocker des expressions ; 4. Utilisation du foncteur de base de données de l'étape 3 pour écrire un compilateur du langage vers un langage existant (par exemple OCaml ou C) et/ou un interprète. Le produit final de cette phase est donc, selon ce mode de réalisation de l'invention, un langage de programmation de haut niveau QML capable de traiter de façon transparente des données persistantes et de créer automatiquement, et sans intervention de l'utilisateur, des bases de données relatives aux données manipulées par l'utilisateur dans son programme et qui seront gérées automatiquement par les programmes créés à l'aide du langage de programmation. L'invention comprend également des mécanismes permettant une utilisation de grammaire de description de langage (par exemple le langage QML) et l'intégration, au sein de ce langage et à l'aide de ces grammaires, de modules spécifiques dédiés à remplir diverses fonctions, notamment des fonctions qui sont remplies par des programmes écrits dans des langages impératifs ou encore des modules de vérification formelle. De tels modules de vérification permettront, avant même la compilation du programme créé dans le langage QML, d'attester de l'absence d'anomalie au sein de ce programme une fois qu'il sera compilé. Grammaire Les grammaires permettent, selon l'invention, de décrire les langages (par exemple le langage QML) et des les intégrer selon le processus préalablement décrit. Les inventeurs ont ainsi écrit un type de grammaire de la classe des PEG ( parsing expression grammars ) pour écrire des productions en QML. Au sein de cette grammaire, les inventeurs ont ajouté la notion de fonctions de parsing (fonctions d'analyse grammaticales), ce qui permet de factoriser le code, souvent redondant, des grammaires. Un exemple de grammaire, telle qu'obtenue après parsing de sa propre syntaxe est présenté ci-dessous : type definition = { expression : expression debug : bool mark : bool } and expression = sequence list and sequence = item list * (bool * code) option and item = ['AND I 'NOT I 'NORMAL] * primary * [QUESTION I 'STAR I 'PLUS I 'NORMAL] and primary = I Ident of ident I Paren of expression I Literai of string * bool I Class of range list type include_type = Incl I Read type include_def = { it : include_type ; gl : string list } type pre_grammar = { pheader : header list pextra : code_ident list incl : include_def stringmap funs : gfun stringmap defs : definition stringmap } and gfun = { vars : ident list ; expr : expression } and header = [ inside of code normal of code I file of filename

I type grammar = { start : string 10 ; grammar : definition stringmap ; header : header list ; extra : code_ident list } Ces grammaires, tout en étant uniques, présentent l'avantage de pouvoir 15 être compilées vers plusieurs destinations : - vérifieur-coloriseur de syntaxe, qui valident une syntaxe en renvoyant les zones de l'entrées matchées par chaque règle (ceci permet de créer un vérifieur de syntaxe, que les inventeur ont eu l'ingénieuse idée de coupler avec un coloriseur automatique) ; 20 - transducteur, qui analyse et produit du code en sortie (par exemple en QML) en fonction de l'entrée ; vérifieur en JavaScript, qui permet de vérifier des syntaxes du côté du client dans des applications AJAX (Asynchronous JavaScript and XML). Ainsi, une même grammaire peut selon l'invention être utilisée, sans 25 duplication de code, pour remplir plusieurs objectifs. Syntaxes multiples L'utilisation des grammaires définies préalablement permet, selon une première extension, de proposer facilement de multiples syntaxes pour le même langage. Tout programme est en effet stocké en mémoire comme sur le disque de 30 manière persistante sous forme d'un arbre. Si l'on choisit des règles inversibles, un5 parseur permet de passer du code source à l'arbre et, à l'inverse, un pretty pinter permet de passer d'un arbre stocké sur le disque à un code source. L'association à un prettyprinter classique permet alors de proposer un environnement dans lequel plusieurs programmeurs travaillent sur des syntaxes différentes en partageant leur code. Un développeur peut voir le code de l'autre développeur dans la syntaxe qui correspond à ses préférences (indentations, mots-clés, couleurs, ...). Ceci facilite en particulier le travail collaboratif de nombreux développeurs qui ne sont pas nécessairement situés dans le même pays. L'activité précise de chaque développeur peut faire l'objet d'une analyse statistique à des fins de gestion. A titre, d'exemple, voici un tableau qui compare deux syntaxes possibles pour QML : Syntaxe ML Syntaxe Java val f x = x + 1 function f(x) { x + 1 ; } val f x = match x with 1 -> "ok" I function f(x) { select x ; case 1 : "ok" ; _ -> "erreur" default : "erreur" ; } Ce mécanisme permettant l'utilisation conjointe de syntaxes multiples permettra d'offrir une syntaxe proche de PHP pour un programmeur habitué à PHP, une syntaxe proche de Java pour un programmeur plus à l'aise avec Java,... tout en leur permettant d'échanger et de partager du code. Ceci permet d'élargir la cible potentielle du langage. Ce mécanisme permet en outre d'utiliser une syntaxe particulière pour un programme ou une portion de programme de manière à augmenter sa lisibilité, puisqu'en fonction du contenu du programme certaines syntaxes seront naturellement plus expressives.

Syntaxes extensibles Une seconde extension proposée par les inventeurs consiste à intégrer une syntaxe extensible au langage QML. Un tel mécanisme permet d'étendre la syntaxe directement dans le code du programme. Par exemple, le mot-clé syntax décrit une extension de la syntaxe de la définition de valeurs (val) dans laquelle on ajoute un appel paramétré à la fonction ~ log lors de chaque définition de valeurs. val before x = x syntax <val> <ident> <int> <ident>* <equal> <expr> I l VAL ( 2 , 4, Letln ("_", Apply ("jlog", 3 ), 6 ) I l val after 2 x = x Le mot-clé VAL fait partie des mots-clé de l'extension. Il est ainsi possible d'étendre la grammaire pour intégrer des fonctionnalités qui ne sont pas, a priori, supportées dans le langage de programmation d'origine et de permettre ainsi une création d'application complexe d'une manière simple et exempte d'anomalies.

Coloration du code Les inventeurs proposent également un mécanisme permettant de trouver automatiquement des règles de coloration pour une syntaxe définie dans le langage de grammaires. Pour cela, le procédé consiste à : - introduire un mécanisme de calcul d'un nombre unique à partir d'une chaîne de caractères représentant le nom d'une règle ; - de la séparation en trois parties de ce nombre, afin d'associer un nombre à chaque canal de couleur (rouge, vert, bleu) ; - à sélectionner les règles les plus pertinentes, qui ne sont ni trop globales (elles recouvrent tout le texte) ni trop particulières (elles ne manipulent qu'un symbole, ce qui produirait une coloration trop complexe) ; - utiliser un mécanisme pour renforcer la lisibilité des caractères sur un fond uni (par exemple blanc), en introduisant des seuils de luminosité et de contraste vis à vis des autres règles. L'originalité de l'invention consiste ici à permettre la coloration par le parseur exact du langage et non une approximation comme cela est systématiquement le cas dans l'état de l'art. Ainsi, un développeur peut être certain de l'exactitude de la coloration du code, et ne peut être induit en erreur par une coloration différente de celle utilisée par le vrai compilateur du langage. 5.2.3. Construction d'un langage AML dédié au développement d'applications web dynamiques à partir du langage QML. L' invention permet donc d'obtenir un langage de programmation QML qui autorise la création de programmes qui, une fois compilés, présenteront peu ou pas d'anomalies. Selon l'invention, le langage QML, sert de base à la construction d'un nouveau langage de programmation, nommé AML (pour Application Meta Language ). AML est un langage de haut-niveau utilisé au dessus de QML pour développer des applications Internet. La construction d'AML à partir de QML repose sur des techniques déjà citées d'utilisation de modules. AML reprend QML en ajoutant : - une interface automatique avec un serveur Web via une fonction qui retourne une chaîne de caractère (en utilisant le protocole http) suite à une réception d'une requête donnée ; - l'utilisation d'une grammaire pour spécifier les correspondances des urls vers une fonction ; - des fonctions d'internationalisation des chaînes de caractères (les messages) éparpillés dans le code de l'application ; - un mécanisme de réactions à des événements qui décrivent la dynamique de l'application. Selon l'invention, une application est définie comme étant une description d'une statique qui représente l'état initial de l'application, et des réactions qui sont des transformations de cette interface initiale. A tout moment, il est possible de sauvegarder, par exemple dans la base de données, l'état de l'application, ce qui permet de recharger instantanément un programme depuis l'état dans lequel il se trouvait lors de l'enregistrement. Le même ensemble de modifications peut être appliqué : l'interface "vit". Selon l'invention, le code écrit dans le langage est compilé et un exécutable unique est généré. Cet exécutable unique intègre tous les éléments de l'application, y compris des ressources externes. La solution apportée par l'invention est la seule à intégrer cette compilation jusqu'à celle des requêtes d'interrogation de base de données qui sont compilées en langage machine (alors que dans les solutions peu fréquentes de serveurs compilés, le code des requêtes demeure en SQL et est interprété à l'exécution). Cette compilation et cette intégration de tous les éléments au sein de l'application présente des avantages en termes de sécurité : - immunité totale vis à vis des failles de type SQL injection , qui sont aujourd'hui présentes chez de très nombreux serveurs internet; - immunité totale vis-à-vis des attaques de type Buffer Overflow (débordement de pile) ; - immunité vis-à-vis de certaines attaques de type XSiteScripting . Un des intérêts techniques majeurs d'AML apparaît lors du développement d'applications web dynamiques reposant sur la technologie AJAX (Asynchronous JavaScript XML). En effet, le programmeur n'écrit pas une seule ligne de JavaScript et ne se soucie pas des détails techniques de l'implémentation d'AJAX : tout le code JavaScript est généré automatiquement à partir d'AML et il est validé à la compilation. Ainsi le langage AML repose sur un modèle de type EABV : [Evenement > Action > (Base, Vue)]. Selon ce modèle, chaque événement déclenche une action qui elle-même déclenche des modifications atomiques sur la base de donnée d'une part et la vue d'autre part. Le programme est découpé en tranches qui sont exécutées sur le serveur et en tranches qui sont exécutées sur le client. Diverses heuristiques peuvent être utilisées pour optimiser le découpage, par exemple en cherchant à minimiser les durées des échanges entre le client et le serveur. Alternativement, d'autres modèles plus classiques comme le modèle MVC : [Modèle, Vue, Contrôleur] peuvent être utilisés. 5.2.4. Exemple d'application codée en langage AML : un wiki. A titre d'exemple, ci-dessous un programme offrant les fonctionnalités de base d'un wiki et qui ne compte qu'une vingtaine de lignes en AML, sans utilisation de bibliothèque dédiée alors qu'il faut plusieurs centaines lignes de code et de configuration pour créer la même application en utilisant par exemple un système de type [Linux, Apache, PHP, MySQL]. L'exécutable créé à partir du langage AML pèse moins de 300 kilooctets contre dix à cent fois plus avec un système de type [Linux, Apache, PHP, MySQL]. wikis : string stringmap;; counts : int stringmap;; save name content = temp = result <- <img src='wait.gif' />; x = $content.value; c = int_of_string $"countdiv".value; [1 "wikis"/name 1] = x; [1 "counts"/name 1] = c + 1; [ temp; result <- "ok" ];; wiki name = default "this is a new page" [1 "wikis"/name I];; count name = string_of_int (default 0 [1 "counts"/name I]);; button content name = <a href=$save name "contentl"$>savel</a> 1 <a href=$save name "content2"$>save2</a>;; page name = <h1>$name$</h1> <textarea id="contentl">$wiki name$</textarea> <textarea id="content2"></textarea> <div id="countdiv">$count name$</div> <div id="machindiv" class="button">$button content name$</div> <div id="result"/>;; main name = js_page "MLstate wiki :: narre" auto_js (page name);; val urls(normal) {{ "/code.js" {{ (fun r -> match (commoncode r) : pair with { fst ; snd } -> make_response r (((%% Webserve.SC_OK %%) . web_status)) fst snd) }} "/wait.gif" {{ (fun req -> image (((%% Base.File.content %%) : string -> string) "waitl6.gif") req) }} "/" (.+ $_) {{ main 2 }} }};; *normal* = 2009;; On notera plusieurs nouveautés importantes par rapport au code d'applications web existantes. Tout d'abord, pour nommer un élément du DOM (document object model : interface permettant d'accéder au contenu, à la structure et au style du document sur le client, on utilise simplement l'instruction) : $"nom de l'élément" Surtout, l'utilisation d'une base de données est transparente pour le programmeur qui n'a pas à se préoccuper de la création de tables et de relations entre les tables. Le stockage d'une valeur dans la base (sur le serveur) se fait simplement par une instruction du type : [1 "wiki"/name 1] = x; et la lecture d'une valeur stockée dans la base s'écrit sous la forme : [1 "wiki"/name 1] Ainsi, on aboutit à une syntaxe à la fois concise et expressive, sans redondances inutiles et avec des risques réduits d'anomalies. En outre, le programme est analysé statiquement à la compilation. Ceci offre un grand nombre d'avantages : le code HTML généré est validé ; le programmeur n'écrit pas une seule ligne de JavaScript et le JavaScript généré est également validé. en outre, la structure des données dans la base de données est optimisée en fonction du type de requêtes qui sont effectuées. 5.3 Mode de réalisation : environnement de développement intégré (IDE) client/serveur.

Ce mode de réalisation décrit la construction, par le procédé selon l'invention, d'un environnement de développement de programmes informatiques. Cet environnement de développement constitue à la fois un produit du procédé selon l'invention et un outil permettant la mise en oeuvre du procédé selon l'invention.

Un environnement de développement est développé sous la forme de client/serveur. Ainsi, un même serveur d'environnement de développement peut servir plusieurs utilisateurs. Le client que nous avons implanté est un client Eclipse. Les fonctionnalités gérées par le serveur sont : - la coloration du code, faisant notamment intervenir la méthode détaillée en section 5.2.2. Les grammaires utilisées pour les langages sources sont incrémentales. De ce fait, seules les portions du code qu'il est vraiment nécessaire de parser le sont. Une des particularités rendue possible par l'invention est d'utiliser la même grammaire pour l'écriture de l'ensemble de la chaîne. En particulier, la grammaire du coloriseur est la même que celle du compilateur. Il n'y a plus de code en double et surtout d'inexactitude entre la coloration et l'interprétation du code par le compilateur comme cela est généralement le cas aujourd'hui ; - la détection de l'ensemble des types, des fonctions dans une liste des éléments ; - le typage de manière incrémentale et en temps réel du code. C'est la première fois, grâce à l'invention, qu'un système de typage statique fort est associé à un vérifieur de code incrémentai, pour : - ne pas avoir à spécifier les types manuellement ; - les inférer de manière statique ; - calculer la cohérence des types manuellement sur l'ensemble du programme. Les actions des développeurs peuvent ainsi être, au travers du serveur, communiquées aux développeurs concernés par les modifications en cours.

De plus, le serveur se charge de manière transparente pour les développeurs de l'historique des versions, en stockant le code dans la base de données définie préalablement, et donc gérant de manière automatique l'historisation du code. Enfin, en couplant le serveur d'environnement de développement et la méthode proposée en section 5.2.2, des développeurs peuvent (à condition de détenir des droits d'accès suffisants) consulter des parties du code d'autres développeurs avec leur syntaxe propre. Enfin, grâce aux mécanismes de persistance et d'historisation apportée par la base de données fonctionnelle, l'environnement de développement permet de visualiser les modifications qui sont apportées aux codes sources des programmes.

En effet, selon l'invention toutes les données sont historisées au sein de la base. Or un code source est un ensemble de données (les mots du code source) qui fait également l'objet d'une historisation. Il est donc possible de suivre l'évolution du code source selon l'invention sous la forme d'un graphe, par exemple. Ainsi, l'invention permet de tracer les différentes versions des codes sources des programmes mais également, et ceci est totalement inédit, de définir en fonction des changements apportés au code source, des mécanismes de suivi des données qui sont comprises dans la base de données. A titre d'exemple, imaginons une première version d'une application dont le code source définit un utilisateur comme étant un objet comprenant un nom et un prénom. Cette première version de l'application est utilisée et de nombreux utilisateurs sont insérés dans la base de données interne de l'application. Dans un deuxième temps, une modification de la notion d'utilisateur intervient et il est décidé que l'utilisateur comprendra également une donnée date de naissance. Selon l'art antérieur, pour ne pas perdre les données qui ont été insérées dans la base avec la première version de l'application, il aurait été nécessaire de prévoir une migration de la base de données. Avec le mécanisme d'historisation de la base de données et le suivi de la modification du code source au sein de l'environnement de développement, l'invention permet de ne pas avoir à modifier la base de données. En effet, au moment de la compilation du nouveau programme intégrant la donnée date de naissance, le compilateur saura que préalablement, l'utilisateur ne comprenait que deux types de données et sera capable de lire la base de données en conséquence. Ceci mécanisme renforce considérablement le caractère agile du développement d'applications. 5.4 Mode de réalisation : langage de spécification SL Afin de simplifier encore davantage la programmation d'applications, le procédé selon l'invention intègre la construction d'un langage de spécifications, appelé SL. Ce langage de spécification est construit à partir d'un langage de haut niveau de type AML ou QML et il est caractérisé en ce qu'il ne présente pas de caractère fonctionnel. Le langage SL traduit de manière naturelle les spécifications de l'application, notamment la définition des types, la définition de valeurs instanciant ces types et stockées dans la base de données, les règles de vérification de ces données dans le cas où elles sont saisies par un utilisateur, ... Le langage SL traduit également la définition des données présentes sur des écrans , sous-écrans ou interfaces diverses ainsi que la navigation entre ces différents éléments. Les traitements effectués sur les données peuvent ne pas être précisés et, de préférence, ils ne le sont pas. Ainsi le langage SL tel que construit par le procédé selon l'invention permet à un utilisateur n'ayant pas de connaissances particulières en programmation de spécifier de manière naturelle et transparente, sous forme d'un cahier des charges, les caractéristiques (spécifications) de l'application web qui répond à ses besoins et à ses contraintes. La construction de ce langage SL repose sur l'utilisation de types enregistrement qui sont : - des chaînes de caractères ; - des chaînes de caractères avec garde : - des listes ; - des options ; - des chemins ; - des n-uplets.

Une application écrite en langage SL est générée automatiquement par le procédé selon l'invention suivant la cascade : SL -> AML -> QML -> PML, la flèche -> indiquant ici compilation vers . SL est construit en éliminant les valeurs fonctionnelles qui traduisent les calculs de AML et SL note de manière compacte la définition des types comme la définition des valeurs. Par exemple, identifiant : login, password ; se traduit en AML en - un type: type identifiant = { login : string ; password : string j - une définition de données persistantes : val identifiant identifiant intmap qui représente l'équivalent en fonctionnel : - de la définition (par exemple SQL) d'une table - de la définition d'une variable (par exemple de PHP) qui permet d'utiliser cette table - du liant (implicite en AML) entre les deux SL est construit en supprimant de l'information lors de la spécification d'AML; SL constitue ainsi un sous-ensemble fonctionnel de AML. Les 20 informations manquantes peuvent être de deux natures : - non inférées - inférées selon un mécanisme de compilation connu de l'homme du métier. - certaines tables créent automatiquement des valeurs val identifiant : 25 identifiant intmap - d'autres tables créent des pointeurs sur les valeurs (pas de val) Suivant un mécanisme du même type, SL prend en compte les liens (usuellement les relations entre tables), de manière la plus transparente possible pour l'utilisateur, qui n'a pas à s'occuper des détails de l'implémentation. 30 Le fichier en langage SL est d'abord validé en utilisant une grammaire puis, au cas où la validation réussit, il est compilé en AML puis en QML et enfin en PML. 5.5 Mode de réalisation : parseur XML Un parseur est un programme d'ordinateur (ou un dispositif électronique) qui prend en entrée une chaîne de caractères (un signal) et qui fournit en sortie d'une part une réponse booléenne quant à la validité de cette chaîne de caractères par rapport à un ensemble de règles et d'autre part, si la réponse booléenne est VRAI (chaîne valide), une structure de donnée (généralement un arbre de syntaxe abstraite) représentant la chaîne de caractères.

Un parseur XML (de l'anglais eXtensible Markup Language ) prend donc en entrée une chaîne de caractère, vérifie qu'il s'agit de XML correct (c'est à dire si la chaîne de caractères est conforme à l'ensemble de règles qui constitue la spécification XML) et, le cas échéant construit l'arbre de syntaxe abstraite correspondant.

Il est important d'avoir un parseur correct, c'est à dire un parseur qui vérifie correctement la validité de n'importe quelle chaîne de caractères XML. C'est notamment le cas dans le cadre de dispositifs de type diodes numériques qui sont placés à l'entrée d'autres dispositifs et qui servent à vérifier que les données fournies à ces seconds dispositifs sont conformes à la norme XML, afin d'éviter des anomalies dans le fonctionnement de ces derniers. Dans un mode de réalisation préféré d'une telle diode numérique (logicielle ou électronique), en sortie du parseur est placée l'entrée d'un filtre numérique, qui est un autre élément permettant de vérifier la validité de la structure de donnée fournie par le parseur par rapport à d'autres règles métier. Ces règles métier sont des règles spécifiques aux clients, qui sont différentes des règles du parseur. Le parseur ayant notamment pour fonction de vérifier la validité d'une entrée, il est essentiel que ce programme lui-même soit valide, et donc qu'il ne présente pas d'anomalies. La seule façon de vérifier formellement la validité d'un parseur et donc de garantir son fonctionnement correct quelle que soit la chaîne de caractères qui lui est fournie en entrée, est de construire un parseur prouvable. Le caractère prouvable offre la possibilité d'une garantie de correction par l'utilisation d'une preuve formelle. Le problème est que la preuve est difficile à obtenir. Pour faciliter l'obtention d'une preuve, le procédé selon l'invention fait donc appel à un code le plus concis possible. Le procédé de construction du parseur est illustré à la figure 4. Chacun des éléments utilisé est prouvable et le parseur fait notamment appel à une grammaire de grammaire ainsi qu'à une représentation intermédiaire du XML notée XMLint. Plus précisément, partant d'une grammaire (G1) exprimant la sémantique de la structure des données XMLint, on construit, par le biais d'une grammaire (GO) de cette grammaire G1, via un parseur GO-> PML (P0) et un compilateur GO -> PML (Cl), un parseur XML->XMLint (P1) admettant pour entrée une chaîne de caractères XML et produisant en sortie une structure de données XMLint. De préférence, XMLint utilise un modèle de pile (stack), mais d'autres représentations sont possibles. L'intérêt de l'utilisation de XMLint est de simplifier les calculs par rapport à des calculs qui seraient effectués sur les mêmes données exprimées sous forme de graphe XML. Un nouveau compilateur C2 (XMLint -> XML) permet finalement d'une part de valider ou non la chaîne de caractère initiale et d'autre part, le cas échéant, de construire un arbre de syntaxe abstraite XML à partir de la représentation en XMLint. On notera que dans ce mode de réalisation, d'une part un nombre de lignes de code très réduit est nécessaire et d'autre part le langage utilisé est à algèbre réduite. Ainsi on réduit à la fois la longueur et la largeur des arbres sous-jacents qui représentent le programme et c'est cette double réduction qui permet de faciliter l'obtention d'une preuve. Tous les composants utilisés sont prouvables et ce parseur lui-même est donc prouvable. La preuve a lieu par les méthodes classiques de l'analyse statique. Le procédé selon l'invention permet ainsi la construction d'un parseur XML prouvable. Avec des adaptations évidentes pour l'homme de métier, le même procédé permet de construire d'autres parseurs, et notamment, sans que cette liste puisse être considérée comme exhaustive : un parseur IP, un parseur HTTP, XHTML .... Chacun de ces parseurs peut également être associés à des filtres numériques afin d'obtenir des dispositifs de type diodes numériques prouvables (logicielles ou électroniques). Dans un autre mode de réalisation, la structure de données (par exemple, l'arbre de syntaxe abstraite) générée par le parseur est utilisé comme un intermédiaire qui associé avec un compilateur au sein d'un dispositif permet de convertir la chaîne de caractère à l'entrée du dispositif en une autre chaîne de caractère à la sortie. Dans ce mode de réalisation, le procédé selon l'invention peut ainsi par exemple prendre en entrée une chaîne de caractères en XML, la valider et la convertir en graphe XML et la récrire pour permettre une lecture par un dispositif qui n'accepte pas directement en entrée du XML standard (par exemple un dispositif mobile), ou encore pour permettre une représentation visuelle qui est commode pour un utilisateur humain. 5.6 Composants électroniques programmables L'invention apporte une réponse nouvelle et inventive aux problèmes d'anomalies dans les composants électroniques programmables. En effet, de tels composants, qui sont utilisés dans tous les domaines qui vont de l'électronique grand public à l'aviation ou à la production, sont généralement testés postérieurement à leur programmation, pour s'assurer que les fonctionnalités qui y sont implantées seront correctement réalisées. De nombreuses méthodes de test de ces composants sont connues de l'homme du métier et elles permettent généralement d'identifier des bugs qui peuvent être liés à des problèmes fonctionnels, mais pas à des problèmes liés au langage de programmation utilisés à l'origine. L'invention pallie cet inconvénient en fournissant un langage dont les microprogrammes peuvent être prouvés et donc qui assurent qu'au moins les microprogrammes insérés dans les composants ne contiennent pas l'anomalie liée au langage. Les microprogrammes obtenus à l'aide d'un dispositif qui comprend des moyens de mise en oeuvre du procédé de l'invention sont notamment insérés dans des composants de type FPGA

Claims (14)

1. REVENDICATIONS1. Procédé de création d'un programme informatique écrit dans un langage de programmation de haut niveau, caractérisé en ce qu'il comprend : une phase préalable à l'écriture dudit programme dans ledit langage de 5 programmation de haut niveau comprenant : une étape de construction d'un langage de base fonctionnel, à algèbre réduite, sans opérations de réaffectation, dit langage PML ; une étape d'écriture d'au moins une bibliothèque dans un langage préexistant puis, à partir de ladite au moins une bibliothèque, 10 une étape de construction d'interfaces fonctionnelles à partir de fonctionnalités impératives lesquelles appartiennent au groupe comprenant au moins : - le stockage pérenne d'information sur un support, l'envoi et la réception de paquets sur un réseau, 15 - l'analyse d'un flux de données ; une étape de construction d'un langage de haut niveau par liaison des dites interfaces dans des fonctions du langage PML, - une phase de création dudit programme informatique à partir du langage de haut niveau comprenant une étape de compilation. 20
2. 2. Procédé de création selon la revendication 1, caractérisé en ce que ladite phase de création dudit programme informatique comprend en outre une étape d'intégration, au sein d'un composant électronique ou informatique, dudit programme informatique créé.
3. 3. Procédé de création selon l'une quelconque des revendications 1 et 2, 25 caractérisé en ce que ledit programme informatique écrit dans un langage de programmation de haut niveau est un parleur XML et en ce que ladite fonctionnalité impérative d'analyse d'un flux de données est une fonctionnalité d'analyse et de vérification d'un fichier XML.
4. 4. Procédé de création selon l'une quelconque des revendications 1 à 3 30 caractérisé en ce qu'il comprend un ensemble de primitives despécification d'accès aux données d'une base de données au sein du langage de haut-niveau, permettant ledit stockage pérenne d'information sur un support sans qu'une application tierce partie de gestion de base de données ne soit nécessaire.
5. 5. Procédé selon la revendication 4. caractérisé en ce que des données, structures de données et états de l'application dudit programme informatique sont rendus persistants par l'utilisation d'au moins une structure de données qui a la même représentation en mémoire vive et sur un dispositif de stockage de masse.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5 caractérisé en ce que ladite phase de création dudit programme informatique comprend en outre une étape d'analyse statique du code source dudit programme informatique préalablement à sa compilation de sorte que ledit programme informatique obtenu est optimisé et/ou prouvé formellement.
7. 7. Procédé selon l'une quelconque des revendications 4 à 6 caractérisé en ce qu'à la compilation le programme détermine automatiquement quels indexes générer afin de répondre aux requêtes implicites sur la base de données.
8. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que lesdites bibliothèques permettent d'implémenter des fonctionnalités absentes dudit langage PML et en ce que l'utilisation de ladite au moins une bibliothèque par ledit programme informatique permet de conserver des propriétés dudit langage PML, telles que les caractéristiques appartennant au groupe comprenant au moins : - le caractère fonctionnel dudit langage ; le caractère prouvable dudit langage ; la persistance des données manipulées.
9. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'au moins une desdites bibliothèques permet de traiter des échanges réseau en intégrant au moins deux primitives de lecture et d'écriture dedonnées sur des ports de communication et où ledit programme informatique produit est une application de type service web.
10. 10. Procédé selon la revendication 9 caractérisé en ce qu'un binaire unique est compilé à partir d'un seul langage source et en ce que ce binaire unique compilé génère du code HTML, CSS et JavaScript ainsi que des requêtes compilées d'accès aux données.
11. 11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend en outre une étape de construction d'un langage de spécifications ne présentant pas de caractéristiques fonctionnelles et en ce que les programmes codés dans ce langage sont compilés vers ledit langage de haut niveau.
12. 12. Dispositif de création d'un programme informatique écrit dans un langage de programmation de haut niveau, caractérisé en ce qu'il comprend : - des moyens de création dudit langage de haut niveau comprenant : des moyens de construction d'un langage de base fonctionnel, à algèbre réduite, sans opérations de réaffectation, dit langage PML ; des moyens d'écriture d'au moins une bibliothèque dans un langage préexistant puis, à partir de ladite au moins une bibliothèque, des moyens de construction d'interfaces fonctionnelles à partir de fonctionnalités impératives lesquelles appartiennent au groupe comprenant au moins : le stockage pérenne d'information sur un support, l'envoi et la réception de paquets sur un réseau, l'analyse d'un flux de données ; - des moyens de construction d'un langage de haut niveau par liaison des dites interfaces dans des fonctions du langage PML, des moyens de création dudit programme informatique à partir du langage de haut niveau comprenant une étape de compilation.
13. 13. Dispositif selon la revendication 12, caractérisé en ce qu'il comprend en outre des moyens d'intégration, au sein d'un composant électronique ouinformatique, dudit programme informatique de haut niveau créé et des moyens d'association d'une sortie de ce composant électronique à un composant de type filtre ou convertisseur.
14. 14. Dispositif selon l'une quelconque des revendications 12 et 13 caractérisé en ce que ledit programme informatique est implémenté au sein d'un composant électronique, tel qu'un composant électronique programmable de type FPGA.