EP1839131A2 - Librairie structurante pour le developpement d'interfaces homme-machine - Google Patents

Librairie structurante pour le developpement d'interfaces homme-machine

Info

Publication number
EP1839131A2
EP1839131A2 EP05826431A EP05826431A EP1839131A2 EP 1839131 A2 EP1839131 A2 EP 1839131A2 EP 05826431 A EP05826431 A EP 05826431A EP 05826431 A EP05826431 A EP 05826431A EP 1839131 A2 EP1839131 A2 EP 1839131A2
Authority
EP
European Patent Office
Prior art keywords
application
component
layer
components
domain
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.)
Withdrawn
Application number
EP05826431A
Other languages
German (de)
English (en)
Inventor
Philippe Fournies
Emmanuel Grivot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Publication of EP1839131A2 publication Critical patent/EP1839131A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces

Definitions

  • the present invention relates to a structuring library ("Framework” in English) for the development of human-machine interfaces (HMI or HCI in English: “Human Computer Interface”).
  • Man-machine interface developers design applications by studying their structure or architecture, taking into account dynamic events and implementing the specified functions.
  • the HMIs receive their qualification after having been subjected to various tests.
  • a structuring library is generally intended to solve a specific domain of problems.
  • structuring libraries are technically oriented (depending on technical issues, persistence issues, ).
  • Some structuring libraries available in the form of common commercial products, known as “COTS”("Commercial Off The Shelf” in English), make it possible to implement control-command applications (in English: “CCIS”, ie: “Command & Contrai Information System”), such as "OpenMap", "Debrief”, ....
  • Such structuring libraries offer a solution when the architecture of the system intended to receive them is well defined. All the features provided are then integrated to form a complete application.
  • a plug-in technique allows a developer to insert his own processes.
  • the present invention relates to a structuring library for the development of human-machine interfaces that is scalable and open, that is to say able to accommodate third-party software elements, in particular but not exclusively "COTS", in order to offer new services and / or to be able to be updated when new products are introduced that will replace similar used products if they are more efficient than the latter, without changing the entire structure of the product. application and without impact on the other elements of the structure.
  • COTS third-party software elements
  • the library according to the invention is a component-based library for the development of HMI for information and control systems comprising hardware, an operating system, a platform execution environment. form of development and it is characterized in that it comprises a technical layer comprising an arrangement of technical components not specialized in the field of application of said systems, each dedicated to an elementary task, their assembly providing non-functional services to the application, and an application domain layer grouping a software component layout of the application domain, their assembly providing the functional services to the application, the set serving as the foundation of the HMI application in question.
  • FIG. 1 is a simplified block diagram of an information system comprising the structuring library of the invention
  • FIG. 2 is a simplified block diagram of an exemplary embodiment of the technical layer of the structuring library of FIG. 1,
  • FIG. 3 is a simplified block diagram of an exemplary embodiment of the application domain layer of the structuring library of FIG. 1, and
  • FIG. 4 is a block diagram of an exemplary development process, component by component, with a view to temporarily replacing, for a particular application, at least one component of the library of FIG. 1.
  • the structuring library of Figure 1 is a development and integration infrastructure for the realization of HMI on a Java platform. It essentially comprises the following elements which are known per se and represented in the form of a stack of layers communicating with each other: a "hardware" part 1 (for example a PC, etc.), an operating system 2 (Windows) , Unix, Linux, ...), a Java 3 virtual machine, which is a classic COTS known as "Java runtime". It is the implementation of an abstraction of all the services of the operating system, which allows the application to be independent of this operating system. This machine 3 communicates both with one or more Java libraries 4, one or more additional libraries 5 in the form of COTS, and a specific application of HMI 6.
  • Java libraries 4 also called Java Application Programming Interface (API) , cover the fields of graphic design, network, access to databases, etc.
  • the additional libraries 5 are generally COTS, and relate, for example, to the fields of data management in XML format, persistence libraries, cartography, ...
  • these elements 1 to 6 are combined with a technical layer 7 and with a layer 8 specific to the field of the relevant HMI application.
  • the layer 7 communicates with the elements 4 and 6, while the layer 8 communicates with the elements 6 and 7.
  • the technical layer 7 is of type "middleware" (intermediate layer) graphic. It makes it possible to extend the possibilities of Java interfaces, which are no longer dependent on the application domain, and presents itself as a development and integration infrastructure for implementing HMI applications in very diverse domains such as those relating to banks, insurance, medical equipment, aviation, etc.
  • This layer described in more detail below with reference to FIG. 2, essentially comprises a software component container, technical services and generic components. These services and components provide, in particular, the following "non-functional" services: management of the component execution cycle, connections between the components, event notification, asynchronous management, persistence of the parameters, generic database of which events can be notified, multi-task management, inter-office communication, data collection management, graphic layer management, ....
  • Layer 8 comprises generic software components, but more specific than those of layer 7.
  • This layer described in more detail below with reference to FIG. 3, essentially comprises an inter-domain part common to several different applications and specific parts to each of the main areas of application. It provides so-called “functional" services such as geo-referenced display, alpha-numeric display, all functions directly related to the application domain, management of multimedia outputs, etc.
  • this layer comprises components such as a generic track table, a generic track display function, a map display function, and so on.
  • FIG. 2 shows an exemplary embodiment of the technical layer 7.
  • This layer constitutes a development and integration infrastructure making it possible to implement HMI applications in very diverse fields: banking, insurance, medical equipment, large industrial systems, ...
  • Layer 7 relies on Java Libraries sub-layer 4, which includes data collections, Swing, AWT, Java Beans, Java 2D, Reflection, Serialization, ... Over the sub-layer.
  • layer 4 there is an underlayer 10 of language extensions such as “enum” (enumerated), “ranged” (bounded values), “variant” (variables), “recyclable” (reusable values), this sub-layer layer 10 being surmounted by a sub-layer 1 1 of component management (components being taken here in its conventional sense in this context of elementary tasks), these components being the components 12 to 14 described below.
  • the architecture of these components is a pattern of the type, known per se, said MVC ("Model -View-Controller”).
  • the manager 1 also called “component container”, receives these components during the execution of the application and offers them technical services of connections, event notification, persistence of their parameters, etc.
  • the component 12, of the "Model” type comprises the following functions: data collection, router, event notification, push-pull of client-side data (search for data or receive data), management of asynchronism, distribution, ...
  • the component 13 is of the "Controller” type. It manages the following functions: actions (of the user on the peripherals such as a keyboard), the passwords, the "proxies” UDP ("proxy” being a representation of an entity such as a calculator), the remote computers, ...
  • the component 14 "View” comprises the following functions: view generator, layer management, graphic objects, display formats, window management, graphic editor.
  • Component 15 brings together the functions of tools and utilities, in particular statistics, stimulation, mathematical calculations, input / output management, multimedia management, C input / output structures, etc.
  • FIG. 3 schematically shows an exemplary embodiment of the domain layer 8.
  • this layer relies on the technical layer 7, and it comprises: a layer 16 for managing components, which are in this case collections data relating to the areas concerned.
  • these data may be examples relating to: tracks (for tracking mobiles), plots (radar echoes), distance markers, graduated rosé, cartography, operator aids (calculation of the nearest waypoint, said "CPA", the calculation of the rally, known as "CTS”), operator alerts, the various operating modes of the consoles, sectors and equipment areas, radar video, ....
  • the layer 16 of domain types communicates with a layer 17, also of the "MVC" type mentioned above, and comprising "model” components 18, “controller” components 19, “view” components 20 and “tool” components 21.
  • Each of the component types of layer 16 is implemented with a model 18, at least one view 19 and a controller 20.
  • the “model” component 18 is a management component of a collection of data of the identified domain that can be implemented.
  • the “controller” component 19 essentially comprises Layer 8 command checking services and menu management services of the functions provided by the components of the "domain component” layer 22 which is superimposed on all the components.
  • the “view” component 20 comprises, in particular, “conventional” view management, georeferenced view management, and orthonormal view management services.
  • the “tools and utilities” component 21 comprises in particular the following services: graphic projections, geo-referencing calculation, "OICD” (Operator Interface Control Document) generator (that is to say an operator interface management document) ), format management of the identified domain, ...
  • the layer 22 of domain-specific components comprises, in the present example, the following components: management of the radar video, "circles” (PPI-type display technique), acknowledgments of the operator's commands , tracks, maps, pads, sectors, alerts, console operation modes, snap and select, and operator aids such as "CPA” (Closest Point of Approach: point to the closest), CTS (Race To Steer), etc.
  • FIG. 4 illustrates, very simply, an advantageous process for developing the structuring library of the invention.
  • This figure illustrates, from bottom to top, the different successive stages of the development of an HMI application.
  • Shown at 23 is the technical layer, which comprises, in this case, and without limitation, the following six components: a component model 24, components 25 to 27 which are respectively of the model, view and controller type ( analogous to components 12 to 14), a component "MVC” and a component 29 which is here a graphical projection management component.
  • Component 28 is in operative connection with all other components of this layer.
  • the functional links between components of FIG. 4 are symbolized each time by an arrow. This arrow indicates that the component from which the arrow is pointing needs the one pointed by the arrow.
  • the components of the domain layer 30, similar to the layer 8, are added. These components are, in the present example, the following: a track management component 31, a management component 32 mapping and a sector management component 33 and radar areas.
  • the invention makes it possible to replace temporarily or permanently a component that is no longer appropriate for this new use by an appropriate component.
  • the component 31 is replaced by a component 34 suitable for this new use, and without modifying the other components.
  • the component 28 is connected to the components 31, 32 and 33, the component 31 being further connected to the component 33, while the component 32 is connected to the component 29.
  • a "project” layer being developed for specific applications.
  • it comprises: a radar firing sector management component 36, a specific track management component 37 and a specific navigation management component 38.
  • the components 36 to 38 are respectively connected to the homologous components 33, 31 and 32.
  • the structuring library of the invention proposes a development process that supports all the different phases necessary for the development of an HMI application. Thanks to the fact that the architecture of this library is based on components, we can realize the same way the architecture of the application that relies on this library. This architecture of the application can then be regular and of a high level of abstraction. The application can be broken down into sub-applications and then into elementary components. One can establish a clear separation between the interfaces of these last components and their implementation. It is also possible to delete the use code of the technical services of these components because it is supported by the manager 11. Because each component of the library of the invention is entirely replaceable by another specific implementation, it confers a total opening to the realized system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

La librairie structurante de l'invention est à 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), et elle est caractérisée en ce qu'elle comporte, entre l'environnement d'exécution et l'application spécifique d'interface homme-machine (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.

Description

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 : « Human 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 & Contrai Information 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 plate-forme 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 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 intertâ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 1 1 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 1 1 , é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). Il 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 rosé 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 œuvre. 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éo- ré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 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 confère une ouverture totale au système réalisé.

Claims

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 homme- machine (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 ).
EP05826431A 2004-12-22 2005-12-21 Librairie structurante pour le developpement d'interfaces homme-machine Withdrawn EP1839131A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0413740A FR2879785A1 (fr) 2004-12-22 2004-12-22 Librairie structurante pour le developpement d'interfaces homme-machine
PCT/EP2005/057024 WO2006067181A2 (fr) 2004-12-22 2005-12-21 Librairie structurante pour le developpement d'interfaces homme-machine

Publications (1)

Publication Number Publication Date
EP1839131A2 true EP1839131A2 (fr) 2007-10-03

Family

ID=35385195

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05826431A Withdrawn EP1839131A2 (fr) 2004-12-22 2005-12-21 Librairie structurante pour le developpement d'interfaces homme-machine

Country Status (4)

Country Link
US (1) US20080148285A1 (fr)
EP (1) EP1839131A2 (fr)
FR (1) FR2879785A1 (fr)
WO (1) WO2006067181A2 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7093005B2 (en) * 2000-02-11 2006-08-15 Terraspring, Inc. Graphical editor for defining and creating a computer system
US7490167B2 (en) * 2002-05-22 2009-02-10 Sony Corporation System and method for platform and language-independent development and delivery of page-based content

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006067181A2 *

Also Published As

Publication number Publication date
WO2006067181A2 (fr) 2006-06-29
FR2879785A1 (fr) 2006-06-23
US20080148285A1 (en) 2008-06-19
WO2006067181A8 (fr) 2006-10-19

Similar Documents

Publication Publication Date Title
US8161413B2 (en) Method and system for providing user interface representing organization hierarchy
US10740121B2 (en) User interface for navigating multiple applications
RU2336557C2 (ru) Классы структур автоматизации пользовательского интерфейса и интерфейсы
US20030005412A1 (en) System for ontology-based creation of software agents from reusable components
WO2021096953A1 (fr) Système informatisé et procédé pour un environnement informatique distribué avec peu de codes/sans codes
US20080120593A1 (en) GUI modeling of deep hierarchical data
US20120324423A1 (en) Navigation history visualization in integrated development environment
Keenan Spatial Decision Support Systems: a conning of age
US20130014039A1 (en) Integrated graphical user interface
Gitis et al. Web-Based GIS platform for automatic prediction of earthquakes
US20070239746A1 (en) Visual merge of portlets
US9110570B1 (en) Reversed links from graphical diagram representation
Lata et al. Web-GIS based dashboard for real-time data visualization & analysis using open source technologies
FR3134474A1 (fr) Dispositif et procédé de gestion centralisée d’un système de gestion de vol pour aéronef
CN110663028B (zh) 动态调整用户界面的面板
CN112527495B (zh) 硬件和软件资源优化
US20190146757A1 (en) Hardware device based software generation
EP1839131A2 (fr) Librairie structurante pour le developpement d'interfaces homme-machine
US20180275833A1 (en) System and method for managing and displaying graphical elements
US8191010B2 (en) Method, system, and computer program product for providing enhanced dropdown selection lists and combination boxes
Duan et al. ROS debugging
EP3112814A1 (fr) Systeme de visualisation comprenant des moyens de selection, de partage et d'affichage d'objets graphiques dans differents modes de visualisation et procede associe
US10460481B2 (en) Shape building in a digital medium environment
CN110908647A (zh) 一种积木式编程的对象变量呈现方法、装置、终端及存储介质
De Amicis et al. Geo-visual analytics for urban design in the context of future internet

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070621

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20090211

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120703