FR3107608A1 - Dispositif electronique et procede de generation d'au moins un code informatique, programme d'ordinateur associe - Google Patents
Dispositif electronique et procede de generation d'au moins un code informatique, programme d'ordinateur associe Download PDFInfo
- Publication number
- FR3107608A1 FR3107608A1 FR2001871A FR2001871A FR3107608A1 FR 3107608 A1 FR3107608 A1 FR 3107608A1 FR 2001871 A FR2001871 A FR 2001871A FR 2001871 A FR2001871 A FR 2001871A FR 3107608 A1 FR3107608 A1 FR 3107608A1
- Authority
- FR
- France
- Prior art keywords
- generic
- processing
- code
- component
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 28
- 238000004590 computer program Methods 0.000 title claims abstract description 7
- 230000008569 process Effects 0.000 title abstract description 13
- 238000012545 processing Methods 0.000 claims abstract description 127
- 230000004913 activation Effects 0.000 claims abstract description 50
- 230000009471 action Effects 0.000 claims description 27
- 238000006243 chemical reaction Methods 0.000 claims description 21
- 230000008859 change Effects 0.000 claims description 7
- 238000001994 activation Methods 0.000 description 42
- 238000004088 simulation Methods 0.000 description 21
- 230000000295 complement effect Effects 0.000 description 9
- 238000003058 natural language processing Methods 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 2
- 125000004122 cyclic group Chemical group 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000000638 solvent extraction Methods 0.000 description 2
- 241000726425 Circe Species 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
Dispositif électronique et procédé de génération d’au moins un code informatique, programme d’ordinateur associé Ce dispositif électronique (10) de génération d’un code informatique (26, 30) comprend: - un module (20) de création d’une spécification formalisée (22) comportant des chapitres de composant (50), décomposés en section(s) de traitement (52) comportant une suite d’exigence(s) (54) et un ordre de mise en œuvre de ladite suite, - un module (24) de génération d’un code générique (26) à partir de la spécification formalisée (22), destiné à simuler un fonctionnement ou être converti en un code source (30) compilable ; le code générique comportant des composants génériques (60), décomposés en traitement(s) génériques (62) comportant une suite de tâche(s) générique(s) (64) ; chaque composant, traitement et tâche génériques étant associés respectivement à un chapitre de composant, à une section de traitement et à une exigence ; et à chaque tâche étant associé un ordre d’activation fonction de l’ordre de mise en œuvre pour la section de traitement associée. Figure pour l'abrégé : Figure 2
Description
La présente invention concerne un dispositif électronique de génération d’au moins un code informatique, pour la mise en œuvre d’une application logicielle apte à être exécutée par une plateforme électronique d’exécution.
L’invention concerne également un procédé de génération d’au moins un code informatique, le procédé étant mis en œuvre par un tel dispositif électronique de génération.
L’invention concerne également un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un tel procédé de génération.
L’invention concerne alors le domaine de la génération au moins partiellement automatique d’au moins un code informatique, pour la mise en œuvre d’une application logicielle, en particulier une application logicielle temps-réel, embarquée ou non.
L’application logicielle est décomposée en plusieurs composants et s’interface, via une ou plusieurs interfaces, chacune numérique ou physique, à des équipements réels. Elle permet alors de gérer l’ensemble des interfaces des composants et des équipements pour mettre en œuvre l’ensemble d’un système.
Les traitements principaux de telles applications logicielles sont de synthétiser l’ensemble des valeurs issues des composants du système ou d’un système de système, ainsi que l’ensemble des commandes reçues par celui-ci, interne ou depuis un réseau extérieur, afin de pouvoir élaborer des informations, telles que des états et des pannes, à destination d’un opérateur; piloter les commandes et réponses vers des équipements; et piloter la diffusion d’informations à d’autres systèmes externes, sur des réseaux informatiques de type L16, Internet, ou encore SATCOM.
De manière connue, l’approche la plus courante pour spécifier un logiciel consiste à synthétiser dans un document une liste d’exigences textuelles de niveau LLR (de l’anglaisLow-Level Requirement) décrivant l’intégralité du comportement attendu de l’application logicielle.
Aujourd’hui, les solutions les plus répandues pour rédiger ce type de document sont, d’une part, les éditeurs de texte, et d’autre part, les éditeurs d’exigences. Les éditeurs de texte n’offrent aucune fonction de vérification des propriétés des exigences et sont couplés à des outils externes pour assurer la traçabilité des exigences dans le reste du processus. Les éditeurs d’exigences, comme DOORS, répondent au besoin de gestion de configuration, de gestion de la traçabilité entre modules (liens), de caractérisation des exigences (attributs), mais n’offre en revanche aucune aide à la rédaction des exigences.
Depuis quelques années, des approches utilisant un langage dédié, ou DSL (de l’anglaisDomain Specific Langage), ont émergées. Un langage dédié est un langage de programmation, remplissant généralement aussi le rôle de langage de spécification, spécialement conçu pour répondre aux contraintes d’un domaine d'application précis.
Par ailleurs, des articles, tels que «Automatic Requirements Specification Extraction from Natural Language» de S. Ghosh, «On the Systematic Analysis of Natural Language Requirements with CIRCE» de V. Ambriola et«Requirement Specifications using Natural Languages» de T. Bures, font part de recherches sur l’utilisation d’algorithmes NLP (de l’anglaisNatural Language Processing) afin d’étudier des exigences relatives à une application logicielle et de les analyser. Ces technologies sont basées sur des algorithmes d’intelligence artificielle à base d’apprentissage, pour faire une identification des éléments des phrases, souvent complétés par des ontologies permettant de faire des déductions possibles sur les exigences.
Cependant, de tels outils ne sont pas toujours pratiques pour spécifier, puis générer facilement un code de l’application logicielle en particulier pour une application logicielle temps-réel devant être certifiée et pour laquelle le comportement doit alors être prédictible.
Le but de l’invention est alors de proposer un dispositif électronique, et un procédé associé, permettant de générer plus facilement au moins un code informatique, pour la mise en œuvre d’une application logicielle, en particulier une application logicielle temps-réel devant être certifiée.
A cet effet, l’invention a pour objet un dispositif électronique de génération d’au moins un code informatique, pour la mise en œuvre d’une application logicielle apte à être exécutée par une plateforme électronique d’exécution, le dispositif comprenant:
- un module de création configuré pour créer une spécification formalisée de l’application logicielle, la spécification formalisée comportant un ensemble de chapitres de composant, chaque chapitre de composant étant décomposé en une ou plusieurs sections de traitement, chaque section de traitement comportant une suite d’exigence(s) à mettre en œuvre et un ordre de mise en œuvre de la suite d’exigence(s),
- un module de génération configuré pour générer un code générique à partir de la spécification formalisée créée, le code générique étant destiné à simuler un fonctionnement de l’application logicielle ou à être converti en un code source compilable en un code exécutable de ladite application logicielle; le code générique comportant un ensemble de composants génériques, chaque composant générique étant décomposé en un ou plusieurs traitements génériques, chaque traitement générique comportant une suite de tâche(s) générique(s); chaque composant générique étant associé à un chapitre de composant respectif, chaque traitement générique étant associé à une section de traitement respective et chaque tâche générique étant associée à une exigence respective; et à chaque tâche générique étant associé un ordre d’activation de ladite tâche au sein du traitement générique, en fonction de l’ordre de mise en œuvre de la suite d’exigence(s) pour la section de traitement associée.
Suivant d’autres aspects avantageux de l’invention, le dispositif électronique de génération comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles:
- le module de génération est en outre configuré pour associer, à chaque composant générique, un ordre de déroulement suivant lequel doit être exécutée chaque tâche générique dudit composant, lors de chaque activation dudit composant;
- pour chaque traitement générique, la suite de tâche(s) générique(s) est non-fragmentable, la ou les tâches génériques de ladite suite étant aptes, à chaque activation dudit traitement, à être mises en œuvre successivement et sans scission entre deux tâches génériques successives;
au moins un traitement générique comportant de préférence en outre une condition d’activation, l’activation dudit traitement étant alors effectuée seulement si la condition d’activation est vérifiée;
- chaque composant générique comporte en outre un ensemble de données aptes à être lues et/ou élaborées par le composant respectif, un ensemble de constantes utilisées par le composant respectif, et un ensemble de types de données utilisées par le composant respectif;
- chaque traitement générique comporte en outre une liste de données aptes à être élaborées par le traitement respectif, une liste de données à sauvegarder à la fin de la mise en œuvre du traitement respectif et une description d’actions à effectuer sur reprise du traitement respectif;
une donnée respective étant de préférence apte à être élaborée par un unique traitement générique;
la liste de données étant de préférence apte à être initialisée à chaque activation du traitement générique respectif;
- le code générique comporte en outre une bibliothèque de types,
chaque type étant de préférence choisi parmi le groupe consistant en: un type entier, un type réel, un type booléen, un type énuméré, un type tableau, un type liste, un type structure, un type chaîne de caractères, un type évènement, un type requête, un type temporisation;
- le code générique comporte en outre une bibliothèque (68) de données aptes à être utilisées par des traitements génériques, chaque donnée étant d’un type choisi parmi la bibliothèque de types;
- le module de génération comporte un convertisseur apte à convertir la spécification formalisée en ledit code générique à partir d’une grammaire formelle prédéfinie;
la grammaire formelle étant de préférence une grammaire DSL;
le code générique étant de préférence au format XML ou au format JSON;
- le convertisseur comporte en outre un lot de service(s) prédéfini(s), chacun étant associé à un type respectif, chaque service étant une suite d’opération(s) pour ledit type;
le lot de service(s) incluant de préférence au moins un service, de préférence encore plusieurs services, et de préférence encore chacun des services, choisi(s) parmi le groupe consistant en: un service de vérification d’un état d’une temporisation, un service de démarrage d’une temporisation, un service d’arrêt d’une temporisation, un service de répétition d’action(s), un service d’affectation circulaire, un service d’affectation temporaire, un service de chronométrage, un service d’attente pour retarder le démarrage d’un traitement, et un service de détection d’un évènement, tel qu’un changement de valeur; et
- le dispositif comprend en outre un module de conversion configuré pour convertir le code générique en au moins un code source établi selon un langage informatique prédéfini;
le module de conversion étant de préférence configuré pour convertir le code générique en plusieurs codes source distincts, chacun étant établi selon un langage informatique respectif;
le langage informatique étant de préférence choisi parmi le groupe consistant en: C++, ADA, JAVA;
le code source étant de préférence établi en outre selon la plateforme électronique d’exécution.
L’invention a également pour objet un procédé de génération d’au moins un code informatique, pour la mise en œuvre d’une application logicielle apte à être exécutée par une plateforme électronique d’exécution, le procédé étant mis en œuvre par un dispositif électronique de génération et comprenant les étapes suivantes:
- la création d’une spécification formalisée de l’application logicielle, la spécification formalisée comportant un ensemble de chapitres de composant, chaque chapitre de composant étant décomposé en une ou plusieurs sections de traitement, chaque section de traitement comportant une suite d’exigence(s) à mettre en œuvre et un ordre de mise en œuvre de la suite d’exigence(s),
- la génération d’un code générique à partir de la spécification formalisée créée, le code générique étant destiné à simuler un fonctionnement de l’application logicielle ou à être converti en un code source compilable en un code exécutable de ladite application logicielle; le code générique comportant un ensemble de composants génériques, chaque composant générique étant décomposé en un ou plusieurs traitements génériques, chaque traitement générique comportant une suite de tâche(s) générique(s); chaque composant générique étant associé à un chapitre de composant respectif, chaque traitement générique étant associé à une section de traitement respective et chaque tâche générique étant associée à une exigence respective; et à chaque tâche générique étant associé un ordre d’activation de ladite tâche au sein du traitement générique, en fonction de l’ordre de mise en œuvre de la suite d’exigence(s) pour la section de traitement associée.
L’invention a également pour objet un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé de génération, tel que défini ci-dessus.
Ces caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels:
Sur la figure 1, un dispositif électronique de génération 10 est connecté à un écran d’affichage 12, ainsi qu’en complément facultatif à une base de données informatiques 14. Le dispositif électronique de génération 10 est alors configuré pour générer au moins un code informatique, pour la mise en œuvre d’une application logicielle apte à être exécutée par une plateforme électronique d’exécution, non représentée. La plateforme électronique d’exécution est typiquement une plateforme configurée pour être embarquée à bord d’un véhicule, tel qu’un aéronef.
Le dispositif électronique de génération 10 comprend un module 20 de création d’une spécification formalisée 22 de l’application logicielle et un module 24 de génération d’un code générique 26 à partir de la spécification formalisée 22 créée, comme représenté sur la figure 2.
En complément facultatif, le dispositif électronique de génération 10 comprend un module 28 de conversion du code générique 26 en au moins un code source 30 établi selon un langage informatique prédéfini, visible sur la figure 2.
En complément facultatif encore ou en variante, le dispositif électronique de génération 10 comprend en outre un module 32 de simulation d’un fonctionnement de l’application logicielle, à partir du code générique 26, le module de simulation 32 étant apte à générer un fichier 34 de résultat de la simulation de l’application logicielle, visible sur la figure 2.
En complément facultatif encore, le dispositif électronique de génération 10 comprend en outre un module 36 d’affichage d’informations relatives à la génération du ou des codes informatiques 26, 30.
L’homme du métier comprendra alors que, par code informatique, on entend le code générique 26 généré par le dispositif de génération 10, et en particulier par le module de génération 24, ou bien un code source 30 respectif généré également par le dispositif de génération 10, et en particulier par le module de conversion 28 à partir du code générique 26.
L’écran d’affichage 12 permet l’affichage d’informations relatives à la génération du code informatique 26, 30, telles que des informations relatives à la spécification formalisée 22 servant à la génération ultérieure du code générique 26 et/ou d’informations relatives aux codes informatiques 26, 30 eux-mêmes.
La base de données informatiques 14 contient par exemple des bibliothèques logicielles, telles que des bibliothèques pour chacun de langages informatiques prédéfinis associés aux codes source 30, le module de conversion 28 étant alors typiquement relié à ladite base de données informatiques 14.
Dans l’exemple de la figure 1, le dispositif électronique de génération 10 comprend une unité de traitement d’informations 40 formée par exemple d’une mémoire 42 et d’un processeur 44 associé à la mémoire 42.
Dans l’exemple de la figure 1, le module de création 20 et le module de génération 24, ainsi qu’en complément facultatif le module de conversion 28, le module de simulation 32 et le module d’affichage 36, sont réalisés chacun sous forme d’un logiciel ou d’une brique logicielle exécutable par le processeur 44. La mémoire 42 du dispositif de génération 10 est alors apte à stocker un logiciel de création de la spécification formalisée 22 et un logiciel de génération du code générique 26 à partir de la spécification formalisée 22 créée. En complément facultatif, la mémoire 42 du dispositif de génération 10 est apte à stocker un logiciel de conversion du code générique 26 en au moins un code source 30 respectif, un logiciel de simulation du fonctionnement de l’application logicielle à partir du code générique 26 généré, et un logiciel d’affichage d’informations relatives au code informatique 26, 30 généré. Le processeur 44 du dispositif de génération 10 est alors apte à exécuter chacun des logiciels parmi le logiciel de création et le logiciel de génération, ainsi qu’en complément facultatif le logiciel de conversion, le logiciel de simulation et le logiciel d’affichage.
En variante non représentée, le module de création 20 et le module de génération 24, ainsi qu’en complément facultatif le module de conversion 28, le module de simulation 32 et le module d’affichage 36, sont réalisés chacun sous forme d’un composant logique programmable, tel qu’un FPGA (de l’anglaisField Programmable Gate Array), ou encore d’un circuit intégré, tel qu’un ASIC (de l’anglaisApplication Specific Integrated Circuit).
Lorsque le dispositif de génération 10 est réalisé sous forme d’un ou plusieurs logiciels, c’est-à-dire sous forme d’un programme d’ordinateur, il est en outre apte à être enregistré sur un support, non représenté, lisible par ordinateur. Le support lisible par ordinateur est par exemple, un medium apte à mémoriser des instructions électroniques et à être couplé à un bus d’un système informatique. A titre d’exemple, le support lisible est un disque optique, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, tout type de mémoire non-volatile (par exemple EPROM, EEPROM, FLASH, NVRAM), une carte magnétique ou une carte optique. Sur le support visible est alors mémorisé un programme d’ordinateur comprenant des instructions logicielles.
Le module de création 20 est configuré pour créer la spécification formalisée 22 de l’application logicielle, la spécification formalisée 22 comportant un ensemble de chapitre(s) de composant 50, chaque chapitre de composant 50 étant décomposé en une ou plusieurs sections de traitement 52, chaque section de traitement 52 comportant une suite d’exigence(s) 54 à mettre en œuvre et un ordre de mise en œuvre de la suite d’exigence(s) 54, comme représenté sur la figure 2.
Comme cela sera décrit plus en détail par la suite, le module de génération 24 comporte un convertisseur 56, apte à convertir la spécification formalisée 22 en ledit code générique 26 à partir d’une grammaire formelle prédéfinie, et la spécification formalisée 22 est alors en forme d’un document en langage naturel restreint. Ce complément facultatif facilite alors la création de la spécification formalisée 22.
Le module de création 20 comporte par exemple un moteur d’inférence, tel qu’un moteur d’inférence NLP (de l’anglaisNatural Language Processing), apte à projeter - sur la grammaire formelle prédéfinie - un texte rédigé par un utilisateur, reçu en entrée du module de création 20, puis à proposer à l’utilisateur une exigence 54 respective selon la grammaire formelle.
Le module de génération 24 est configuré pour générer le code générique 26 à partir de la spécification formalisée 22 créée, le code générique 26 étant destiné à être utilisé pour simuler un fonctionnement de l’application logicielle ou à être converti en un code source 30 respectif, compilable en un code exécutable de ladite application logicielle.
Dans l’exemple de la figure 2, le code générique 26 comporte un ensemble de composant(s) générique(s) 60, chaque composant générique 60 étant décomposé en un ou plusieurs traitements génériques 62, chaque traitement générique 62 comportant une suite de tâche(s) générique(s) 64. Chaque composant générique 60 est associé à un chapitre de composant 50 respectif; puis au sein de chaque composant générique 60, chaque traitement générique 62 est associé à une section de traitement 52 respective contenue dans le chapitre de composant 50 associé audit composant générique 60; et enfin au sein de chaque traitement générique 62, chaque tâche générique 64 est associée à une exigence 54 respective, contenue dans la section de traitement 52 associée audit traitement générique 62. A chaque tâche générique 64 est associé un ordre d’activation de ladite tâche au sein du traitement générique 62, en fonction d’un ordre de mise en œuvre de la suite d’exigence(s) 54 pour la section de traitement 52 associée.
Le code générique 26 est de préférence au format XML (de l’anglaisExtensible Markup Language), ou encore au format JSON (de l’anglaisJava Script Object Notation).
En complément, le code générique 26 comporte une bibliothèque de types 66. Chaque type est par exemple choisi parmi le groupe consistant en: un type entier, un type réel, un type booléen, un type énuméré, un type tableau, un type liste, un type structure, un type chaîne de caractères, un type évènement, un type requête et un type temporisation.
En complément encore, le code générique 26 comporte en outre une bibliothèque 68 de données aptes à être utilisées par des traitements génériques 62, chaque donnée étant d’un type choisi parmi la bibliothèque de types 66.
En complément facultatif, le module de génération 24 est en outre configuré pour associer, à chaque composant générique 60, un ordre de déroulement suivant lequel doit être exécuté chaque tâche générique 64 dudit composant 60, lors de chaque activation dudit composant 60, cet ordre étant par exemple représenté par la flèche F1 à la figure 3. En effet, dans l’exemple de la figure 3, un composant générique 60, noté C1, est décomposé en trois traitements génériques 62, à savoir un premier traitement générique T1, un deuxième traitement générique T2 et un troisième traitement générique T3, chaque traitement générique respectif T1, T2, T3 comportant une suite respective de tâche(s) générique(s) 64. Dans cet exemple, le premier traitement générique T1 comporte une suite de deux tâches génériques R1, R2, le deuxième traitement générique T2 comporte une suite de trois tâches génériques R3, R4, R5, et le troisième traitement générique T3 comporte une suite de deux tâches génériques R6, R7. Dans l’exemple de la figure 3, l’ordre de déroulement (flèche F1) suivant lequel doit être exécuté chaque tâche générique R1 à R7 dudit composant C1, lors de chaque activation dudit composant C1, est alors l’ordre allant de R1 à R7, la première tâche exécutée étant la tâche générique R1 et la dernière tâche exécutée étant la tâche générique R7. Autrement dit, dans cet exemple, les tâches génériques R1, R2 du premier traitement générique T1 sont exécutées en premier, avant celles R3, R4, R5 du deuxième traitement générique T2, pour finir par l’exécution des tâches génériques R6 et R7 du troisième traitement générique T3.
L’homme du métier comprendra alors que l’ordre de déroulement d’exécution des tâches génériques 64 au sein d’un composant générique 60 respectif dépend notamment de l’ordre d’activation associé à chaque tâche générique 64, cet ordre définissant l’ordre dans lequel ladite tâche générique 64 peut être activée au sein du traitement générique 62 associé.
En complément facultatif, le module de génération 24 comporte le convertisseur 56 apte à convertir la spécification formalisée 22 en ledit code générique 26 à partir de la grammaire formelle prédéfinie. La grammaire formelle est par exemple une grammaire DSL (de l’anglaisDomain Specific Language).
Le module de génération 24 est par exemple apte à utiliser la grammaire formelle afin d’analyser la spécification formalisée 22 sous forme d’un arbre d’instances de classe d’éléments syntaxiques. Chacune de ces instances de classe d’éléments syntaxiques contient un ensemble de champs spécifiques à ses données. Une de ces instances est par exemple une instance d’affectation, avec la donnée à affecter et la valeur affectée.
Le module de génération 24 est ensuite apte à utiliser cet arbre d’instances de classe d’éléments syntaxiques pour créer un arbre d’instances de générateurs. Ces instances de générateurs sont chargées de recopier, puis de compléter les informations à partir de bases de données qu’elles élaborent et d’un parcours de l’arbre d’instances de classe d’éléments syntaxiques. Une de ces instances de générateur est par exemple celle d’une boucle sur un tableau, qui permet d’effectuer une action pour chaque valeur contenue dans le tableau, avec la recopie du nom de la donnée d’index et du nom du tableau à parcourir, suivi par la recherche de la taille du tableau, ainsi que du type contenu dans le tableau pour le définir comme type de la donnée de l’index.
Le module de génération 24 est ensuite apte à produire le code générique 26 en appelant une fonction d’impression récursive sur l’arbre d’instances de générateurs. Cette fonction d’impression est implémentée pour chaque générateur et est apte à mettre en forme les données récupérées lors de l’élaboration de l’arbre d’instances de générateurs, ainsi qu’à appeler les générateurs positionnés en-dessous de lui dans l’arbre.
Le module de conversion 28 est configuré pour convertir le code générique 26 en au moins un code source 30 respectif, chaque code source 30 étant établi selon un langage informatique respectif prédéfini. Le module de conversion 28 est de préférence configuré pour convertir le code générique 26 en plusieurs codes sources 30 distincts, chacun étant établi selon un langage informatique respectif, comme représenté sur la figure 2.
Le langage informatique est par exemple choisi parmi le groupe consistant en: le langage C++, le langage ADA, le langage JAVA.
En complément facultatif, chaque code source 30 est de préférence établi en outre selon la plateforme électronique d’exécution. Autrement dit, chaque code source 30 issu du module de conversion 28 est établi à la fois pour un langage informatique respectif prédéfini et pour une plateforme électronique d’exécution prédéfinie.
Selon ce complément facultatif, le module de conversion 28 est par exemple configuré pour convertir les types contenus dans le code générique en des types spécifiques, en fonction de ladite plateforme d’exécution.
En complément facultatif, chaque section de traitement 52 comporte une exigence 54 de démarrage, c’est-à-dire une description des actions à réaliser une seule fois au démarrage du traitement générique 62 correspondant; une exigence 54 de reprise, c’est-à-dire une description des données à sauvegarder pour pouvoir relancer sans impact le traitement générique 62 correspondant et/ou une description des actions à réaliser une seule fois sur reprise dudit traitement générique 62; une exigence 54 de condition d’activation, c’est-à-dire une description d’une condition d’activation permettant de conditionner l’exécution de l’intégralité du traitement générique 52 correspondant; et une liste d’autres exigences 54, ces autres exigences 54 correspondent alors aux tâches génériques 64 propres audit traitement générique 62.
Chaque composant générique 60 comporte en outre un ensemble de données aptes à être lues et/ou élaborées par le composant 60 respectif, un ensemble de constantes utilisées par le composant 60 respectif, et un ensemble de types de données utilisées par le composant 60 respectif.
En complément facultatif, outre l’ensemble de traitement(s) générique(s) 62, chaque composant générique 60 comporte une déclaration des interfaces utilisées par ledit composant 60, ce qui permet d’avoir un fonctionnement plus robuste de l’application logicielle, avec une spécification pour chaque composant des données traitées, i.e. utilisées, par ledit composant 60.
Chaque traitement générique 62 comporte en outre une liste de données aptes à être élaborées par le traitement 62 respectif, une liste de données à sauvegarder à la fin de la mise en œuvre du traitement 62 respectif et une description d’actions à effectuer sur reprise du traitement 62 respectif.
En complément facultatif, pour chaque traitement générique 62, la suite de tâche(s) générique(s) 64 est non-fragmentable, la ou les tâches génériques 64 de ladite suite étant alors aptes, à chaque activation dudit traitement 62, à être mises en œuvre successivement et sans scission entre deux tâches génériques 64 successives.
En complément facultatif encore, au moins un traitement générique 62 comporte de préférence en outre une condition d’activation, l’activation dudit traitement 62 étant alors effectuée seulement si ladite condition d’activation est vérifiée.
En complément facultatif également, une donnée respective est de préférence apte à être élaborée par un unique traitement générique 62, ceci afin d’éviter des conflits d’élaboration de données entre traitements génériques 62. La liste de données est également de préférence apte à être initialisée à chaque activation du traitement générique 62 respectif, afin d’avoir un fonctionnement davantage déterministe de l’application logicielle lorsqu’elle est exécutée par la plateforme électronique d’exécution.
L’homme du métier comprendra alors que la structuration de la spécification formalisée 22 créée par le module de création 20 selon l’invention, où la spécification formalisée 22 comporte un ensemble de chapitre(s) de composant 50, chaque chapitre de composant 50 étant lui-même décomposé en une ou plusieurs sections de traitement 52, et chaque section de traitement 52 comportant une suite d’exigence(s) 54, permet d’avoir une projection similaire sur le code générique 26, chaque composant générique 60 correspondant à un chapitre de composant 50 respectif, chaque traitement générique 62 correspondant à une section de traitement 52 respective, et chaque tâche générique 64 correspondant à une exigence 54 respective. La spécification formalisée 22 est en outre apte à adresser plusieurs composants génériques 60 dans une même spécification formalisée 22, avec en outre une séparation entre les composants respectifs, de par le chapitrage des chapitres de composant 50.
L’homme du métier comprendra également que l’ordre d’activation associé à chaque tâche générique 64, et en complément facultatif l’ordre de déroulement des tâches génériques 64 associées à chaque composant 60, permet d’offrir un meilleur déterminisme de fonctionnement de l’application logicielle correspondant au code informatique 36, 30 ainsi généré.
En complément, le convertisseur 56 comporte en outre un lot de service(s) prédéfini(s), chacun étant associé à un type respectif, chaque service étant une suite d’opération(s) pour ledit type. En complément facultatif, le convertisseur 56 comporte en outre un lot de service(s) commun(s) à chacun des types.
Le lot de service(s) commun(s) comporte par exemple au moins un service, de préférence plusieurs services, et de préférence encore chacun des services, choisi(s) parmi le groupe consistant en: un service d’accession en lecture permettant de lire la valeur de la donnée, figée au début d’un cycle d’activation; un service d’accession en écriture, permettant de publier la valeur de la donnée pour les autres cycles d’activation; un service d’accession en lecture à la valeur précédente, permettant de lire la valeur de la donnée figée au début du cycle précédent d’activation; un service d’évènement de delta de données permettant de détecter que la valeur de la donnée a été modifiée durant l’activation précédente; et un service d’évènement de delta depuis l’activation permettant de détecter que la valeur de la donnée a été modifiée depuis le début du cycle d’activation.
Les types entier, réel, booléen et énumérés sont des types de bases. Les types tableau, liste, structure et chaîne de caractères sont des types composés, c’est-à-dire des types composés eux-mêmes d’éléments d’un autre type.
Le type tableau est un type composé de plusieurs éléments d’un autre type. Un lot de service(s) prédéfini(s) inclus dans le convertisseur 56 pour ce type tableau comporte par exemple au moins un service, de préférence plusieurs services, et de préférence encore chacun des services, choisi(s) parmi le groupe consistant en: un service d’accès en lecture à une valeur d’un indice donné, un service d’accès en écriture à une valeur d’un indice donné, et un service d’accès à la taille du tableau.
Le type liste est un type permettant d’empiler plusieurs éléments d’un autre type. Un lot de service(s) prédéfini(s) inclus dans le convertisseur 56 pour ce type tableau comporte par exemple au moins un service, de préférence plusieurs services, et de préférence encore chacun des services, choisi(s) parmi le groupe consistant en: un service d’accès au premier, respectivement au dernier, élément de la liste, un service d’accès à la liste contenant tous les éléments sauf le premier, respectivement le dernier, élément, un service de suppression du premier, respectivement du dernier, élément, un service de retour d’un booléen signalant ou non que la liste est pleine, un service de fourniture d’un nombre d’éléments contenus dans la liste, un service d’ajout d’un élément en tête, respectivement en fin, la liste, et un service permettant de vider complètement la liste.
Le type structure est un type composé de plusieurs champs d’un autre type, tel qu’un type de base, chacun étant défini par un nom.
Le type chaîne de caractères est connu en soi. Un lot de service(s) prédéfini(s) inclus dans le convertisseur 56 pour ce type tableau comporte par exemple au moins un service, de préférence plusieurs services, et de préférence encore chacun des services, choisi(s) parmi le groupe consistant en: un service de comparaison d’égalité entre chaînes de caractères, un service de comparaison d’ordre lexicographique entre chaînes de caractères, un service d’accès à un sous-ensemble de la chaîne de caractères et un service d’insertion d’un ou plusieurs caractères dans la chaîne.
Le type évènement est un type permettant de signaler un déclencheur, également appelé élément de déclenchement. Un lot de service(s) prédéfini(s) inclus dans le convertisseur 56 pour ledit type d’évènement comporte typiquement un service de levée d’évènement et/ou un service de test si l’évènement a été simulé précédemment.
Le type requête est un type assimilable à une boite aux lettres et permettant d’empiler une ou plusieurs données conventionnelles pour utilisation de tous les éléments dans une activation. Un lot de service(s) prédéfini(s) inclus dans le convertisseur 56 pour ce type requête comporte par exemple au moins un service, de préférence plusieurs services, et de préférence encore chacun des services, choisi(s) parmi le groupe consistant en: un service de dépose d’un élément dans la requête, un service de test si un élément est présent dans la requête et un service de dépilement de l’évènement pour déposer l’élément le plus ancien de la requête.
Le type temporisation est un type permettant de gérer une durée temporelle programmée. Un lot de service(s) prédéfini(s) inclus dans le convertisseur 56 pour ledit type temporisation comporte par exemple au moins un service, de préférence plusieurs services, et de préférence encore chacun des services, choisi(s) parmi le groupe consistant en: un service de vérification d’un état d’une temporisation, un service de démarrage d’une temporisation, un service d’arrêt d’une temporisation, un service de répétition d’action(s), un service d’affectation circulaire, un service d’affectation temporaire, un service de chronométrage, un service d’attente pour retarder le démarrage d’un traitement, et un service de détection d’un évènement, tel qu’un changement de valeur.
La grammaire formelle prédéfinie utilisée par le convertisseur 56 pour convertir la spécification formalisée 22 en le code générique 26 comporte en outre des éléments de grammaire pour certains, ou pour chacun, des services prédéfinis pour un type donné.
La grammaire formelle prédéfinie permet alors de proposer des complétions de noms de données, valeurs directement lors de la création de la spécification formalisée 22, de valider des propriétés statiques des exigences 54 (exemples de données élaborées dans un seul traitement, contrôle de cohérence de numéros d’identification, …), et de générer ensuite le code générique 26.
A titre d’exemple, pour le type temporisation, la grammaire formelle prédéfinie comporte un premier élément de grammaire G1, ci-après, associé au service de vérification de l’état d’une temporisation, et le premier élément de grammaire G1 permet alors d’avoir une exigence en langage naturel restreint pour tester l’état de la temporisation, telle que la première exigence E1 ci-après.
G1: «EventTempo :
tempo=IdentTempo ( isNot?="n'est" 'pas' | 'est' ) ( isExpired?='expirée' | 'en' 'cours' )
;»
E1: «Si la temporisation"Timer 1"est expirée alorsvaleur_temporaire = 1.»
Le module de génération 24 est alors configuré pour générer, à partir de la première exigence E1 ci-dessus, une première tâche générique 64, notée T1 ci-après, c’est-à-dire une portion du code générique 26.
T1: «<d:timer-service operation="isExpired">
<d:data
name="timer1"
is-constante="false"
type="timer"
origin="Exmeple_Interface"
is-from-actor="false"
is-local="false"
is-msg="false" >
</d:data>
</d:timer-service>»
A titre d’exemple complémentaire pour le type temporisation, la grammaire formelle prédéfinie comporte un deuxième élément de grammaire G2, ci-après, associé au service de démarrage d’une temporisation ou au service d’arrêt de la temporisation, permettant alors d’avoir une exigence en langage naturel restreint pour démarrer ou arrêter une temporisation, telle que la deuxième exigence E2 ci-après.
G2: «ActionTempo:
tempo=IdentTempo (( 'de' value=ValeurTempo 'est' isStart?='lancée' ) | ( 'est' ( 'inhibée' | 'stoppée' )))
;»
E2: «Une temporisation"Timer 1"de12secondes est lancée.»
Le module de génération 24 est alors configuré pour générer, à partir de la deuxième exigence E2 ci-dessus, une deuxième tâche générique 64, notée T2 ci-après, c’est-à-dire une autre portion du code générique 26.
T2: «<d:timer-service operation="start">
<d:data
name="timer1"
is-constante="false"
type="timer"
origin="Exmeple_Interface"
is-from-actor="true"
is-local="false"
is-msg="false" >
</d:data>
<d:duration>
<d:unit value="seconds"/>
<d:valeur-num>
<d:valeur-int value="12" />
</d:valeur-num>
</d:duration>
</d:timer-service>»
A titre d’autre exemple complémentaire pour le type temporisation, la grammaire formelle prédéfinie comporte un troisième élément de grammaire G3, ci-après, associé au service de répétition d’action(s), permettant alors d’avoir une exigence en langage naturel restreint pour limiter le nombre de fois où une action est effectuée, contrairement à une boucle classique pour laquelle le compteur ne peut s’incrémenter qu’une fois par cycle, telle que la troisième exigence E3 ci-après.
G3: «RetryAction:
('Le' |'le' ) 'traitement' name='répétable' 'suivant' 'est' 'effectué' 'au' 'maximum' count=IntegerLiteral 'fois'
action=Action
('Le' 'traitement' 'est' ('annulé'|'stoppé'|'interrompu'|'abandonné') 'si' cancelled=Condition)?
'Le' 'traitement' 'est' 'relancé' (('sous' 'réserve' 'que')|'si') relaunch=Condition
;»
E3: «Si condition alors
Le traitement répétable suivant est effectué au maximum3fois:
• valeur_temporaire = valeur_temporaire + 1 .
Le traitement est abandonné si"Erreur générale"vaut vrai
Le traitement est relancé si"Autorisation de lecture"vaut VRAI et"Enum 1"vaut'Saturation'
condition = FAUX»
A titre d’exemple complémentaire pour le type temporisation, la grammaire formelle prédéfinie comporte également un quatrième élément de grammaire G4, ci-après, associé au service d’affectation circulaire, permettant alors d’avoir une exigence en langage naturel restreint pour changer la valeur d’une variable à chaque cycle, suivant une suite de valeurs spécifiées par un utilisateur ou une plage d’entiers, et de repartir de la première valeur une fois que la dernière valeur est atteinte, telle que la quatrième exigence E4 ci-après.
G4: «CircularAffectation:
("L'information"|"l'information")? data=IdentOuAbbrevData
( 'passe' 'alternativement' 'de' circValues+=Valeur 'à' circValues+=Valeur
| 'alterne' 'entre' (circValues+=Valeur ('et'|'puis'))+ circValues+=Valeur
| 'prend' 'successivement' 'les' 'valeurs' (circValues+=Valeur 'puis')+ circValues+=Valeur
| isPlage?='varie' 'de' 'manière' 'circulaire' 'de' min=IntegerLiteral ('inclus'|minExcluded?='exclu')?
'à' max=IntegerLiteral (maxIncluded?='inclus'|'exclu')?
);»
E4: «L’information"A4"passe alternativement de Vrai à Faux.»
Le module de génération 24 est alors configuré pour générer, à partir de la quatrième exigence E4 ci-dessus, une quatrième tâche générique 64, notée T4 ci-après.
T4: «<d:action>
<d:if>
<d:condition>
<d:expression>
<d:binary-expr operation="test-equals">
<d:expression>
<d:data
name="a4"
is-constante="false"
type="boolean"
origin="EXEMPLEC4_tExemple"
is-from-actor="true"
is-local="false"
is-msg="false" >
</d:data>
</d:expression>
<d:expression>
<d:valeur-boolean value="false" />
</d:expression>
</d:binary-expr>
</d:expression>
</d:condition>
<d:action-if>
<d:action>
<d:assignment>
<d:data
name="a4"
is-constante="false"
type="boolean"
origin="EXEMPLEC4_tExemple"
is-from-actor="true"
is-local="false"
is-msg="false" >
</d:data>
<d:expression>
<d:valeur-boolean value="true" />
</d:expression>
</d:assignment>
</d:action>
</d:action-if>
<d:action-else>
<d:action>
<d:if>
<d:condition>
<d:expression>
<d:binary-expr operation="test-equals">
<d:expression>
<d:data
name="a4"
is-constante="false"
type="boolean"
origin="EXEMPLEC4_tExemple"
is-from-actor="true"
is-local="false"
is-msg="false" >
</d:data>
</d:expression>
<d:expression>
<d:valeur-boolean value="true" />
</d:expression>
</d:binary-expr>
</d:expression>
</d:condition>
<d:action-if>
<d:action>
<d:assignment>
<d:data
name="a4"
is-constante="false"
type="boolean"
origin="EXEMPLEC4_tExemple"
is-from-actor="true"
is-local="false"
is-msg="false" >
</d:data>
<d:expression>
<d:valeur-boolean value="false" />
</d:expression>
</d:assignment>
</d:action>
</d:action-if>
</d:if>
</d:action>
</d:action-else>
</d:if>
</d:action>
»
A titre d’exemple complémentaire encore pour le type temporisation, la grammaire formelle prédéfinie comporte un cinquième élément de grammaire G5, ci-après, associé au service d’affectation temporaire, permettant alors d’avoir une exigence en langage naturel restreint pour effectuer une affectation temporaire à une valeur, c‘est à dire un forçage temporaire à ladite valeur, telle que la cinquième exigence E5 ci-après.
G5: «
AffectationTemporaire:
( 'Forcer' | 'forcer' ) forcedData+=IdentOuAbbrevData ( ( ',' | 'et' ) forcedData+=IdentOuAbbrevData)*
'à' valueAffect=ValeurAffectation 'pendant' duration=ValeurTempo
| ( 'Pendant' | 'pendant' ) duration=ValeurTempo',' forcedData+=IdentOuAbbrevData
( ( ',' | 'et' ) forcedData+=IdentOuAbbrevData )*
( 'est' ('forcé' | 'forcée') | 'sont' ('forcés' | 'forcées') ) 'à' valueAffect=ValeurAffectation
;»
E5: «Forcer "A4" à Vrai pendant 50 ms.»
A titre d’exemple complémentaire additionnel pour le type temporisation, la grammaire formelle prédéfinie comporte encore par exemple un sixième élément de grammaire G6, ci-après, associé au service de chronométrage, et permettant alors d’avoir une exigence en langage naturel restreint pour renvoyer un booléen afin de vérifier si une condition est restée vraie pendant un temps donné, telle que la sixième exigence E6 ci-après.
G6: «Chronometre:
( 'le' 'temps' 'écoulé' ',' 'depuis' ('que' | "qu'") evt=Evenement ','
'est' operator=( 'supérieur' | 'supérieure' | 'inférieur' | 'inférieure' )
( 'ou' ( 'égal' | 'égale' ) )? 'à' duree=ValeurTempo )
| (',' 'pendant' operator=('plus' | 'moins') 'de' duree=ValeurTempo ',' expr=Expression)
;»
E6: «Si,pendant plus de10sec, "l'altitude"est supérieure à100alorsvaleur_temporaire = 1.»
A titre d’autre exemple complémentaire pour le type temporisation, la grammaire formelle prédéfinie comporte un septième élément de grammaire G7, ci-après, associé au service d’attente pour retarder le démarrage d’un traitement, et permettant alors d’avoir une exigence en langage naturel restreint pour retarder le démarrage d’un traitement, telle que la septième exigence E7 ci-après.
G7: «ActionAttendre:
name=('attendre'|'Attendre')
(
(
(('au' operator=('moins'|'plus'))? duree=ValeurTempo )?
((('que' | "qu'") trigger=Condition)|( 'la' event=ExpEvent ))
)
|
(
('au' operator=('moins'|'plus'))? duree=ValeurTempo
)
)
('puis' ('effectuer' ('les' 'traitements' 'suivants'|'le' 'traitement' 'suivant') ':'?)?
action=Action
)?
;»
E7: «Attendre au plus1080ms que"A4"soit égal à vrai puis positionnervaleur_temporaireà VRAI.»
A titre de dernier exemple complémentaire pour le type temporisation, la grammaire formelle prédéfinie comporte un huitième élément de grammaire G8, ci-après, associé au service de détection d’un évènement, tel qu’un changement de valeur, et permettant alors d’avoir une exigence en langage naturel restreint pour détecter des évènements, notamment un changement de valeur entre deux cycles, telle que la huitième exigence E8 ci-après.
G8: «EventRise :
( ('quand')? ("l'information")? testedVar = IdentOuAbbrevData
( name='change' 'de' 'valeur'
| 'a' name='changé' 'de' 'valeur'
| 'a' name='variée'
| name='varie'
| isFreezed?='est' name=( 'figé' | 'figée' )
| ( name='passe' | 'est' name=( 'passé' | 'passée' ))
( fromValueExist?=('de'|"d'") (valueStart=Valeur|valueStart=EnsembleValeur))?
( testPasse?='à') ( value = Valeur
| value = EnsembleValeur
| value = ValeurAutreQue
)
| ( ( 'est' ( name='devenu' | name='devenue' ) | name='devient' ) ( operator=( 'égal' | 'égale' ) 'à'
| operator=( 'vaut' | 'valent' )
| operator=( 'différent' | 'différente' ) 'de'
| operator=( 'supérieur' | 'supérieure' ) ( 'ou' isCompWithEq?=( 'égal' | 'égale' ) )? 'à'
| operator=( 'inférieur' | 'inférieure' ) ( 'ou' isCompWithEq?=( 'égal' | 'égale' ) )? 'à'
)
value = Valeur
)
)
| name=('variation'|'Variation') ('de'|"d'un"|"d'une"|"d'") testedVar=IdentOuAbbrevData
);»
E8: «Si"A4"change de valeur,alorsvaleur_temporaire = 1.»
Le module de génération 24 est alors configuré pour générer, à partir de la huitième exigence E8 ci-dessus, une huitième tâche générique 64, notée T8 ci-après.
T8: «<d:action>
<d:if>
<d:condition>
<d:expression>
<d:exp-event>
<d:evtDeltaData deltaAfterAffect="false">
<d:data
name="a4"
is-constante="false"
type="boolean"
origin="EXEMPLEC4_tExemple"
is-from-actor="true"
is-local="false"
is-msg="false" >
</d:data>
</d:evtDeltaData>
</d:exp-event>
</d:expression>
</d:condition>
<d:action-if>
<d:action>
<d:assignment>
<d:data
name="valeur_temporaire"
is-constante="false"
type="int"
origin="EXEMPLEC4_tExemple"
is-from-actor="true"
is-local="true"
is-msg="false" >
</d:data>
<d:expression>
<d:valeur-int value="1" />
</d:expression>
</d:assignment>
</d:action>
</d:action-if>
</d:if>
</d:action>»
Le module de simulation 32 est configuré pour simuler le fonctionnement de l’application logicielle, directement à partir du code générique 26. Autrement dit, le module de simulation 32 forme un émulateur du code générique 26, la simulation étant de préférence effectuée en fonction de la grammaire formelle prédéfinie, telle que la grammaire DSL. Cette simulation est typiquement basée sur une même utilisation des différents lots de service(s) prédéfini(s), décrits précédemment. Le langage informatique utilisé pour cette simulation n’est toutefois pas nécessairement l’un des langages informatiques prédéfinis, tels que décrits ci-dessus et associés à la plateforme électronique d’exécution, à savoir par exemple le langage C++, le langage ADA, le langage JAVA. Le langage informatique utilisé pour cette simulation est alors de préférence un langage informatique moins contraint que les langages informatiques précités. Le langage informatique utilisé pour cette simulation est par exemple le langage PYTHON, voire le langage JAVA qui est le moins contraint parmi les langages C++, ADA et JAVA.
Le module de simulation 32 est alors configuré pour recevoir en entrée un fichier de configuration, non représenté, listant les valeurs pour chaque pas d’exécution des entrées définies dans la spécification formalisée 22, ces valeurs étant également appelées données d’entrée. Le fichier de configuration comporte alors typiquement des valeurs pour les exigences 54 de la spécification formalisée 22, ces exigences 54i formant la ou les sections de traitement 52, formant elles-mêmes le ou les chapitres de composant 50.
Le module de simulation 32 est alors configuré pour appeler, c’est-à-dire lancer ou mettre en œuvre, le module génération 24 afin de générer le code générique 26, ceci à partir de la spécification formalisée 22 et du fichier de configuration. Le module de simulation 32 est ensuite, pour chaque cycle d’activation défini dans le fichier de configuration, adapté pour:
- positionner, dans un émulateur du code générique 26, les valeurs des données d’entrée spécifiées dans le fichier de configuration; puis
- exécuter un processus d’appel cyclique du code générique 26, c’est-à-dire exécuter le code générique 26 pour le cycle d’activation respectif; et
- enregistrer les valeurs de données de sortie résultant de l’exécution du code générique 26 sur les données d’entrée pour ledit cycle d’activation.
Une fois parcouru l’ensemble des cycles d’activation contenus dans le fichier de configuration, le module de simulation 32 est enfin configuré pour récupérer les données enregistrées, notamment les données de sortie, voire les données d’entrée, et les stocker dans un fichier de résultat 34, par exemple cycle d’activation par cycle d’activation.
En complément facultatif, le module de simulation 32 est configuré pour envoyer le fichier de résultat 34 au module de création 20, selon la flèche F2 à la figure 2. Selon ce complément facultatif, le module de création 20 est alors configuré pour prendre en compte ce fichier de résultat 34, par exemple pour créer une nouvelle version de la spécification formalisée 22 à partir de ce fichier de résultat 34.
Le fonctionnement du dispositif de génération 10 selon l’invention va être à présent décrit en regard de la figure 4 représentant un organigramme du procédé, selon l’invention, de génération d’au moins un code informatique 26, 30 pour la mise en œuvre de l’application logicielle apte à être exécutée par la plateforme électronique d’exécution.
Lors d’une étape initiale 100, le dispositif de génération 10 crée, via son module de création 20, la spécification formalisée 22 de l’application logicielle. Comme décrit précédemment, la spécification formalisée ainsi créée est structurée en chapitre(s) de composant 50, chacun correspondant à un composant générique 60, chaque chapitre de composant 50 étant lui-même décomposé en une ou plusieurs sections de traitement 52, chacune correspondant à un traitement générique 62, et chaque section de traitement 52 est elle-même décomposée en une suite d’exigence(s) 54 à mettre en œuvre, chacune correspondant à une tâche générique 64, tout en comportant un ordre de mise en œuvre de la suite d’exigence(s) 54 au sein de la section de traitement 52, afin d’avoir un meilleur déterminisme de fonctionnement de l’application logicielle en ayant alors un ordre d’activation des tâches génériques 64 au sein du traitement générique 62, correspondant à la section de traitement 52 respective.
Lorsqu’en complément facultatif le module de génération 24 comporte le convertisseur 56 basé sur une grammaire formelle prédéfinie, telle que la grammaire DSL, la spécification formalisée 22 est de préférence en outre en forme d’une spécification en langage naturel restreint, comme décrit précédemment, avec par exemple les première à huitième exigences E1 à E8 décrites ci-dessus, à titre d’exigences liées à des temporisations.
A l’issue de cette étape de création 100, le dispositif de génération 10 passe à l’étape suivante 110 lors de laquelle il génère, via son module de génération 24, le code générique 26 à partir de la spécification formalisée 22 créée lors de l’étape précédente 100. Cette génération du code générique 26 est par exemple effectuée par conversion, via le convertisseur 56, de la spécification formalisée 22 en ledit code générique 26 à l’aide de la grammaire formelle prédéfinie.
Le code générique 26 ainsi généré est alors structuré de la même manière que la spécification formalisée 22, le code générique 26 comportant l’ensemble de composant(s) générique(s) 60, chacun correspondant à un chapitre de composant 50 respectif, chaque composant générique 60 étant décomposé en un ou plusieurs traitements génériques 62 respectifs, avec chaque traitement générique 62 correspondant à une section de traitement 52 respective, et chaque traitement générique 62 étant lui-même décomposé en une suite de tâche(s) générique(s) 64, chacune correspondant à une exigence 54 respective.
L’ordre de mise en œuvre de la suite d’exigence(s) 54 pour chaque section de traitement 52 résulte alors en l’ordre d’activation des tâches génériques 64 au sein du traitement générique 62 correspondant. Cet ordre d’activation permet alors d’avoir un meilleur déterminisme de fonctionnement de l’application logicielle lorsque le code informatique 26, 30 est exécuté.
Cet effet technique est encore plus sensible lorsque l’application logicielle est une application logicielle temps-réel, par exemple décomposée en un ensemble de messages/données à publier à l’extérieur de l’application, en plusieurs composants logiciels échangeant des données entre eux, avec plusieurs cycles d’activations. L’homme du métier comprendra que chaque composant logiciel résulte de la conversion, par le module de conversion 28, d’un composant générique 60 respectif.
Chaque cycle d’activation contient un ensemble de composants logiciels à activer/exécuter. Certains cycles d’activation sont exécutés cycliquement, par exemple toutes les 160 ms, et d’autres cycles d’activation sont exécutés sur évènement. En complément, des ordres de priorités sont associés aux cycles d’activation afin que les cycles moins prioritaires soient interrompus pendant l’exécution des cycles les plus prioritaires.
Au lancement de l’application logicielle, la plateforme d’exécution lance un cycle d’initialisation des données internes de chaque composant, puis déclenche les activations des composants selon les priorités. Lors d’une activation, chaque composant va élaborer, dans une suite de traitements, un ensemble d’informations qui seront publiées vers la plateforme d’exécution, laquelle les mettra à disposition de chaque utilisateur au début de son cycle d’exécution. Il est à noter qu’une fois mis à disposition pour utilisation, les états et valeurs des données élaborées sont figés vis-à-vis de l’utilisateur, même si le producteur de la donnée est amené à modifier ces valeurs en parallèle. Ceci permet d’améliorer la reproductibilité de l’application logicielle et de limiter des risques de conflit entre lecture et écriture des données.
L’homme du métier observera en outre que le code générique 26 qui est par exemple réalisé en XML se décompose de préférence alors en trois parties, à savoir la bibliothèque de types 66, la bibliothèque 68 de données utilisées par les traitements génériques 62, basée sur la bibliothèque de types 66; et l’ensemble des traitements génériques 62, c’est-à-dire des traitements cycliques à exécuter, basé sur la bibliothèque de données 68.
A l’issue de l’étape 110 de génération, le dispositif de génération 10 convertit par exemple, lors de l’étape suivante 120 et via son module de conversion 28, le code générique 26 généré par l’étape précédente 110 en un ou plusieurs codes source 30 respectif, chacun étant établi selon un langage informatique prédéfini respectif.
Cette conversion est par exemple effectuée en lisant l’arbre XML associé au code générique 26 et en le chargeant en mémoire, afin de le parcourir. Chaque balise XML rencontrée voit alors les données qu’elle contient être chargées dans un conteneur qui lui est propre, et toutes les balises enfant de cette balise rencontrée sont elles-mêmes placées dans des conteneurs appropriés respectifs. Une fois ces données chargées, le module de conversion 28 applique un groupe de motifs (de l’anglaist emplate) sur l’arbre des conteneurs à partir de sa racine, chaque motif, outemplate, contenant un canevas, également appelé ossature ou texte à trou, représentant la syntaxe propre au langage informatique prédéfini, et le module de conversion 28 complète alors le canevas à partir du contenu de chaque tâche générique 64 correspondante.
L’homme du métier comprendra alors que le dispositif de génération 10 selon l’invention permet de générer facilement, à partir d’un même code générique 26, plusieurs codes source 30 respectifs, chacun dans un langage informatique distinct. Autrement dit, le dispositif de génération 10 selon l’invention permet d’avoir plus efficacement et plus facilement une même application logicielle codée dans différents langages informatiques, et en complément facultatif pour différents plateformes électroniques d’exécution, afin de permettre plus facilement la mise en œuvre de la même application logicielle sur ces différentes plateformes électroniques d’exécution.
En complément ou en variante, à l’issue de l’étape de génération 110, le dispositif de génération 10 simule, lors de l’étape 130 et via son module de simulation 32, le fonctionnement de l’application logicielle à partir du code générique 26 généré lors de l’étape 110. Le module de simulation 32 permet alors, en d’autres termes, de simuler la mise en œuvre de l’application logicielle directement à partir du code générique 26, pour pouvoir identifier, de manière préalable, d’éventuels dysfonctionnements de l’application logicielle, sans avoir à convertir le code générique en code source, puis à compiler ledit code source en un code exécutable pour l’exécuter sur la plateforme électronique d’exécution correspondante.
Le module de simulation 32 permet alors de tester plus rapidement et plus facilement le fonctionnement de l’application logicielle.
On conçoit ainsi que ledit dispositif de génération 10 selon l’invention et le procédé de génération associé permettent de générer plus facilement au moins un code informatique 26, 30 pour la mise en œuvre de l’application logicielle, en particulier d’une application logicielle temps-réel devant être certifiée, notamment de par le déterminisme de fonctionnement amélioré et le partitionnement respectivement entre tâches génériques 64, puis entre traitements génériques 62, et enfin entre composants génériques 60, ce partitionnement résultant de la structuration décrite précédemment.
Claims (12)
- Dispositif électronique (10) de génération d’au moins un code informatique (26, 30), pour la mise en œuvre d’une application logicielle apte à être exécutée par une plateforme électronique d’exécution, le dispositif (10) comprenant:
- un module de création (20) configuré pour créer une spécification formalisée (22) de l’application logicielle, la spécification formalisée (22) comportant un ensemble de chapitres de composant (50), chaque chapitre de composant (50) étant décomposé en une ou plusieurs sections de traitement (52), chaque section de traitement (52) comportant une suite d’exigence(s) (54) à mettre en œuvre et un ordre de mise en œuvre de la suite d’exigence(s) (54),
- un module de génération (24) configuré pour générer un code générique (26) à partir de la spécification formalisée (22) créée, le code générique (26) étant destiné à simuler un fonctionnement de l’application logicielle ou à être converti en un code source (30) compilable en un code exécutable de ladite application logicielle; le code générique (26) comportant un ensemble de composants génériques (60), chaque composant générique (60) étant décomposé en un ou plusieurs traitements génériques (62), chaque traitement générique (62) comportant une suite de tâche(s) générique(s) (64); chaque composant générique (60) étant associé à un chapitre de composant (50) respectif, chaque traitement générique (62) étant associé à une section de traitement (52) respective et chaque tâche générique (64) étant associée à une exigence (54) respective; et à chaque tâche générique (64) étant associé un ordre d’activation de ladite tâche (64) au sein du traitement générique (62), en fonction de l’ordre de mise en œuvre de la suite d’exigence(s) (54) pour la section de traitement (52) associée. - Dispositif (10) selon la revendication 1, dans lequel le module de génération (24) est en outre configuré pour associer, à chaque composant générique (60), un ordre de déroulement suivant lequel doit être exécutée chaque tâche générique (64) dudit composant (60), lors de chaque activation dudit composant (60).
- Dispositif (10) selon la revendication 1 ou 2, dans lequel, pour chaque traitement générique (62), la suite de tâche(s) générique(s) (64) est non-fragmentable, la ou les tâches génériques (64) de ladite suite étant aptes, à chaque activation dudit traitement (62), à être mises en œuvre successivement et sans scission entre deux tâches génériques (64) successives;
au moins un traitement générique (62) comportant de préférence en outre une condition d’activation, l’activation dudit traitement (62) étant alors effectuée seulement si la condition d’activation est vérifiée. - Dispositif (10) selon l’une quelconque des revendications précédentes, dans lequel chaque composant générique (60) comporte en outre un ensemble de données aptes à être lues et/ou élaborées par le composant (60) respectif, un ensemble de constantes utilisées par le composant (60) respectif, et un ensemble de types de données utilisées par le composant (60) respectif.
- Dispositif (10) selon l’une quelconque des revendications précédentes, dans lequel chaque traitement générique (62) comporte en outre une liste de données aptes à être élaborées par le traitement (62) respectif, une liste de données à sauvegarder à la fin de la mise en œuvre du traitement (62) respectif et une description d’actions à effectuer sur reprise du traitement (62) respectif;
une donnée respective étant de préférence apte à être élaborée par un unique traitement générique (62);
la liste de données étant de préférence apte à être initialisée à chaque activation du traitement générique (62) respectif. - Dispositif (10) selon l’une quelconque des revendications précédentes, dans lequel le code générique (26) comporte en outre une bibliothèque de types (66),
chaque type étant de préférence choisi parmi le groupe consistant en: un type entier, un type réel, un type booléen, un type énuméré, un type tableau, un type liste, un type structure, un type chaîne de caractères, un type évènement, un type requête, un type temporisation. - Dispositif (10) selon l’une quelconque des revendications précédentes, dans lequel le code générique (26) comporte en outre une bibliothèque (68) de données aptes à être utilisées par des traitements génériques (62), chaque donnée étant d’un type choisi parmi la bibliothèque de types (66).
- Dispositif (10) selon l’une quelconque des revendications précédentes, dans lequel le module de génération (24) comporte un convertisseur (56) apte à convertir la spécification formalisée (22) en ledit code générique (26) à partir d’une grammaire formelle prédéfinie;
la grammaire formelle étant de préférence une grammaire DSL;
le code générique (26) étant de préférence au format XML ou au format JSON. - Dispositif (10) selon les revendications 6 et 8, dans lequel le convertisseur (56) comporte en outre un lot de service(s) prédéfini(s), chacun étant associé à un type respectif, chaque service étant une suite d’opération(s) pour ledit type;
le lot de service(s) incluant de préférence au moins un service, de préférence encore plusieurs services, et de préférence encore chacun des services, choisi(s) parmi le groupe consistant en: un service de vérification d’un état d’une temporisation, un service de démarrage d’une temporisation, un service d’arrêt d’une temporisation, un service de répétition d’action(s), un service d’affectation circulaire, un service d’affectation temporaire, un service de chronométrage, un service d’attente pour retarder le démarrage d’un traitement, et un service de détection d’un évènement, tel qu’un changement de valeur. - Dispositif (10) selon l’une quelconque des revendications précédentes, dans lequel le dispositif (10) comprend en outre un module de conversion (28) configuré pour convertir le code générique (26) en au moins un code source (30) établi selon un langage informatique prédéfini;
le module de conversion (28) étant de préférence configuré pour convertir le code générique (26) en plusieurs codes source (30) distincts, chacun étant établi selon un langage informatique respectif;
le langage informatique étant de préférence choisi parmi le groupe consistant en: C++, ADA, JAVA;
le code source (30) étant de préférence établi en outre selon la plateforme électronique d’exécution. - Procédé de génération d’au moins un code informatique (26, 30), pour la mise en œuvre d’une application logicielle apte à être exécutée par une plateforme électronique d’exécution, le procédé étant mis en œuvre par un dispositif électronique de génération (10) et comprenant les étapes suivantes:
- la création (100) d’une spécification formalisée (22) de l’application logicielle, la spécification formalisée (22) comportant un ensemble de chapitres de composant (50), chaque chapitre de composant (50) étant décomposé en une ou plusieurs sections de traitement (52), chaque section de traitement (52) comportant une suite d’exigence(s) (54) à mettre en œuvre et un ordre de mise en œuvre de la suite d’exigence(s) (54),
- la génération (110) d’un code générique (26) à partir de la spécification formalisée (22) créée, le code générique (26) étant destiné à simuler un fonctionnement de l’application logicielle ou à être converti en un code source (30) compilable en un code exécutable de ladite application logicielle; le code générique (26) comportant un ensemble de composants génériques (60), chaque composant générique (60) étant décomposé en un ou plusieurs traitements génériques (62), chaque traitement générique (62) comportant une suite de tâche(s) générique(s) (64); chaque composant générique (60) étant associé à un chapitre de composant (50) respectif, chaque traitement générique (62) étant associé à une section de traitement (52) respective et chaque tâche générique (64) étant associée à une exigence (54) respective; et à chaque tâche générique (64) étant associé un ordre d’activation de ladite tâche (64) au sein du traitement générique (62), en fonction de l’ordre de mise en œuvre de la suite d’exigence(s) (54) pour la section de traitement (52) associée. - Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon la revendication précédente.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2001871A FR3107608B1 (fr) | 2020-02-26 | 2020-02-26 | Dispositif electronique et procede de generation d'au moins un code informatique, programme d'ordinateur associe |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2001871 | 2020-02-26 | ||
| FR2001871A FR3107608B1 (fr) | 2020-02-26 | 2020-02-26 | Dispositif electronique et procede de generation d'au moins un code informatique, programme d'ordinateur associe |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3107608A1 true FR3107608A1 (fr) | 2021-08-27 |
| FR3107608B1 FR3107608B1 (fr) | 2022-03-11 |
Family
ID=72178616
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2001871A Active FR3107608B1 (fr) | 2020-02-26 | 2020-02-26 | Dispositif electronique et procede de generation d'au moins un code informatique, programme d'ordinateur associe |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3107608B1 (fr) |
-
2020
- 2020-02-26 FR FR2001871A patent/FR3107608B1/fr active Active
Non-Patent Citations (5)
| Title |
|---|
| CARNEVALI L ET AL: "Automatic Code Generation from Real-Time Systems Specifications", RAPID SYSTEM PROTOTYPING, 2009. RSP '09. IEEE/IFIP INTERNATIONAL SYMPOSIUM ON, IEEE, PISCATAWAY, NJ, USA, 23 June 2009 (2009-06-23), pages 102 - 105, XP031485601, ISBN: 978-0-7695-3690-3 * |
| PORTILLO JAVIER ET AL: "Contributions to the design of real time distributed control systems", 2001 EUROPEAN CONTROL CONFERENCE (ECC), IEEE, 4 September 2001 (2001-09-04), pages 2233 - 2238, XP032769655, ISBN: 978-3-9524173-6-2, [retrieved on 20150331] * |
| S. GHOSH, AUTOMATIC REQUIREMENTS SPÉCIFICATION EXTRACTION FROM NATURAL LANGUAGE |
| T. BURES, REQUIREMENT SPECIFICATIONS USING NATURAL LANGUAGES |
| V. AMBRIOLA, ON THE SYSTEMATIC ANALYSIS OF NATURAL LANGUAGE REQUIREMENTS WITH CIRCE |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3107608B1 (fr) | 2022-03-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3371719B1 (fr) | Procede de simulation parallele de niveau systeme electronique avec detection des conflits d'acces a une memoire partagee | |
| CN108964968B (zh) | 一种容器云环境下的服务接入管理方法和系统 | |
| FR2688611A1 (fr) | Utilisation d'un langage dont le typage porte sur le contenu des variables et permettant de manipuler des constructions complexes. | |
| WO2004013800A2 (fr) | Logiciel de generation de code d'application informatique et langage de description de logiciel | |
| US7552422B2 (en) | Test case inheritance controlled via attributes | |
| EP1739551A1 (fr) | Procédé de traitement de données compatible avec un formalisme de modélisation d'objets | |
| BE1008621A3 (fr) | Procedure et procede de communication entre machines et procede generalise de preparation de programmes afferents. | |
| US8849612B2 (en) | System and method of substituting parameter sets in self-contained mini-applications | |
| FR2907933A1 (fr) | Procede pour la creation d'une description des exigences pour un systeme incorpore. | |
| WO2010009996A1 (fr) | Procede de compilation de programme informatique | |
| EP1290554B1 (fr) | Systeme informatique modulaire et procede associe | |
| EP2453356B1 (fr) | Procédé, programme d'ordinateur et dispositif de sécurisation de code intermédiaire de programmation pour son exécution par une machine virtuelle | |
| CN112084488A (zh) | 应用权限管理方法、装置及系统 | |
| WO2021069626A1 (fr) | Procédé de simulation parallèle reproductible de niveau système électronique mis en oeuvre au moyen d'un système informatique multi-coeurs de simulation à événements discrets | |
| CN114416547A (zh) | 基于测试用例的测试方法 | |
| FR2938091A1 (fr) | Procede de realisation d'un appel d'une instance d'une fonction, dispositif, programme d'ordinateur correspondant | |
| FR2998073A1 (fr) | Systeme electronique, plateforme d'execution modulaire embarquee et procede assurant le cloisonnement de regles decisionnelles parametrables | |
| CN110659022B (zh) | 一种基于Java自动调用Python脚本的方法 | |
| FR3107608A1 (fr) | Dispositif electronique et procede de generation d'au moins un code informatique, programme d'ordinateur associe | |
| FR2882837A1 (fr) | Procede et dispositif de construction d'un dialogue vocal | |
| EP3195113B1 (fr) | Procédé de vérification de traçabilité de premières instructions en un langage de programmation procédurale générées à partir de secondes instructions en un langage de modélisation | |
| FR2688608A1 (fr) | Utilisation d'un langage ayant une representation similaire pour les programmes et les donnees en informatique distribuee. | |
| FR3087916A1 (fr) | Procede de traitement d'un code source, dispositif, systeme et programme correspondant | |
| WO2003075188A1 (fr) | Procede d'extraction de la topologie d'un systeme a partir de sa description textuelle | |
| CN117827629A (zh) | 针对flutter的代码检测方法、装置、计算机设备和存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20210827 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |