Brevet FR2879785A1 — publié le 20060623

LIBRAIRIE STRUCTURANTE POUR LE DEVELOPPEMENT D'INTERFACES HOMME-MACHINE La présente invention se rapporte à une librairie structurante ( Framework en anglais) pour le développement d'interfaces homme-machine (IHM ou HCI en anglais: Humain Computer Interface ). Les interfaces homme-machine actuelles comportent très souvent une grande quantité de code logiciel caché. On considère généralement qu'environ 20% du code applicatif est visible à l'utilisateur, les 80% restants correspondent à du code caché (incluant en particulier la supervision technique des événements, des services, des notifications de données push/pull (, gestion de collections, des proxys -qui sont des images locales d'objets distants-, des transformations de données telles que la projection objet-objet, dite mapping en anglais, etc.). Les développeurs d'interfaces homme-machine conçoivent des applications en étudiant leur structure ou architecture, en prenant en compte les événements dynamiques et en implémentant les fonctions spécifiées. Les IHM reçoivent leur qualification après avoir été soumises à différents tests. Dans ces conditions, les développeurs ont à résoudre plusieurs problèmes, en particulier: - Le choix d'une architecture, qui a des répercussions sur l'ensemble de l'application. - La maîtrise des événements dynamiques, dont dépend l'évolutivité (ou l'extensibilité) de l'interface. Les services fonctionnels offerts, dont dépend la satisfaction du client. - Les choix ergonomiques. On a inventé le concept de librairie structurante pour aider les développeurs à résoudre leurs problèmes. Une librairie structurante est généralement destinée à résoudre un domaine spécifique de problèmes. Habituellement, les librairies structurantes sont techniquement orientées (en fonction de questions techniques, de questions de persistance,...). Certaines librairies structurantes, disponibles sous forme de produits courants du commerce, dits COTS ( Commercial Off The Shelf en anglais), permettent de réaliser des applications en contrôle-commande (en anglais: CCIS , soit: Command & Control Ilnformation System ), comme par exemple les produits OpenMap , Debrief ,.... De telles librairies structurantes offrent une solution lorsque l'architecture du système destiné à les recevoir est bien définie. Toutes les fonctionnalités fournies sont alors intégrées pour former une application complète. Une technique d'enfichage permet à un développeur d'insérer ses propres processus. De telles possibilités d'extension doivent avoir été prévues lors de la conception de la librairie structurante. L'application intégrée complète ne peut fonctionner lorsque des fonctions entières ont été remplacées. Un développeur ne peut que personnaliser l'application utilisant ces extensions prédéfinies. En outre, avec ces librairies structurantes connues, lorsque le développeur désire remplacer une fonction entière, l'application ne peut plus fonctionner correctement. La présente invention a pour objet une librairie structurante pour le développement d'interfaces homme-machine qui soit évolutive et ouverte, c'est-à-dire capable d'accueillir des éléments logiciels tiers, en particulier mais non exclusivement des COTS , en vue d'offrir de nouveaux services et/ou pour pouvoir être mise à jour lors de l'apparition de nouveaux produits qui remplaceront les produits utilisés similaires s'ils sont plus performants que ces derniers, et ce, sans modifier toute la structure de l'application et sans impact sur les autres éléments de la structure. La librairie conforme à l'invention est une librairie à base de composants pour le développement d'IHM pour des systèmes d'information et de contrôle-commande comportant du matériel, un système d'exploitation, un environnement d'exécution de la plate-forme de développement et elle est caractérisée en ce qu'elle comporte une couche technique regroupant un agencement de composants techniques non spécialisés dans le domaine d'application desdits systèmes, dédiés chacun à une tâche élémentaire, leur assemblage fournissant les services non fonctionnels à l'application, et une couche de domaine d'application regroupant un agencement de composants logiciels du domaine d'application, leur assemblage fournissant les services fonctionnels à l'application, l'ensemble servant de fondation de l'application IHM considérée. La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel: la figure 1 est un bloc-diagramme simplifié d'un système d'information comprenant la librairie structurante de l'invention, la figure 2 est un bloc-diagramme simplifié d'un exemple de réalisation de la couche technique de la librairie structurante de la figure 1, la figure 3 est un bloc-diagramme simplifié d'un exemple de réalisation de la couche de domaine d'application de la librairie structurante de la figure 1, et la figure 4 est un bloc-diagramme d'un exemple de processus de développement, composant par composant, en vue de remplacer temporairement pour une application particulière au moins un composant de la librairie de la figure 1. La librairie structurante de la figure 1 est une infrastructure de développement et d'intégration pour la réalisation d'IHM sur une plateforme Java. Elle comporte essentiellement les éléments suivants qui sont connus en soi et représentés sous forme d'un empilement de couches communiquant entre elles: une partie matériel 1 (par exemple un PC,... ), un système d'exploitation 2 (Windows, Unix, Linux,...), une machine virtuelle Java 3, qui est un COTS classique connu sous la dénomination Java runtime . C'est l'implémentation d'une abstraction de l'ensemble des services du système d'exploitation, ce qui permet à l'application d'être indépendante de ce système d'exploitation. Cette machine 3 communique à la fois avec une ou plusieurs librairies Java 4, une ou plusieurs librairies supplémentaires 5 sous forme de COTS, et une application spécifique d'IHM 6. Les librairies Java 4, dénommées également API (Application Programming Interface ) Java, couvrent les domaines du graphisme, du réseau, de l'accès aux bases de données, ... Les librairies supplémentaires 5 sont généralement des COTS, et se rapportent, par exemple, aux domaines de la gestion de données en format XML, des librairies de persistance, de la cartographie, ... Selon l'invention, ces éléments 1 à 6 sont combinés avec une 35 couche technique 7 et avec une couche 8 spécifique au domaine de l'application IHM considérée. La couche 7 communique avec les éléments 4 et 6, tandis que la couche 8 communique avec les éléments 6 et 7. La couche technique 7 est de type middleware (couche intermédiaire) graphique. Elle permet d'étendre les possibilités des interfaces (API) Java, qui ne sont alors plus dépendantes du domaine d'application, et se présente comme une infrastructure de développement et d'intégration pour réaliser des applications IHM dans des domaines très divers tels que ceux relatifs aux banques, aux assurances, à l'appareillage médical, à l'aviation, etc. Cette couche, décrite plus en détail ci-dessous en référence à la figure 2, comporte essentiellement un conteneur à composants logiciels, des services techniques et des composants génériques. Ces services et composants assurent en particulier les services dits non fonctionnels suivants: gestion du cycle d'exécution des composants, connexions entre les composants, notification d'événements, gestion de l'asynchronisme, persistance des paramètres, base de données générique dont les événements peuvent être notifiés, gestion multi-tâche, communication inter-tâches, gestion des collections de données, gestion de la couche graphique,.... La couche 8 comporte des composants logiciels génériques, mais plus spécifiques que ceux de la couche 7. Cette couche, décrite plus en détail ci-dessous en référence à la figure 3, comporte essentiellement une partie inter-domaines commune à plusieurs applications différentes et des parties spécifiques à chacun des grands domaines d'application. Elle assure des services dits fonctionnels tels que l'affichage géo- référencé, l'affichage alpha-numérique, toutes les fonctions directement liées au domaine d'application, la gestion des sorties multimédias, ... Dans le cas d'une application radar, cette couche comporte des composants tels qu'une table de pistes générique, une fonction d'affichage de pistes générique, une fonction d'affichage d'une cartographie, etc. On a représenté en figure 2 un exemple de réalisation de la couche technique 7. Cette couche constitue une infrastructure de développement et d'intégration permettant de réaliser des applications IHM dans des domaines très divers: banque, assurance, appareillage médical, grands systèmes industriels, ... La couche 7 s'appuie sur la sous-couche 4 de librairies Java, comportant des collections de données, des interfaces graphiques Swing, AWT, Java Beans, Java 2D, Réflexion, Sérialisation,.... Au-dessus de la sous-couche 4, on dispose une sous-couche 10 d'extensions de langage telles que enum (énumérés), ranged (valeurs bornées), variant (variables), recyclable (valeurs réutilisables), cette sous-couche 10 étant surmontée d'une sous-couche 11 de gestion de composants (composants étant pris ici dans son sens classique dans ce contexte de tâches élémentaires), ces composants étant les composants 12 à 14 décrits ci- dessous. L'architecture de ces composants est un patron du type, connu en soi, dit MVC ( Model View- Controller ). Le gestionnaire 11, également appelé conteneur de composants , accueille ces composants lors de l'exécution de l'application et leur propose des services techniques de connexions, de notification d'événements, de persistance de leurs paramètres, etc. Le composant 12, de type Modèle , comporte les fonctions suivantes: collection de données, routeur, notification d'événements, push-pull de données côté client ( chercher des données ou les recevoir), gestion de l'asynchronisme, distribution, ... Le composant 13 est du type Controller (contrôleur ou gestionnaire). II gère les fonctions suivantes: actions (de l'utilisateur sur les périphériques tels qu'un clavier), les mots de passe, les proxys UDP ( proxy étant une représentation d'une entité telle qu'un calculateur), les calculateurs distants, ... Le composant 14 View (visualisation) comprend les fonctions suivantes: générateur de vues, gestion de couches, objets graphiques, formats d'affichage, gestion des fenêtres, éditeur graphique. Le composant 15 rassemble les fonctions d'outils et d'utilitaires, en particulier les statistiques, la stimulation, les calculs mathématiques, la gestion des entrées/sorties, la gestion multimédia, les structures d'entrées/sorties en C, ... On a schématiquement représenté en figure 3 un exemple de réalisation de la couche domaine 8. Comme déjà indiqué, cette couche repose sur la couche technique 7, et elle comporte: une couche 16 de gestion de composants, qui sont dans le cas présent des collections de données relatives aux domaines considérés. Dans le domaine des radars, pris en exemple dans la présente description, ces données peuvent être par exemple relatives: aux pistes (pour la poursuite de mobiles), aux plots (échos radar), aux marqueurs de distance, à la rose graduée, à la cartographie, aux aides à l'opérateur (calcul du point de passage au plus près, dit CPA , au calcul du ralliement, dit CTS ), aux alertes d'opérateur, aux différents modes de fonctionnement des consoles, aux secteurs et zones d'équipements, à la vidéo radar,.... La couche 16 de types de domaines communique avec une couche 17, également du type MVC mentionné ci-dessus et comportant des composants modèle 18, des composants contrôleur 19, des composants vue 20 et des composants outils et utilitaires 21. Chacun des types de composants de la couche 16 est implémenté avec un modèle 18, au moins une vue 19 et un contrôleur 20. Le composant modèle 18 est un composant de gestion d'une collection de données du domaine identifié susceptible d'être mis en oeuvre. Le composant contrôleur 19 comporte essentiellement des services de vérification des commandes transitant par la couche 8 et des services de gestion des menus des fonctions assurées par les composants de la couche 22 composants du domaine qui est superposée à l'ensemble des composants de la couche 17. Le composant vue 20 comporte notamment les services de gestion de vues classiques , de gestion de vues géoréférencées, et de gestion de vues orthonormées. Le composant outils et utilitaires 21 comporte en particulier les services suivants: projections graphiques, calcul de géo-référencement, générateur OICD ( Operator Interface Control Document , c'est-à-dire document de gestion d'interface opérateur), gestion de formats du domaine identifié,.. . La couche 22 de composants spécifiques à un domaine comporte, dans le présent exemple, les composants suivants: gestion de la vidéo radar, des cercles (technique relative à l'affichage de type PPI), des acquittements des commandes de l'opérateur, des pistes, des cartes, des plots, des secteurs, des alertes, des modes d'exploitation de console, de la fonction accrochage et sélection, et des aides à l'opérateur telles que CPA (Closest Point of Approach: point de passage au plus près), CTS (Course To Steer: cap à rallier), etc. On a illustré en figure 4, de façon très simplifiée, un processus 35 avantageux de développement de la librairie structurante de l'invention. Cette figure illustre, de bas en haut, les différentes étapes successives du développement d'une application IHM. On a représenté en 23 la couche technique, qui comporte, dans le cas présent, et de façon non limitative, les six composants suivants: un modèle de composant 24, des composants 25 à 27 qui sont respectivement du type modèle, vue et contrôleur (analogues aux composants 12 à 14), un composant 28 MVC et un composant 29 qui est ici un composant de gestion de projection graphique. Le composant 28 est en liaison fonctionnelle avec tous les autres composants de cette couche. Les liaisons fonctionnelles entre composants de la figure 4 sont symbolisées à chaque fois par une flèche. Cette flèche indique que le composant duquel part la flèche a besoin de celui qui est pointé par la flèche. A l'étape suivante du développement, on ajoute les composants de la couche de domaine 30, similaire à la couche 8. Ces composants sont, dans le présent exemple, les suivants: un composant 31 de gestion de pistes, un composant 32 de gestion de cartographie et un composant 33 de gestion de secteurs et de zones radar. Dans le cas d'un changement de domaine ou d'une modification importante de la gestion d'un domaine, l'invention permet de remplacer temporairement ou définitivement un composant qui n'est plus approprié à cette nouvelle utilisation par un composant approprié. Dans l'exemple représenté sur le dessin, lorsque l'on change la nature des pistes gérées, on remplace le composant 31 par un composant 34 approprié à cette nouvelle utilisation, et ce, sans modifier les autres composants. Le composant 28 est relié aux composants 31, 32 et 33, le composant 31 étant par ailleurs relié au composant 33, tandis que le composant 32 est relié au composant 29. Au-dessus des couches 23 et 30, on a représenté une couche 35 projet en cours de développement, pour des applications spécifiques. Dans cet exemple, elle comprend: un composant 36 de gestion de secteurs de tir radar, un composant 37 de gestion de pistes spécifiques et un composant 38 de gestion de navigation spécifique. Les composants 36 à 38 sont respectivement reliés aux composants homologues 33, 31 et 32. Ainsi, la librairie structurante de l'invention propose un processus de développement qui prend en charge l'ensemble des différentes phases nécessaires au développement d'une application d'IHM. Grâce au fait que l'architecture de cette librairie est à base de composants, on peut réaliser de la même façon l'architecture de l'application qui repose sur cette librairie. Cette architecture de l'application peut alors être régulière et d'un haut niveau d'abstraction. L'application peut être décomposée en sous-applications, puis en composants élémentaires. On peut établir une séparation claire entre les interfaces de ces derniers composants et leur implémentation. On peut également supprimer le code d'utilisation des services techniques de ces composants, car il est pris en charge par le gestionnaire 11. Du fait que chaque composant de la librairie de l'invention est entièrement remplaçable par une autre implémentation spécifique, on o confère une ouverture totale au système réalisé. REVENDICATIONS 1. Librairie structurante à base de composants pour le développement d'interfaces homme-machine pour des systèmes d'information et de contrôle-commande comportant du matériel informatique (1), un système d'exploitation (2), un environnement d'exécution de la plate- forme de développement (3, 4), caractérisée en ce qu'elle comporte, entre l'environnement d'exécution et l'application spécifique d'interface hommemachine (6), une couche technique (7) regroupant un agencement de composants techniques non spécialisés dans le domaine d'application desdits systèmes, dédiés chacun à une tâche élémentaire, leur assemblage fournissant les services non fonctionnels à l'application, et une couche de domaine d'application (8) regroupant un agencement de composants logiciels du domaine d'application, leur assemblage fournissant les services fonctionnels à l'application, l'ensemble servant de fondation de l'application IHM considérée. 2. Librairie structurante selon la revendication 1, caractérisée en ce que la couche technique comporte, une couche d'extensions de langage (10), un composant Modèle (12), un composant Contrôleur (13), un composant Vue (14) et un composant rassemblant les fonctions d'outils et d'utilitaires (15). 3. Librairie structurante selon la revendication 1, caractérisée en ce que la couche domaine (8) comporte: une couche de types de domaines (16), un composant Modèle (18), un composant Contrôleur (19), un composant Vue (20) et un composant rassemblant les fonctions d'outils et d'utilitaires (21).