Brevet FR2889325A1 — publié le 20070202

ARCHITECTURE A COMPOSANTS LOGICIELS POUR LES APPLICATIONS A PLATE-FORME D'EXECUTION DONNANT ACCES AU NIVEAU METAPROGRAMME La présente invention se rapporte à une architecture à composants logiciels pour les applications à plate-forme d'exécution donnant accès au niveau métaprogramme, et en particulier pour le développement et l'exécution d'interfaces homme-machine (IHM ou HCI en anglais: Human Computer Interface ). Le développement d'applications IHM rencontre des problèmes de natures différentes: - les problèmes fonctionnels (qui répondent aux besoins opérationnels du client) - les problèmes techniques (qui répondent aux besoins non fonctionnels du client) Le développeur doit fournir des solutions à tous ces problèmes. Ces solutions sont habituellement imbriquées. Cette imbrication ne permet pas une maintenance, une évolution et une réutilisation faciles. Les évolutions fonctionnelles demandées par le client sont plus difficiles à prendre en compte. Il est également très difficile de capitaliser des solutions techniques séparément des fonctionnalités (spécifiques de chaque client). Le développeur ne peut pas se concentrer sur la valeur ajoutée du développement que sont les fonctionnalités pour le client. De plus, le développeur doit structurer son application en choisissant une architecture. Une architecture à composants propose une décomposition en éléments (composants) faiblement couplés (avec le minimum possible d'interdépendance entre eux). Cette architecture à composants est régulière et est applicable à l'ensemble de l'application. Ces composants étant faiblement couplés, leur maintenance, leur évolution et leur réutilisation en sont plus faciles. Ces composants ayant une structure régulière, ils sont gérés de façon générique par un gestionnaire de composants (un conteneur, "container" en anglais). Ce conteneur apporte des solutions techniques aux problèmes non fonctionnels de l'application. Ces solutions techniques sont capitalisées séparément des fonctionnalités et disponibles pour toutes les applications d'IHM. Le développeur peut alors plus facilement se concentrer sur les besoins fonctionnels, indépendamment des besoins techniques. Aujourd'hui, des architectures à composants sont proposées par des standards (JavaBeans, Enterprise JavaBeans- EJB, CORBA Component ModelCCM) et des COTS (Component Object Model-COM, SpringFramework, etc.). Dans le cadre d'une architecture multi-niveaux (Figure 1), ces architectures se concentrent sur le niveau métier, peu concernent le niveau présentation. Le niveau présentation peut se présenter sous deux formes différentes: clients lourds (application IHM à part entière à déployer sur 15 le poste client avant utilisation) - clients légers (seul un navigateur Web est déployé sur le poste client). Les architectures à composants sont essentiellement proposées pour les clients légers (Java Server Page-JSP, Active Server 20 Page-ASP, etc.). Pour les clients lourds, les architectures connues à composants ne proposent qu'un sous-ensemble de la totalité des caractéristiques nécessaires à la définition complète d'un composant, et qui constituent un modèle de composant. Le modèle de composant au sens de la présente invention doit comporter au moins les définitions suivantes: - définition explicite des services rendus et utilisés par le composant - définition explicite des événements produits et consommés par le composant définition explicite des paramètres du composant - définition explicite du type du composant. Ces caractéristiques, si elles étaient toutes présentes dans une architecture permettraient de séparer clairement l'interface du composant de son implémentation. Elles permettraient donc de fournir plusieurs implémentations pour une même interface. De plus, la majorité des modèles de composants connus imposent une forme particulière: ces modèles de composants sont très intrusifs. Les classes d'analyse (résultant de l'analyse des spécifications fonctionnelles de l'application) doivent être profondément transformées pour se conformer au moule de l'architecture à composants du standard ou du COTS. L'objectif actuel de l'industrie informatique est d'atteindre la transparence totale pour les modèles de composants: les classes d'analyse ne seraient alors pas transformées pour être accueillies par le conteneur. Par ailleurs, les architectures actuelles de composants ne proposent qu'un sous-ensemble des capacités techniques nécessaires: - les services sont uniquement en mode synchrone, - les événements sont uniquement en "push" asynchrone, - les données des services et des événements sont uniquement définies par valeurs (par copie) ou par référence sur la base du déploiement (les données sont définies par valeur uniquement dans le cas d'un accès distant réseau). Les capacités techniques nécessaires sont présentes lorsque: - les services peuvent être utilisés de manière synchrones ou asynchrones, - les événements peuvent être publiés en "push" ou en "pull", de manière synchrone ou asynchrone, - les données des services et des événements sont transmises par valeur ou par référence indépendamment du 25 déploiement et de l'accès réseau. La présente invention a pour objet une architecture à composants logiciels pour les applications à plate-forme d'exécution donnant accès au niveau métaprogramme, et en particulier pour le développement et l'exécution d'interfaces homme-machine dans le cadre de clients lourds, qui soit complète et transparente, et elle a également pour objet une interface homme-machine comportant une telle architecture. La présente invention a également pour objet un procédé de mise en communication de composants logiciels pour une application à plate-forme d'exécution donnant accès au niveau métaprogramme, dans une architecture du type précité, procédé ne produisant pratiquement pas d'intrusion dans le code des composants, les contraintes techniques étant réduites à leur plus simple expression. L'architecture à composants conforme à l'invention est une architecture à composants définissant explicitement toutes les caractéristiques des composants, sans pratiquement intervenir sur le code définissant ces composants, gérant les composants pendant leur exécution, et leur fournissant des services techniques, et elle comporte un conteneur générique accueillant d'une part des composants dont la définition découle des spécifications du cahier des charges de l'application à réaliser et dépend du domaine d'utilisation de l'application, ce conteneur accueillant d'autre part des services techniques fournis. Le procédé de l'invention est caractérisé en ce que le conteneur détermine automatiquement à l'exécution les caractéristiques des composants et la description des services techniques fournis par interrogation via le métaprogramme des composants et des services fournis. Selon un autre aspect du procédé de l'invention, les services techniques fournis sont mis à disposition des composants par un morceau de code directement exécutable généré par le conteneur. De façon avantageuse, le morceau de code assure la jonction entre deux composants quelconques. 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 25 limitatif et illustré par le dessin annexé, sur lequel: - la figure 1, déjà mentionnée ci-dessus, est un bloc-diagramme simplifié d'une architecture à composants logiciels pour le développement et l'exécution d'interfaces homme-machine aussi bien dans le cadre de clients lourds que de clients légers, architecture à laquelle peut s'appliquer l'invention, la figure 2 est un bloc-diagramme simplifié de l'architecture à composants conforme à l'invention, avec le conteneur, les composants applicatifs accueillis, et les services techniques fournis par le conteneur et disponibles pour tous les composants, la figure 3 est un bloc-diagramme explicitant des détails de fonctionnement de l'architecture de la figure 2, - les figures 4 à 8 sont des diagrammes d'exemples d'implémentations de composants, conformément à l'invention. La présente invention est décrite en détail ci-dessous en référence à une interface homme-machine, mais il est bien entendu qu'elle n'est pas limitée à ce seul exemple, et qu'elle peut être mise en oeuvre pour toutes autres applications comportant une plate-forme d'exécution permettant l'accès au niveau métaprogramme, c'est-à-dire des applications mettant en oeuvre un langage de programmation qui fournit une définition objet de lui-même. On a schématiquement représenté en figure 1 les trois principaux niveaux d'une architecture à composants logiciels pour le développement et l'exécution d'interfaces homme-machine. Ces trois niveaux sont: le niveau données (mettant en oeuvre un standard tel que EJB), le niveau métier (pouvant mettre en oeuvre des standards tels que EJB session, CCM, COM, Spring) et le niveau présentation, qui est un poste de travail. Si ce poste est celui de clients lourds, il fonctionne généralement sous JavaBeans, alors que pour les clients légers, il peut fonctionner sous JSP ou ASP par exemple. L'architecture à composants logiciels représentée en figure 2 comporte essentiellement un conteneur générique 1 accueillant d'une part des composants 2 dont la définition découle des spécifications du cahier des charges de l'application à réaliser et dépend du domaine d'utilisation de cette application. Le conteneur 1 accueille d'autre part des services fournis tels que ceux cités ci-dessous. Le conteneur a en charge la gestion du cycle de vie d'exécution des composants. Il les active, les supprime, assure la mise en communication entre eux, et les connecte aux services techniques dont ils ont besoin, par exemple en fonction de la qualité de service requise, qui peut être évolutive. Les composants accueillis sont les composants développés dans le cadre d'une application spécifique. Ils expriment d'une manière compréhensible par le conteneur la nature des services techniques dont ils souhaitent bénéficier. Le conteneur interprète ces expressions de besoins et appelle les services techniques désirés à la place de ces composants, pour leur bénéfice, et les met en relation avec les composants demandeurs. Les services techniques sont des composants utilisés par le conteneur pour prendre en charge les capacités non fonctionnelles, tels 10 que: - la persistance des paramètres des composants - la propagation d'événements entre composants (suivant les modes "push" ou "pull") - les traces des entrées / sorties des composants - l'asynchronisme des entrées / sorties des composants - la communication distante (réseau) entre les composants L'architecture de l'invention définit les principes de développement d'une application à base de composants par spécification de composants compatible d'un processus centré sur le modèle UML ("model driven" en anglais). Sur le diagramme de la figure 3, qui représente partiellement une interface d'un dispositif de contrôle d'un véhicule, un conteneur 4 accueille d'une part des composants applicatifs tels que les composants 5 et 6 (respectivement un composant de mesure de vitesse et un composant de calcul de temps de trajet, pour cet exemple), et des services techniques 7, 8 et 9 (respectivement les traces des entrées/sorties des composants mis en oeuvre, la notification d'événements et la gestion d'asynchronisme) . En outre, le conteneur étant considéré comme un composant au même titre que tous les éléments qu'il accueille, il comporte un prolongement 10 qui est représenté comme les autres composants et qui se comporte comme eux. II en résulte que toute cette architecture est homogène et constituée de composants communiquant entre eux de la même façon, comme expliqué cidessous. On suppose que le composant 5 désire communiquer avec le service technique 10. A cet effet, il envoie une requête d'événement au conteneur 4. Le conteneur ajoute à cette requête un morceau de code directement exécutable (code pouvant être produit uniquement par le conteneur et dénommé en anglais glue ) assurant la jonction technique entre le composant demandeur et le composant demandé, dont le contenu est fonction du besoin exprimé par le demandeur. La requête, accompagnée de ce code, est transmise au composant demandé (le service technique 10 dans le cas présent), qui se met en état de communiquer. Ensuite, le dialogue se poursuit entre les composants 5 et 10 à chaque fois via le conteneur 4 jusqu'à son achèvement. Le même processus est à chaque fois mis en oeuvre entre deux composants rattachés au conteneur 4, quelle que soit leur nature (composants en tant que tels, comme les composants 5 et 6, ou bien services techniques). La présente invention utilise les mécanismes de réflexion offerts par la plate-forme Java pour décrire les composants sans les déformer (pratiquement pas d'intrusion dans le code des composants, les contraintes techniques sont réduites à leur plus simple expression). Ces mécanismes de réflexion permettent au programme de s'examiner et de manipuler les éléments du langage pendant son exécution, à l'aide d'une représentation objet de lui-même. L'utilisation d'éléments de programmation tels que les interfaces de marquage ("tag interfaces" en anglais) ou les annotations permet de décrire les caractéristiques de ces composants sans contrepartie (en particulier, pas de code supplémentaire dans le composant lié à l'utilisation de ces interfaces de marquage ni aux annotations). La description des caractéristiques d'un composant se fait à l'aide des éléments suivants du modèle de composant: É Type du composant "ComponentType". É Services du composant "ComponentServices". É Événements du composant "ComponentEvents". É Paramétrage du composant "ComponentParameters". interface ou méta-donnée interface ou méta-donnée : interface ou métadonnée interface ou méta-donnée É Données du composant: interface ou métadonnée "ComponentDataServices" pour l'accès aux données, interface ou méta-donnée "ComponentDataEvents" pour les événements liés aux données. Sur la figure 4, qui illustre un exemple de description d'un composant 11 ( component impl ) faite avant son utilisation dans une application, les quatre premières interfaces 12 (le modèle de composant) sont représentées sur une première rangée. Viennent ensuite les interfaces et les classes du composant défini pour l'application considérée: type de composant 13, services du composant 14 (services fournis) et 14A (services utilisés), événements du composant 15 (événements utilisés) et 15A (événements produits), paramètres du composant 16 (paramètres fournis) . Sur l'exemple de la figure 5, les services et les événements liés 15 aux données sont représentés par l'utilisation de méta-données (annotations Java). Le composant 17 est décrit par: - des services techniques fournis 18 définis par des données relatives aux données du composant et auxquelles sont rattachées des annotations Java 18A, le type de composant 19, auquel est rattachée l'annotation Java 19A, des événements produits définis par des données d'événements 20, auxquelles sont rattachées des annotations Java 20A. Selon l'invention, le conteneur assure la gestion des composants dont il a la description. En particulier, il gère le cycle de vie des composants, à savoir: É La création des instances des composants. É L'activation et la désactivation des instances des composants. É La suppression des instances des composants. Les composants qui sont intéressés par leur cycle de vie doivent écrire du code supplémentaire pour prendre la main dans les phases qui les intéressent. Dans la figure 6, le composant 21 est intéressé par toutes les phases du cycle de vie de son cycle de vie: initialisation, suppression, panne, activation, passivation. Les transitions 22 entre ces différents états sont classées en deux catégories: des transitions 23 dites techniques (initialisation, suppression et panne) et des transitions 24 dites fonctionnelles (activation, passivation et panne). A l'exécution de l'application, le conteneur connecte les composants de l'application en fonction de leurs besoins: É Branchement des services fournis ("provided services") dans les services utilisés ("used services") . É Branchement des événements produits ("produced events") dans les événements consommés ("consumed events"). É Branchement des paramètres fournis ("provided parameters") dans les paramètres utilisés ("used parameters"). Le conteneur exploite la description des services techniques 15 demandés pour connecter les composants entre eux. La figure 7 explicite un exemple de description des services techniques demandés par un composant. On y a représenté une interface 25 de modèle de composant comportant quelques exemples de services techniques pouvant être demandés par un composant 26. Le composant 26 est décrit dans l'exemple par: É Les paramètres 27 du composant (CompAParameters) sont déclarés persistants (marquage par l'interface "PersistanceCapable" ou la méta-donnée correspondante). É Les services 28 du composant (CompAServices) sont déclarés comme étant accessible à distance (marquage par l'interface "Remotable" ou la métadonnée correspondante). É Les événements 29 du composant (CompAEvents) sont publiés de façon asynchrone (marquage par l'interface "Asynchronous" ou la méta-donnée correspondante). Dans tous les cas, les interfaces de marquage peuvent être remplacées par le mécanisme de méta-données proposé par le langage et la plate-forme de programmation. Dans le cas du langage Java, ces méta-données sont transcrites par des annotations. Ce qui donne le schéma de la figure 8, dans laquelle le composant 30 est décrit dans l'exemple par: -des paramètres de composant 31, auxquels est rattachée l'annotation Java 31A, - des services de composant 32, auxquels est rattachée l'annotation Java 32A, - une description de type de composant 33, à laquelle est rattachée l'annotation Java 33A, - une description d'événements produits 34, à laquelle est rattachée l'annotation Java 11 REVENDICATIONS 1. Architecture à composants logiciels pour une application à plate-forme d'exécution donnant accès au niveau métaprogramme, caractérisée en ce qu'elle est une architecture à composants (2, 3) définissant explicitement toutes les caractéristiques des composants, sans pratiquement intervenir sur le code définissant ces composants, gérant les composants pendant leur exécution, et leur fournissant des services techniques, et qu'elle comporte un conteneur générique (1) accueillant d'une part des composants (2) dont la définition découle des spécifications du cahier des charges de l'application à réaliser et dépend du domaine d'utilisation de l'application, ce conteneur accueillant d'autre part des services techniques fournis (3). 2. Architecture selon la revendication 1, caractérisée en ce que les services fournis sont au moins un des services suivants: la persistance des paramètres des composants, la propagation d'événements entre composants, suivant les modes "push" ou "pull", les traces des entrées / sorties des composants, l'asynchronisme des entrées / sorties des composants, la communication distante entre les composants. 3. Procédé de mise en communication de composants logiciels pour une application à plate-forme d'exécution donnant accès au niveau métaprogramme, dans une architecture selon la revendication 1 ou 2, caractérisé en ce que le conteneur détermine automatiquement à l'exécution les caractéristiques des composants et la description des services techniques fournis par interrogation via le métaprogramme des composants et des services fournis. 4. Procédé selon la revendication 3, caractérisé en ce que les services techniques fournis sont mis à disposition des composants par un morceau de code directement exécutable généré par le conteneur. 5. Procédé selon la revendication 4, caractérisé en ce que le morceau de code assure la jonction entre deux composants quelconques. 6. Interface homme-machine, caractérisée en ce qu'elle comporte une architecture selon l'une des revendications 1 ou 2.