Brevet FR3021769A1 — publié le 20151204

Dispositif et procédé de génération d'au moins un fichier informatique pour la réalisation d'une interface graphique d'un équipement électronique, et produit programme d'ordinateur associé La présente invention concerne un dispositif électronique de génération d'au moins un fichier informatique parmi un code informatique et au moins un document descriptif du code informatique, pour la réalisation d'au moins une partie d'une interface graphique d'un équipement électronique. Le dispositif de génération comprend un module de création d'une description formalisée de l'interface graphique sous forme d'exigences logicielles, chaque exigence étant associée à un objet graphique de l'interface graphique et étant créée à partir d'une liste de ressources. Le dispositif de génération comprend un module de génération, à partir de la description formalisée créée, d'au moins un fichier informatique parmi un code source et au moins un document descriptif du code source, le code source étant destiné à être compilé en un code exécutable pour la réalisation de ladite au moins une partie de l'interface graphique de l'équipement électronique, chaque document descriptif contenant des informations relatives aux exigences logicielles. L'invention concerne également un procédé de génération d'au moins un tel fichier informatique. L'invention concerne également un produit programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont mises en oeuvre par un ordinateur, mettent en oeuvre un tel procédé de génération. L'invention s'applique au domaine des interfaces homme-machine d'équipements électroniques embarqués, en particulier aux interfaces graphiques de ces équipements embarqués, tels que des équipements aéronautiques, des équipements ferroviaires, des équipements automobiles et des équipements spatiaux. On connaît du document US 6,681,383 B1 un dispositif et un procédé de génération du type précité. Ce document décrit un outil de production automatique d'un logiciel comprenant des moyens de création d'une spécification formelle, des moyens de validation de la spécification formelle générée et des moyens de conversion automatique de la spécification formelle validée en un code source. La spécification formelle est créée sous forme d'exigences systèmes qui sont saisies via des diagrammes de classes, et le dispositif de génération comprend une interface graphique de saisie d'exigences, l'interface graphique étant une interface orientée objet. 3021769 2 Ce document concerne le domaine des applications client-serveur. L'interface graphique est générée en une seule étape, et les exigences sont créées à partir d'une liste figée de ressources. Un tel dispositif de génération est adapté pour un développement logiciel en trois 5 phases pour la partie descendante du cycle en V, à savoir la spécification, la conception et la réalisation du code. Un tel dispositif de génération valide la complétude et la justesse des exigences créées une fois que ces exigences ont été converties en la ou les spécifications formelles. Le concepteur jouit donc d'une importante liberté de création pendant la phase de 10 création des exigences. Un tel dispositif de génération permet également de générer une documentation à but informatif et décrivant le code source créée. Toutefois, un tel dispositif de génération n'est pas très adapté pour la génération d'un code source d'interface graphique dans le domaine des équipements électroniques 15 embarqués. Un but de l'invention est donc de faciliter et d'améliorer la réalisation d'au moins une partie de l'interface graphique d'un équipement embarqué, notamment la génération du code source ou de la documentation associée, en aidant le concepteur à créer des exigences logicielles, puis en générant automatiquement le code source à partir des 20 exigences logicielles créées. A cet effet, l'invention a pour objet un dispositif électronique de génération, du type précité, dans lequel le module de création comporte des moyens de filtrage adaptés pour sélectionner, notamment en fonction de l'objet graphique correspondant, seulement certaines ressources parmi ladite liste de ressources. 25 Grâce au dispositif de génération selon l'invention, le concepteur est assisté dans la réalisation de ladite partie de l'interface graphique, en étant guidé au plus tôt, en particulier dès la saisie des exigences logicielles, le dispositif selon l'invention proposant au concepteur, de par les moyens de filtrage, seulement une liste restreinte de ressources pour la création des exigences logicielles. Cela permet de s'assurer au plus tôt, dès la 30 création des exigences logicielles, que les contraintes associées à l'interface graphique de l'équipement embarqué sont bien vérifiées. Suivant d'autres aspects avantageux de l'invention, le dispositif de génération comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles : 3021769 3 - le dispositif comprend en outre un module de compilation du code source généré en un code exécutable, le code exécutable étant apte à être exécuté par l'équipement électronique pour réaliser ladite au moins une partie de l'interface graphique ; - au moins une exigence logicielle comporte un champ à remplir ; et les moyens 5 de filtrage sont adaptés pour sélectionner seulement certaines ressources parmi ladite liste de ressources en fonction en outre du type du champ ; - le module de création comporte en outre des moyens d'acquisition, uniquement sous forme d'une chaîne de caractères alphanumériques, des données du champ ; - chaque exigence logicielle est choisie parmi le groupe consistant en : une 10 exigence d'affichage initial, une exigence de rafraîchissement d'affichage, une exigence d'interaction associée à l'objet graphique et une exigence de traitement d'un évènement ; - les moyens de filtrage sont adaptés pour sélectionner seulement certaines ressources parmi ladite liste de ressources en fonction en outre du type de l'exigence logicielle correspondante ; 15 - les moyens de filtrage sont en outre adaptés pour sélectionner une syntaxe de l'exigence parmi plusieurs syntaxes possibles, notamment en fonction de l'objet graphique correspondant ; - les moyens de filtrage sont adaptés pour sélectionner la syntaxe de l'exigence en fonction en outre du type de l'exigence logicielle correspondante ; 20 - chaque document descriptif généré par le module de génération est conforme à des exigences de la norme RTCA DO-178C, chaque document descriptif étant de préférence choisi parmi le groupe consistant en : un document de spécification, un document de conception et un document de traçabilité d'exigences des documents de spécification et/ou de conception. 25 L'invention a également pour objet un procédé de génération d'au moins un fichier informatique parmi un code informatique et un document descriptif du code informatique, pour la réalisation d'au moins une partie d'une interface graphique d'un équipement électronique, le procédé étant mis en oeuvre par un ordinateur et comprenant les étapes 30 suivantes : - la création d'une description formalisée de l'interface graphique sous forme d'exigences logicielles, chaque exigence étant associée à un objet graphique de l'interface graphique et étant créée à partir d'une liste de ressources, - la génération, à partir de la description formalisée créée, d'au moins un fichier 35 informatique parmi un code source et un document descriptif du code source, le code source étant destiné à être compilé en un code exécutable pour la réalisation de ladite au 3021769 4 moins une partie de l'interface graphique de l'équipement électronique, le document descriptif contenant des informations relatives aux exigences logicielles, dans lequel l'étape de création comporte en outre le filtrage des ressources pour sélectionner, notamment en fonction de l'objet graphique correspondant, seulement 5 certaines ressources parmi ladite liste de ressources. Suivant un autre aspect avantageux de l'invention, le procédé de génération comprend la caractéristique suivante : le procédé comprend en outre, après l'étape de génération, une étape de compilation du code source généré en un code exécutable, le code exécutable étant apte 10 à être exécuté par l'équipement électronique pour réaliser ladite au moins une partie de l'interface graphique. L'invention a également pour objet un produit programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont mises en oeuvre par un ordinateur, mettent en oeuvre un procédé de génération tel que défini ci-dessus. 15 Ces caractéristiques et avantages de l'invention apparaîtront à 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 : - la figure 1 est une représentation schématique d'un équipement électronique embarqué comportant un premier écran d'affichage d'informations et une première unité 20 de traitement d'informations, formée d'un premier processeur et d'une première mémoire associée audit premier processeur, la première mémoire étant apte à stocker un noyau et une interface graphique, pour l'affichage d'informations sur le premier écran ; - la figure 2 est une représentation schématique d'une définition statique de l'interface graphique ; 25 - la figure 3 est une représentation schématique d'un dispositif de génération d'au moins un fichier informatique parmi un code informatique et au moins un document descriptif du code informatique, pour la réalisation d'au moins une partie de l'interface graphique ; - la figure 4 est un organigramme d'un procédé selon l'invention de génération 30 d'au moins un fichier informatique parmi le code informatique et les documents descriptifs ; et - la figure 5 est un organigramme plus détaillé d'une étape du procédé de la figure 4 pour créer une description formalisée de l'interface graphique sous forme d'exigences logicielles. 35 Sur la figure 1, un équipement électronique 10 comprend un premier écran d'affichage 12 et une première unité de traitement d'informations 14 formée par exemple 3021769 5 d'un premier processeur 14 et d'une première mémoire 16 associée au premier processeur 14. L'équipement électronique 10 est par exemple un équipement embarqué, tel qu'un équipement aéronautique, un équipement ferroviaire, un équipement automobile ou 5 encore un équipement spatial. La première mémoire 16 est apte à stocker un noyau 20, également appelé coeur système, rendant une liste de services logiciels et manipulant des données coeur, une première couche 22 de standardisation d'interfaces avec le noyau 20 (de l'anglais core wrapper), permettant d'utiliser des services logiciels mis à disposition par le noyau 20 et 10 de consulter/modifier les données coeur et une deuxième couche 24 de standardisation d'interfaces de gestion de messages (de l'anglais message manager). Les messages comportent des messages système et des messages utilisateur, la gestion des messages système étant effectuée par le coeur 20, et celle des messages utilisateur étant effectuée par la deuxième couche de standardisation 24. Par gestion des messages, on entend 15 notamment la publication et/ou l'effacement de ces messages. La première mémoire 16 est également apte à stocker une première bibliothèque 26 de formats de données (de l'anglais data format iibrary), un séquenceur 28 de l'interface graphique (de l'anglais component processing) et un navigateur 30 (de l'anglais browser). 20 La première mémoire 16 est aussi apte à stocker une deuxième bibliothèque 32 de définition d'objets graphiques (de l'anglais widget library), une troisième bibliothèque 34 d'encodage/de décodage d'informations (de l'anglais coding libraiy) et un gestionnaire de protocoles 36 (de l'anglais protocol manager). Les deuxième et troisième bibliothèques 32, 34 et le gestionnaire de protocoles 36 forment une couche 38 de gestion de l'affichage 25 de données à l'écran 12. La première mémoire 16 est enfin apte à stocker une couche spécifique 40. La première couche de standardisation 22, la deuxième couche de standardisation 24, la première bibliothèque 26, le séquenceur 28, le navigateur 30, la deuxième bibliothèque 32, la troisième bibliothèque 34, le gestionnaire de protocoles 36 et la couche 30 spécifique 40 sont chacun une brique logicielle. Les briques logicielles 22, 24, 28, 30 et 40 forment une instance d'interface homme-machine 41, également appelée instance d'IHM 41. L'ensemble des briques logicielles 22 à 40 forme un composant logiciel 42 de gestion d'une interface graphique 50 de l'équipement, ledit composant logiciel 42 étant 35 apte à être stocké dans la première mémoire 16, comme représenté sur la figure 1. L'interface graphique 50 comprend au moins un élément de plus haut niveau 52, 3021769 6 également appelé format, chaque format 52 comportant au moins une page 54, et chaque page 54 comporte au moins un objet graphique 56, comme cela sera décrit plus en détail par la suite en regard de la figure 2. L'équipement électronique 10 comporte alors par exemple N écran(s) 12 5 susceptible(s) d'afficher des interfaces graphiques 50 et la mémoire 18 comporte M instance(s) d'IHM 41 gérant chacune un format 52, N et M étant des nombres entiers supérieurs ou égaux à 1, par exemple supérieurs ou égaux à 2. Les valeurs des nombres N et M ne sont pas corrélées, N et M étant de valeurs distinctes ou bien égales. La première couche de standardisation 22 permet de gérer de manière 10 standardisée des interfaces avec le noyau 20 et fournit alors une manière générique de manipuler des listes et des objets interactifs. La deuxième couche de standardisation 24 permet de traiter de manière standardisée des interfaces de gestion des messages, notamment de gérer des listes d'alerte système générées par le noyau 20 ou encore des listes de messages utilisateur. 15 La première bibliothèque 26 contient des informations relatives à des formats de données saisies ou à afficher à travers l'interface graphique 50. Les informations contenues dans la première bibliothèque 26 sont multiples et dépendent des formats. Parmi les informations relatives à chaque format figurent par exemple un type du format, un intervalle de valeurs autorisées pour les données du format, une taille du format. Pour 20 le formatage d'un angle, il faut par exemple spécifier l'unité de la valeur en entrée et celle de la valeur en sortie du formatage, afin d'être convertie si nécessaire. Pour formater une donnée numérique du coeur en une chaine de caractères à afficher, il faut par exemple préciser un nombre maximal de caractères à conserver après la virgule, ou encore s'il faut combler avec des 0 pour atteindre une taille maximale de la chaine. 25 Le séquenceur 28 est adapté pour recevoir, filtrer et séquencer les événements issus du gestionnaire de protocoles 36 ou du noyau 20, les évènements étant par exemple une action de l'utilisateur sur l'interface graphique 50, une connexion/déconnexion. Le séquenceur 28 est apte à solliciter la couche spécifique 40 qui, elle, va s'appuyer sur la première bibliothèque 26, respectivement le navigateur 30, 30 les première et deuxième couches de standardisation 22 et 24, la deuxième bibliothèque 32, pour formater les données manipuler, respectivement changer de page, récupérer des données ou déclencher des traitements dans le noyau 20, récupérer/publier/supprimer des messages, modifier les propriétés d'objets graphiques. Après cette sollicitation, le séquenceur 28 est apte à ordonner au gestionnaire de protocoles 36 d'envoyer des 35 trames à destination de l'écran 12. 3021769 7 Le navigateur 30 est adapté pour gérer un historique de pages 54 (figure 2) affichées à l'écran 12, et également pour gérer des services d'affichage, tel que le rafraîchissement ou la fermeture des pages 54. La deuxième bibliothèque 32 est adaptée pour définir de manière standardisée 5 l'affichage de l'interface graphique 50 de la figure 2, en particulier de vignettes actives (de l'anglais widget), par exemple selon la norme ARINC 661, ou encore selon la norme ARINC 739. La deuxième bibliothèque 32 comporte notamment des informations relatives au type et aux propriétés des objets graphiques. La troisième bibliothèque 34 fournit des services d'encodage ou de décodage 10 d'informations contenues dans des mémoires tampon (de l'anglais buffer), et est alors adaptée pour encoder des informations à destination de l'écran 12 et/ou pour décoder des informations reçues de l'écran 12. Le gestionnaire de protocoles 36 est adapté pour gérer la réception, respectivement l'envoi, de trames en provenance du ou des écrans 12, respectivement à 15 destination du ou des écrans 12. Le gestionnaire de protocoles 36 est en particulier adapté pour rediriger les communications en provenance d'un écran 12 vers le séquenceur 28 de l'instance d'IHM 41 correspondante et inversement de renvoyer les trames élaborées par la couche spécifique 40 d'une instance d'IHM 21 vers l'écran 12 correspondant. 20 Le gestionnaire de protocoles 36 comprend une table, non représentée, contenant un identifiant respectif pour chacun des écrans 12 et pour chacune des instances d'IHM 41, la table faisant le lien entre le ou les écrans 12 et la ou les instances d'IHM 41 correspondantes. Le gestionnaire de protocoles 36 est, par exemple, conforme à la partie 4.0 25 intitulée « Communication Protocol » de la norme ARINC 661. La couche spécifique 40 est spécifique de l'interface graphique 50, et est distincte d'une interface graphique à l'autre. La couche spécifique 40 est apte à être générée par un dispositif 60 (figure 3) de génération d'au moins un fichier informatique parmi un code informatique et au moins un document descriptif du code informatique. Autrement dit, la 30 couche spécifique 40 correspond à un code exécutable compilé à partir d'un code source, le code source étant propre à être généré par le dispositif de génération 60. Le code exécutable est propre à être compilé également par le dispositif de génération 60 et à partir du code source généré. La couche spécifique 40 contient une liste des pages 54, une définition dynamique 35 de chacune des pages 54, la définition dynamique précisant le comportement dynamique des pages 54 en fonction de services ou d'évènements pris en charge par la deuxième 3021769 8 bibliothèque 32, le navigateur 30, les première et deuxième couches de standardisation 22, 24 et la première bibliothèque 26. La couche spécifique 40 contient également un contexte de l'interface graphique 50, c'est-à-dire les données partagées entre les pages 54, une liste des messages 5 utilisateur et une liste des formats de données. Cette architecture logicielle du composant logiciel 42 de gestion de l'interface graphique, le composant 42 comportant les briques logicielles 22 à 40, permet alors une gestion standardisée du noyau 20. Cette architecture logicielle permet également une gestion standardisée de l'écran 10 12 et/ou des normes d'affichage via : - la gestion, par le gestionnaire 36, du protocole de réception, respectivement d'envoi, des trames en provenance, respectivement à destination, de l'écran 12, - la bibliothèque 34 de décodage, respectivement d'encodage, des trames 15 reçues, respectivement à envoyer, et - des services standardisés de manipulation des propriétés d'objets graphiques 56 de par la deuxième bibliothèque 32. Cette architecture logicielle permet en outre la gestion de la navigation via le navigateur 30, la gestion du formatage de données à afficher ou saisies par l'opérateur 20 via la première bibliothèque 26 et la gestion standardisée de messages via la deuxième couche de standardisation 24. La figure 2 illustre une définition statique de l'interface graphique 50. Comme décrit précédemment, l'interface graphique 50 comprend un ou plusieurs formats 52, chaque format 52 comportant lui-même une ou plusieurs pages 54, et chaque page 54 25 comporte un ou plusieurs objets graphiques 56. Le format 52 est assimilable à un calque regroupant un ensemble d'informations et d'interactions cohérentes en termes de fonctionnalités affichées et de rendu graphique, un premier format 52 étant par exemple dédié à l'affichage cartographique et un deuxième format 52 étant par exemple dédié à l'affichage textuel. 30 Chaque page 54 comporte un sous-ensemble cohérent d'objets graphiques 56 en termes de fonctionnalités, l'objet graphique 56 étant l'élément de plus bas niveau et permettant des interactions avec un utilisateur et l'affichage d'informations à l'attention de l'utilisateur. Chaque objet graphique 56 est caractérisé par des propriétés et des interactions, 35 et le pilotage de ces propriétés permet d'offrir à l'utilisateur lesdites informations et lesdites interactions. 3021769 9 L'objet graphique 56 est par exemple une étiquette (de l'anglais label), et ses propriétés comportent alors une taille, une position, une visibilité et un texte associé. Aucune interaction n'est associée à l'objet graphique 56 lorsque celui-ci est une étiquette. L'objet graphique 56 est par exemple un bouton, et ses propriétés comportent 5 dans ce cas une taille, une position, une visibilité, un texte associé et un état relatif à la possibilité d'activer ou non le bouton formant l'objet graphique 56. Une interaction associée à l'objet graphique 56, lorsque celui-ci est un bouton, est une sélection de l'objet graphique 56. L'objet graphique 56 est par exemple un champ de saisie, et ses propriétés 10 comportent alors une taille, une position, une visibilité, un texte par défaut et un état relatif à la possibilité d'activer ou non le champ de saisie formant l'objet graphique 56. Des interactions associées à l'objet graphique 56, lorsque celui-ci est un champ de saisie, sont une entrée en édition, une saisie d'un caractère, une validation d'une chaine saisie et une annulation de l'édition. 15 L'objet graphique 56 est par exemple une coche, et les propriétés associées à la coche sont une taille, une position, une visibilité, un état relatif à la possibilité d'activer ou non la coche formant l'objet graphique 56, et un état de sélection. L'état de sélection présente deux valeurs possibles, à savoir un état actif correspondant à une coche sélectionnée et un état inactif correspondant à une coche désélectionnée. Des 20 interactions associées à l'objet graphique 56, lorsque celui-ci est une coche, sont une sélection de la coche lorsque l'état de sélection est l'état inactif, et une désélection de la coche lorsque l'état de sélection est l'état actif. Sur la figure 3, le dispositif de génération 60 comprend un deuxième écran d'affichage 62, des moyens 64 de saisie de données et une deuxième unité de traitement 25 d'informations 66 formée par exemple d'une deuxième mémoire 68 et d'un deuxième processeur 70 associé à la deuxième mémoire 68. Les moyens de saisie et de sélection 64 sont adaptés pour saisir notamment des caractères alphanumériques, et comportent par exemple un clavier et une souris. La deuxième mémoire 68 est apte à stocker une application logicielle 72 de 30 création d'une description formalisée de l'interface graphique 50 sous forme d'exigences logicielles, chaque exigence logicielle étant associée à un objet graphique 56 et étant créée à partir d'une liste de ressources 74. Dans l'exemple de réalisation de la figure 3, la deuxième mémoire 68 est configurée pour stocker la liste de ressources 74. En variante non représentée, la liste de 35 ressources 74 est stockée dans une mémoire, non représentée, externe au dispositif de génération 60. 3021769 10 La deuxième mémoire 68 est également apte à stocker une application logicielle 76 de génération, à partir de la description formalisée créée, d'au moins un fichier informatique parmi un code source et au moins un document descriptif du code source. En complément facultatif, la deuxième mémoire 68 est apte à stocker une 5 application logicielle 78 de compilation du code source généré en un code exécutable, le code exécutable étant apte à être exécuté par l'équipement électronique 10 pour réaliser au moins une partie l'interface graphique 50. Dans l'exemple de réalisation décrit, le code exécutable correspond alors à la couche spécifique 40 visible sur la figure 1. L'application logicielle de création 72, l'application logicielle de génération 76 et 10 l'application logicielle de compilation 78 forment chacune respectivement un module de création, un module de génération et un module de compilation. En variante non représentée, le module de création 72, le module de génération 76 et le module de compilation 78 sont réalisés sous forme de composants logiques programmables ou encore sous forme de circuits intégrés dédiés. 15 Le module de création 72 est adapté pour créer la description formalisée de l'interface graphique 50, c'est-à-dire pour établir une définition dynamique de l'interface graphique 50. Cette définition dynamique permet de définir la manière dont l'interface graphique 50, en réaction à un ensemble de stimulations en provenance de l'utilisateur, du noyau 20 20 et/ou encore de l'écran 12, déclenche des traitements liés à la réception de chacune de ces stimulations, puis met à jour l'affichage de données à l'écran 12. La mise à jour de l'affichage consiste à afficher une ou plusieurs nouvelles pages 54 ou bien à rafraîchir la ou les pages 54 actuelles, plusieurs pages 54 pouvant être affichées simultanément. Le déclenchement des traitements liés à la réception de stimulations est assuré à 25 différents niveaux de la structure de l'interface graphique 50. A titre d'exemple, chaque format 52 prend en charge la réception d'événements provenant d'un équipement de visualisation, tel que l'écran d'affichage 12, ces événements étant par exemple la connexion ou encore la déconnexion de l'équipement de visualisation. Chaque page 54 prend en charge la réception de stimulations, telles que des événements et des retours de 30 commandes (déclenchées précédemment) en provenance du noyau 20, l'expiration d'une temporisation (par exemple pour le rafraîchissement périodique de l'affichage), ou encore des événements de page (par exemple une entrée ou une sortie de la page 54). Chaque objet graphique 56 prend en charge la réception d'interactions le concernant, telles qu'un appui sur un bouton, la saisie d'informations relatives à cet objet graphique 56. 35 En complément facultatif, l'affichage et le rafraîchissement des pages 54 sont optimisés par l'utilisation d'une configuration de référence (de l'anglais layout). 3021769 11 L'introduction de la notion de configuration de référence permet, après affichage de cette configuration, de faciliter le rafraichissement de l'affichage en réélaborant inconditionnellement un sous-ensemble restreint, connu pour cette configuration, d'objets graphiques 56 et de propriétés associées. Dans un mode de consultation, la page 5 correspondante 54 présente alors des objets graphiques 56 non modifiables. La configuration de référence de chaque page 54 est modifiable dans un mode de modification, pour lequel les objets graphiques 56 sont éditables, leurs propriétés étant modifiables. Selon une variante, une façon de rafraichir l'interface graphique 50 consiste à 10 réélaborer inconditionnellement toutes les propriétés de tous les objets graphiques 56 et ce pour chaque événement susceptible de modifier cette interface graphique 50. Cette réélaboration complète est toutefois consommatrice de ressources informatiques (CPU, RAM) et est alors susceptible de saturer la communication vers l'écran 12. Selon une autre variante, une autre façon de rafraichir l'interface graphique 50 est 15 de déterminer précisément, en fonction du contexte et en fonction de l'événement reçu, quels sont les objets graphiques 56 et quelles sont les propriétés à réélaborer, et de les réélaborer en conséquence, et ce pour chaque événement susceptible de modifier cette interface graphique 50. Cette réélaboration est optimisée, mais le calcul du ciblage des objets 56 et propriétés à réélaborer est toutefois également consommateur de ressources 20 informatiques (CPU). Selon l'invention, le module de création 72 comporte des moyens de filtrage 80 adapté pour sélectionner seulement certaines ressources parmi la liste de ressources 74, la sélection étant notamment fonction de l'objet graphique correspondant, voire en complément facultatif, fonction de l'événement à spécifier. 25 Parmi les exigences logicielles formant la description formalisée de l'interface graphique 50, au moins une exigence logicielle comporte un champ à remplir. Le module de création 72 comporte, en complément facultatif, des moyens 82 d'acquisition, uniquement sous forme d'une chaîne de caractères alphanumériques, de données du champ. Le cas échéant, les caractères alphanumériques acquis sont par exemple reçus 30 des moyens de saisie 64. Chaque champ à remplir est rempli à l'aide des moyens de filtrage 80 et/ou des moyens d'acquisition 82. Dans l'exemple de réalisation de la figure 3, le module de création 72 est réalisé sous forme d'une application logicielle comme décrit précédemment, et les moyens de filtrage 80, respectivement les moyens d'acquisition 82, sont alors réalisés sous forme de 35 fonctions logicielles respectives, incluses dans ladite application logicielle. 3021769 12 La liste de ressources 74 comprend des types caractérisés par leur classe, par leurs contraintes et par leurs opérateurs associés. La classe est par exemple un nombre entier, un nombre flottant, un booléen, une chaine de caractères, un énuméré, un tableau, ou encore un objet. Les contraintes sont, par exemple, des bornes (pour entier et flottant), 5 une taille et des caractères autorisés/interdits (pour chaine de caractères), des valeurs possibles (pour énuméré), une taille et un type d'élément contenu (pour tableau). Les opérateurs sont, par exemple, des opérateurs de comparaison, des opérateurs d'opération, tels que des opérateurs d'opération mathématique (multiplication, division..), des opérateurs sur les chaines (concaténation...). 10 Les ressources sont des éléments inclus dans les bibliothèques 26, 32, 34, le navigateur 30 et les couches de standardisations 22, 24 et accessibles par la couche spécifique 40 pour effectuer les traitements qui lui incombent. De manière générale, chaque ressource contient des informations relatives à : - son affichage en tant que morceau d'exigence (motif de texte), ceci étant utile 15 pour la génération de documentation et l'affichage lors de la création de l'exigence ; et - ses caractéristiques techniques, ceci étant utile pour la génération de code, le filtrage et la création de l'exigence. La liste de ressources 74 comprend également des commandes caractérisées par leur signature complète, leur type - à savoir synchrone ou asynchrone - et par leur retour 20 associé de commande s'il existe. La signature d'une commande est la liste des paramètres en entrée et sortie de la commande, cette commande étant par exemple un service du coeur 20, une commande du navigateur 30, une commande de la deuxième bibliothèque 32, une commande du gestionnaire de messages 34. La liste de ressources 74 comprend aussi des retours de commande caractérisés 25 par leurs statuts possibles de fin de commande et leurs données retournées, également appelées données renvoyées. Les statuts de commandes dépendent des commandes elles-mêmes. De manière générale, il va s'agir de déclinaisons de statuts « succès de la commande » (ou encore `OK') et « échec de la commande » (ou encore '1(0'), voire en complément de la raison du rejet liée au coeur 20 (saturation d'une pile, erreur de syntaxe, 30 utilisation d'une donnée non connue du coeur, erreur de borne sur une unité etc.). La liste de ressources 74 comprend des événements caractérisés par leurs raisons associées et par leurs données retournées. Les raisons des événements sont le pendant des statuts de commandes. Elles dépendent de l'événement et indiquent pour quelle raison cet événement a été levé. Un événement est généré par le noyau 20 ou 35 encore par l'utilisateur via le gestionnaire de protocoles 36. 3021769 13 La liste de ressources 74 comprend des données caractérisées par la signature complète de l'accesseur, le type de la donnée, la présence éventuelle d'une validité associée. La liste de ressources 74 comprend des listes de données caractérisées par le 5 type des données et les filtres disponibles. La liste de ressources 74 comprend des éléments interactifs caractérisés par leur type. Un élément interactif est défini sous forme d'une variable globale, susceptible d'être de n'importe quel type défini dans les ressources. En complément, les types d'éléments interactifs sont limités à un sous-ensemble de types en fonction de l'interface graphique 10 50. En complément, dans le cas particulier des formatages de données, la liste de ressources 74 comprend en outre des catégories de formatages de données caractérisées par leur nom, les paramètres du formatage (nom, type), les résultats du formatage (nom, type). Un résultat du formatage est le statut du formatage, tel que 15 succès, erreur de format, hors-domaine. Un autre résultat du formatage dépend du format lui-même. A titre d'exemple, pour un formatage de donnée à afficher, cet autre résultat du formatage est une chaine de caractère du même type qu'attendu par la propriété de l'objet graphique à renseigner. A titre d'exemple additionnel, pour un formatage d'une donnée numérique saisie, cet autre résultat du formatage est la donnée convertie dans 20 l'unité correspondante, potentiellement arrondie et donc du type étendu par la commande coeur à renseigner. Selon ce complément relatif aux formatages de données, la liste de ressources 74 comprend en outre des formats de données caractérisés par leur nom, la catégorie de formatage instanciée et les valeurs pour une partie ou la totalité des paramètres de la 25 catégorie instanciée. En complément, dans le cas particulier des messages, la liste de ressources 74 comprend en outre des catégories de messages caractérisées par leurs nom et droit d'instanciation et une structure composée de champs (nom, droit de modification, type). Selon ce complément relatif aux messages, la liste de ressources 74 comprend en 30 outre des messages caractérisés par leurs nom, droit de modification et catégorie. Par catégorie, on entend un ensemble de messages qui sont gérés de la même manière. A titre d'exemple, les messages de la catégorie 'utilisateur' ont des propriétés qui leur sont propres et peuvent être publiés ou effacés par la couche spécifique 40. Les messages de type 'système' sont caractérisés différemment et n'ont pas de commandes pour les 35 publier, ceux-ci étant directement publiés par le noyau 20. Les droits de modification permettent de contraindre le spécificateur ou concepteur dans sa gestion des messages 3021769 14 via le module de création 72. Suivant l'exemple précédent, les messages 'système' sont définis par le noyau 20 et ne peuvent donc être créés, modifiés, supprimés par la couche spécifique 40. De manière analogue, certaines de leurs propriétés ne sont pas modifiables par la couche spécifique 40. A l'inverse, les messages 'utilisateur' sont 5 susceptibles d'être créés, supprimés et modifiés par la couche spécifique 40. La liste de ressources 74 est initialement une liste prédéfinie qui caractérise les première et deuxième couches de standardisation 22 et 24, les bibliothèques 32 et 26, le navigateur 30 ainsi que la définition statique de l'interface graphique 50, définie au préalable. En complément, la liste de ressources 74 est configurée pour être enrichie, 10 notamment par le module de création 72, via l'ajout notamment de listes de données, de messages, de formats de données et d'éléments interactifs. Le module de génération 76 est alors adapté pour générer, à partir de la description formalisée créée par le module de création 72, au moins un fichier informatique parmi le code source et le ou les documents descriptifs du code source. 15 Le code source généré est destiné à être compilé, par exemple via le module de compilation 78, en code exécutable pour la réalisation d'au moins une partie de l'interface graphique 50 de l'équipement électronique 10. Chaque document descriptif généré contient des informations relatives aux exigences logicielles. Chaque document descriptif généré par le module de génération 76 20 est, par exemple, conforme aux exigences correspondantes de la norme internationale RTCA DO-178C, et est apte à contribuer à la certification de l'interface graphique 50 correspondante selon la norme internationale RTCA DO-178C. A titre d'exemple, le module de génération 76 est alors adapté pour générer trois documents descriptifs, à savoir un document de spécification comportant des exigences 25 de haut niveau (High Level Requirements), un document de conception comportant des exigences de bas niveau (Low Level Requirements), et un document de traçabilité d'exigences des documents de spécification et/ou de conception. Le document de traçabilité permet de vérifier par exemple qu'à chaque exigence de haut niveau correspond au moins une exigence de bas niveau. En complément ou en variante, le 30 document de traçabilité permet de vérifier des liens entre des éléments de code source (constantes, procédures, fichiers sources, types) et les exigences de bas niveau. Le document de traçabilité permet alors de démontrer que chaque exigence de haut niveau a bien été prise en compte lors de la conception, et est un élément important pour la certification RTCA DO-178C. Le module de compilation 78 est connu en soi, et est adapté 35 pour compiler le code source généré par le module de génération 76 en code exécutable, le code exécutable étant, par exemple, destiné à être exécuté par l'équipement 3021769 15 électronique 10, en particulier par le premier processeur 16, pour la mise en oeuvre de l'interface graphique 50. Les moyens de filtrage 80 sont configurés pour sélectionner seulement certaines ressources parmi la liste de ressources 74, telle que la liste décrite précédemment à titre 5 d'exemple. La sélection effectuée par les moyens de filtrage 80 est notamment fonction de l'objet graphique 56 pour lequel l'exigence logicielle est créée. La sélection est, par exemple, effectuée en fonction des propriétés de l'objet graphique 56. Chaque exigence logicielle est choisie parmi le groupe consistant en : une 10 exigence d'affichage initial, une exigence de rafraîchissement d'affichage, une exigence d'interaction associée à l'objet graphique et une exigence de traitement d'un évènement. En d'autres termes, le groupe précité contient les différents types possibles d'exigences logicielles associées aux objets graphiques 56 de l'interface graphique. En complément facultatif, les moyens de filtrage 80 sont alors configurés pour 15 sélectionner, en fonction en outre du type de l'exigence logicielle correspondante, seulement certaines ressources parmi la liste des ressources 74. À titre d'exemple, dans le cas d'une exigence de rafraîchissement d'affichage, les seules commandes disponibles pour la création de l'exigence logicielle sont des commandes de gestion des propriétés de l'objet graphique 56 correspondant. À titre d'exemple complémentaire, dans le cas d'une 20 exigence d'interaction associée à l'objet graphique, toutes les commandes sont disponibles pour la création de l'exigence logicielle hormis les commandes de gestion des propriétés de l'objet graphique 56 correspondant. En complément facultatif encore, lorsque l'exigence logicielle à créer comporte un champ à remplir, les moyens de filtrage 80 sont configurés pour sélectionner seulement 25 certaines ressources parmi la liste des ressources 74 en fonction en outre du type du champ à remplir. À titre d'exemple, lorsque l'exigence logicielle à créer comporte une comparaison entre un premier champ et un deuxième champ, les seules données autorisées pour le deuxième champ sont des données du même type que celle du premier champ. 30 En complément facultatif, les moyens de filtrage 80 sont en outre configurés pour sélectionner une syntaxe de l'exigence parmi plusieurs syntaxes possibles, notamment en fonction de l'objet graphique correspondant. Par syntaxe, on entend un ensemble de locutions conditionnées, chaque locution conditionnée comportant un opérateur conditionnel, tel qu'IF, THEN, ELSEIF, ELSE, FOR, WHILE, suivi d'une condition et/ou 35 d'une action associée. 3021769 16 Selon ce complément facultatif, les moyens de filtrage 80 sont de préférence adaptés pour sélectionner la syntaxe de l'exigence en fonction en outre du type de l'exigence logicielle correspondante. Lorsque l'exigence à créer est une exigence asynchrone avec au moins un retour 5 de commande, alors les moyens de filtrage 80 sont en outre adaptés pour forcer le concepteur à renseigner le comportement attendu pour chaque retour de commande. Autrement dit, les moyens de filtrage 80 sont alors adaptés pour bloquer la génération, ou validation, d'une telle exigence tant que tous les retours de commande n'ont pas été renseignés par le concepteur. 10 Le fonctionnement du dispositif de génération 60 selon l'invention va désormais être expliqué à l'aide de la figure 4 illustrant un organigramme du procédé, selon l'invention, de génération d'au moins un fichier informatique parmi le code informatique et le ou les documents descriptifs du code informatique. Lors d'une étape initiale 100, la définition statique de l'interface graphique 50 est 15 créée, l'interface graphique 50 comportant, selon la définition statique créée, des format(s) 52, page(s) 54 et objets graphiques 56, comme décrit précédemment en regard de la figure 2. Lors d'une étape suivante 105, la description formalisée de l'interface graphique 50 est créée sous forme d'exigences logicielles via le module de création 72. Cette étape 20 de création 105 sera décrite plus en détail par la suite à l'aide de la figure 5. Lors de l'étape suivante 110, le ou les documents descriptifs de l'interface graphique 50 sont générés automatiquement via le module de génération 76, à partir de la description formalisée créée lors de l'étape 105. Dans l'exemple de réalisation décrit, les documents créés automatiquement correspondent aux deux niveaux de spécification 25 exigés par la norme DO-178C. Lors de l'étape suivante 120, le code source d'au moins une partie de l'interface graphique 50 est généré automatiquement via le module de génération 76, à partir de la description formalisée créée lors de l'étape 105. Dans l'exemple de réalisation décrit, le code source généré correspond à celui de la couche spécifique 40, les autres briques 30 logicielles 22 à 36 du composant logiciel 42 étant préexistantes dans cet exemple de réalisation et étant de préférence communes d'une interface graphique 50 à l'autre. Enfin, lors de l'étape 130, le code source généré lors de l'étape 120 précédente est compilé en code exécutable via le module de compilation 78, par exemple pour être chargé dans la première mémoire 18 de l'équipement électronique 10, puis pour être 35 exécuté par le premier processeur 16, afin de mettre en oeuvre l'interface graphique 50. 3021769 17 L'étape de création de la description formalisée 105 va être à présent décrite en regard de la figure 5. L'étape de création 105 comprend une sous-étape 200 de sélection d'un format 52, puis pour chaque format 52 sélectionné, la construction des exigences logicielles 5 spécifiant les traitements à réaliser sur réception de chaque événement provenant d'un équipement de visualisation, tel que le premier écran 12, cette construction étant effectuée via une sous-étape 210 de sélection d'un événement, puis une sous-étape 220 de création de l'exigence logicielle pour l'événement sélectionné. L'étape de création 105 comprend ensuite, pour chaque format 52 sélectionné, 10 une sous-étape 230 de sélection d'une page correspondante 54. Pour chaque page 54 sélectionnée, l'étape de création 105 comprend une sous-étape 240 de définition des configurations de référence (de l'anglais layout), également appelées agencements de référence. Pour chaque page 54 sélectionnée, l'étape de création 105 comprend la construction des exigences logicielles spécifiant les traitements réalisés sur réception de 15 chaque événement et de chaque retour de commande provenant du noyau 20, et de chaque événement de page, cette construction étant effectuée via une sous-étape 250 de sélection d'un événement, puis une sous-étape 260 de création de l'exigence logicielle pour l'événement sélectionné. L'étape de création 105 comprend ensuite, pour chaque page 54 sélectionnée, 20 une sous-étape 270 de sélection d'un objet graphique 56. Pour chaque objet graphique 56 sélectionné, l'étape de création 105 comprend alors la construction des exigences logicielles spécifiant les traitements à réaliser sur réception de chacune des interactions associées à l'objet graphique 56 correspondant, ainsi que les mises à jour des propriétés de l'objet graphique 56 à réaliser sur réception 25 des commandes d'affichage et de rafraichissement de page pour chaque configuration de référence (de l'anglais layout), cette construction étant effectuée via une sous-étape 280 de sélection d'un événement, puis une sous-étape 290 de création de l'exigence logicielle pour l'événement sélectionné. Lorsque l'exigence à créer est une exigence comportant au moins un retour de 30 commande, alors les moyens de filtrage 80 forcent le concepteur à renseigner le comportement attendu pour chaque retour de commande. Le champ d'un retour de commande correspondant est si besoin complété par une information indiquant une absence d'action, telle qu'une information appelée « NOTHING_TO_DO », lorsqu'il n'y a rien à faire pour le retour de commande associé. 35 Lors de l'étape de création 105, le module de création 72 permet à l'utilisateur de créer les exigences logicielles correspondantes via une interface homme-machine, non 3021769 18 représentée, découpée en quatre zones à titre d'exemple. Une première zone permet de sélectionner l'élément à éditer ou à consulter, c'est-à-dire le format 52, la page 54 ou l'objet graphique 56, pour la construction des exigences logicielles. Une deuxième zone permet d'éditer, c'est-à-dire de créer ou de modifier, l'exigence pour l'élément sélectionné 5 parmi le format 52, la page 54 et l'objet graphique 56. Une troisième zone présente les ressources disponibles parmi la liste des ressources 74 pour l'édition de l'exigence. Autrement dit, les ressources présentées dans cette troisième zone sont les ressources préalablement sélectionnées par les moyens de filtrage 80. Enfin, une quatrième zone permet de naviguer dans la description formalisée en cours de création, en présentant le 10 résultat d'une recherche, le résultat d'une compilation, les éléments liés à celui sélectionné sous forme d'hyperliens. Ainsi, avec le dispositif de génération 60 selon l'invention et le procédé de génération associée, le concepteur est assisté dans la réalisation de l'interface graphique 50, en étant guidé au plus tôt, en particulier dès la création des exigences logicielles, le 15 dispositif de génération 60 proposant au concepteur seulement une liste restreinte de ressources pour la création des exigences logicielles, la liste restreinte ayant été filtrée par les moyens de filtrage 80. Cela permet également de s'assurer au plus tôt, à savoir dès la création des exigences logicielles, que les contraintes associées à l'interface graphique de 20 l'équipement embarqué 10 sont bien vérifiées, et non pas seulement une fois que ces exigences ont été converties en la ou les spécifications formelles comme cela est fait avec le dispositif de l'état de la technique. La liste des ressources 74 est en outre configurable est susceptible d'être enrichie par le dispositif de génération 60, en particulier par le module de création 72. 25 Les exigences logicielles sont directement saisies sous forme textuelle et sont considérées comme des spécifications formelles. L'interface graphique 50 est alors créée suivant un processus en deux étapes, à savoir une définition statique, suivie d'une définition dynamique, la définition statique de l'interface graphique 50 comportant la structuration de l'interface graphique 50 autour de 30 notions de formats 52 contenant des pages 54, ces pages 54 étant elles-mêmes composées d'objets graphiques 56. La définition dynamique de l'interface graphique 50 correspond à l'étape 105 de création de la description formalisée de l'interface graphique 50. Le dispositif de génération 60 comporte une interface homme-machine de saisie 35 d'exigences textuelles par sélection. 3021769 19 Le dispositif de génération 60 couvre et facilite alors le développement industriel d'un logiciel en cinq phases pour la partie descendante du cycle en V, à savoir la spécification client, la spécification système, la spécification formelle logicielle, la conception formelle et la génération du code. 5 Enfin, le dispositif de génération 60 est qualifié, garantissant que ce qui est défini dans la documentation générée est entièrement implémenté, et que ce qui est implémenté est entièrement spécifié. Le dispositif de génération 60 permet donc d'économiser les phases de revues et de tests liées à la norme RTCA DO-178C. Le dispositif de génération 60 permet au final de diminuer le coût de réalisation de 10 l'interface graphique 50, de garantir la conformité du code généré avec la spécification générée (et inversement), et de réduire l'effort de certification du code généré et de la documentation associée. On conçoit ainsi que le dispositif de génération 60 et le procédé de génération selon l'invention permettent de faciliter la réalisation d'au moins une partie de l'interface 15 graphique 50, notamment la génération du code source ou de la documentation associée, en aidant le concepteur à créer des exigences logicielles, puis en générant automatiquement le code source et/ou la documentation associée à partir des exigences logicielles créées. REVENDICATIONS1.- Dispositif électronique (60) de génération d'au moins un fichier informatique parmi un code informatique et au moins un document descriptif du code informatique, pour la réalisation d'au moins une partie d'une interface graphique (50) d'un équipement électronique (10), le dispositif (60) comprenant : - un module (72) de création d'une description formalisée de l'interface graphique (50) sous forme d'exigences logicielles, chaque exigence étant associée à un objet graphique (56) de l'interface graphique (50) et étant créée à partir d'une liste de ressources (74), et - un module (76) de génération, à partir de la description formalisée créée, d'au moins un fichier informatique parmi un code source et au moins un document descriptif du code source, le code source étant destiné à être compilé en un code exécutable (40) pour la réalisation de ladite au moins une partie de l'interface graphique (50) de l'équipement électronique (10), chaque document descriptif contenant des informations relatives aux exigences logicielles, caractérisé en ce que le module de création (72) comporte des moyens de filtrage (80) adaptés pour sélectionner, notamment en fonction de l'objet graphique (56) correspondant, seulement certaines ressources parmi ladite liste de ressources (74). 2.- Dispositif (60) selon la revendication 1, dans lequel le dispositif (60) comprend en outre un module (78) de compilation du code source généré en un code exécutable (40), le code exécutable (40) étant apte à être exécuté par l'équipement électronique (10) pour réaliser ladite au moins une partie de l'interface graphique (50). 3.- Dispositif (60) selon la revendication 1 ou 2, dans lequel au moins une exigence logicielle comporte un champ à remplir ; et dans lequel les moyens de filtrage (80) sont adaptés pour sélectionner seulement certaines ressources parmi ladite liste de ressources (74) en fonction en outre du type du champ. 4.- Dispositif (60) selon la revendication 3, dans lequel le module de création (72) comporte en outre des moyens (82) d'acquisition, uniquement sous forme d'une chaîne de caractères alphanumériques, des données du champ. 3021769 21 5.- Dispositif (60) selon l'une quelconque des revendications précédentes, dans lequel chaque exigence logicielle est choisie parmi le groupe consistant en : une exigence d'affichage initial, une exigence de rafraîchissement d'affichage, une exigence d'interaction associée à l'objet graphique et une exigence de traitement d'un évènement. 5 6.- Dispositif (60) selon la revendication 5, dans lequel les moyens de filtrage (80) sont adaptés pour sélectionner seulement certaines ressources parmi ladite liste de ressources (74) en fonction en outre du type de l'exigence logicielle correspondante. 10 7.- Dispositif (60) selon l'une quelconque des revendications précédentes, dans lequel les moyens de filtrage (80) sont en outre adaptés pour sélectionner une syntaxe de l'exigence parmi plusieurs syntaxes possibles, notamment en fonction de l'objet graphique (56) correspondant. 15 8.- Dispositif (60) selon les revendications 5 et 7, dans lequel les moyens de filtrage (80) sont adaptés pour sélectionner la syntaxe de l'exigence en fonction en outre du type de l'exigence logicielle correspondante. 9.- Dispositif (60) selon l'une quelconque des revendications précédentes, dans 20 lequel chaque document descriptif généré par le module de génération (76) est conforme à des exigences de la norme RTCA DO-178C, chaque document descriptif étant de préférence choisi parmi le groupe consistant en : un document de spécification, un document de conception et un document de traçabilité d'exigences des documents de spécification et/ou de conception. 25 10.- Procédé de génération d'au moins un fichier informatique parmi un code informatique et un document descriptif du code informatique, pour la réalisation d'au moins une partie d'une interface graphique (50) d'un équipement électronique (10), le procédé étant mis en oeuvre par un ordinateur (66) et comprenant les étapes 30 suivantes : - la création (105) d'une description formalisée de l'interface graphique (50) sous forme d'exigences logicielles, chaque exigence étant associée à un objet graphique (56) de l'interface graphique (50) et étant créée à partir d'une liste de ressources (74), - la génération (110, 120), à partir de la description formalisée créée, d'au moins 35 un fichier informatique parmi un code source et un document descriptif du code source, le code source étant destiné à être compilé en un code exécutable pour la réalisation de 3021769 22 ladite au moins une partie de l'interface graphique (50) de l'équipement électronique (10), le document descriptif contenant des informations relatives aux exigences logicielles, caractérisé en ce que l'étape de création (105) comporte en outre le filtrage des ressources pour sélectionner, notamment en fonction de l'objet graphique (56) correspondant, seulement certaines ressources parmi ladite liste de ressources (74). 11.- Procédé selon la revendication 10, dans lequel le procédé comprend en outre, après l'étape de génération (120), une étape (130) de compilation du code source généré en un code exécutable, le code exécutable étant apte à être exécuté par l'équipement 10 électronique (10) pour réaliser ladite au moins une partie de l'interface graphique (50). 12.- Produit programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont mises en oeuvre par un ordinateur, mettent en oeuvre un procédé de génération selon la revendication 10 ou 11. 15