FR2805907A1 - Procede de representation graphique d'une application informatique - Google Patents

Abstract

Le procédé comprend la génération d'une carte représentative de composants de l'application (22) et d'une organisation désirée de ces composants, en faisant une description de ces composants et de leur organisation désirée indépendamment d'une charte graphique définissant des attributs de représentation graphique des composants et de leur organisation désirée. Ce procédé simplifie la mise à jour de la carte tout en conservant les modifications de personnalisation de la carte.

Description

Procédé de représentation graphique d'une application informatique. Domaine technique.

L'invention se rapporte à un procédé représentation graphique d'une application informatique. La représentation graphique d'une application informatique est générée en utilisant un systeme informatique. Elle ordinairement visualisée sur un écran électronique mais peut aussi l'être aussi sous d'autres formes. Elle sert notamment à surveillance des composants de l'application et/ou du déroulement de l'exécution de l'application dans un système informatique.

Une application informatique est un ensemble de processus permettant d'assurer un service ou d'effectuer une tâche particulière. Par exemple, ce peut être une application de comptabilité, une application de gestion de stocks, une application de prise de commandes une application pour internet.

Une application peut se décomposer en un certain nombre de composants. Certains de ces composants représentent l'infrastructure informatique sur laquelle elle s'appuie. Ces composants peuvent représenter par exemple des systèmes, des réseaux et des bases de données. D'autres composants jouent un rôle important dans la logique l'application et peuvent être par exemple des processus et des transferts de données. La décomposition d'une application n'est pas unique. Elle dépend principalement de la façon désirée de surveiller l'application.

La surveillance d'une application a pour d'assurer la continuité du service offert par l'application ou de la tâche à exécuter. Une surveillance permanente du comportement de l'application permet à un utilisateur administrateur de réagir rapidement en cas de panne. Pour cela, un dispositif de surveillance de chaque composant de l'application fournit un statut (par exemple bon, alarmant, critique ou inconnu) sur l'état de ce composant à un moment donné. Le bon fonctionnement de l'application peut être assuré par surveillance globale ou une surveillance par composant. Une surveillance globale permet par exemple de savoir s'il est possible de transmettre commande avec un temps de réponse satisfaisant. Une surveillance par composant permet de savoir par exemple si un composant tel qu'un réseau ou une base de données fonctionne correctement et diagnostiquer rapidement un composant en panne, de prévenir la personne adéquate pour intervenir, et d'anticiper sur les conséquences dans l'ensemble du processus.

L'invention s'applique donc notamment à l'administration système d'information. Il existe des produits logiciels d'administration pour représenter et surveiller des applications exécutées dans un système d'information. tel produit est par exemple celui connu sous le nom AGOV (Application Governor) du système d'administration OpenMaster demandeur. exemple servira dans la suite du texte pour illustrer procédé de l'invention.

L'invention a donc pour objets un procédé de représentation graphique d'une application informatique, ainsi qu'un système d'administration et un système d'information mettant en oeuvre le procédé. L'art antérieur La représentation graphique destinée à la surveillance d'une application informatique est soumise à trois conditions. Elle doit être facilement générée, très lisible par un opérateur et très flexible pour s'adapter aux besoins des utilisateurs et à l'évolution des systèmes d'information. fait d'être très lisible est important. Dans une salle de contrôle, l'écran surveillance se situe souvent à deux ou trois mètres de l'utilisateur. Sur l'écran, la représentation graphique doit donc être de très bonne qualité. Elle doit aussi distinguer nettement les composants pour être repérés rapidement et sans hésitation si l'un d'eux est défectueux. Elle doit aussi donner a l'utilisateur une organisation qui lui permette comprendre le déroulement de l'application pour mieux en apprécier la qualité, diagnostiquer rapidement un problème et connaître les répercussions de problème sur le déroulement de l'application. Ces trois conditions de la représentation graphique ne sont actuellement pas toutes satisfaites dans un même procédé. En bref, une condition avantageuse se fait au détriment d'une autre condition. Il existe actuellement plusieurs types de procédé de représentation graphique d'une application informatique.

Un premier type donne une représentation fixe de l'application. Les composants de l'application sont rangés d'une manière fixe telle que dans un tableau ou dans un arbre. La manière d'organiser et de ranger les composants est libre, mais la structure est fixe. exemple, dans le produit d'administration AGOV précité du demandeur, les composants sont structurés par défaut en domaines tels que Unix, NT , et Oracle; et dans l'explorateur de Windows NT de la société Microsoft, les fichiers sont représentés dans un arbre de répertoires. La représentation fixe offre l'avantage de ranger automatiquement les objets au bon endroit et de ne nécessiter aucun effort de mise en forme de la représentation puisqu'elle est fixe. En outre, un arbre permet de représenter application informatique comme une hiérarchie de composants. Mais ce type a pour inconvénient de nécessiter une représentation arborescente de l'application. Elle n'offre donc aucune vue logique de l'application. De plus, compréhension de la représentation graphique devient lente et difficile quand l'application est complexe.

Le second type connu repose sur le principe de laisser un utilisateur concepteur faire une carte manuelle pour représenter graphiquement une application. Les composants sont choisis et placés à la main dans un espace non structuré. L'utilisateur place les objets à son gré dans une carte en utilisant des fonctions telles que couper, coller et déplacer. Il personnalise également chaque objet individuellement. La carte est construite "sur mesure" en fonction du besoin de l'utilisateur. On trouve par exemple ce type dans le produit "ISM Monitor" du système d'administration OpenMaster du demandeur. Un utilisateur peut ainsi représenter sur une mappemonde les parties d'un système d'information propre à une société en fonction de leur localisation géographique. Ce type présente l'avantage de donner à l'utilisateur la vue qu'il désire, mais il a le gros inconvénient de rendre difficile toute modification de la représentation, même en disposant de fonctions ensemblistes, telles que celles du type consistant à appliquer une caractéristique donnée à tous les objets sélectionnés. La maintenance de ce type de représentation graphique est donc très lourde.

Un troisième type connu de représentation graphique utilise une carte automatique. Une carte est générée en fonction des objets existants. La génération est faite à l'aide d'un objet modèle, d'une requête chargée d'associer les objets à l'objet modèle, et de fonctions de placement objets. L'aspect graphique (taille, couleur, etc.) est défini par l'objet modèle. Le placement est effectué suivant une fonction de formatage, exemple verticalement à partir de l'objet modèle, en cercle, etc. On trouve une telle carte dans le produit précité "ISM Monitor". La carte peut représenter tous les systèmes d'un sous-réseau. Dans ce cas, il suffit par exemple de représenter un système par une icône et de déterminer sa taille, d'écrire une requête pour rechercher tous les systèmes, et de ranger en colonnes les systèmes trouves. Ce type de représentation a l'avantage de fixer une seule fois l'objet modèle, mais présente deux inconvénients. D'abord, la génération d'une carte générique demande un savoir-faire important, notamment savoir comment écrire les requêtes et comment placer les objets, sachant que leur nombre n'est déterminable à l'avance et qu'il peut y avoir parfois un seul objet mais parfois plus de cent objets. Ensuite, quelle que soit la sophistication fonctions de placement des objets, il n'est jamais possible d'obtenir le résultat souhaité sans retoucher les cartes. Cependant, si ce type permet de personnaliser une carte et d'en conserver la personnalisation, il ne permet pas de mettre à jour la personnalisation en utilisant le même procédé. Sommaire de l'invention.

Un premier but de l'invention est de générer aisément une représentation visuellement riche et contrastant bien les composants. Ce but offre l'avantage de faciliter la génération tout en mettant oeuvre un logiciel de dessin puissant et fonctionnellement adapté à la fonction demandée.

Un second but de l'invention est de pouvoir adapter la représentation graphique au métier représentatif de l'application à exécuter. Ce but présente l'avantage de pouvoir représenter les composants d'une application selon une organisation compréhensible quasiment <B>.</B> i 'd* <B>1 1</B> mme latement par l'utilisateur administrateur qui surveille l'application et qui a les compétences dans le métier relatif à l'application. On comprendra l'importance de cet avantage en prenant l'exemple suivant. Dans le métier bancaire, une application effectue très souvent des transferts de fonds. L'utilisateur de l'application sait interpréter immédiatement une représentation graphique de l'application sous forme d'un flux de données entre une source et un destinataire, et non pas sous la forme d'une simple organisation de composants. Une telle représentation adaptée à la logique et aux objets du métier de l'utilisateur de l'application lui permet de comprendre rapidement et pratiquement sans documentation les processus et opérations de l'application, de diagnostiquer tout problème et de prévoir les conséquences du problème sur le déroulement de l'application. Ainsi, il peut agir rapidement pour éviter qu'un défaut dégénère en panne grave. De même, il peut savoir immédiatement quels sont les composants à vérifier ou à relancer après correction d'un défaut.

Un troisième but de l'invention est pouvoir adapter rapidement et simplement la représentation en correspondance avec l'évolution de l'application et des systèmes d'information susceptibles de l'exécuter. Cet avantage est particulièrement important quand on sait, d'une part, que dans le domaine de l'informatique la nécessité de s'adapter aux évolutions implique de fréquents changements dans l'organisation et l'infrastructure informatique et, d'autre part, que la mise à jour de la cartographie pour assurer la maintenance des actuels procédés et moyens surveillance pose un problème considérable par son coût en argent, en temps et en hommes, occasionné par un travail fastidieux et très spécialisé.

L'invention a pour objet un procédé de représentation graphique d'une application informatique définie par une organisation de composants, procédé comprenant la génération à l'aide d'au moins un processeur et dans des moyens de mémoire d'un système informatique, d'une carte représentative de composants de l'application et d'une organisation désirée ces composants, caractérisé en ce que l'étape de génération comprend, dans les moyens de mémoire, une description de composants de l'application d'une organisation désirée de ces composants, une formation d'au moins une charte graphique définissant des attributs de représentation graphique des composants et de leur organisation désirée, et la génération d'au moins une carte en combinant à l'aide dudit processeur la description à au moins la charte graphique.

L'invention a pour objet corollaire un système d'administration incluant au moins un processeur, des moyens de mémoire et une application pour la représentation d'une application informatique exécutable dans un système d'information et la surveillance de son exécution, caractérisé en ce que l'application met en ceuvre dans les moyens de mémoire le procédé précédent.

L'invention a pour autre objet corollaire un système d'information incorporant au moins un processeur, des moyens de mémoire et une application informatique, caractérisé en ce que l'application informatique est représentée graphiquement dans les moyens de mémoire selon le procédé précédent. Présentation des dessins. # La figure 1 est une vue synoptique d'un exemple de système d'administration d'au moins une ressource, en l'occurrence un système d'information, le système d'administration mettant en oeuvre une application informatique d'administration et un exemple de procédé conforme à l'invention de représentation graphique de l'application.

# La figure 2 une vue schématique d'un exemple de structure de l'application mise en oeuvre dans le système d'administration représenté sur la figure la structure étant celle désirée pour la représentation graphique de l'application en utilisant le procédé de l'invention.

# La figure 3 une vue schématique d'un arbre correspondant à la structure de l'application représentée sur la figure 2.

# La figure 4 une vue schématique d'un exemple de structure d'une charte graphique générée selon une étape du procédé de représentation graphique de l'application illustrée dans la figure 2.

# La figure 5 est une vue schématique d'un exemple de fenêtre d'écran pouvant servir ' la formation de la charte graphique illustrée dans la figure 4.

# La figure 6 est vue schématique d'un exemple de carte générée selon une étape du procédé de représentation graphique de l'application représentée sur la figure 2.

# La figure 7 est une vue schématique d'un exemple de carte générée selon une autre étape du procédé de représentation graphique pour la mise à jour de l'application représentée sur la figure 2.

# Et la figure 8 est une vue en partie schématique et en partie synoptique d'un exemple variante de mise en oeuvre du procédé de représentation graphique d'une application informatique.

Description détaillée d'exemples illustrant l'invention.

La figure 1 représente un système d'administration 10 d'un système d'information 11. L'exemple qui suit se rapporte au système d'administration de sécurité connu sous le nom de marque déposée OpenMaster du demandeur. Sa conception est conforme aux normes ISO de l'administration systèmes et réseaux. Dans ces conditions, les termes utilisés seront conformes à cette norme, qui sont de langue anglaise, notamment les sigles et acronymes. D'autre part, les verbes "administrer" et "gérer" et leurs dérivés qui seront employés ici traduisent tous deux indifféremment le verbe anglais "manage" et ses dérivés. L'homme métier connaît bien ces normes. Compte tenu de leur masse informative on ne donnera ici que les éléments nécessaires à la compréhension de l'invention.

système d'information illustré 11 est distribué et se compose de machines 12, en l'occurrence quatre machines 12a-12d, organisées en un ou plusieurs réseaux 13. Une machine est une unité conceptuelle très large, de nature matérielle et logicielle, pouvant être les moyens impliqués pour exécuter une application donnée, des moyens pour exécuter une fonction donnée, un ordinateur, ainsi qu'un système informatique dans une architecture à systèmes en cascade. Les machines 12 peuvent être donc très diverses, telles que stations de travail, serveurs, routeurs, machines spécialisées passerelles entre réseaux. Le système d'information 11 est ordinairement un système comprenant plusieurs processeurs un processeur 14 étant par exemple illustré dans chaque machine 12, moyens de mémoire pour contenir les logiciels et les données du système, des moyens d'entrée-sortie 16 servant pour la communication entre machines par l'intermédiaire du réseau 13 à l'aide de protocoles divers, ainsi que pour une ou plusieurs communications extérieures, par exemple pour l'impression, la télécopie, etc. tel système peut par exemple gérer des données à distance, distribuer des données dans le cas d'un système de réservation, commander l'exécution de programmes à distance sur des machines spécialisées, partager localement ressources physiques ou logicielles, et communiquer Plus généralement, le système 11 se compose de ressources matérielles et/ou logicielles, réelles ou virtuelles, telles que machines, imprimantes, circuits virtuels, réseaux et applications. Le système d'administration 10 utilise au moins l'une ces ressources selon un modèle de données orienté objets, dont on connaît les principales caractéristiques : classes, objets, héritage, encapsulation, méthodes et événements. système d'administration 10 choisi a une architecture de type client-serveur. Dans l'exemple illustré, un gestionnaire forme un serveur d'administration inclus dans la machine 12a, dite machine gestionnaire, tandis que clients d'administration 18a, 18b et 18c sont appelés agents et sont inclus dans les machines respectives 12b, 12e et , dites machines gérées. Le gestionnaire 17 analyse et agit sur l'environnement à gérer selon la technologie orientée objets. Dans l'exemple choisi, tous les objets sont hiérarchisés dans un arbre correspondant à une base d'information d'administration plus connue sous le nom de MIB (Management Information Base). Les agents 18a-18c permettent l'accès aux ressources à gérer dans les machines respectives 12b-12d. Les ressources gérées dans les machines 12b- 12d sont identifiées sous forme d'objets organisés dans des sous-arbres (sous- MIB) respectifs 19a-19c de la base MIB. On suppose que les machines gérées 12b-12d incluent dans leurs sous-MIB respectifs 19a-19c trois bases de données correspondantes 20a-20c appelées DB1, DB2 et DB3. Selon une option courante et avantageuse du système d'administration 10, le gestionnaire gère aussi la machine gestionnaire 12a correspondante ou peut gérer tout ou partie d'autres machines gestionnaires possibles. Cela peut se faire de façon similaire à celle illustrée avec une machine gérée, plus ou moins adaptée à cette option. L'exemple illustré offre le double avantage de faciliter la lecture des dessins tout en permettant à l'homme du métier de faire aisément une généralisation du système décrit et illustré.

Le système d'administration 10 inclut diverses applications d'administration contenues dans le gestionnaire 17, notamment une application 21 de représentation et de surveillance d'au moins une application informatique 22 exécutée dans le système d'information 11. L'application 22 peut être exécutée n'importe où dans le système, en l'occurrence à partir de la machine gestionnaire 12a. L'application 21 est connue sous le nom AGOV déjà cité en introduction de la présente demande. En bref, l'application AGOV 21 mettant en oeuvre le procédé de l'invention permet à un client de décrire exactement ce qu'est pour lui l'application 22, c'est à dire les composants de l'application et leurs liens de composition hiérarchique, les menus attachés à des composants, et la manière d'animer les composants. La représentation graphique fournie par l'application AGOV 21 d'une application se présente sous une forme d'arbre et l'animation se fait par des couleurs représentatives d'états respectifs des composants correspondants.

Le procédé de représentation graphique d'une application 22 définie par une organisation de composants est du type comprenant la génération d'une carte représentative de composants de l'application et d'une organisation désirée de ces composants. Selon l'invention, génération comprend une description de composants de l'application et d'une organisation désirée de ces composants, une formation d'au moins une charte graphique définissant des attributs de représentation graphique des composants et de leur organisation désirée, et la génération moins une carte en associant la description à au moins une charte graphique. Le procédé peut comprendre en outre la personnalisation de la carte et/ou mise à jour de carte. On supposera que le procédé de l'invention est mis en oeuvre en utilisant au moins un des processeurs 14 et les moyens de mémoire 15 du système d'administration 10 et/ou du système d'information 11.

La figure 2 illustre un exemple de représentation graphique d'une application informatique 22. On suppose que cette application est destinée à un utilisateur administrateur du métier de la banque. On a vu précédemment en introduction l'importance d'avoir une représentation des flux de données représentatifs de transferts de fonds entre une source et un destinataire. Dans la figure 2, les composants comprennent les trois bases de données DB1, DB2 et DB3 représentées sur la figure 1, deux processus Pl et P2, deux lots de commande (Batch) B1 et B2. Les flux de données sont référencés par la lettre F. On suppose que le processus tourne en permanence et qu'à une entrée "input" de l'application arrive un flux de données F1. Le processus P1 traite le flux F1 et envoie deux de données F2 F3 vers les bases respectives DB1 et DB2. Le lot B1 calcule à un moment donné, par exemple la nuit, des états, en l'occurrence les états relatifs à l'activité de la banque dans la journée, et les charge par un flux dans la base de données DB2. Le lot B2 est supposé démarrer à une heure prédéfinie. À cette heure, il extrait un flux F5 de données de la base DB2 et traite pour envoyer un flux F7 vers la base DB3 et une notification N1 au processus P2. En réponse à la notification, le processus P2 extrait un flux F6 de données de la base DB2 pour fabriquer un compte rendu et envoyer un flux F8 de données représentatives du compte rendu vers la sortie "output" de l'application.

Le procédé de représentation graphique commence par une description de l'application 22. Cette description inclut une description de composants de l'application et d'une organisation désirée de ces composants. Dans l'exemple choisi, les composants et l'organisation désirée sont tous ceux illustrés dans la figure 2. En d'autres termes, la description se rapporte généralement aux objets représentatifs de composants et de leur organisation désirée dans l'application 22 et l'exemple illustré concerne tous les composants et leur organisation, tels qu'illustrés dans la figure 2. Les composants à décrire peuvent être extraits par le système d'administration 10 d'une base de données où ils ont été stockés après leur découverte dans système d'information, ou être créés directement par le concepteur. Chaque composant dispose d'un identificateur unique. La description peut être faite manuellement ou au moins partiellement automatisée, avec l'aide de boîtes d'écran par exemple. À la fin de la description, on obtient un arbre représentatif de l'application 22.

La figure 3 illustre un exemple d'arbre 23 représentatif d'une description de l'application 22. L'arbre part d'une racine nommant l'application 22 et a un tronc commun d'où se rattachent cinq noeuds représentatifs respectivement de processus, de lot, de base de données, de notification et de flux. Aux cinq noeuds partent des sous-arbres respectifs se terminant par des sous-noeuds correspondant aux processus P1 et P2, aux lots L1 et L2, aux bases DBI-DB3, à la notification N1 et aux flots F1-F8. Les flux F1 et la notification N1 sont des objets de type "lien" et sont chacun décrits dans figure 3 avec les objets qu'ils relient.

La figure 4 illustre un exemple d'une charte graphique 24 formée lors d'une autre étape du procédé de représentation graphique. La charte graphique 24 se rapporte aux objets désirés de l'application à savoir les composants et l'organisation correspondant à ceux utilisés lors de l'étape précédente de description de l'application. Une charte graphique 24 définit des attributs 25 de représentation graphique des composants et de leur organisation désirée. Des attributs 25a appelés Attributel-AttributeN définissent l'aspect visuel qu'auront les composants dans la carte finale. Ces attributs peuvent par exemple définir pour un composant la taille, l'icône, un texte descriptif, etc. Les composants peuvent avoir deux types d'aspect : un aspect type simple et un aspect de type lien. Un composant type lien a un point de départ et un point d'arrivée. D'autres attributs optionnels 25b définissent de préférence des directives appelées Gen GL1-Gen GLM relatives à la génération des objets pour la représentation graphique. Par exemple, des attributs 25b peuvent déterminer si et comment noeud et/ou au moins un objet du sous-arbre correspondant doivent être générés. La charte graphique inclut aussi une fonction d'héritage pour signifier qu'un noeud fils applique la charte graphique de son père. Cependant, est possible de redéfinir au moins un élément de la charte en utilisant concept de surcharge de la technologie orientée objets.

Dans l'exemple choisi, à chaque type de noeud est associée une charte graphique qui contient des attributs graphiques pour objets du sous-arbre correspondant. Selon un premier exemple, on peut avoir les correspondances suivantes Noeud : Processus Type : objet simple Forme : cercle etc. La liste des attributs pouvant figurer dans la charte graphique n'est pas exhaustive. Selon un second exemple, on peut avoir correspondances suivantes Noeud : Flux Type<B>:</B> lien Forme : flèche épaisse orientée La figure 5 illustre un exemple de fenêtre 26 pouvant servir à formation d'une charte graphique. Cet exemple permet de concrétiser les attributs 25 pouvant constituer la charte graphique 24 représentée sur la figure Comme attributs 25a, la fenêtre 26 contient une boîte 27 relative à l'attribut "Type" désignant le type de l'objet, qui peut être simple ou un Le type "Aucun" correspond à une représentation par défaut des objets. Selon l'exemple choisi, chaque objet applique la charte de son père. Le fait positionner le type pour un objet permet de choisir des caractéristiques explicitement pour cet objet et ses fils, conformément au mécanisme surcharge. Le choix du type détermine la présentation des autres attributs 25a. Ceci est illustré par un trait discontinu dans la fenêtre 26, qui isole boîte des autres boîtes relatives aux attributs 25a. Les autres attributs 25a illustrés correspondent au type "simple". Ils comprennent : une boîte 28 relative à la forme de représentation de l'objet simple, qui peut être extraite d'une fenêtre fugitive 29, par exemple une figure géométrique, une icône, un logo, ; une boîte 30 (à deux cases) relative à la taille de la forme de l'objet déterminée précédemment ; une boîte 31 relative au cadre choisi pour le libellé (label) attaché à la forme de l'objet déterminée par les boîtes 28 et 29, la boîte 31 permettant de déterminer notamment la position du libellé par rapport à la forme choisie ; une boîte 32 à deux cases pour déterminer respectivement le nom et la taille de la police de caractères du texte à placer dans libellé ; et une boîte 33 à trois cases pour déterminer respectivement la couleur de la bordure, du fond et du texte du libellé. En choisissant le type "lien" dans la boîte 27, les attributs 25a pourraient contenir par exemple d'autres formes, telles que des flèches variées pour représenter divers flux. La fenêtre 26 contient aussi une zone 34 pour les attributs 25b constituant en l'occurrence directives de génération Gen GL1-Gen_GLM des objets. Dans l'exemple illustré, des cases à cocher 35 sont présentées pour choisir respectivement de générer le noeud concerné, de générer tout sous-arbre, ou seulement noeuds terminaux, de générer plusieurs cartes selon la variante qui sera décrite ultérieurement, etc.

La figure 6 illustre un exemple de carte 36 générée selon une troisième étape du procédé de représentation graphique conforme à l'invention. partir d'un point de l'arbre 23 représenté la figure 3, l'utilisateur concepteur demande la génération d'une carte Les objets sont générés selon les attributs définis par la charte graphique 24. Ainsi, les noeuds concernés et les objets situés dans les sous-arbres correspondants sont dessinés suivant un algorithme de placement relativement simple et en respectant charte graphique. Par défaut, dans l'exemple choisi, tous les objets terminaux sont dessinés, mais pas les objets intermédiaires. Les objets dessinés dans la carte conservent les mêmes caractéristiques que dans l'arbre (animation, menus, ... ).

En pratique, le système d'administration 10 permet d'associer à chaque objet de l'arbre, en fonction de son type, des caractéristiques d'animation, ainsi qu'un menu à fenêtre fugitive (pop-up menu). L'animation détermine la couleur d'un objet en fonction de l'état du composant qu'il représente, par exemple, vert pour un bon état, orange pour un état alarmant, rouge pour un état critique. Dans l'exemple choisi, l'état d'un noeud père est déterminé comme étant le plus mauvais des états de ses fils. Le menu à fenêtre fugitive permet de lancer, entre autres, des actions d'administration sur le composant représenté, telles que les actions démarrer et arrêter. L'arbre représentant l'application et l'ensemble de l'arbre étant animé, un opérateur peut utiliser cet arbre pour surveiller l'état de l'application.

Un exemple de génération de la carte 36 va maintenant être décrit. L'utilisateur dispose d'un menu en mode fenêtre fugitive (pop-up menu) relatif à l'application et incluant une commande, par exemple "générer carte". La génération se fait alors suivant l'algorithme suivant. L'algorithme parcourt l'arbre et dessine tous les objets de type "objet simple", les alignant en rangs par type, et en appliquant la charte graphique. L'algorithme parcourt une nouvelle fois l'arbre et dessine tous les objets de type "lien" en reliant les objets spécifiés dans le lien et en appliquant la charte graphique. L'objet "input" est traité comme un objet invisible situé au- dessus de l'objet destination correspondant au lien. L'objet "output" est traité comme un objet invisible situé au-dessous de l'objet source correspondant au lien.

La figure 6 illustre un exemple de carte 36 générée selon l'algorithme précédent. Les commentaires sur les liens indiqués à la figure 3 ne figurent pas sur le dessin pour des raisons de clarté. En fait, il est à noter que la carte 36 correspond à un arbre 23 similaire à celui de la figure mais annoté des attributs 25 de la charte graphique 24. Dans la figure 6, la génération ne s'est faite que sur les noeuds terminaux de l'arbre, de sorte que les noeuds Processus, Lot, Notification et Flux ne sont pas représentés.

L'algorithme de placement des noeuds présenté précédemment est très simple. Cependant, il pourrait être remplacé par un algorithme plus sophistiqué. On peut envisager notamment un algorithme qui placerait les noeuds de source systématiquement au-dessus des noeuds de destination, ce qui aboutirait à une représentation du processus global plus proche de la réalité. De même, la fonction de génération pourrait être plus sophistiquée, notamment en fonction de directives données dans la charte graphique, telles que par exemple générer seulement certains types de nceuds, ou exclure des types de noeuds, ou utiliser d'autres méthodes de filtrage.

Une étape accessoire mais très avantageuse du procédé de représentation graphique est la personnalisation de la carte, qui peut être faite simplement. La personnalisation d'une carte est faite pour améliorer la présentation visuelle des objets de la carte, par exemple en déplaçant des objets dans la carte, en y ajoutant du texte et des logos et en modifiant ou supprimant des parties de dessins. Il est à noter ici que la charte définit les attributs des objets de la carte et la personnalisation permet par exemple d'individualiser deux objets semblables définis par les mêmes attributs dans la charte, de façon à mieux les distinguer. En utilisant le procédé de l'invention, l'indépendance faite entre la description de l'application 22 et la charte graphique 24 qui lui est associée offre l'avantage de faire la personnalisation sans modification de la charte graphique 24. Il suffit que l'utilisateur concepteur édite la carte obtenue précédemment et la modifie pour obtenir la représentation désirée. Les modifications apportées peuvent être des déplacements d'objets, des changements de tailles, des annotations textuelles, etc. À la fin de cette étape, on obtient la carte définitive remise à l'opérateur pour surveillance.

Une autre étape accessoire et très avantageuse du procédé de représentation graphique est la facilité de mise à jour de la carte 36 obtenue précédemment. Lorsque des objets sont ajoutés ou supprimés, l'utilisateur administrateur doit mettre à jour la carte. La mise à jour est simple car elle ne nécessite pas de mise en page. Selon l'exemple qui va être décrit, mise à jour demande la régénération de la carte existante. Les objets supprimés sont détruits de la carte. Cependant, ils pourraient être placés dans zone particulière. Les objets ajoutés sont placés dans une zone particulière nommée "Nouveau". Il suffit ensuite à l'utilisateur administrateur de déplacer les objets pour les positionner où il veut sur la carte. objets existants sont inchangés.

La figure 7 illustre un exemple de représentation d'une forme nouvelle 22' de l'application 22. La nouvelle forme 22' suppose que l'application 22 a été modifiée de la façon suivante : le flux F3 (P1,DB2) est devenu F3 (P1,DB3), c'est-à-dire un flux allant de P1 vers la base ; un nouveau lot B3 extrait des données de la base DB1 et crée ainsi un nouveau flux F9 ; et le lot B1 est supprimé. L'arbre 23 représenté sur la figure 3 est modifié en conséquence. La régénération de la carte se fait selon l'exemple d'algorithme qui va être présenté. L'algorithme dans une première étape parcourt l'arbre pour vérifier si tous les objets de type "objet simple" sont présents dans la carte précédente. Si oui, il ne fait rien. Sinon il existe au moins objet nouveau et il le dessine dans la zone "Nouveau" en lui appliquant la charte graphique 24. L'algorithme dans une seconde étape parcourt nouvelle fois l'arbre pour vérifier si tous les objets type "lien" sont présents dans la carte précédente. Si chaque lien existe et relie les mêmes objets, il ne fait rien. Si au moins un lien existe et relie au moins un objet différent, il efface l'ancien lien et dessine un nouveau lien en lui appliquant la charte graphique 24. Si au moins un lien nouveau détecté, il le dessine dans la zone "Nouveau" en lui appliquant la charte graphique 24. L'algorithme selon une troisième étape parcourt tous les objets de nouvelle carte et compare avec les noeuds qui ont été parcourus dans l'arbre. Tout objet de nouvelle carte qui ne figure pas dans la liste des noeuds est effacé. Il en résulte comme avantages que la mise en page des objets conservés n'est pas affectée. En outre, les nouveaux objets sont dessinés dans une zone identifiée. Les nouveaux liens sont tracés entre les objets de la carte. Il en résulte pour la mise à jour d'une représentation graphique originale 22, l'utilisateur n'a donc qu'à régénérer la carte en partant de la carte originale 22. Seule mise en page des nouveaux composants reste à faire. Cette mise à jour offre aussi le grand avantage de conserver les modifications de la carte lors de l'étape de personnalisation.

De nombreuses variantes autres que celles déjà indiquées précédemment peuvent encore être apportées par l'homme métier à l'exemple illustré de procédé de représentation graphique. Notamment, en s'appuyant sur des mécanismes connus de découverte et rangement automatique des composants, la première étape du procédé pour la description de l'application peut être entièrement automatisée. troisième étape qui a été décrite pour la génération d'une carte 36 ne comprend qu'une seule génération. Cependant, on peut aussi envisager plusieurs générations possibles de cartes 36a-36b, etc. depuis un même noeud, ou de noeuds différents. Cette variante a l'avantage d'obtenir, à partir d'une même description, des représentations spécialisées. Par exemple, il est possible de ne générer que les composants relatifs aux bases de données. Les cartes peuvent aussi être liées par un mécanisme de navigation.

La figure 8 est une vue en partie schématique d'un arbre illustrant sous forme synoptique un exemple de procédé de représentation graphique similaire à celui qui vient d'être décrit et un exemple d'une variante possible de procédé de représentation graphique d'une application informatique. Les deux exemples se fondent sur un arbre 23' ayant un noeud racine A d'où partent des sous-noeuds A1 et A2 et un noeud composants B différents des composants A et constituant un conteneur (container) de trois sous-noeuds -B3. Selon un premier mode de génération, appelé Génération 1 dans la figure 8, une seule carte 36 est générée conformément à l'étape de génération a été décrite précédemment. Dans l'exemple choisi, seuls les noeuds terminaux A1, A1, B1, B2 et B3 sont pris en compte. Les noeuds intermédiaires A et B sont considérés comme des conteneurs et sont donc ignorés. Selon un second mode de génération, appelé Génération 2 et conforme à variante citée précédemment, deux cartes et 36b sont générées successivement dans des instants très proches, en pratique quasiment simultanément. La première carte 36a comprend objets Al, A2 et le conteneur B. La représentation du container B permet de cacher le sous- arbre B, qui est représenté dans la deuxième carte 36b, qui est liée à l'objet B. La deuxième carte peut être visualisée sur demande, en actionnant par exemple une commande d'un menu à fenêtre fugitive (pop-up menu) relatif à l'objet B. Cette commande est basée sur le principe d'enchaînement de cartes connus sous le nom "map forward". Un tel éclatement d'une représentation graphique en plusieurs cartes 36a-36n peut s'avérer très utile si on veut gérer beaucoup de composants dans une structure arborescente ayant un nombre important de niveaux. Cette représentation ne remet pas en cause les principes de l'invention, qui s'appliquent de la même façon, quel que soit le nombre de cartes générées. Il ressort de ce qui précède que, d'une manière générale, l'invention a pour objet un procédé de représentation graphique d'une application informatique définie par une organisation de composants, procédé comprenant la génération d'une carte représentative de composants de l'application et d'une organisation désirée de ces composants. Une telle génération de l'art antérieur a été décrite en introduction. Selon l'invention l'étape de génération comprend une description de composants l'application et d'une organisation désirée des ces composants, une formation d'au moins une charte graphique définissant des attributs de représentation graphique des composants et de leur organisation désirée, et la génération d'au moins une carte en associant la description à au moins la charte graphique.

Selon une caractéristique optionnelle mais très avantageuse, au moins l'un des attributs d'au moins la charte graphique 24 détermine par un point de départ et un point d'arrivée un type "lien" de composants F1-F9 représentatifs d'un flux de données entre les deux points, tandis qu'au moins un autre attribut détermine un autre type, tel qu'un type ordinaire nomme "simple" de composants P1, P2 et B1-B3.

Dans le cas ordinaire, mais non nécessaire pour l'invention, description de l'application inclut un arbre 23, 23' d'objets incorporant au moins un n#ud constituant une racine d'un sous-arbre d'objets et ayant un type donné, au moins l'un des attributs 25 d'au moins la charte graphique 24 peut définir si le n#ud et/ou au moins un objet du sous-arbre correspondant doivent être générés dans au moins la carte (36). En outre, une charte graphique 24 peut être avantageusement formée, pour un type donné noeuds, avec des attributs 25 relatifs aux objets du sous-arbre correspondant audit type de noeud. Comme autre possibilité avantageuse, un n#ud applique la charte graphique de son n#ud père. Comme autre possibilité, la génération d'au moins la carte 36 est faite selon un algorithme faisant au moins un parcours de l'arbre pour dessiner dans la carte les objets d'un type donné en appliquant au moins la charte graphique correspondante 24. On vu aussi que le procédé permet en outre à un utilisateur concepteur de faire une personnalisation d'au moins une carte 36, la personnalisation comprenant une modification visuelle de la présentation la carte, sans modification de la ou des chartes graphiques correspondantes 24, c'est-à-dire utilisant la ou les mêmes chartes graphiques. De même, permet à un utilisateur de faire une mise à jour d'au moins une carte 36 pour l'adapter à nouvelle forme 22' de l'application 22, la mise à jour comprenant une régénération de la carte 36 incluant une comparaison des composants de la carte et de leur organisation désirée avec les composants leur organisation désirée de la nouvelle forme de l'application, et l'application d'au moins l'une des chartes graphiques 24 aux nouveaux composants. Bien sûr, si les nouveaux composants incluent des composants non identifiés dans la ou les chartes graphiques existantes, ou s'ils nécessitent la modification attributs, la ou les chartes graphiques existantes peuvent être modifiées en conséquence.

L'invention qui vient d'être définie a donc de nombreux avantages. D'abord, elle offre une représentation graphique simple et flexible. Cet avantage résulte du fait que dans le procédé de l'invention, l'étape description de l'application est rendue indépendante de la représentation graphique faite au moyen d'au moins une charte graphique 24 et associée à description 23. Cet avantage se répercute en pratique dans une mise à jour simplifiée de la représentation graphique. Dans l'exemple décrit, la carte simplement mise à jour de manière incrémentale. Seuls les changements apparaissent et toutes les personnalisations faites par le concepteur sont conservées. Ainsi, lors de l'apparition de nouveaux composants, un système de découverte d'objets peut les découvrir et les ranger dans les sous-arbres dédiés aux composants découverts. Par exemple, chaque fois que le système de découverte trouve une base de données de type Oracle, le système va la ranger dans la catégorie de type Oracle en l'insérant dans le sous-arbre dédié à Oracle. Ce nouveau composant bénéficie ainsi de la charte graphique associée à son père, de sorte que la nouvelle base Oracle va être dessinée avec le même aspect que les autres bases de données déjà présentes. Encore un avantage relatif à la flexibilité du procédé de l'invention, est possible d'obtenir plusieurs représentations graphiques à partir d'une même description d'application. autre avantage important est de rendre possible de façon simple une représentation calquée sur la logique du métier relatif à l'application a surveiller. Cet avantage est dû aux trois premières étapes (description de l'application, association d'une charte graphique et génération d'une carte), qui permettent de décrire aussi bien des objets type simple que des objets de type lien et de représenter ainsi des flux de données.

Un autre avantage est de pouvoir personnaliser carte en lui donnant une représentation graphique visuellement riche, sans avoir à modifier une charte graphique et en utilisant des outils tres puissants.

L'invention permet de conserver cet avantage lors de toute mise à jour de la carte, contrairement aux procédés antérieurs.

Claims (10)

Revendications

1. Procédé de représentation graphique d'une application informatique (22) définie par une organisation de composants, le procédé comprenant la génération à l'aide d'au moins un processeur (14) et dans des moyens de mémoire (15) d'un système informatique (11), d'une carte représentative de composants de l'application et d'une organisation désirée de ces composants, caractérisé en ce que l'étape de génération comprend, dans les moyens de mémoire (15), une description (23) de composants de l'application et d'une organisation désirée de ces composants, une formation d'au moins une charte graphique (24) définissant des attributs (25) de représentation graphique des composants et de leur organisation désirée, et la génération d'au moins une carte (36) en combinant ' l'aide dudit processeur (14) la description à au moins la charte graphique.

2. Procédé selon la revendication 1, caractérisé en ce qu'au moins (25a) des attributs (25) d'au moins la charte graphique (24) contenue dans les moyens de mémoire (15) détermine par un point de départ et point d'arrivée un type ("lien") de composants (F1-F9) représentatifs d'un flux de données entre les deux points, tandis qu'au moins un autre attribut (25a) détermine un autre type, tel qu'un type ordinaire ("simple") de composants (P1, P2, Bl-B3).

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la description de l'application incluant dans les moyens de mémoire (15) un arbre (23, 23') d'objets incorporant au moins un noeud constituant une racine d'un sous-arbre d'objets et ayant un type donné, au moins l'un des attributs (25) d'au moins la charte graphique (24) définit si le noeud et/ou au moins un objet du sous-arbre correspondant doivent être générés dans au moins la carte (36).

4. Procédé selon la revendication 3, caractérisé en ce qu'au moins la charte graphique (24) est formée, pour un type donné de nceuds, avec des attributs (25) relatifs aux objets du sous-arbre correspondant audit type de naeud.

5. Procédé selon la revendication 3 ou 4, caractérisé en ce qu'un noeud fils applique à l'aide d'au moins le processeur (14) la charte graphique de noeud père.

6. Procédé selon l'une des revendications 3 à 5, caractérisé en ce génération d'au moins la carte (36) est faite par au moins le processeur (14) dans les moyens de mémoire (15) selon un algorithme faisant moins un parcours de l'arbre pour dessiner dans la carte les objets type donné en appliquant au moins la charte graphique correspondante (24).

7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'il comprend en outre une personnalisation faite, à l'aide d'au moins le processeur (14) dans les moyens de mémoire (15), d'au moins la carte (36) par un utilisateur, la personnalisation comprenant une modification de la carte contenue dans les moyens de mémoire (15) sans modification de la ou des chartes graphiques correspondantes (24).

8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il comprend en outre une mise à jour d'au moins la carte (36) par un utilisateur pour l'adapter à une nouvelle forme (22') de l'application (22), la mise à jour comprenant une régénération de la carte (36) dans les moyens de mémoire (15) à l'aide d'au moins le processeur (14), la régénération incluant une comparaison des composants et de leur organisation désirée de la carte avec les composants et leur organisation désirée la nouvelle forme de l'application et l'application moins la charte graphique (24) aux nouveaux composants.

9. Système d'administration (10) incluant au moins un processeur (14), des moyens mémoire (15) et une application (21) pour la représentation d'une application informatique (22) exécutable dans un système d'information (11) et la surveillance de son exécution, caractérisé en ce que l'application (21) met en oeuvre dans les moyens de mémoire (15) le procédé défini par l'une des revendications précédentes.

10. Système d'information (11) incorporant au moins un processeur (14), des moyens de mémoire (15) et une application informatique (22), caractérisé en ce que l'application informatique est représentée graphiquement dans les moyens de mémoire (15) selon le procédé défini l'une des revendications 1 à 9.