CENTRE REGIONAL ASSOCIE CNAM DE LYON ______ EXAMEN

Transcription

CENTRE REGIONAL ASSOCIE CNAM DE LYON
_______
EXAMEN PROBATOIRE D’INFORMATIQUE
par
Véronique BETEILLE
______
ICL un langage de programmation de composants interfaçables.
Description du langage,
sa mise en œuvre avec OpenJava et la connexion des programmes avec Things.
Juin 2005
Professeurs responsables :
Jacques KOULOUMDJIAN
Claude GENIER
ICL un langage de programmation de composants interfaçables…
Table des matières
Introduction ........................................................................................................................................................... 3
1. Approche du concept de modèle de composants ..................................................................................... 3
1.1. Les composants ........................................................................................................................................ 3
1.2. Description de modèles existants.............................................................................................................. 3
Le modèle Corba ...................................................................................................................................... 4
Le modèle Rainbow .................................................................................................................................. 5
Le modèle Javabeans............................................................................................................................... 5
2. Description du langage ICL.......................................................................................................................... 7
2.1. Description du concept : modèle de composants interfaçables................................................................. 7
Définition du concept de composant interfaçable ..................................................................................... 7
Le modèle de composants interfaçables .................................................................................................. 7
2.2. La syntaxe du langage ICL........................................................................................................................ 9
3. La mise en œuvre d’ICL avec OpenJava .................................................................................................. 14
3.1. Présentation d’OpenJava ........................................................................................................................ 14
3.2. La mise en œuvre d’ICL avec OpenJava ................................................................................................ 15
4. La connexion des programmes avec ThingsTM ........................................................................................ 16
4.1. Le choix de ThingsTM comme outil d’interfaçage ..................................................................................... 16
4.2. Principes de fonctionnement de ThingsTM ............................................................................................... 16
4.3. Couplage d’ICL avec ThingsTM ................................................................................................................ 17
Conclusion........................................................................................................................................................... 18
Glossaire .............................................................................................................................................................. 19
Bibliographie ....................................................................................................................................................... 20
Remerciements.................................................................................................................................................... 20
Annexes ............................................................................................................................................................... 21
Annexe 1 : Tableau comparatif des mécanismes d’interfaçage.............................................................. 21
Annexe 2 : Exemple de code de compilation ICL ................................................................................... 22
2 / 22
Introduction
De nos jours les entreprises doivent répondre à des exigences plus fortes de la part de leurs clients. Leurs
demandes imposent une grande rapidité dans les développements de logiciels ou applications. Les contraintes
d’ergonomie et de qualité augmentent considérablement.
Une des réponses à cette problématique est de concevoir de manière semi-automatique ou automatique
l’interface des applications. Cela autorisera la production de prototypes afin d’effectuer des démonstrations aux
clients. De la même façon, la réduction du temps de conception permettra de répondre plus vite aux attentes.
Il existe sur le marché des logiciels remplissant cette mission, cependant la qualité des IHM1 produites n’est pas
toujours satisfaisante. Aussi M.Fabresse, aidé dans sa mission de M.Dony, Mme Huchard, M.Pichon a entreprit
l’étude d’un nouveau langage. Il s’agit d’ICL : Langage de Composants Interfaçables. L’objectif de ce concept est
l’amélioration de la qualité des interfaces produites par des logiciels comme ThingsTM.
Afin de développer le nouveau langage ICL, le concept de modèle de composants interfaçables est proposé.
Dans cette étude, nous ferons une approche par l’exemple en détaillant quelques modèles de composants et
leurs principes de fonctionnement. Ceci nous permettra de décrire le langage ICL. Nous aborderons ensuite sa
mise en œuvre à l’aide d’OpenJava. Enfin nous examinerons comment la connexion des programmes ICL se fait
à l’aide du logiciel ThingsTM.
1. Approche du concept de modèle de composants
Après avoir précisé la notion de composant, nous examinerons quelques modèles qui ont permis la conception
du langage ICL.
1.1. Les composants
Un composant est un objet : pour qu’il soit considéré comme tel, il faut qu’il soit réutilisable.
C’est un morceau de logiciel :
autonome, indépendant d’un programme, d’un langage, d’un système d’exploitation,
que l’on peut configurer,
capable de s’auto décrire,
conçu pour un nombre limité de tâches,
utilisable dans des combinaisons non prévues par le développeur,
assemblable avec d’autres composants.
L’assemblage de plusieurs composants permet de concevoir une application.
1.2. Description de modèles existants
Un modèle de composants peut être considéré comme un conteneur. Il permet d’encapsuler le composant. Il
prend en charge la sécurité, le nommage, les transactions, la persistance. Il peut gérer partiellement les
connecteurs en invoquant des évènements. Il s’agit aussi d’une structure d’accueil ou les composants peuvent
s’exécuter. Il permet de définir quelles sont les normes qui leur sont imposées.
On note actuellement la présence de nombreux modèles de composants sur le marché. Nous en examinerons
trois qui ont contribué pour partie à la conception du modèle de composants interfaçables : tout d’abord Corba,
puis Rainbow, enfin Javabeans.
1
IHM :Interface Homme Machine
3 / 22
Le modèle Corba
Corba (Common Object Request Brocker Architecture) est une norme de l’OMG (Object Management Group).
C’est un mécanisme qui offre les moyens nécessaires pour identifier un objet, le localiser et enfin l’exposer. Il
utilise une base de données qui agit comme un service d’annuaire. Il simule l’équivalent de la base de registre du
monde Windows. Il est par contre opérationnel sur tout type d’environnement et de machines. Il repose sur un
ORB, bus logiciel assurant la communication entre les objets du réseau. Il utilise une couche de traduction
nommée IDL : il s’agit d’un langage d’interopérabilité qui permet aux objets de communiquer.
Le composant CORBA s’architecture de la manière ci-après :
Interface du composant
O
F
F
E
R
T
S
Facettes
=
Interface Offerte
Composant
Métier
Réceptacles
=
Interfaces Requises
Sources d’événements
=
Evènements produits
Puits d’événements
=
Evènements consommés
Attributs
Fig 1 – Architecture d’un composant Corba
Les facettes sont l’ensemble des méthodes offertes par le composant. Elles permettent au client de disposer de
l’interface dont il a besoin.
Les puits d’évènements représentent les évènements consommés.
Les réceptacles représentent l’ensemble des méthodes consommées par le composant, ils permettent leur
assemblage.
Les sources d’évènements représentent l’ensemble des évènements produits.
CORBA permet :
aux composants de se découvrir les uns les autres,
le développement d’applications à base de composants distribuées,
de s’affranchir des problèmes de communication, d’hétérogénéité, d’interopérabilité. Il réunit
simultanément les “bonnes” fonctionnalités des EJB2, de COM3 et de .NET 4,
la spécification, l’implantation, le conditionnement, l’assemblage, le déploiement et l’exécution des
composants qui peuvent être déployés et s’exécuter sur différentes machines.
Enterprise Java Beans
COM : Component Object Model, Modèle de composants spécifique à Windows.
4 .Net : Plate-forme Microsoft
2
3
4 / 22
R
E
Q
U
I
S
Le modèle Rainbow
Il s’agit d’un projet de l’I3S5 qui vise entre autre à étudier le principe de la conception automatique de logiciels. Il
propose un modèle de composants permettant à chaque entité de définir simultanément sa partie métier et sa
présentation si besoin est.
Prenons un exemple : on souhaite construire une facture avec un champ adresse. Le composant construisant
l’interface doit dialoguer avec un composant adresse pour être capable d’afficher celle ci. Si nous changeons de
composant adresse nous n’aurons pas à modifier celui de l’IHM. Un composant IHM pourra réutiliser la partie
IHM du composant adresse. Même si le composant adresse est modifié, celui de l’IHM ne le sera plus.
Permettre la composition et l’adaptabilité des IHM est l’un des objectifs de ce projet. A ce titre, plusieurs logiciels
ont été conçus :
Un outil d’assemblage dynamique de composants logiciels : Noah. Il utilise un langage de description
nommé ISL. Il est possible grâce à lui de modifier dynamiquement le comportement des composants.
Un atelier pour la composition dynamique d'IHMs : Amusing. Il utilise le langage SunML, dérivé de
XML6. Il permet au moyen d’un arbre de spécifier l’interface d’une application. Il est aussi possible
d’assembler ces arbres.
Ce modèle est intéressant car il permet d’être indépendant de l’implémentation finale ou du langage ; en effet
Noah permet de relier entre eux des composants Java, .Net, JavaRMI, EJB. Toutefois il semble poser quelques
limites comme le fait de devoir décrire pour chaque composant métier une description complète d’IHM. Ce
constat peut poser problème pour obtenir une configuration générale cohérente de l’application.
Le modèle Javabeans
Il s’agit d’une normalisation proposée par Sun pour développer des composants logiciels :
elle permet de spécifier le bus logiciel,
elle définit précisément le mode de fonctionnement des composants,
elle impose que tout composant soit réutilisable et transportable.
Grâce à la normalisation, un composant Javabeans possède : des attributs et des méthodes qui peuvent être
productrices d’évènements. Il intègre aussi des mécanismes d’enregistrement et de notification des évènements
qu’il produit, ainsi que des méthodes de traitements d’évènements. Les attributs forment ce que l’on nomme
aussi la configuration du composant.
La norme Javabeans impose que les attributs ne soient pas accessibles directement, mais par leurs méthodes
que l’on appelle méthodes d’accès ou accesseurs. Un bean7 peut générer des évènements qui sont normalisés.
Le modèle Javabeans offre la possibilité d’analyser les composants au moyen de deux concepts : la réflexion et
l’introspection. L’introspection est un mécanisme qui permet pendant l’exécution du bean de connaître les
propriétés, les événements qu’il supporte. Elle repose sur l’interface à implémenter, dont les méthodes
permettent de renseigner l’appelant sur un certain nombre d’éléments concernant l’objet. La réflexion permet une
analyse automatique de l’objet, à l’aide d’une API8 qui va examiner la classe dont il est issu.
I3S : laboratoire, unité mixte de recherche associée au CNRS et à l’université de Sophia-Antipolis
XML : eXtensible Markup Langage
7 Bean : Composant Javabean
8 API : Interface pour la Programmation d’Applications
5
6
5 / 22
Un des principes novateurs du modèle Javabeans est l’ensemble des possibilités qu’offrent les attributs ou
propriétés de gérer les évènements par rapport à un composant classique.
Les propriétés liées ou bound properties, permettent de disposer d’un support pour gérer les modifications : le
producteur est l’objet dont une, ou plusieurs propriétés, émettront l’événement en cas de changement de valeur
(1). Les auditeurs ou écouteurs seront tous les objets qui s’abonneront à ce type d’événement (2).
Les propriétés contraintes ou constrained properties permettent aux auditeurs d’apposer leur veto à la
modification (3). Cela se traduit par la création d’une exception (4) qui est renvoyée à l’auditeur (5), qui refuse la
modification (6). Cette exception devra être capturée dans le code de la modification de la propriété qui annulera
cette modification (7).
Le schéma ci-dessous résume les principes qui viennent d’être décrits :
Ecouteur 1
7
Code
2
Compteur
1
001
2
Compteur
4
Veto
Evénement
002
3
Ecouteur 2
6
5
Exception
Refus
Fig 2 – Processus d’écoute et de veto
Les évènements sont essentiels à l’assemblage des composants Javabeans même s’ils sont développés
indépendamment, tant que l’un produit et que l’autre écoute le même type d’événement.
Un autre type de propriété existe, il s’agit des propriétés indexées. Elles permettent d’accéder à un élément de
tableau ou de liste. On peut parler de valeurs multiples.
6 / 22
2. Description du langage ICL
Il est construit à partir d’un nouveau modèle de composants que nous allons décrire avant d’examiner les
spécificités du langage ICL.
2.1. Description du concept : modèle de composants interfaçables
Avant de définir ce qu’est le modèle de composant interfaçable il importe de préciser la notion de composant
interfaçable.
Définition du concept de composant interfaçable
La définition de ce concept a un peu évolué au cours de l’étude de M.Fabresse. En effet, à l’origine seule la
notion d’un composant métier possédant des informations pour son interfaçage est donnée. Puis, les notions de
propriétés et évènements apparaissent. Ensuite on fait référence à la description du composant à laquelle il est
possible d’ajouter un ou plusieurs éléments d’interfaces.
Enfin la définition finale prend corps : un composant interfaçable est un composant métier constitué de propriétés
intégrant des informations et des mécanismes qui facilitent la production semi-automatique d’IHM par un outil
d’interfaçage. Il a besoin d’un modèle pour pouvoir se connecter aux autres composants. Il possède deux
parties : métier et conteneur des informations d’interfaçages. Celles ci doivent être bien distinctes. Son objectif
est de simplifier la génération d’IHM avec des outils d’interfaçages.
Le modèle de composants interfaçables
Le nouveau modèle est issu de deux phases de réflexion : une première est la reprise de certaines possibilités
qu’offrent les modèles Corba et Javabeans. La deuxième se base sur les propriétés étendues de Javabeans et
sur quelques principes intéressants du projet Rainbow.
Un premier modèle issu de CORBA et de Javabeans :
Les principes du modèle Corba intéressants pour l’étude de référence sont l’assemblage de composants avec les
notions de puits, sources d’événements et réceptacles. De même, les facettes autorisent la possibilité de
différencier les points de vue sur les composants. Le principe de composant interfaçable aussi les richesses que
peuvent amener Javabeans avec les propriétés. Il s’inspire de la norme Corba 3.0 qui n’était pas totalement
implémentée au moment de l’étude. Ce premier modèle a été abandonné pour donner naissance au modèle
décrit dans le paragraphe ci dessous.
Un modèle basé sur Javabeans et Rainbow :
Le mécanisme des propriétés de Javabeans est à la base du nouveau modèle de composants interfaçables. Il
permet :
de déduire des informations sémantiques par introspection du code d’un composant,
de programmer des composants séparément, puis de les connecter afin qu’ils collaborent, sans qu’ils se
connaissent auparavant,
de gérer l’interfaçage semi automatique.
Quelques améliorations sont apportées au modèle Javabeans pour permettre de répondre précisément aux
besoins spécifiques du nouveau modèle. Le mécanisme des propriétés est notamment enrichi et affiné.
7 / 22
Le concept du projet Rainbow qui semble être intéressant dans le cadre de la conception du nouveau modèle est
la séparation des concepts de composants métier et IHM. Le modèle issu de l’ensemble de ces réflexions est le
suivant ; il provient principalement du modèle Javabeans :
Type
1
Property
is typed by
-nom
1
*
-nom
1
*
Component
-nom
*
Method
-body
is listened by
*
accessed by
Has for container type
{overlapping.incomplete}
0..1
ObservableProperty
AccessibleProperty
InProperty
ValuedProperty
*
accessibility
valueCardinality
{overlapping.complete}
{disjoint.complete}
OutProperty
MonoValuedProperty
MultiValuedProperty
observabiliy
{overlapping.incomplete}
NotifyBeforeChangeProperty
NBCP
NotifyAfterChangeProperty
NACP
*
AskBeforeChangeProperty
ABCP
Fig 3 – Modèle de propriétés d’un composant interfaçable
La représentation ci dessus offre les moyens de définir un nouveau modèle de propriétés pour les composants
interfaçables. Elle respecte le formalisme d’UML.
Le composant est associé à une ou plusieurs propriétés, celles ci sont typées. La contrainte incomplete permet
d’enrichir le modèle d’autres propriétés. La contrainte overlapping indique qu’il n’y a pas de disjonction entre les
sous catégories et qu’une propriété peut très bien être dans plusieurs d’entre elles, par exemple à la fois
accessible, valuée et observable. Les classes AccessibleProperty, ValuedProperty, ObservableProperty sont
héritées de la classe Property. On remarque ensuite, l’implémentation des principes fondateurs de Javabeans.
Les méthodes d’accès ou accesseurs :
La classe AccessibleProperty est accédée par la classe Method, il s’agit en fait de la notion d’accesseurs qui
stipule que les propriétés ne sont accessibles que par des méthodes d’accès. La classe InProperty hérite
d’AccessibleProperty, elle a ses valeurs accessibles en écriture par les méthodes d’accès. De la même façon, la
classe OutProperty a ses valeurs accessibles en lecture et n’est accessible que via les accesseurs.
8 / 22
Les propriétés multiples ou indexées :
Les classes MonoValuedProperty et MultiValuedProperty sont héritées de la classe ValuedProperty, il s’agit de la
notion de valeur unique et de valeurs multiples ou indexées qui sont spécifiées dans le modèle Javabeans. La
classe MultiValued a pour type de conteneur la classe Type.
Les propriétés liées – Les propriétés contraintes :
La classe ObservableProperty représente les concepts de propriétés liées et contraintes du modèle Javabeans.
Le concept d’écouteur est ici modélisé. La classe ObservableProperty est écoutée par la classe Component. Ce
qui signifie qu’un composant peut observer la propriété d’un autre composant. Il est écouteur de cette propriété.
Ici trois types de propriétés ont été modélisés. On peut en ajouter, voire les combiner si besoin est.
Les classes NotifyBeforeChangeProperty (NBCP), et NotifyAfterChangeProperty (NACP) héritent de la classe
ObservableProperty. La classe NBCP dit à ses écouteurs que sa valeur va être modifiée. La classe NACP dit à
ses écouteurs que sa valeur a changée. Ces deux classes correspondent aux principes de propriétés liées de
Javabeans. La classe AskBeforeChangeProperty hérite de NBCP, elle correspond au mécanisme de veto ou
méthode contrainte. Elle dit à ses écouteurs que sa valeur va être modifiée, mais ces derniers ont un droit de
veto, ils peuvent s’opposer à ce changement. Si personne n’a opposé de veto, la valeur est modifiée.
La notion de propriété observable est fondamentale pour l’assemblage de deux composants :
tout composant enregistré comme écouteur d’une propriété peut effectuer des traitements à chaque
notification de changement de la propriété.
l’assemblage est conditionné à l’enregistrement d’un composant comme écouteur des propriétés d’un
autre composant.
Il n’est alors pas nécessaire de savoir ce que les composants vont faire, ni comment ils vont être utilisés.
2.2. La syntaxe du langage ICL
La première syntaxe d’ICL se base sur le langage IDL. Il permet aux objets de définir des interfaces
interopérables et de pouvoir faire communiquer entre eux les composants. Deux concepts sont mis en œuvre.
Le premier concept nécessite de déclarer le composant. La figure ci-dessous illustre ce principe.
Provides permet de déclarer les façades
exportées par le composant.
Uses déclare un réceptacle de référence pour
une facette d’un certain type (ici
FacadePriseCourant)
Component Ordinateur {
provides FaçadeUtilisateur fu;
Emits déclare une source simple (un abonné
au maximum) pour les évènements de type en
panne.
uses FaçadePriseCourant fpc;
emits UnEvenement ue;
publishes EnPanne ep;
consummes UnEvenementExterieur uee;
}
Publishes déclare une source multiple
(nombre d’abonné maximum fixé ou non) pour
les évènements de type en panne
Consummes déclare un puits pour les
évènements de type UnEvenementExterieur
Fig 4 – Exemple de Code ICL à base d’IDL
On retrouve ici les concepts décrits dans le modèle CORBA, les notions de facettes, réceptacles, puits
d’évènements étant réutilisées.
9 / 22
Le deuxième concept détaille comment déclarer les propriétés
property annonce la déclaration d’une propriété.
in « modifieur » de propriété indique qu’elle est en écriture (setter disponible).
out « modifieur » de propriété indique qu’elle est en lecture (getter disponible).
inout « modifieur » de propriété équivalent à la combinaison des précédents (c’est à dire propriété en
lecture /écriture).
viewable « modifieur » indiquant que la propriété est intéressante du point de vue de l’interfaçage
(notion d’indicateur de visibilité).
bound déclare que la propriété est liée.
veto indique que la propriété est veto.
collection indique que la propriété est multiple.
Afin de déclarer un élément d’interface, on utilise ihmelement. Cette syntaxe a été modifiée, IDL a été
abandonné car le logiciel ThingsTM avec lequel les concepteurs veulent coupler ICL utilise du code Java compilé.
La décision d’implémenter ICL, par extension de Java a été prise. Quelques mots clés ont été ajoutés au
langage.
Voici donc comment la déclaration des propriétés s’effectue désormais :
component <component-name> déclare un composant interfaçable,
property annonce la déclaration d’une propriété,
in indique que la propriété est accessible en lecture via une méthode sur le composant,
out indique que la propriété est accessible en lecture via une méthode sur le composant,
nota indique que la propriété notifie ses écouteurs après changement de la valeur (NACP)
notb indique que la propriété notifie ses écouteurs avant changement de valeur (NBCP)
askb indique que la propriété demande l’autorisation de changer ses valeurs à ses écouteurs (ABCP)
collection of <element-type> annonce que la propriété est multi-valuée et contient des éléments de
type <element-type>
On retrouve ici les principes de la figure 3 page 8, spécifiant le modèle de propriétés d’un composant
interfaçable. Les déclarations in et out reprennent les principes des propriétés accessibles.
Les déclarations nota et notb implémentent les principes des propriétés observables. Askb représente les
principes des propriétés contraintes ou veto. Collection of reprend les concepts de propriété multiples ou
indexées.
Le langage se trouve quelque peu enrichi par rapport à sa précédente version. En effet, la déclaration bound est
déclinée en deux déclarations permettant de mieux gérer le mécanisme des écouteurs (nota et notb). La
déclaration inout a disparu, il est possible de mettre à la suite in out pour spécifier que nous sommes en lecture
écriture.
La déclaration Viewable n’existe plus, mais est implémentée d’une autre manière avec le concept de propriété
visualisable expliqué ci dessous. De même la déclaration Ihmelement est abandonnée au profit de la mise en
place d’un composant swing ; concept qui sera détaillé plus tard dans le rapport.
10 / 22
Voici un exemple avec un composant Book programmé avec la nouvelle version d’ICL
Component Book {
/**le titre de ce livre*/
property in out String title ;
/**les auteur(s) de ce livre*/
property in out collection authors collection of authors;
/**le isbn de ce livre*/
property in out askb String isbn;
/**l’éditeur de ce livre*/
property in out Publisher publisher;
/**la couverture délivre le chemin du fichier*/
property in out nota String imageFilename;
…
}
Fig 5 – Exemple de code ICL

La propriété title est de type String, accessible en lecture et en écriture.
La propriété authors permet de gérer une liste d’auteurs, accessible et lecture et écriture.
Une possibilité de contrôler le contenu de ISBN est offerte en déclarant askb, ceci peut permettre à un
composant dédié à la vérification des ISBN, de s’opposer à des valeurs incorrectes.
La propriété imageFilename de type String est accessible en lecture et en écriture, la déclaration de
nota permet de notifier aux écouteurs qu’un changement de valeur a eu lieu.
La mise en place de propriétés supplémentaires :
Comme nous l’avons vu dans le modèle décrit page 8, les propriétés sont le fondement de l’assemblage des
composants. Elles jouent aussi un rôle important lors de l’interfaçage car elles possèdent des caractéristiques de
configuration. On doit donc pouvoir les représenter quand on conçoit une IHM.
Cependant, quand un programmeur produit le code métier d’une application, il déclare les propriétés
visualisables. Or ce n’est normalement pas à lui de faire le choix de l’interfaçage. Il n’y a en effet à ce moment là
pas de possibilité d’isoler la partie vue. Il faudrait, lors de la réalisation, pouvoir indiquer quelles sont les
propriétés visualisables pour l’IHM. Ceci amène à intégrer deux mécanismes dans les composants interfaçables.
La synchronisation des propriétés visualisables devant êtres représentées sur l’IHM :
La synchronisation est possible en stockant pour chaque propriété visualisable, sa liste d’écouteurs ainsi que les
méthodes pour permettre l’abonnement et la résiliation. La notification aux écouteurs lors d’une modification doit
aussi être prise en compte. Pour y parvenir, le principe de HashTable de Java a été utilisé. Cette solution
nécessite un test dans tous les accesseurs de propriétés. Le principe de fonctionnement des HashTable ou
tables de hachage est le suivant : il s’agit d’un ensemble d’objets classés à l’aide d’une clé qui elle même est un
objet.
11 / 22
private Hashtable hash ;
/** Ajoute aListener a la liste des écouteurs de la propriété aPropertyName */
public void addListener( String aPropertyName, Component aListener ){
Collection listeners = (Collection) hash.get( aPropertyName ) ;
1
if( listeners != null ){
listeners.add( aPropertyName ) ;
hash.put( aPropertyName, listeners ) ;
}
}
/** Enlève aListener de la liste des écouteurs de la propriété aPropertyName */
public void removeListener( String aPropertyName, Component aListener ){
2
if( listeners != null ){
listeners.remove( aPropertyName ) ;
hash.put( aPropertyName, ) ;
}
}
/** Rend la propriété aPropertyName visualisable */
public void setVisible( String aPropertyName ){
3
if( listeners == null )
hash.put( aPropertyName, new Vector() ) ;
}
Fig 6 – Déclaration des propriétés visualisables à l’aide d’une HashTable
Ici l’idée est de stocker dans chaque composant une HashTable qui associe à un nom de propriété soit la valeur
null qui indique que la propriété n’est pas visualisable, soit la liste des écouteurs. Chaque composant interfaçable
doit posséder les méthodes AddListener, RemoveListener, SetListener. Elles vont permettre la gestion des
écouteurs. Le code figurant ci dessus illustre l’implémentation de ces principes dont voici l’explication :
1. La méthode AddListener permet l’abonnement du composant aListener :
Elle est associée au nom de la propriété à laquelle va s’abonner aListener : aPropertyName. Hash.get
permet de récupérer l’objet dont la clé est identique à aPropertyName. La liste des écouteurs ajoute
aListener à ses abonnés en implémentant listeners.add. Hash.put, ajoute une paire, clé/valeur, ici
aPropertyName est la clé, listeners est la valeur.
2. La méthode RemoveListener permet la résiliation de l’abonnement du composant aListener :
L’abonnement de aListener à la propriété aPropertyName est résilié avec listeners.remove. Hash.put
ajoute ici uniquement la clé, sans la valeur.
3. La méthode SetVisible permet de rendre visualisable la propriété aPropertyName :
Ici on détecte que si la valeur de listeners est à null. La propriété Hash.put prend en paramètre
aPropertyName et un Vecteur. Ce qui permet de rendre la propriété visualisable.
12 / 22
Ainsi implémentée, la Hashtable permet de couvrir l’objectif initial qui est de pouvoir synchroniser les propriétés
visualisables devant être représentées sur l’IHM. Il est alors possible d’avoir une IHM qui s’enregistre comme
écouteur des propriétés visualisables qu’elle représente. Ce principe permet aussi une bonne séparation du code
métier et du code IHM.
Voyons concrètement comment cela se passe à l’aide du schéma ci dessous :
1
Propriété visualisable
Méthode SetVisible
2
S’enregistre
Compteur
IHM
11
10
3
Incrémente
Notifie les changements
4
5
Met à jour
ses données
Fig 7 – Fonctionnement des propriétés visualisables
Au moment de l’interfaçage,
1 - la propriété valeur est indiquée comme visualisable, la méthode SetVisible est donc implémentée,
2 - L’IHM produite s’enregistre comme écouteur,
3 - le compteur est incrémenté, étant donné qu’il y a changement dans la propriété valeur,
4 - celle ci notifie ses changements à l’IHM,
5 - l’IHM peut mettre à jour les représentations de cette propriété. La valeur inscrite sur l’IHM passerait
donc à 11.
Il est aussi possible de faire appel à d’autres collections du langage Java pour mettre en oeuvre cette solution,
comme par exemple la classe Vector9.
L’association d’une représentation spécifique à une composant :
Il serait intéressant de pouvoir associer à un composant interfaçable, une représentation graphique particulière
qui pourra être utilisée pour le représenter sur une IHM.
Pour obtenir ce résultat, il faut doter le composant d’une propriété specificRepresentation, dont la valeur est un
composant swing ou widget. Les composants swing sont conformes à l’architecture MVC10. Ce concept a comme
avantage l’isolation de la partie vue et permet de définir plusieurs vues interchangeables. Le widget utilisé ici est
le JPanel. C’est un type de conteneur dans lequel on peut mettre d’autres composants et ainsi obtenir des
interfaces par imbrications, on parle aussi de composites.
Dans le cadre de l’étude de référence, l’exemple d’une bibliothèque a été implémenté. Le widget JPanel permet
de mettre côte à côte les images de tous les livres (voir figure 11 page 17).
Pour associer une représentation spécifique à un composant interfaçable, il faut utiliser l’accesseur en écriture
avec setSpecificRepresentation(JPanel) de la propriété specificRepresentation. L’IHM peut alors l’obtenir via
l’accesseur en lecture et peut combiner visuellement les représentations spécifiques de ses constituants afin de
s’en fabriquer une.
Les deux concepts décrits ci-dessus illustrent en fait la séparation possible de la partie vue et de la partie métier.
9
Vector : Ensemble d’objets pouvant être retrouvés par leurs références
MVC : Model Vue Contrôleur
10
13 / 22
3. La mise en œuvre d’ICL avec OpenJava
Nous venons de définir les bases du langage ICL dans la partie ci dessus, il ne peut toutefois pas être utilisé tel
quel. En effet, la modélisation que nous avons décrite en page 8 impose de transformer le concept des propriétés
existant dans le modèle Javabeans en un concept plus étendu. On peut parler en quelque sorte de réification11
des propriétés. Ceci impose de pouvoir gérer les méta-niveaux, notion que nous définissons ci-dessous. Le
langage Java ne gère pas cette possibilité. Il est toutefois possible d’implémenter ce principe avec OpenJava.
Nous expliquerons ici ce qu’est ce concept et comment ICL peut être mis en œuvre grâce à lui.
3.1. Présentation d’OpenJava
Un méta-objet joue le rôle d’interprète pour un ou plusieurs objets. Il permet de contrôler la structure et le
comportement d’autres objets. Les méta-objets sont regroupés dans un méta niveau qui possède la description
du niveau de base et l’interprète. Le code du niveau de base couvre les fonctionnalités de l’application. Le code
du méta-niveau adapte le code du niveau de base à l’environnement. Ils sont liés par le code de configuration.
OpenJava est un Protocole Méta-objet (MOP) pour Java. Il a été conçu par Michiaki Tatsubori et il est disponible
en open source. C’est une extension du langage Java qui met en œuvre les principes énoncés ci-dessus. Un
MOP doit permettre aux utilisateurs d’ajuster la conception et l’implémentation à leurs besoins particuliers.
OpenJava intervient à la compilation, il permet d’obtenir un code source java compilé, de modifier ou étendre le
mécanisme de cette phase et par conséquent de modifier le langage, d’ou son choix dans le cadre de l’étude de
référence.
Le programmeur peut définir des méta-objets qui n’existeront que lors de la compilation. Ils prennent en charge la
modification du code source, en s’appuyant sur l’arbre syntaxique (AST), ils peuvent alors modifier la structure de
chaque type de nœud de l’arbre, comme par exemple la déclaration d’une variable, l’appel d’une méthode,
l’affectation etc.
OpenJava est basé sur la transformation des méta-classes. Elles permettent de décrire les classes et de les
instancier et doivent hériter d’OJCClass.
Le compilateur OpenJava est composé de deux modules, un module qui traduit les sources OpenJava en
sources Java et un module qui correspond avec le compilateur Java.
Son fonctionnement est le suivant :
Code 2
Méta-niveau
1
Code
Niveau de Base
Traducteur
OpenJava
3
4
Lien
compilateur
Java
5
Code
Exécutable
Runtime support
Fig 8 – Fonctionnement du compilateur OpenJava
Le compilateur commence par analyser le code source d’une classe (1). Il tient compte des éléments définis dans
sa méta-classe (2).Le passage du niveau de base au méta-niveau est intégré dans le code, le niveau de base et
le méta-niveau sont alors fusionnés (3). Finalement OpenJava transforme le résultat en une classe java standard
(4) .Le compilateur java peut ensuite compiler (5).
11
Réification : Permet de transformer une entité abstraite en objet.
14 / 22
3.2. La mise en œuvre d’ICL avec OpenJava
Un composant interfaçable est en fait une méta-classe. Il devra donc hériter de la classe OJClass. Celle ci
permet de définir la structure et les traitements utiles pour obtenir une classe Java. Afin de faire fonctionner
OpenJava avec ICL une chaîne de compilation est mise en en place. Elle permet de traduire le code ICL des
composants en Java. Elle est composée des éléments suivants :
un traducteur de code source ICL vers OpenJava qui ajoute dans le code ICL des informations telles
que la méta-classe et permet de s’affranchir des limitations syntaxiques du MOP. Le simple fait de
déclarer un composant par exemple n’est pas pris en compte par ce langage, il faut déclarer une classe.
Le traducteur permet ce genre de transformation,
d’une version modifiée du compilateur OpenJava qui traite les fichiers sortis du traducteur et invoque
des générateurs de codes,
le compilateur modifié va permettre d’invoquer des générateurs de code qui vont produire ces fichiers
supplémentaires,
La chaîne de compilation peut être représentée de la manière suivante :
Fichier ICL
Traducteur ICL
vers OpenJava
Compilateur
Open Java modifié
Fichier
OpenJava
Construction
AST
Modifications par le
méta niveau
Composants
Fichier
Java
Compilateur Java
Fichier
class
Interfaçables
Choix d’un composant
principal
Générateur
Générateur
Eléments
Fichier things
Interfaces
composites
Fichier
things
Eléments
Interfaces
Composites
Fig 9 – Chaîne de compilation ICL - OpenJava
Le fichier ICL est donc transmis au traducteur ICL ; il va produire un fichier OpenJava, qui lui même va être
transmis au compilateur modifié OpenJava.
Celui ci va produire d’une part un fichier java standard qui pourra être ensuite compilé. Par ailleurs, les
informations utiles seront transmises aux générateurs de codes qui pourront alors générer le fichier contexte, les
éléments d’interfaces composites (Voir code compilation annexe 2).
15 / 22
4. La connexion des programmes avec ThingsTM
ThingsTM est un outil de la société Gatonero ; il permet de générer semi automatiquement des IHM à partir d’une
logique métier préexistante. Après avoir examiné pourquoi il a été choisi comme outil d’interfaçage avec ICL,
nous décrirons ses principes de fonctionnement, puis nous aborderons comment il fonctionne avec ICL.
4.1. Le choix de ThingsTM comme outil d’interfaçage
Plusieurs outils existent sur le marché permettant de créer de manière semi-automatique des interfaces. Le
comparatif joint en annexe 1 fait ressortir que ThingsTM possède des fonctionnalités qui le place bien par rapport
à ses concurrents. Les principaux avantages offerts par l’outil sont : les possibilités de personnalisation par le
concepteur et l’utilisateur, une bonne qualité finale de l’IHM, une bonne ergonomie et un temps faible de
conception. ThingsTM à une approche qui consiste à générer le plus automatiquement possible l’IHM d’une
application à partir de l’étude de son code métier. L’ensemble de ces facteurs a contribué au choix de ThingsTM.
4.2. Principes de fonctionnement de ThingsTM
ThingsTM s'utilise plutôt dans des cas de ré-ingéniérie d'interfaces pour des applications existantes. Il analyse le
code compilé, afin de découvrir les informations nécessaires à l’interfaçage de l’application. Il permet ainsi de
fournir une interface au code métier.
Pour que ThingsTM fournisse une IHM complète, ergonomique et utilisable, il est nécessaire de fournir via un
fichier de contexte des paramètres qui vont faciliter l’analyse du code métier. Le fichier contexte est en fait un
fichier XML, qui respecte une syntaxe imposée par le logiciel. Il indique au minimum, l’emplacement du code
Java compilé, ainsi que les ressources. Il est utile au concepteur, pour diriger l’introspection. En effet il est
possible de spécifier quels éléments du code métier on veut conserver, quels sont ceux que l’on veut masquer.
Ceci est intéressant notamment à des fins de prototypage, quand on a développé une partie, qui n’est pas encore
totalement terminée, que l’on ne veut peut être pas montrer tout de suite. Grâce à ce fichier contexte, il est
possible d’indiquer pour chaque objet s’il doit être affiché. En outre, on peut spécifier les paramètres d’affichage
pour l’explorateur et le formview qui encapsulent les informations de l’objet, la représentation spécifique sous
forme d’objet. On peut aussi séparer le code métier et le code de l’interface.
Le code métier se trouve dans un fichier compilé ou bytecode Java. Il doit respecter la norme Javabeans, pour
l’introspection et la connexion du code métier avec celui de ThingsTM par le mécanisme des évènements. Ceci
permet à ThingsTM d’utiliser le principe des écouteurs, ce qui lui assure un meilleur fonctionnement.
L’interface se compose d’une fenêtre principale, avec une barre de menus en haut, et une barre de raccourci à
gauche. On y trouve d’autres écrans représentant les objets métiers. On peut explorer l’objet au moyen d’un
treeview ou explorateur. Sur la droite, on trouve les éléments détaillés de l’objet. Deux parties composent ce
volet, le Form View ou l’on retrouve des champs de saisie, Le Preview dans lequel on trouve une représentation
particulière de l’objet métier, dans l’exemple de la figure 10 page 17 il n’est pas présent.
16 / 22
Exemple de fichier contexte minimal:
<?xml version="1.0" ?>
<context>
<resources>
<jar href="." />
</resources>
</context>
Exemple de bytecode Java :
FormView
public class Compteur {
private int valeur ;
valeur=0 ;
}
public int getValeur() {return valeur ;}
public void SetValeur (int i) {valeur=1 ;}
public void increment()
{setValeur(getValeur(getValeur()+1) ;}
Fig 10 – Fonctionnement de Things
ThingsTM a des limites. Il est par exemple difficile de représenter les objets métiers d’une façon spécifique, par
exemple un entier représenté sous forme de chiffre romain. Il est aussi compliqué d’interpréter les liens de
composition entre objets métiers et de produire une représentation d’objets composites La synchronisation des
valeurs affichées dans l’IHM avec celles des objets en mémoire peut également poser problème. C’est pour cette
raison qu’ICL le renforce notamment avec les concepts de propriétés visualisables et la possibilité de créer des
éléments d’interfaces composites.
4.3. Couplage d’ICL avec ThingsTM
OpenJava est l’élément essentiel qui permet de connecter les programmes ICL et le logiciel ThingsTM. La chaîne
de compilation l’est aussi. Le code Java généré par le compilateur ICL représente le code métier dont a besoin le
logiciel. Les fichiers crées par les générateurs sont les éléments nécessaires à l’interfaçage. On voit ce qui peut
être obtenu en couplant ICL et ThingsTM figure 11 ci-dessous. Dans la fenêtre Book–All, le champ titre du livre
sélectionné est représenté par un champ texte éditable car cette propriété est qualifiée d’in out dans le code. Si
un autre programme modifie le titre du livre, le changement sera immédiat dans l’IHM grâce aux mécanismes de
notification imposés sur les propriétés représentées par l’IHM. Les livres sont représentés par l’affichage de leur
couverture. Comme une bibliothèque a une propriété multi-valuée de livres, elle est représentée en juxtaposant
les images de livres. Ceci n’est pas possible avec une version n’implémentant pas ICL comme dans la figure 12
ci-dessous, ou ne peut voir ici qu’un seul livre.
Améliorations dues à ICL : superposition des images
FormView
Title
Preview
Treeview
Fig 11. Fonctionnement de Things avec ICL
Fig 12. Fonctionnement de Things sans ICL
17 / 22
Conclusion
M.Fabresse estime que ses travaux ont dévié de ses objectifs premiers; il voulait produire des composants
logiciels métiers interfaçables. Finalement il s'est attaché à produire une nouvelle structuration du code métier
objet d'une application afin de l'interfacer. ICL reste pour l’instant à l’état de prototype, mais les travaux pourraient
être repris dans quelque temps.
Ce langage met en exergue un nouveau modèle de propriétés intéressant. Il permet l’implémentation du principe
MVC et constitue une phase intéressante dans l’isolation de la partie vue. L’utilisation d’ICL implémente les
concepts de propriété visualisable et d’éléments d’interfaces composites. Il simplifie le code métier en exprimant
directement les propriétés. L’IHM gagne aussi en qualité en autorisant par exemple la juxtaposition des images
comme le montre la figure 11 de la page 17.
Selon M.Pichon, responsable de la société éditrice du logiciel ThingsTM, un autre produit nommé Gatonero est en
cours de développement. Le nouveau logiciel s’inscrit dans une approche complémentaire de ThingsTM, dont
l’étude a été mise temporairement de côté. Gatonero se situe dans une phase amont d'un projet, en ajout des
spécifications fonctionnelles détaillées pour lesquelles il n'y a pas à priori de logique métier déjà existante.
ThingsTM est destiné à intégrer Gatonero comme un module d'introspection. Gatonero verra son utilisation
facilitée dans les phases plus avales d'un projet, alors que la logique métier est en cours d'élaboration, ou même
en production. ThingsTM permettra à Gatonero une intégration plus poussée avec la logique métier. La fusion des
deux technologies est prévue pour l'été 2005.
Le modèle de composants interfaçables, tel qu’il est défini, s’inscrirait éventuellement dans la logique des travaux
de l’OMG sur MDA : Model Driven Architecture. En effet, les travaux sur ICL consistent à vouloir isoler la partie
métier et la partie IHM. Ceci rejoint les préoccupations de MDA qui visent une séparation entre le métier des
applications et la technique des intergiciels12. Les avantages recherchés d’une approche MDA sont la pérennité
des savoir-faire, les gains de productivité, la prise en compte des plates-formes d’exécution. Il serait intéressant à
ce titre d’adapter le modèle de composants interfaçables à un contexte PIM13.
Une autre approche serait de considérer l’interfaçage comme un service dans le cadre d’une programmation
orientée aspect. Un aspect permet de faire appel au point technique d’un module à un certain stade d’exécution
du système, comme l’authentification d’un utilisateur dans le cas d’un module bancaire.
Un autre axe envisageable serait peut-être l’implémentation via le modèle .Net. Certaines fonctionnalités de cette
plate-forme offrent la possibilité de gérer nativement les événements : il s’agit du mécanisme de délégation. Une
équipe du projet Rainbow travaille sur un prototype utilisant ces technologies pour les wearables computers14.
Pour l’instant l’outil ne sert qu'à manipuler et présenter le fonctionnement ainsi que le couplage des composants
développés. Une version plus évoluée permettrait la construction et la sauvegarde interactive d'applications sous
forme d'assemblage.
12
Intergiciels : conçus pour faire face à la complexité des applications réparties
PIM :Platform Independant Model
14 Wearables computers : Ordinateurs sortis de leur contexte habituel : lunettes, vêtements, frigidaire…
13
18 / 22
Glossaire
AST : Arbre de Syntaxe Abstraite - Abstract Syntax Tree.
API : Application Programming Interface. Interface pour la Programmation d’Applications. Ensemble de
bibliothèques permettant une programmation plus aisée, les fonctions sont indépendantes du matériel. On peut
citer les API de Java, Microsoft.
Bean : Composant Javabean
CORBA: Common Object Request Brocker Architecture
COM : Component Object Model. Modèle de composants Windows.
EJB : Enterprise Java Beans. Ce sont des composants Java qui peuvent être assemblés entre eux afin de former
des applications d’entreprise.
I3S : Laboratoire, unité mixte de recherche associée au CNRS à l’université Sophia Antipolis.
ICL : Langage de Composants Interfaçables
IDL : Interface Definition Langage. Langage de description des objets
IHM : Interface Homme Machine
Intergiciels : Couche d’abstraction entre les applications et les machines sur lesquelles elles s’exécutent et
permet de résoudre les problèmes techniques d’interopérabilité.
ISL : Interaction Specification Langage
JPanel : Composant swing qui permet de contenir d’autres composants.
HashTable : Ensemble d’objets classés à l’aide d’une clé qui elle même est un objet.
MDA : Model Driven Architecture. Son principe est l’utilisation de modèles aux différentes phases du cycle de
développement d’une application. MDA préconise l’élaboration de modèles d’exigences (CIM), d’analyse et de
conception (PIM) et de code (PSM).
MOP : Protocole Méta-objet.
MVC : Modèle Vue Contrôleur.
.NET : Plate-forme Microsoft pour la nouvelle génération de logiciels distribués et coopérants, les services Web
XML. Elle se compose de 2 principaux composants : La CLR (Common Langage Runtime) et la bibliothèque de
classe du framework .NET . Il est composé d’un ensemble de langages (C #, VB.NET etc.) qui sont des langages
orientés objets. La plate forme .NET est compatible avec d’autres langages, ce qui signifie que les composants
.NET peuvent interagir avec d’autres indépendamment du langage avec lequel ils ont été écrits.
ORB : Object Request Brocker, bus logiciel. Mécanisme de communication entre logiciels.
OMG : Object Management Group. Consortium s’occupant de la normalisation de concepts comme UML, Corba,
MDA.
PIM : Platform Independant Model, modèle d’analyse et de conception abstraite issu du projet MDA. Il se situe en
aval du modèle d’exigence (CIM).
Rainbow : Projet de l’équipe I3S.
Réification : Permet de transformer une entité abstraite en objet
Vector : Ensemble d’objets pouvant être retrouvés grâce à leurs références.
Wearables Computers : Ordinateurs sortis de leur contexte habituel : lunettes, vêtements, frigidaire.
Widgets : ce sont des composants conformes à l’architecture MVC, dans le cadre de l’étude de référence, il
s’agit des composants swing.
XML : eXtensible Markup Langage. Langage de description de données.
19 / 22
Bibliographie
[1] Proposition d'un langage de programmation à base de composants logiciels interfaçables et application à la
génération semi-automatisée d'IHM (luc fabresse)
[2] http://www.lifl.fr/lmo2004/slides_lmo2004/fabresse.pdf
[3] http://papyrus.lirmm.fr/GEIDEFile/04_alcaa.PDF?Archive=191299191947&File=04_alcaa_PDF
[4] http://papyrus.lirmm.fr/GEIDEFile/fabresse_document_ocm04.PDF?Archive=191247991942&File=fabresse_
document_ocm04_PDF
[5] http://www.csg.is.titech.ac.jp/openjava/papers/mich_2000lncs1826.pdf :
OpenJava: Class-based Macro System for Java (Michiaki Tatsubori, Shigeru Chiba, Marc-Olivier Killijian,
and Kozo Itano)
[6] http://www.csg.is.titech.ac.jp/openjava/papers/mich_thesis99.pdf An Extension Mechanism for the Java
Language (Michiaki Tatsubori)
[7] http://rangiroa.essi.fr/rapports/2000/00-dea-bouraqadi.pdf : Java et la réflexion (Noury Bouraqadi-Saâdani)
[8] http://rangiroa.essi.fr/rapports/2000/00-dea-beauvois.pdf
Réification des mécanismes systèmes d’un environnement d’exécution java
[9] http://www.csg.is.titech.ac.jp/openjava/papers/chiba_ECOOP98ws.pdf :
A Yet Another java.lang.Class (Shigeru Chiba Michiaki Tatsubori)
[10] http://www.crescenzo.nom.fr/publications/these-2001-12.pdf :
Ofl : un modèle pour paramétrer la sémantique opérationnelle des langages à objets application
aux relations inter-classes (Pierre Crescenzo)
[11] http://www-sop.inria.fr/oasis/Julien.Vayssiere/publications/20720256.pdf :
Reflections on MOPs, Components, and Java Security (Denis Caromel and Julien Vayssière)
[12] http://java.sun.com/products/javabeans/docs/index.html
[13] http://perso.ec-lyon.fr/bertrand.david/ihm-ecl/IHM-java.pdf
[14] Java la maîtrise, Eyrolles, Jérome Bourgeault
[15] Mda en action, Eyrolles, xavier blanc
[16] http://perso.ec-lyon.fr/bertrand.david/gl-cnam/GL-CNAM-MDA.pdf
[17] http://openjava.sourceforge.net/
[18] http://rainbow.essi.fr
[19] http://sardes.inrialpes.fr/ecole/2003/support/cours/CCM.ppt
[20] http://pastel.paristech.org/archive/00000798/01/carrez03contrats_these.pdf
[21] Client serveur – guide de survie – Vuibert -Robert Orfali, Dan Arkley, Jeri Edwards
[22] http://www.iutc3.unicaen.fr/~bourdf/cours/CNAM/Composant2EJB.pdf
[23] Composants et Transactions – Eyrolles -Jean Marie Chauvet
Remerciements
Je tiens à remercier tout particulièrement M.Fabresse et M.Pichon pour les éléments dont ils m’ont fait part lors
de la conception de mon rapport.
Mes remerciements s’adressent ensuite à l’ensemble de mes collègues et amis pour leur aide et leur soutien lors
de la préparation du probatoire.
20 / 22
Annexes
Annexe 1 : Tableau comparatif des mécanismes d’interfaçage
21 / 22
Annexe 2 : Exemple de code de compilation ICL
22 / 22