SlideShare une entreprise Scribd logo
Assemblage par vues de composants
            logiciels




                     Alexis M ULLER

         Mémoire de DEA Informatique - Équipe GOAL
        Laboratoire d’Informatique Fondamentale de Lille

                  Alexis.Muller@lifl.fr
Remerciements
    Je tiens à remercier ici toutes les personnes qui m’ont permis de réaliser ce mémoire ainsi que toutes
celles qui le liront.

    Je remercie donc Jean-Marc Geib, pour m’avoir permis d’effectuer mon stage de DEA dans son équipe.
Je tiens à remercier tout particulièrement mes responsables, Olivier Caron, Bernard Carré et Gilles Van-
wormhoudt pour ce qu’ils m’ont appris du métier de chercheur et pour toute la précieuse aide qu’ils m’ont
apporté.

   Merci également à Jean-Luc Dekeyser pour m’avoir permis d’effectuer ce DEA.

   Merci aussi à toute l’équipe GOAL, ceux de mon bureau (Jean-François Roos, Bassem Kosayba, Em-
manuel Renaux et Olivier Caron) et les autres, pour leur accueil et pour leur(s) machine(s) à café.

    Enfin merci à mes camarades de DEA, particulièrement Florent Fareneau, Stéphane Patureau et Patrick
Tessier d’avoir supporté mes blagues à l’heure du midi, ainsi que Jérémie Hattat pour avoir été mon binome
au premier semestre et pour nos soirées passées à . . . travailler.
Table des matières



Introduction                                                                                                                                                          5

1 Problématique et positionnement                                                                                                                                     7
  1.1 Composants, ACCORD . . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
  1.2 Vues, SOP / AOP, Catalysis . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
  1.3 Rapprochement vues/composants .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10
  1.4 Modèle, Méta-Modèle, MDA . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   15

2 Le modèle abstrait                                                                                                                                                 17
  2.1 Le méta-modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                 17
  2.2 Description des éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                 17
  2.3 Contraintes OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                  18

3 Réalisation du Profil UML                                                                                                                                           21
  3.1 Identification du sous-ensemble UML . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                     21
  3.2 Les éléments du profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                21

4 Ciblage                                                                                                                                                            25
  4.1 Du modèle abstrait aux composants CCM .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
       4.1.1 Le modèle de composants CORBA                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
       4.1.2 Règles de transformation . . . . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   26
  4.2 Du modèle abstrait aux composants EJB . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   30
       4.2.1 Le modèle de composants EJB . . .                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   30
       4.2.2 Règles de transformation . . . . . .                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   34

Conclusion et Perspectives                                                                                                                                           41

A Le code J                                                                                                                                                          45

B La démarche MDA                                                                                                                                                    57




                                                             1
2   Table des matières
Table des figures



1.1   Location de voitures - Approche objet . . . . . . . . .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
1.2   Location de voitures - Structuration par contextes . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10
1.3   Bibliothèque universitaire - Approche objet . . . . . .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
1.4   Bibliothèque universitaire - Structuration par contextes          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
1.5   Composant de recherche . . . . . . . . . . . . . . . .            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   12
1.6   Location de voitures - Approche composants vues . . .             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   13
1.7   Bibliothèque universitaire - Approche composants vues             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   14
1.8   Les quatre niveaux de modélisation . . . . . . . . . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   15
1.9   Application de MDA . . . . . . . . . . . . . . . . . .            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   16

2.1   Le méta-modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                18

3.1   Méta-modèle virtuel des ExternalFeature           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   22
3.2   Méta-modèle virtuel des ViewClass . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   22
3.3   Méta-modèle virtuel des viewOf . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   23
3.4   Méta-modèle virtuel des ViewAttribute . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   23
3.5   Méta-modèle virtuel des ViewAssociation           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   23
3.6   Méta-modèle virtuel des Component . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   24
3.7   Le module Objecteering . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   24

4.1   Composant abstrait CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                  26
4.2   L’architecture EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                31
4.3   Modèle abstrait vers EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                35




                                                  3
4   Table des figures
Introduction


    Il existe aujourd’hui plusieurs modèles technologiques de composants : CCM (OMG), EJB, .NET, ...
Le problème de l’hétérogénéité de ces modèles se pose aujourd’hui et une recherche consiste à définir un
modèle abstrait commun de composants et d’assemblage par contrats, comportant des spécifications de
haut niveau, indépendantes des plates-formes technologiques.
    Les moyens d’expression de l’assemblage, pour spécifier un système d’information dans son entier,
restent assez pauvres et l’assemblage n’est généralement pas représenté. Le contrat d’assemblage d’un
composant se limite souvent à une interface de services unitaires. Nous proposons ici une approche de la
problématique de l’assemblage, guidée par la conception par vues de systèmes d’information (SI).
    Ce mode de conception favorise le découpage fonctionnel de SI en rapport avec un référentiel d’enti-
tés qui le caractérise. Chaque vue décrit une fonction du système. Par exemple, un système d’information
d’entreprise peut se décomposer en grandes fonctions : comptable, commerciale, décisionnelle, ... Les sys-
tèmes de vues ont été très étudiés dans le monde des bases de données à objets, en particulier dans l’équipe
[1]. Il s’agit ici de structurer modulairement le schéma du système d’information en schémas vues (corres-
pondant aux fonctions du système), d’en gérer la cohérence et les interactions. Une telle conception vise la
traçabilité des besoins fonctionnels (localisés dans les vues correspondantes) et l’évolution du système par
greffage de nouvelles vues.
    Ces qualités sont pour beaucoup communes aux deux approches et l’idée consiste à faire le lien entre la
notion de vues fonctionnelles et la notion de composants métiers et d’appliquer les principes de composition
de vues au problème de l’assemblage de tels composants. Les bénéfices espérés sont réciproques. Les
composants apportent leurs propriétés d’autonomie, d’auto-description, de réutilisation et de dynamicité.
La conception par vues apporte quant à elle des règles d’assemblage de vues métiers pour former un SI
dans son entier.
    Dans un premier temps nous présentons, brièvement, les notions de composants et de vues, position-
nons notre travail dans ce paysage et introduisons les notions de modèle, méta-modèle et l’approche MDA.
Nous détaillons ensuite, dans le deuxième chapitre, le modèle abstrait et le méta-modèle virtuel que nous
avons réalisés. Les chapitres suivants présentent respectivement leur mise en œuvre par le profil UML
correspondant et le ciblage de l’exemple vers les plates-formes EJB et CCM (IDL3). Enfin, nous discu-
tons des perspectives d’évolutions de notre approche que nous pouvons attendre du travail sur le MDA,
notamment la version 2.0 d’UML, qui doit introduire la notion de composant, ainsi que les techniques de
transformation de modèles.




                                                     5
6   Introduction
Chapitre 1

                   Problématique et positionnement



1.1 Composants, ACCORD
     L’origine des composants logiciels n’est pas nouvelle. Certains pensent qu’ils ont toujours existé sous
différentes formes pour la construction de systèmes logiciels [2]. Pour d’autres cette notion est apparue
dans les années 70 en réponse à la deuxième crise du logiciel afin de réduire les coûts et d’améliorer la
qualité des logiciels [3].
     L’idée des composants logiciels s’inspire largement de ce qui existe dans les autres domaines industriels
(électronique, automobile...), le but est de pouvoir concevoir une application par assemblage comme on
assemble un téléviseur ou une voiture, à l’aide de composants existants en limitant les développements
spécifiques au strict minimum. Si cette capacité de réutilisation avait été attribuée à la programmation
objet, du fait du très bas niveau de mise en œuvre (celui du code source), elle n’a jamais pu être réellement
utilisée sauf pour des structures de données simples (listes, piles, ...) ou pour des traitements très “standard”
(comme les services objets communs de CORBA [4]) ainsi que dans le domaine des interfaces hommes-
machines (IHM). En se plaçant à un niveau de granularité beaucoup plus important, la conception par
composants logiciels doit permettre la réutilisation de structures plus complexes et ce de façon naturelle
en les rendant disponibles le plus tôt possible dans le cycle de vie. Ce type de composants, suffisamment
complexes pour contenir un certain “savoir faire”, est appelé composant métier. Ce sont eux qui nous
semblent le plus intéressant et que nous considérons dans notre approche.
Les bénéfices attendus sont multiples :
     – Diminuer considérablement les coûts et le temps de conception en généralisant la réutilisation ou
        l’achat de composants déjà réalisés.
     – Augmenter la fiabilité des logiciels par l’utilisation de composants largement testés.
     – Faciliter et réduire les coûts de maintenance et d’évolution des systèmes, par le remplacement de
        composants.
     – Enfin, rentabiliser les développements par la vente de COTS Component (Commercial-off-the-shelf
        Component ou composants sur étagère).
Il n’y a pas encore de définition consensuelle dans le domaine des composants comme c’est le cas pour les
objets. Cependant, la vision minimale suivante est toujours retenue. Un composant logiciel est une unité qui
rend des services grâce à des interfaces externes et utilise d’autre services grâce à des interfaces requises.
Afin d’obtenir un système complet il faut donc assembler un certain nombre de composants en reliant leurs
interfaces externes et leurs interfaces requises.
     C’est pour cette phase d’assemblage qu’il reste encore beaucoup de problèmes à résoudre. Comment
formaliser les connexions entre les composants ? Comment décrire un système dans son ensemble ? Il
existe pour répondre à ces questions plusieurs travaux de recherche notamment sur les ADL (Application
Definition Language) [5]. Cependant, ils imposent l’utilisation (et donc l’apprentissage) de leur propre
langage. D’autres problèmes sont à résoudre si l’on souhaite réellement profiter de la grande promesse

                                                       7
8                                                                Chapitre 1. Problématique et positionnement

des composants, c’est à dire la réutilisation. En effet, il faut être capable de choisir les composants qui
répondent à nos besoins et de savoir si ils sont “compatibles”. Actuellement, la description d’un composant
est le plus souvent résumée à la liste de ses interfaces, ce qui est insuffisant pour espérer “comprendre” le
composant. Il devient donc indispensable de développer la notion de contrat. Ces contrats doivent décrire
les besoins et capacités d’un composant, mais il n’existe pas encore de méthode formelle pour les spécifier.
De plus, les méthodes de conception actuelles ne sont pas adaptées [3], elles poussent le plus souvent à
spécifier des composants alors qu’ils sont, la plupart du temps, déjà disponibles.
    Pour répondre à ces problèmes et du fait de l’hétérogénéité des modèles technologiques de composants,
une recherche consiste à définir un modèle abstrait commun de composants et d’assemblage par contrats.
L’équipe participe à ce titre à un projet national (RNTL ACCORD pour “Assemblage de Composants par
Contrats en environnement Ouvert et Réparti”) visant à définir un tel modèle abstrait et ses projections
technologiques, en particulier vers CCM et EJB.
    Pour qu’un modèle de composants permette réellement la réutilisation, il doit fournir les moyens de
spécifier des composants génériques et de représenter leur configuration. La généricité est le concept par
lequel un composant peut être défini indépendamment des contextes dans lesquels il sera utilisé. La confi-
guration, au contraire, permet d’intégrer le composant dans un contexte particulier. Il apparaît donc que ces
deux concepts soient indissociables et indispensables.


1.2 Vues, SOP / AOP, Catalysis
     Dans l’approche CROME [1] qui constitue le point de départ de ce mémoire, le mécanisme des vues
permet à chaque utilisateur de manipuler un système avec une vision qui lui est propre, adaptée en fonction
de ses besoins. Dans cette approche, le schéma de base correspond aux éléments communs aux différentes
fonctions du système. Les schémas vues quant à eux ajoutent au schéma de base un certain nombre d’élé-
ments propres à leur fonction. Cette approche permet de tenir compte de l’orthogonalité objets/fonctions.
En effet, pour un système donné les objets peuvent intervenir dans plusieurs fonctions et celles-ci peuvent
utiliser un certain nombre d’objets. Mais il est évident que tous les objets n’interviennent pas dans toutes les
fonctions de même les fonctions n’utilisent pas systématiquement tous les objets [6, 7]. Si l’approche objet
permet de découper naturellement le système en entités distinctes, elle ne permet pas de séparer les diffé-
rentes fonctions à l’intérieur des objets. Le mécanisme des vues ajoute ce découpage et rend ainsi possible
de concevoir les fonctions du système indépendamment des autres tout en garantissant leur compatibilité.
     Pour illustrer cette orthogonalité, considérons l’exemple d’un système de location de voitures (cf figure
1.1). Grâce à l’approche objet, le découpage en entités distinctes est bien représenté, mais toutes les fonc-
tions sont confondues. L’activité de gestion des voitures (transfering, add, remove) , par exemple, n’a pas
d’intérêt à considérer la liste des clients. De même, l’activité consistant à rechercher à quelle agence est rat-
tachée un client ne doit pas être perturbée par la durée ou le nombre de locations de celui-ci. Une approche
“à la CROME” permet de séparer les fonctions du système et permet de les réaliser indépendamment les
unes des autres (cf figure 1.2). Les attributs communs à toutes les fonctions sont déclarés dans le plan de
base, les autres attributs et méthodes sont déclarés dans le plan où ils sont utilisés. Prenons en exemple la
classe Agency, les attributs Name et adresse, qui sont utiles à toutes les fonctions du système, sont déclarés
dans le plan de base. L’attribut capacity et les méthodes add, transfering et remove, qui ne servent qu’à la
gestion des ressources, sont déclarés dans le plan correspondant.
     D’autres approches comme l’AOP [8] (Aspect-Oriented Progamming) ou le SOP [9] (Subject-Oriented
Programming) permettent de mieux découper les systèmes en “séparant les préoccupations” (sécurité, au-
thentification...). Elles suggèrent de développer séparément les différentes fonctions du système puis de
les assembler, cette étape est appelée le tissage. Contrairement à la conception par vues, qui s’applique au
niveau conception, la programmation par aspects (comme son nom l’indique) est destinée à être utilisée
au niveau des langages de programmation. Clarke [9] propose le découpage d’un système en activités au
niveau modèle, à l’aide du langage UML. Chaque activité est représentée par un paquetage indépendant.
Celui-ci contient uniquement les éléments nécessaires à son activité. Contrairement à l’approche par vues,
il n’y a pas de paquetage de référence, si un élément est utile à plusieurs paquetages, il est représenté dans
chacun d’eux. L’application complète peut être retrouvée par “l’assemblage” de tous les paquetages au
travers d’un jeu d’opérateurs de composition (override, merge, ...), la correspondance entre les différents
1.2. Vues, SOP / AOP, Catalysis                                                                 9




                     Base




                                       Agency                                       Client

                            Name                                          Name
                            adresse                                       date
                                                         own       0..*
                            capacity                                      phone
                                                                          adresse
                            Client* findAll()

                            Car* findAll()                                Agency location()

                            void transfering(Client c)                    Client findByDate()

                            void add(Agency a)                            Client findByName()

                            void remove(Agency a)                         int nbRenting()




                                 manage

                                    0..*
                                                                             reference

                                             Car

                        immatriculation
                                                                                  0..*
                        date
                        constructor                                                 Rent

                        model                                             From

                        Agency location()                                 due_date

                        Car findByDate()                 contain          return_date
                                                                   0..*
                        Car findByImmatriculation()

                        int nbRenting()
                        bool free(date from, date to)




                                F IG . 1.1 – Location de voitures - Approche objet
10                                                              Chapitre 1. Problématique et positionnement

                         Agency                  Client                          Car                     Rent

                   att: Name,                att: Name,                att: date, model,
  Plan de                                    date, phone,
  base             adresse                                             immatriculation,
                                             adresse                   constructor

  Plan de          mth: findAll              mth: location,
  recherche                                  findByDate,
  client                                     findByKey


  Plan de           mth: findAll                                         mth: location,
  recherche                                                              findByDate,
  voiture                                                                findByKey

 Plan de            att: capacity
 gestion des        mth: add,
 resources          transfering,
                    remove

 Plan de            mth: free,               att:                                                    att: From,
 locations          nbRenting                maximum_                                                due_date,
                                             duration                                                return_date
                                             mth: nbRenting



                       F IG . 1.2 – Location de voitures - Structuration par contextes



éléments étant indiquée grâce à un nommage identique dans les différents paquetages. Dans l’approche
Catalysis [10], il est également question de découpage fonctionnel. Elle propose le découpage d’un schéma
UML (par exemple, d’un système de ventes) en “composants à gros grains” (paiement, base de contact,
vente...). D’après les auteurs, avant de penser à réutiliser des composants existants, nous avons besoin d’un
modèle spécifiant ce qu’ils font. Malheureusement, actuellement ils ne sont jamais accompagnés d’un tel
modèle. L’approche Catalysis diffère de celles de CROME et de [9] par le fait que le découpage n’est pas
effectué au niveau des attributs et des méthodes, mais au niveau des classes dans leur intégralité. L’assem-
blage des composants est modélisé par les associations qui traversent les frontières des ces composants,
c’est à dire, par les associations entre des classes ne faisant pas partie du même composant.
    Toutes ces approches permettent de mieux structurer le système en fonction de ses activités, mais
n’apportent rien au niveau de la généricité. Il n’y a pas de réutilisation dans ces méthodes, tout doit être
réévalué d’un système à l’autre.


1.3 Rapprochement vues/composants
    Nous proposons de considérer les approches composants et vues dans un même modèle, la première
apportant le principe de généricité et de configuration, la seconde, une méthode de structuration cohérente
et plus riche que l’approche objet traditionnelle. Pour illustrer les bénéfices d’une telle approche, considé-
rons l’exemple d’une bibliothèque universitaire (cf figure 1.3). Il est possible de découper ce système en
contextes comme nous l’avons fait pour l’exemple précédent (cf figure 1.4). Il apparaît ici clairement qu’un
certain nombre de fonctions sont communes aux deux systèmes, même s’ils utilisent des noms différents,
et qu’il serait intéressant de pouvoir disposer de composants génériques pour les implémenter.
    L’approche conception par vues permet de représenter un système à base de composants en associant à
chaque composant un schéma vue. Le schéma de base représente le système déjà en place auquel on sou-
haite ajouter des fonctions par application de composants. Dans le cas d’un nouveau système, le schéma de
base peut représenter le cœur de l’application, c’est à dire la partie “stable”, qui a peu de chance d’évoluer
dans le temps.
    Notre modèle d’assemblage s’inspire donc largement de la notion de vues, cependant il diffère sur
1.3. Rapprochement vues/composants                                                                                  11


                  Base



                                        Location                                               Team

                     indentifiant                                                     name

                     adresse

                     capacity

                     Document* findAll()

                     void transfering(ResourceOwner o)                                       Researcher
                     void add(Document r)
                                                                                      name
                     void remove(Document r)
                                                                                      arrival_date


                                                                  publishes    1..*
                                      0..*               0..*

                                    Document                                                    Rent
                                                                    Contain    0..*
                     title                                                            From

                     publication_date                                                 due_date

                                                                                      return_date
                     Location location()
                     Document findByDate()
                     Document findByKey()
                                                                                                     0..*
                     int nbRenting()
                                                                                                 reference
                     bool free(date from, date to)



                                                                                                 Client
                                Book                              Periodical
                                                                                        name
                     ISBN                                  number                       inscription_date

                                                                                        int nbRenting()




                             F IG . 1.3 – Bibliothèque universitaire - Approche objet



                         Location                               Client                               Document     Rent

 Plan de        att: adresse,                        att: Name,                              att: title,
 base           identifiant                          inscription_                            publication_date
                                                     date

 Plan de         mth: findAll                                                                  mth: location,
 recherche                                                                                     findByDate,
 document                                                                                      findByKey

Plan de          att: capacity
gestion des      mth: add,
resources        transfering,
                 remove

Plan de          mth: free,                          att:                                                       att: From,
locations        nbRenting                           maximum_                                                   due_date,
                                                     duration                                                   return_date
                                                     mth: nbRenting



                 F IG . 1.4 – Bibliothèque universitaire - Structuration par contextes
12                                                                       Chapitre 1. Problématique et positionnement


               <<Component>> Search



                                                                                <<ViewClass>>
                         <<ViewClass>>                                            DateResource
                             Location
                                                                        identifiant <<ViewAttibute>>
                  name <<ViewAttribute>>                                date <<ViewAttribute>>
                  adresse <<ViewAttribute>>
                                                         store   0..*
                                                                        Location location()
                  DateResource* findAll()
                                                                        DateResource findByDate()
                                                                        DateResource findByKey()




                                            F IG . 1.5 – Composant de recherche




certains points. Contrairement à un schéma vue qui “importe” systématiquement tous les éléments du
schéma de base, un composant vue doit préciser les éléments (classes, attributs, associations) du schéma
de base qu’il souhaite manipuler, il les contextualisent.

    L’interface requise correspond donc à un “schéma requis”, celui-ci est matérialisé par les ViewClass,
ViewAttribute et ViewAssociation du composant (cf figure 1.5). Les éléments vues du compo-
sant Search indiquent que celui-ci ne pourra s’appliquer qu’à un schéma de base contenant une classe
(jouant le rôle de location) contenant au moins deux attributs pour matérialiser les ViewAttribute
Name et adresse, et une autre classe (jouant le rôle de DateRessource) avec des attributs matérialisant iden-
tifiant et date. Ces deux classes devant être liées par une association pour matérialiser la ViewAssociation
store. La définition formelle des éléments vues ainsi que les règles auxquelles ils sont soumis sont détaillées
dans le deuxième chapitre de ce mémoire. L’interface externe est quant à elle matérialisée par le schéma
constitué des éléments publiques du composant.

    A partir des exemples précédents, il est possible d’extraire trois fonctions communes : recherche, ges-
tion des ressources et location, et d’en faire des composants. Pour cela, il faut les rendre génériques et
pouvoir les configurer afin de les appliquer aux deux exemples. Dans notre modèle, la généricité est intro-
duite par l’utilisation d’éléments “externes” et la phase de configuration est représentée par un mécanisme
de connexion.

     Les modèles obtenus pour chacun des deux exemples sont représentés figure 1.6 pour l’agence de
location de voitures et 1.7 pour la bibliothèque universitaire. L’application d’un composant vue à la base se
fait par la connexion entre chaque ViewClass du composant et la classe de la base qui la matérialise. Ces
connexions sont représentées sur les figures par les flèches pointillées. Pour être complètes, les connexions
doivent également être effectuées entre chaque ViewAttribute et l’attribut de la base qui le matérialise,
de même pour les ViewAssociation et les associations (ces connexions ne sont pas représentées par
souci de clarté). Les connexions, pour être valides, doivent vérifier un certain nombre de contraintes. Celles-
ci sont détaillées pour chaque élément vue dans le deuxième chapitre.

    On retrouve dans les deux exemples les mêmes composants fonctionnels Search, ResourceManager et
Renting, ce qui illustre leur réutilisation sur différentes bases. La généricité permet également d’utiliser le
même composant à plusieurs “endroits” de la même application, illustré ici par l’application du composant
Search entre Agency et Car et entre Agency et Client dans le premier exemple. De façon conforme à
l’approche par vues, les données spécifiques à une fonction particulière du système sont regroupées dans le
composant correspondant (la classe Rent par exemple fait partie du composant Renting et non de la base).
1.3. Rapprochement vues/composants                                                                                                                                                                              13




                                         <<Component>> Search


                                                                                                                                           <<ViewClass>>
                                                     <<ViewClass>>                                                                          DateResource
                                                         Location
                                                                                                                               identifiant <<ViewAttibute>>
                                           name <<ViewAttribute>>                     <<ViewAssociation>>                      date <<ViewAttribute>>
                                           adresse <<ViewAttribute>>
                                                                                                    store               0..*   Location location()

                                           DateResource* findAll()                                                             DateResource findByDate()
                                                                                                                               DateResource findByKey()




 <<Component>> Search                                                                                                                                                <<Component>> ResourceManager

                                                          Base
                                                                                                                                                                                      <<ViewClass>>
           <<ViewClass>>
                                                                                                                                                                                       ResourceOwner
                Location                                                                                                          Client
                                                                           Agency
                                                                                                                                                                         identifiant <<ViewAttribute>>
    name <<ViewAttribute>>                                                                                              Name
                                                                   Name                                own                                                               capacity
                                                                                                                 0..*   date
    adresse <<ViewAttribute>>
                                                                   adresse
                                                                                                                        phone                                            void transfering(ResourceOwner o)
    DateResource* findAll()
                                                                                                                        adresse                                          void add(Resource r)
    <<ViewAssociation>>
                                                                                                                                                                         void remove(Resource r)
            store
                                                                     manage
              0..*                                                                                                                                                              <<ViewAssociation>>
                                                                        0..*
            <<ViewClass>>                                                                                                                                                               manage
                                                                               Car
              DateResource                                                                                                                                                                 0..*
                                                                    immatriculation
    identifiant <<ViewAttibute>>
                                                                    date                                                                                                                 <<ViewClass>>
    date <<ViewAttribute>>
                                                                    constructor                                                                                                              Resource

    Location location()                                             model                                                                                                       identifiant <<ViewAttribute>>
    DateResource findByDate()

    DateResource findByKey()




                              <<Component>> Renting



                                                                                                             Rent

                                                                                                   From

                                                                                                   due_date

                                                                                                   return_date


                                                                                            0..*                                0..*
                                                                                  contain                                         reference



                                            <<ViewClass>>                                                                                                  <<ViewClass>>

                                                 Product                                                                                                        Client

                                   identifiant <<ViewAttribute>>                                                                                 identifiant <<ViewAttibute>>

                                                                                                                                                 maximum_duration
                                   int nbRenting()
                                   bool free(date from, date to)                                                                                 int nbRenting()




                                           F IG . 1.6 – Location de voitures - Approche composants vues
14                                                                                                                           Chapitre 1. Problématique et positionnement




                                                     <<Component>> ResourceManager


                                                                  <<ViewClass>>
                                                                   ResourceOwner                                                                          <<ViewClass>>
                                                                                                         <<ViewAssociation>>                                  Resource
                                                       identifiant <<ViewAttribute>>

                                                       capacity                                                                                  identifiant <<ViewAttribute>>
                                                                                                                     store              0..*
                                                       void transfering(ResourceOwner o)

                                                       void add(Resource r)

     <<Component>> Search                              void remove(Resource r)



                <<ViewClass>>                              Base

                     Location

         name <<ViewAttribute>>

         adresse <<ViewAttribute>>                                                  Location
                                                                                                                                                Team
         DateResource* findAll()                                          indentifiant

                                                                          adresse                                                   name
         <<ViewAssociation>>
                   store

                     0..*

                  <<ViewClass>>                                                    0..*

                   DateResource                                                                                                                Researcher
                                                                                   Document
         identifiant <<ViewAttribute>>                                                                                               name
                                                                          title                        0..*   publishes      1..*
         date <<ViewAttribute>>                                                                                                      arrival_date                                AddToBase
                                                                          publication_date

         Location location()
                                                                                                                                                                                             Client
         DateResource findByDate()
         DateResource findByKey()                                                                                                                                                   name
                                                                                                                                                                                    inscription_date
                                                                                          Book                            Periodical

                                                                                  ISBN                            number




                                         <<Component>> Renting


                                                                                                                Rent

                                                                                                       From
                                                                                                       due_date

                                                                                                       return_date


                                                                                                0..*                                   0..*
                                                                                          contain                                         reference



                                                        <<ViewClass>>
                                                                                                                                                                 <<ViewClass>>
                                                             Product
                                                                                                                                                                       Client
                                               identifiant <<ViewAttribute>>
                                                                                                                                                         identifiant <<ViewAttibute>>
                                               int nbRenting()
                                                                                                                                                         int nbRenting()
                                               bool free(date from, date to)




                               F IG . 1.7 – Bibliothèque universitaire - Approche composants vues
1.4. Modèle, Méta-Modèle, MDA                                                                                15

                                                         Il existe des entités qui
               Niveau M3        Méta-méta-modèle         peuvent avoir des relations
                                                         entre elles
                                                         Une classe désigne un
               Niveau M2           Méta-modèle           ensemble d’objets qui peuvent
                                                         avoir des attributs
                                                         Une voiture a une couleur
               Niveau M1              Modèle             et une immatriculation

                                                         Cette voiture
               Niveau M0            Instances            rouge immatriclée
                                                         12 XY 59


                               F IG . 1.8 – Les quatre niveaux de modélisation



1.4 Modèle, Méta-Modèle, MDA
     Nous décrivons notre modèle abstrait à l’aide d’un méta-modèle, nous introduisons donc ici les bases
des techniques de modélisation et de méta-modélisation avant de le détailler. Les méthodes de méta-
modélisations sont basées sur quatre couches [11] (cf figure 1.8). Chaque niveau est décrit à l’aide du niveau
supérieur. Le niveau M0 correspond à celui des instances, aux données réellement manipulées. C’est, par
exemple, à ce niveau qu’est décrit une voiture particulière, immatriculée ’12 XY 59’, de couleur rouge...
Le niveau M1 est celui des modèles, c’est lui qui est utilisé pour concevoir un logiciel. Un diagramme écrit
en UML correspond à ce niveau. Pour reprendre notre exemple, c’est le niveau qui définit le type voiture,
qu’elle doit avoir une immatriculation, une couleur... On ne décrit pas une voiture en particulier mais son
concept. Le niveau M2 est le niveau des méta-modèles, c’est par exemple à ce niveau qu’est décrite la
syntaxe du langage UML, le fait qu’une classe a un nom, qu’elle est composée d’attributs... Le dernier
niveau, M3, a la particularité de se décrire lui même. Il serait sinon possible d’avoir une infinité de niveaux.
Ce niveau est celui des méta-méta-modèles, c’est certainement le niveau le plus difficile à comprendre. Il
permet de décrire le niveau M2, qu’il existe des entités (classes, attributs...) qui peuvent avoir des relations
entre elles. Pour résumer, on peut dire que le niveau M0 correspond à une application en cours d’exécution,
le niveau M1 au schéma UML d’une application en particulier, le niveau M2 à la façon de représenter une
application en général et enfin le niveau M3 à introduire les concepts nécessaires au niveau M2.
     Il existe deux grandes techniques de méta-modélisations, le MOF (Meta Object Facilities) [12] et les
profils UML. Le MOF est un langage de niveau M3, il permet donc d’introduire de nouveaux concepts pour
le niveau M2. La méta-modélisation par profils est une technique plus “légère” prévue par le langage UML,
elle ne permet pas vraiment d’introduire de nouveaux méta-concepts mais de spécialiser, en les étiquetant
par des “stéréotypes”, les méta-concepts existants.
     L’approche MDA (Model Driven Architecture) [13, 14, 15] de l’OMG (Object Managment Group) [16]
définit une méthode de conception basée sur les modèles permettant d’obtenir à partir d’un schéma de base
unique sa réalisation sur n’importe quelle plate-forme (supportée par le MDA). La principale motivation
est de rester indépendant d’un système donné afin de suivre l’évolution des technologies et des intergiciels
sans perdre ce qui a déjà été réalisé.
     Pour obtenir ce résultat, le MDA introduit deux types de modèles : les PIMs (Platform Independent
Model) qui doivent représenter l’application en utilisant uniquement des concepts indépendants de toutes
plates-formes, et les PSMs (Platform Specific Model) qui sont des projections des PIMs pour une plate-
forme donnée. Nous avons réalisé dans le cadre du projet ACCORD un état de l’art de l’approche MDA,
celui-ci est disponible en annexe de ce mémoire.
     En proposant une approche qui définit un modèle de composants abstraits (PIM) tout en permettant sa
projection vers des plates-formes existantes (PSM), nous respectons la philosophie du MDA. De plus, en
utilisant l’UML et les profils, nous sommes “compatibles” avec les choix technologiques de l’OMG, ce
qui facilite l’utilisation de notre modèle (outils, XMI...). La figure 1.9 illustre l’articulation des différents
modèles dans notre approche. L’interconnexion de nos composants au niveau PIM permet l’interopérabilité
au niveau binaire.
16                                               Chapitre 1. Problématique et positionnement




        View UML                                           Base UML
                     connexion

                     vérification
                     des contraintes

                                                                                PIM

                                                                                PSM

       Modèle CCM
          avec                                             XML+
      associations                   IDL                   Java              XML




     Binaire   Binaire          Base Binaire         Base Binaire
       CCM     EJB(++)              CCM                EJB(++)               BDR



                         F IG . 1.9 – Application de MDA
Chapitre 2

                                                       Le modèle abstrait



2.1 Le méta-modèle
    La figure 2.1 représente les concepts du modèle de composant vues. Ce méta-modèle introduit la notion
de connexions entre un élément et sa vue, grâce aux associations viewOf et root.
Les sémantiques de ces deux types de relation sont différentes. Une association viewOf indique que
l’élément source (de type Component ou ViewClass) est une extension de l’élément qu’il désigne
(respectivement de type Package ou Class). Par contre, une association root signifie que l’élément
source (de type ViewAttribute ou ViewAssociation) n’est qu’une représentation de l’élément
désigné (respectivement de type Attribute ou Association).
    Dans ce modèle, un composant est donc un ensemble de ViewClass et de Class que l’on peut
appliquer à un ensemble (Package) de Class. Grâce au mécanisme de connexions, un composant peut
être modélisé indépendamment des Package sur lesquelles il sera appliqué. Les seuls règles à suivre
lors de cette phase de modélisation sont décrites par les règles de conception, néanmoins pour que le
système obtenu par la “fusion” des Package et des Component soit cohérent, les règles de connexion
doivent être vérifiées. Ce découpage correspond respectivement aux phases de conception et d’assemblage
du composant. Les contraintes OCL sont présentées pour chacun des concepts à la fin de ce chapitre.


2.2 Description des éléments
Component Un Composant est une spécialisation de la méta-classe UML Package. Son rôle est de
    regrouper toutes les ViewClass, Class ainsi que tout autre élément UML nécessaire à la modé-
    lisation du composant.
ViewClass Une ViewClass est une spécialisation de la méta-classe UML Classifier. Une instance
     de celle-ci peut contenir les mêmes éléments qu’un autre Classifier ainsi que des
     ViewAttribute. L’association viewOf (entre une ViewClass et une Class) indique dans
     quelle Class les Attribute racine (root) des ViewAttribute de la ViewClass doivent
     se trouver.
     Pour reprendre l’analogie avec la structuration par contextes, une Class correspond au plan de base
     et, une ViewClass qui lui est connectée correspond à son extension dans un autre plan.
ExternalFeature et ExternalStructuralFeature Une ExternalFeature est un élément abstrait consti-
     tuant d’un Classifier au même titre qu’une StructuralFeature ou qu’une
     BehavioralFeature, son rôle est de désigner, par l’association root, une autre Feature.
     L’élément ExternalStructuralFeature spécialise ExternalFeature en imposant une
     StructuralFeature comme racine (root).

                                                  17
18                                                                                                                                                         Chapitre 2. Le modèle abstrait

     Component                                                      Package (from UML)


                   0..*


                                                   +viewOf                                                                              AssociationEnd (from UML)

                                                                                  0..*                                                  isNavigable
                                                                                                                                   *                                              Association (from UML)
                                                                                                                                        ordering
                                                                   Classifier (from UML)
                                                                                                                                                                    +connection
                                                                                                                                        aggreagation
                                                                                            +participant           +association
                                                                                                                                        targetScope
                                                                                                                                                                    2..*
                                                                                             *                                     *    multiplicity

                                                                                                                                        changeability
                                                                                           +specification      +specifedEnd
                                                                                                                                        visibility                                                    +root
                                                                                             0..1
                                                                                                                                                                                               0..*

                                                                                                            0..*
                                                                                            +owner                                                                                     ViewAssociation
                                                                          +type                +feature
                                                                                                                     Feature (from UML)

                                                                                                                   ownerScope
     ViewClass                         Class (from UML)
                 0..*                                                                                              visibility
                                    isActive
                          +viewOf




                                                                                                                                  connection
                                                                                    0..*                                                        +root
                                                                                                                                       0..*
                                                     StructuralFeature (from UML)
                                                                                                                         ExternalFeature
                                                    multiplicity

                                                    changeability

                                                    targetScope




                                                                                                                   ExternalStructuralFeature


                                                             Attribute (from UML)

                                                          initialValue




                                                                                                                                ViewAttribute




                                                                         F IG . 2.1 – Le méta-modèle

     Ce sont les éléments de base de notre modèle, qui permettent “d’importer” des données de l’exterieur
     et qui permettent ainsi la conception du composant.
ViewAttribute Un ViewAttribute est un ExternalStructuralFeature dont le lien racine
     (root) ne peut porter que sur un Attribute. Un ViewAttribute ne peut appartenir qu’à
     une ViewClass.
     C’est le seul élément de type ExternalFeature qui ne soit pas abstrait, donc le seul à pouvoir
     apparaître dans un modèle de conception.
ViewAssociation Une ViewAssociation est une spécialisation de la méta-classe UML Association.
     Une instance de celle-ci permet de contextualiser une Association du Package auquel s’ap-
     plique (par le lien viewOf) le Component.
     Une ViewAssociation est utilisée dans un composant pour “imposer” et manipuler l’Association
     conrrespondante entre les classes de la base.


2.3 Contraintes OCL
ExternalFeature et ExternalStructuralFeature
Contraintes de conception
     [1] La racine d’un ExternalStructuralFeature doit être un StructuralFeature.
self.root.oclIsKindOf(StructuralFeature);
2.3. Contraintes OCL                                                                                   19

ViewClass
Contraintes de conception
   [2] Toutes les ViewClass doivent être dans un Component.
self.package.oclIsKindOf(Context);

Contraintes de connexion
   [3] Tous les ViewAttribute d’une ViewClass doivent avoir le même propriétaire de leur racine que la
viewOf.
self.allFeatures->select( f | f.oclIsKindOf(ViewAttribute) )
           ->forAll ( f : ViewAttribute | f.root.owner = self.viewOf );


ViewAttribute
Contraintes de conception
   [4] Le propriétaire d’un ViewAttribute doit être une ViewClass.
self.owner.oclIsKindOf(ViewClass);

Contraintes de connexion
   [5] Le propriétaire de la racine d’un ViewAttribute doit être une Class.
self.root.owner.oclIsKindOf(Class);


ViewAssociation
Contraintes de conception
   [6] Une ViewAssociation ne peut être que dans un Component
self.namespace.oclIsKindOf(Context);

Contraintes de connexion
    [7] S’il existe dans le Component une ViewClass dont la viewOf participe à ViewAssociation.root alors
cette ViewClass participe à la ViewAssociation.
self.namespace.allContents->select( v | v.oclIsKindOf(ViewClass) )
     ->forAll( v : ViewClass | self.root.allConnections->collect( type )
                ->includes(v.viewOf)
        implies self.allConections->collect( type )
                ->includes(v));


Component
Contraintes de connexion
   [8] Toutes les ViewClass d’un Component doivent avoir le même Package de leur viewOf que la viewOf
du Component.
self.allReferencedElements->select( v | v.oclIsKindOf(ViewClass) )
     ->forAll ( v : ViewClass | v.viewOf.package = self.viewOf );

   [9] Il ne peut pas y avoir deux ViewClass de la même Class dans un Component
self.allReferencedElements->select( v | v.oclIsKindOf(ViewClass) )
     ->forAll ( v1, v2 : ViewClass | not v1.viewOf = v2.viewOf );
20                                                                   Chapitre 2. Le modèle abstrait

   [10] Si deux ViewClass (v1, v2) sont dans le même Component et qu’il y a une Association entre
v1.viewOf et v2.viewOf alors il y a une ViewAssociation entre v1 et v2
self.allReferencedElements->select( v | v.oclIsKindOf(ViewClass) )
     ->forAll ( v1, v2 : ViewClass |
       v1.viewOf.allAssociations
          ->intersection(v2.viewOf.allAssociations)->size
     = v1.allAssociations->intersection(v2.allAssociations)
          ->select( va | va.oclIsKindOf(ViewAssociation) )->size);
Chapitre 3

                                    Réalisation du Profil UML


    Comme il a été présenté dans le premier chapitre, il existe deux méthodes de méta-modèlisation, le
MOF et les profils. Nous présentons ici la réalisation de notre modèle abstrait grâce aux profils. Vous pour-
rez trouver en annexe, la réalisation de celui-ci avec l’outil Objecteering de la société Softeam, partenaire
du projet ACCORD. Actuellement, le langage OCL n’est pas supporté par cet outil, les contraintes ont
donc été traduites en J1 , le langage spécifique à Objecteering. Le module résultant de cette réalisation (cf
figure 3.7), utilisable avec la version gratuite d’Objecteering, est disponible en ligne.
(http ://www.lifl.fr/ mullera/ViewComponents.prof).
                         




3.1 Identification du sous-ensemble UML
   Le profil de composant vues étend le paquetage UML core en se basant sur les méta-classes suivantes :
   – Package
   – Classifier
   – Feature
   – Class
   – StructuralFeature
   – Attribute
   – Association
   – Dependency


3.2 Les éléments du profil
Les ExternalFeature et ExternalStructuralFeature sont représentées dans notre profil UML par une
     Feature stéréotypée respectivement par «ExternalFeature» et
     «ExternalStructuralFeature».
     La valeur marquée de nom root s’applique au stéréotype «ExternalFeature» ainsi qu’aux
     stéréotypes héritant de celui-ci («ExternalStructuralFeature» et «ViewAttribute»).
     La valeur de type chaîne de caractères associée à ce tag contient le nom de la Feature racine de
     l’élément. Cette valeur marquée est indispensable pour représenter la connexion.

Une ViewClass est représentée dans notre profil par une Class stéréotypée par «ViewClass». L’as-
     sociation entre une ViewClass et la Class à laquelle elle se réfère est représentée par une
     Dependency entre elles stéréotypée par «viewOf».
  1 Disponible   en annexe


                                                     21
22                                                               Chapitre 3. Réalisation du Profil UML

     Stéréotype                s’applique à                  Définition
     «ExternalFeature»         Feature                       Indique que la Feature est
                                                             externe.
     «ExternalStructural       Feature                       Spécialise «ExternalFeature».
     Feature»                                                Indique que la racine porte
                                                             sur un élément structurel.
     Tag                       s’applique à                  Définition
     root                      «ExternalFeature»             Nom d’une Feature
                                                             Désigne la racine de l’élément.

TAB . 3.1 – Stéréotypes et valeurs marquées pour les méta-types ExternalFeature et
ExternalStructuralFeature.



                                                   <<baseElement>>    Feature
                                                                     {From UML}
                         «stereotype»
                       ExternalFeature
                 <<tagged value>> root: string


                                <<baseElement>>

                       «<<stereotype>>»
                   ExternalStructuralFeature

                                <<baseElement>>
                         «stereotype»
                        ViewAttribute


                   F IG . 3.1 – Méta-modèle virtuel des ExternalFeature




            Stéréotype       s’applique à        Définition
            «ViewClass»      Class               Indique que la Class est
                                                 une vue.
            «viewOf»         Dependency          Permet d’indiquer une dépendance entre
                                                 une classe et sa vue.

                    TAB . 3.2 – Stéréotypes pour le méta-type ViewClass.

                                            Classifier
                                               {From UML}



                                           <<baseElement>>


                                          «stereotype»
                                          ViewClass


                       F IG . 3.2 – Méta-modèle virtuel des ViewClass



Un ViewAttribute est représenté par un Attribute UML stéréotypé par «ViewAttribute». En
     spécialisant «ExternalStructuralFeature», le stéréotype «ViewAttribute» hérite de
     la valeur marquée root, qui doit ici contenir le nom d’un Attribute.
3.2. Les éléments du profil                                                                         23

                                              Dependency
                                                {From UML}



                                             <<baseElement>>


                                          «stereotype»
                                              viewOf


                             F IG . 3.3 – Méta-modèle virtuel des viewOf



     Stéréotype               s’applique à     Définition
     «ViewAttribute»          Attribute        Spécialise «ExternalStructuralFeature».
                                               Indique que l’attribut est une vue.

                     TAB . 3.3 – Stéréotype pour le méta-type ViewAttribute.

                                              Attribute
                                               {From UML}



                                             <<baseElement>>

                                             «stereotype»
                                          ViewAttribute


                        F IG . 3.4 – Méta-modèle virtuel des ViewAttribute
Une ViewAssociation est représentée par une Association UML stéréotypée par «ViewAssociation».
     Une valeur marquée de nom root lui est appliquée. La valeur de type chaîne de caractères associée à
     ce tag contient le nom de l’Association racine. Celle-ci permet de manipuler, dans le composant,
     l’association définie dans le paquetage de base.



 Stéréotype                  s’applique à                   Définition
 «ViewAssociation»           Association                    Indique que l’association est une vue.
 Tag                         s’applique à                   Définition
 root                        «ViewAssociation»              Nom d’une Association
                                                            Désigne la racine de la ViewAssociation.

         TAB . 3.4 – Stéréotypes et valeurs marquées pour le méta-type ViewAssociation.

                                              Association
                                                 {From UML}



                                               <<baseElement>>


                                              «stereotype»
                                          ViewAssociation
                                    <<tagged value>> root: string


                      F IG . 3.5 – Méta-modèle virtuel des ViewAssociation
Un composant est représenté par un Package UML stéréotypé par «Component». Son application à
     un Package est représenté par une Dependency entre eux stéréotypée par «viewOf».
24                                                    Chapitre 3. Réalisation du Profil UML

     Stéréotype      s’applique à     Définition
     «Component»     Package          Indique que le Package est
                                      un composant vue.
     «viewOf»        Dependency       Permet d’indiquer un dépendance entre
                                      un paquetage et un composant.

           TAB . 3.5 – Stéréotypes pour le méta-type Component.

                                    Package
                                    {From UML}



                                <<baseElement>>


                               «stereotype»
                               Component


                F IG . 3.6 – Méta-modèle virtuel des Component




                      F IG . 3.7 – Le module Objecteering
Chapitre 4

                                                                                      Ciblage


    Pour tester notre modèle, nous avons mis en œuvre l’exemple de la bibliothèque universitaire présentée
dans le premier chapitre sur les plates-formes CCM et EJB. La première réalisation (vers CCM) ne produit
pas de code éxecutable, uniquement les spécifications (IDL 3) mais elle est entièrement automatisée. La
seconde (vers EJB) n’a pas fait l’objet d’une automatisation, mais a été entiérement spécifiée. Les sections
suivantes présentent ces travaux.


4.1 Du modèle abstrait aux composants CCM
    Nous proposons ici une génération automatique des descriptions UML des composants vues vers des
composants CCM. Plus précisément, l’atelier UML génère :
    – La spécification IDL3 des composants CCM issus d’un composant de base.
    – La spécification IDL3 des composants CCM issus d’un composant vue.
    – La spécification IDL3 des composants CCM d’assemblage entre un composant vue et un composant
      de base.
Après une description succinte du modèle de composants CORBA (cf 4.1.1), nous détaillons les différentes
règles de transformation d’un schéma UML profilé vers la spécification IDL3 (cf 4.1.2).


4.1.1 Le modèle de composants CORBA
    Les modèles à objets ont progressivement montré leurs limites. Certains industriels, comme Microsoft,
Sun et l’OMG, ont fait évoluer leurs modèles vers les composants, dans le but de simplifier le dévelop-
pement d’applications. La réponse de l’OMG [16] est le "CORBA Component Model" (CCM) modèle de
base du futur standard CORBA 3 [17, 18, 19]. Dans un but de compatibilité ascendante, l’OMG a défini
son modèle de composants comme une extension du modèle objet de CORBA 2. Les composants CORBA
représentent donc une spécialisation des objets CORBA tels que nous les connaissons aujourd’hui. La spé-
cification de ce standard n’est pas encore achevée ; cependant, le chapitre sur le modèle de composants a
été finalisé à l’OMG en janvier 2002. C’est donc l’un des plus jeunes modèles de composants mais aussi
l’un des plus riches en comparaison avec d’autres modèles.
    La spécification du CCM, qui représente plus de 1000 pages, est découpée en quatre modèles et un
méta-modèle. Ce document décrit :
Le modèle abstrait offre aux concepteurs le moyen d’exprimer les interfaces (fournies et utilisées) et les
     propriétés d’un type de composant. Pour cela, le langage OMG IDL a été étendu pour prendre en
     compte les nouveaux concepts introduits dans le CCM (le langage IDL3). Un type de composant
     (component) regroupe la définition d’attributs et de ports. Les attributs représentent les propriétés

                                                    25
26                                                                                         Chapitre 4. Ciblage

      configurables du type de composant. Un port représente une interface (au sens CORBA 2) soit four-
      nie, soit requise, par le type de composant. Quatre types de ports sont définis dans le contexte du
      CCM :
      – Une facette est une interface fournie par un type de composant et qui est utilisée par des clients en
        mode synchrone.
      – Un réceptacle est une interface utilisée par un type de composant en mode synchrone.
      – Un puit d’événement est une interface fournie par un type de composant et utilisée par ses clients
        en mode asynchrone.
      – Une source d’événement est une interface utilisée par un type de composant en mode asynchrone.
      La figure 4.1 illustre un composant abstrait CCM doté de plusieurs ports.
                 Référence de                                                 Réceptacle
                 Composant             Composant CCM

                                                                                   Composant

                                               Implémentation
          Références                           des facettes                     Puit d’événement
          de facettes

                                                                                Source d’événement


                                                                                   Composant

                                            Attributs




                                   F IG . 4.1 – Composant abstrait CCM

Le modèle de programmation spécifie le langage CIDL (Component Implementation Definition Lan-
     guage) à utiliser pour définir la structure de l’implantation d’un type de composant, ainsi que cer-
     tains de ses aspects non-fonctionnels (persistance, transactions, sécurité). L’utilisation de ce langage
     est associée à un framework, le CIF (Component Implementation Framework), qui définit comment
     les parties fonctionnelles (programmées) et non-fonctionnelles (décrites en IDL / CIDL et générées)
     doivent coopérer. Il inclut aussi la manière dont l’implantation d’un composant interagit avec le
     conteneur.
Le modèle de déploiement définit un processus qui permet d’installer une application sur différents sites
     d’exécution de manière simple et automatique. Ce modèle s’appuie sur l’utilisation de paquetages de
     composants, ainsi que de descripteurs OSD (Open Software Description, un vocabulaire XML), les
     paquetages étant déployables et composables.
Le modèle d’exécution définit l’environnement d’exécution des instances de composants. Le rôle princi-
     pal des conteneurs est de masquer et prendre en charge les aspects non-fonctionnels des composants
     qu’il n’est alors plus nécessaire de programmer.

4.1.2 Règles de transformation
    Pour la génération automatique, nous nous sommes basés sur le langage IDL3 permettant de décrire le
modèle abstrait CCM. De plus, nous nous sommes interressés uniquement aux ports synchrones du modèle
(facettes et réceptacles).

Génération du composant de base
   Le tableau 4.1 énumère la transformation de chaque concept UML vers des concepts IDL3. Un com-
posant de base défini par un paquetage UML est spécifié par un module CCM.
4.1. Du modèle abstrait aux composants CCM                                                                  27

Chaque classe UML de ce paquetage est spécifiée par un composant CCM, ce composant dispose d’une
facette décrite par une interface IDL contenant toutes les descriptions publiques (attributs et opérations) de
la classe UML.
Les attributs d’une classe sont transformés en attributs primitifs CORBA (l’atelier UML vérifiant que les
attributs définis dans le modèle sont des attributs simples). Ces attributs sont spécifiés dans l’interface cor-
respondante à l’unique facette du composant CCM.
Les opérations UML sont également transformées en opérations contenues dans l’interface IDL de la fa-
cette du composant
Les associations sont exprimées par des opérations primitives de manipulation de l’association (add, get
, remove) définies dans l’interface IDL correspondante à la facette du composant. ces associations sont
également gérées par l’introduction de réceptacles au niveau des composants participants à l’association
(l’atelier UML se limite aux associations binaires)
                 Concept modèle abstrait UML       spécification IDL3 correspondante
                 paquetage UML X                   module CCM X
                 classe X                          component X doté d’une
                                                   facette de nom serviceX de l’interface IX
                                                   et d’une maison de composant homeX
                 attributs publiques UML           attributs IDL3 dans l’interface IX
                 opérations publiques UML          opérations IDL3 dans l’interface IX
                 association UML                   opérations de gestion des associations,
                                                   réceptacle pour l’extrémité de l’association.

                TAB . 4.1 – Correspondance composant UML de base et composants CCM

    Exemple : Nous illustrons cette génération par l’exemple de la bibliothèque universitaire et en se
limitant aux classes UML Location et Document reliée par une association de nom manage, la spé-
cification IDL3 générée par l’atelier UML est la suivante :

module Base
{
  interface ILocation ;
  interface IDocument ;
  typedef sequence<IDocument> IDocuments ;

  interface ILocation
  {
    attribute string identifiant ;
    attribute string adresse ;
    public void addManage(IDocument value) ;
    public IDocuments getManage() ;
    public void removeManage(IDocument value) ;
  } ;

  interface IDocument
  {
    attribute string title ;
    attribute string publication_date ;
    public void setManage(ILocation value) ;
    public ILocation getManage() ;
    public void removeManage() ;
  } ;

  component Location
  {
    provides ILocation serviceLocation ;
    uses multiple IDocument manage ;
  } ;
28                                                                                         Chapitre 4. Ciblage


  component Document
  {
    provides IDocument serviceDocument ;
    uses ILocation manage ;
  } ;

  home LocationHome manages Location { } ;
  home DocumentHome manages Document { } ;
} ;


Génération du composant vue
      Pour un composant vue, les règles de transformation définies pour un composant de base sont intégra-
lement applicables pour les constructions UML standards.
      Le tableau 4.2 énumère la transformation de chaque concept UML étendu (viewClass, viewAttribute,
. . .) vers des concepts IDL3.
      Une classe «viewClass» est spécifiée par un composant CCM, ce composant dispose d’une fa-
cette décrite par une interface IDL contenant toutes les descriptions publiques (attributs et opérations) de
la classe UML et dispose d’un réceptacle correspondant à toutes les descriptions requises (constructions
«viewAttribute» et «viewAssociation»).
              Concept modèle abstrait UML     spécification IDL3 correspondante
              «viewClass» X                   component X dotée d’une
                                              facette de nom serviceX de l’interface IX
                                              et d’un réceptacle de nom receptX de l’interface RX
                                              et d’une maison de composant homeX
              «viewAttribute»                 spécifié dans l’interface IX si public
                                              spécifié dans l’interface RX
              «viewAssociation»               opérations de manipulation de l’association
                                              spécifiés dans l’interface IX et RX

                  TAB . 4.2 – Correspondance composant UML vue et composants CCM

     Exemple : Pour illustrer la spécification IDL3 suivante décrit le composant vue resourceManager :

module ResourceManager
{
  interface IResourceOwner ;
  interface IResource ;
  typedef sequence<IResource> IResources ;

  interface IResourceOwner
  {
    attribute string identifiant ;
    attribute long capacity ;
    public void addStore(IResource value) ;
    public IResources getStore() ;
    public void removeStore(IResource value) ;
    public void transfering(IResourceOwner o) ;
  } ;

  interface RResourceOwner
  {
    attribute string identifiant ;
    public void addStore(RResource value) ;
    public RResources getStore() ;
    public void removeStore(RResource value) ;
4.1. Du modèle abstrait aux composants CCM                                                            29

  } ;

  interface IResource
  {
    attribute string identifiant ;
    public void setStore(IResourceOwner value) ;
    public IResourceOwner getStore() ;
    public void removeStore() ;
  } ;

  interface RResource
  {
    attribute string identifiant ;
    public void setStore(RResourceOwner value) ;
    public RResourceOwner getStore() ;
    public void removeStore() ;
  } ;

  component ResourceOwner
  {
    provides IResourceOwner serviceResourceOwner ;
    uses RResourceOwner receptResourceOwner
  } ;

  component Resource
  {
    provides IResource serviceResource ;
    uses RResource receptResource ;
  } ;

  home ResourceOwnerHome manages ResourceOwner { } ;
  home ResourceHome manages Resource { } ;
} ;


Génération du composant d’assemblage
    Comme l’illustre les exemples, composants de bases et composants vues sont parfaitement indépen-
dants. Les constructions UML détaillant la connexion d’un composant vue à un composant de base vont
permettre de générer les composants CCM d’assemblage : ce sont en fait, des composants adaptateurs qui
vont permettre de relier un réceptacle d’un composant CCM vue à la facette du composant CCM de base.
    Le pattern classique adaptateur [20] est utilisé pour les connexions comme le montre le code exemple
suivant permettant de connecter un composant vue X à un composant de base Y :
  component AdaptX_Y
  {
    provides RX serviceAdaptX ;
    uses IY receptAdaptY ;
  }

   Exemple : voici l’exemple du composant d’assemblage permettant de connecter le composant vue
ResourceManager au composant de base Base de la bibliothèque universitaire :
import ResourceManager ;
import Base ;

module adapt
{
  component AdaptResourceOwner_Location
  {
30                                                                                                           Chapitre 4. Ciblage

     provides ResourceManager::RResourceOwner serviceAdaptResourceOwner ;
     uses Base::Ilocation receptAdaptLocation ;
   } ;

   component AdaptResource_Document
   {
     provides ResourceManager::RResource serviceAdaptResource ;
     uses Base::IDocument receptAdaptDocument ;
   } ;

   home AdaptResourceOwner_LocationHome
     manages AdaptResourceOwner_Location {} ;
   home AdaptResource_Documenthome
     manages AdaptResource_Document {} ;



4.2 Du modèle abstrait aux composants EJB
     Dans cette section, nous présentons une seconde projection des composants de notre modèle abstrait.
Il s’agit d’une projection vers la plate-forme EJB qui propose des composants orientés vers le développe-
ment d’applications au-dessus d’un système d’informations d’entreprise. En plus de proposer des règles
pour générer la spécification, des composants, cette projection introduit aussi des règles pour produire leur
implantation.
     La projection proposée produit le code Java d’implantation de composants EJB correspondant aux
classes ViewClass d’un composant connecté à un composant de base au niveau modèle. Un composant
de notre modèle sera matérialisé par une archive empaquetant ces composants EJB avec des descripteurs
de déploiement1.
     Les composants EJB résultant de la projection présentent les caractéristiques suivantes 2 .
     – Ils sont connectables localement ou à distance avec des composants EJB implantant les classes du
       composant de base pour lesquels la connexion a été vérifiée ;
     – Ils mettent en oeuvre des traitements pour préserver la sémantique de vues à l’exécution ;
     – Ils sont manipulables pour les outils EJB standard d’empaquetage et de déploiement sur un serveur.
     – Ils définissent un schéma abstrait de persistance qui permet de définir un descripteur pour leur sau-
       vegarde (état, associations) dans une base de donnée quelconque.
Dans la prochaine section, nous présentons les grandes lignes de la norme EJB. Cette partie permettra
d’introduire les notions utilisées lors de la projection. Ces notions sont illustrées en implantant le composant
de base de la bibliothèque sous forme de composants EJB. La section suivante décrit le choix de mise en
oeuvre et les règles de générations qui en découlent pour les composants vues.


4.2.1 Le modèle de composants EJB
    La norme EJB (Enterprise Java Bean) a été proposée par SUN Microsystems pour répondre aux be-
soins de l’industrie en matière de construction de serveurs d’applications d’entreprise. Cette norme (qui
en est à sa version 2.0) décrit une architecture normalisée pour le développement et le déploiement de ces
applications à base de composants "Bean" écrits en Java. L’apport principal de cette norme est d’accorder
une grande importance à la prise en change des aspects non fonctionnels requis par les composants de ce
type d’applications à savoir la persistance des données, la sécurité et la gestion des transactions. Cette prise
en charge permet au développeur de se concentrer sur les aspects métiers de ces composants.
    Un composant EJB est un ensemble de définitions JAVA (interfaces et classes) et des descripteurs XML
empaquetés - dans une archive de type jar - qui sont déployés sur un serveur d’applications. Le serveur
   1 dans sa version actuelle, la projection ne produit pas le descripteur de déploiement des composants EJB mais cette opération est

tout à fait envisageable
   2 La production de composants EJB qui seraient génériques par rapport à plusieurs composants de base implantées avec des

composants EJB est envisageable mais réclame l’utilisation d’outils puissants comme la réflexivité. Nous laissons l’étude de tels
composants pour des travaux futurs
4.2. Du modèle abstrait aux composants EJB                                                               31

utilise les informations contenues dans le descripteur pour instancier le composant EJB dans un container
dont la fonction est de fournir une interface entre le composant et son environnement, prenant en charge un
certain nombre d’aspects non-fonctionnels.




                                      F IG . 4.2 – L’architecture EJB
    Un composant EJB offre des services exposés aux clients sous la forme d’une interface Java de type
EJBObject (pour des client distants) ou EJBLocalObject (pour des clients locaux, c’est-à-dire s’exécutant
dans la même machine virtuelle). Un client d’un EJB peut être n’importe quel programme susceptible de
communiquer par le protocole RMI-IIOP et notamment un autre EJB ou encore un ensemble de servlet
et de pages JSP. Le container se charge de transformer les requêtes distantes du client en appels réels aux
composants, en les enveloppant éventuellement dans un contexte transactionnel.
    Le code suivant présente l’interface de services proposée par des composants EJB implantant respecti-
vement la classe Document et la classe Location appartenant au composant de base de notre exemple. Les
méthodes spécifiées par chaque interface donne accès aux attributs et aux associations définis à ce niveau.
public interface Document extends EJBLocalObject
{
        public String getDocumentId();
        public String getTitle();
        public void setTitle(String title);
        public Date getPublicationDate();
        public void setPublicationDate(Date d);
        public Location getLocation();
        public void setLocation(Location loc);
        public Collection getAuthors();
        public void addAuthor(Researcher r);
}

public interface Location extends EJBLocalObject
{
        public String getLocationId();
        public String getAddress();
        public void setAddress(String a);
        public Collection getDocuments();
        public void addDocument(Document d);
}

   A chaque composant EJB est également associée une maison de composant qui est chargée de la
construction effective des composants, de leur destruction et éventuellement de leur recherche. Ces mai-
sons correspondent à la notion bien connue de fabrique. Elles sont généralement localisables par un client,
32                                                                                          Chapitre 4. Ciblage

par exemple au travers d’un service de nommage, et offre une interface uniforme de type EJBHome (des-
tinée aux clients distants) ou EJBLocalHome (destinée aux clients locaux) pour la gestion des instances de
composants associés.
    Le code suivant présente les interfaces de fabrique pour la création (méthodes de nom "create") et la
recherche (méthodes ayant un nom préfixé par "find") d’instances de composants EJB implantant respecti-
vement la classe Document et la classe Location du composant de base.

public interface LocalDocumentHome extends EJBLocalHome
{
        public Document create(String id, String title,
                               Date publication Date)
                 throws CreateException;
        public Document create(String id, String title,
                               Date publicationDate, Location loc)
                 throws CreateException;
        public Document findByPrimaryKey(String id)
                 throws FinderException;
        public Document findByDate(Date d)
                 throws FinderException;
}

public interface LocationHome extends EJBLocalHome
{
        public Location create(String id, String address)
                 throws CreateException;
        public Location findByPrimaryKey(String id)
                 throws FinderException;
}

     La norme EJB définit trois types de composants qui se différentient principalement par rapport à leur
utilité et la gestion de leur cycle de vie par le conteneur : il s’agit des beans "session", des beans "orientés
message" (message-driven) et des beans "entité". Les bean "session" sont des composants existants pour
une session demandée par le client. Ils peuvent être avec état ou sans état ce qui, dans ce dernier cas, permet
au conteneur de les partager entre plusieurs clients (sous forme de pool). Les beans "orientés message" sont
des réceptables de messages asynchrones gérés par file d’attente. Les beans "entité" sont des composants
représentant des données d’une base de données dont ils permettent d’obtenir une vue orientée objet.
     Etant donné que les beans "entité" sont les seuls beans à être employés lors de la projection, nous nous
focalisons sur les caractéristiques de ce type de bean dans le reste de la présentation, notamment ceux qui
sont liées à la gestion de la persistance.
     L’association des beans "entité" avec les éléments d’une base de données leur confère deux caractéris-
tiques principales.
     La première caractéristique est d’être identifié de manière unique par un clé primaire. La présence de
cette clé permet aux clients de rechercher un bean entité donné par sa clé primaire. Il suffit pour cela que
le client s’adresse à la maison liée au bean. Cette clé primaire peut-être n’importe quel objet sérialisable.
     La seconde caractéristique est d’être persistant ce qui signifie que l’état du bean et ses associations
avec d’autres beans peuvent être sauvegardés dans la base de données. Pour la gestion de cette persistance,
la norme EJB propose deux approches : une gestion par le bean et une gestion par le conteneur que nous
privilégions. Dans ce second cas, le container collabore avec le gestionnaire de la base pour mettre en
oeuvre un schéma de persistence qui leur est fourni au travers du descripteur de bean. Schématiquement,
le descripteur définit des sources de données, des champs de données et des relations (à la manière d’un
schéma de base de données) qui sont identifiés au niveau de la classe d’implantation du bean par des
méthodes d’accès abstraites nommées selon des conventions particulières. Il appartient au conteneur et au
gestionnaire de la base de créer et de mettre à jour effectivement et automatiquement les données lors de la
création et l’exécution des beans.
     Le code suivant présente les classes d’implantation des composants EJB Document et Location (sans
code d’implantation pour plus de clarté). Ces classes héritent de EntityBean pour indiquer que ceux sont
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants
Assemblage par vues de composants

Contenu connexe

Tendances

Rapport Sdec Pi64
Rapport Sdec Pi64Rapport Sdec Pi64
Rapport Sdec Pi64guestf223f9
 
Manuel du module additionnel RF-LAMINATE pour RFEM
Manuel du module additionnel RF-LAMINATE pour RFEMManuel du module additionnel RF-LAMINATE pour RFEM
Manuel du module additionnel RF-LAMINATE pour RFEM
Grégoire Dupont
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
safwenbenfredj
 
Cours bd
Cours bdCours bd
Recherches opérationnelles
Recherches opérationnellesRecherches opérationnelles
Recherches opérationnelles
Kevin Ratsimbazafy
 
Cours matlab
Cours matlabCours matlab
Cours matlab
mohamednacim
 
Rapport pfe el_abdalaoui
Rapport pfe el_abdalaouiRapport pfe el_abdalaoui
Rapport pfe el_abdalaoui
Boughraraanis
 
Cours processus- production
Cours processus- productionCours processus- production
Cours processus- productionAmine Chahed
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
Glei Hadji
 
Conception et développement d&rsquo;une place de marché B2C
Conception et développement d&rsquo;une place de marché B2CConception et développement d&rsquo;une place de marché B2C
Conception et développement d&rsquo;une place de marché B2C
Nassim Bahri
 
Cours achirecture des ordi 1
Cours achirecture des ordi 1Cours achirecture des ordi 1
Cours achirecture des ordi 1fofanaabou
 

Tendances (18)

Rapport Sdec Pi64
Rapport Sdec Pi64Rapport Sdec Pi64
Rapport Sdec Pi64
 
Manuel du module additionnel RF-LAMINATE pour RFEM
Manuel du module additionnel RF-LAMINATE pour RFEMManuel du module additionnel RF-LAMINATE pour RFEM
Manuel du module additionnel RF-LAMINATE pour RFEM
 
Batteries chargeur.fr
Batteries chargeur.frBatteries chargeur.fr
Batteries chargeur.fr
 
Qgis 1.7.2 user-guide_fr
Qgis 1.7.2 user-guide_frQgis 1.7.2 user-guide_fr
Qgis 1.7.2 user-guide_fr
 
cours-plaques
cours-plaquescours-plaques
cours-plaques
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
 
Mmc
MmcMmc
Mmc
 
Analyse s1
Analyse s1Analyse s1
Analyse s1
 
Cours bd
Cours bdCours bd
Cours bd
 
Définition de l'ETR
Définition de l'ETRDéfinition de l'ETR
Définition de l'ETR
 
Recherches opérationnelles
Recherches opérationnellesRecherches opérationnelles
Recherches opérationnelles
 
Cours matlab
Cours matlabCours matlab
Cours matlab
 
9782212127829
97822121278299782212127829
9782212127829
 
Rapport pfe el_abdalaoui
Rapport pfe el_abdalaouiRapport pfe el_abdalaoui
Rapport pfe el_abdalaoui
 
Cours processus- production
Cours processus- productionCours processus- production
Cours processus- production
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 
Conception et développement d&rsquo;une place de marché B2C
Conception et développement d&rsquo;une place de marché B2CConception et développement d&rsquo;une place de marché B2C
Conception et développement d&rsquo;une place de marché B2C
 
Cours achirecture des ordi 1
Cours achirecture des ordi 1Cours achirecture des ordi 1
Cours achirecture des ordi 1
 

En vedette

Lamuneca
LamunecaLamuneca
Lamuneca
pelayoxxx2
 
Agenda des-reformes-motion-b
Agenda des-reformes-motion-bAgenda des-reformes-motion-b
Agenda des-reformes-motion-b
Jean-Michel Boudon
 
Otro modo de la tecnología digital la nanotecnología octubre 1
Otro modo de la tecnología digital la nanotecnología octubre 1Otro modo de la tecnología digital la nanotecnología octubre 1
Otro modo de la tecnología digital la nanotecnología octubre 1
Vanessa Fonseca
 
Palabras
PalabrasPalabras
Palabras
Diego Guamán
 
Strategie Marketing
Strategie MarketingStrategie Marketing
Strategie Marketingbergadaa
 
educacion slp
educacion slpeducacion slp
educacion slp
guestbc3a3c
 
Andres - LIB Present
Andres - LIB PresentAndres - LIB Present
Andres - LIB Present
iPodsMakeZombies
 
Modu1 Final Al
Modu1 Final AlModu1 Final Al
Modu1 Final Al
alexxxiac
 
Progetto francese
Progetto franceseProgetto francese
Progetto francesenivolasy
 
Francese+ federica piras
Francese+ federica pirasFrancese+ federica piras
Francese+ federica pirasnivolasy
 
Warcraft 2 Mapa Royal Rumble
Warcraft 2 Mapa Royal RumbleWarcraft 2 Mapa Royal Rumble
Warcraft 2 Mapa Royal Rumble
sergio18
 
P R E S E N T A C IÓ N D E I N F A N T I L 3 AÑ O S
P R E S E N T A C IÓ N  D E  I N F A N T I L 3  AÑ O SP R E S E N T A C IÓ N  D E  I N F A N T I L 3  AÑ O S
P R E S E N T A C IÓ N D E I N F A N T I L 3 AÑ O S
18domingo
 
Keynote t3uni12
Keynote t3uni12Keynote t3uni12
Keynote t3uni12
Talan
 
Le carnaval+mara dagostino
Le carnaval+mara dagostinoLe carnaval+mara dagostino
Le carnaval+mara dagostinonivolasy
 
Casewise EA Foundation (FR) - Episode 1/4
Casewise EA Foundation (FR) - Episode 1/4Casewise EA Foundation (FR) - Episode 1/4
Casewise EA Foundation (FR) - Episode 1/4
Jean-Patrick Ascenci
 
Yo soy
Yo soyYo soy
Yo soy
guest1fe27d
 
Emergia 2
Emergia 2Emergia 2
Emergia 2
b3l3nxita
 
Emergia 2
Emergia 2Emergia 2
Emergia 2
b3l3nxita
 
L’origine de la facilitation
L’origine de la facilitationL’origine de la facilitation
L’origine de la facilitation
IAF France
 

En vedette (20)

Lamuneca
LamunecaLamuneca
Lamuneca
 
Agenda des-reformes-motion-b
Agenda des-reformes-motion-bAgenda des-reformes-motion-b
Agenda des-reformes-motion-b
 
Otro modo de la tecnología digital la nanotecnología octubre 1
Otro modo de la tecnología digital la nanotecnología octubre 1Otro modo de la tecnología digital la nanotecnología octubre 1
Otro modo de la tecnología digital la nanotecnología octubre 1
 
Palabras
PalabrasPalabras
Palabras
 
Strategie Marketing
Strategie MarketingStrategie Marketing
Strategie Marketing
 
educacion slp
educacion slpeducacion slp
educacion slp
 
Andres - LIB Present
Andres - LIB PresentAndres - LIB Present
Andres - LIB Present
 
Modu1 Final Al
Modu1 Final AlModu1 Final Al
Modu1 Final Al
 
Progetto francese
Progetto franceseProgetto francese
Progetto francese
 
M-L s
M-L sM-L s
M-L s
 
Francese+ federica piras
Francese+ federica pirasFrancese+ federica piras
Francese+ federica piras
 
Warcraft 2 Mapa Royal Rumble
Warcraft 2 Mapa Royal RumbleWarcraft 2 Mapa Royal Rumble
Warcraft 2 Mapa Royal Rumble
 
P R E S E N T A C IÓ N D E I N F A N T I L 3 AÑ O S
P R E S E N T A C IÓ N  D E  I N F A N T I L 3  AÑ O SP R E S E N T A C IÓ N  D E  I N F A N T I L 3  AÑ O S
P R E S E N T A C IÓ N D E I N F A N T I L 3 AÑ O S
 
Keynote t3uni12
Keynote t3uni12Keynote t3uni12
Keynote t3uni12
 
Le carnaval+mara dagostino
Le carnaval+mara dagostinoLe carnaval+mara dagostino
Le carnaval+mara dagostino
 
Casewise EA Foundation (FR) - Episode 1/4
Casewise EA Foundation (FR) - Episode 1/4Casewise EA Foundation (FR) - Episode 1/4
Casewise EA Foundation (FR) - Episode 1/4
 
Yo soy
Yo soyYo soy
Yo soy
 
Emergia 2
Emergia 2Emergia 2
Emergia 2
 
Emergia 2
Emergia 2Emergia 2
Emergia 2
 
L’origine de la facilitation
L’origine de la facilitationL’origine de la facilitation
L’origine de la facilitation
 

Similaire à Assemblage par vues de composants

Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Guide projet Iset
Guide projet IsetGuide projet Iset
Guide projet Iset
Habib M'henni
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
Taieb Kristou
 
Rapport Sdec Pi64
Rapport Sdec Pi64Rapport Sdec Pi64
Rapport Sdec Pi64guestf223f9
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
SafaAballagh
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
nesrine haloui
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 
Analyses factorielles.pdf
Analyses factorielles.pdfAnalyses factorielles.pdf
Analyses factorielles.pdf
ahmed92358
 
Développement d’une application pour la gestion de stock.pdf
Développement d’une application pour la gestion de stock.pdfDéveloppement d’une application pour la gestion de stock.pdf
Développement d’une application pour la gestion de stock.pdf
AbdelHadiTLM
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
Université de Rennes 1
 
8.02 introduction to electrodynamics 3e-griffiths
8.02 introduction to electrodynamics 3e-griffiths8.02 introduction to electrodynamics 3e-griffiths
8.02 introduction to electrodynamics 3e-griffiths
prefeitura municipal de araraquara
 
Liste instruction
Liste instructionListe instruction
Liste instruction
Ali Fsahi
 
courspython3.pdf
courspython3.pdfcourspython3.pdf
courspython3.pdf
Dendouga1
 
Poly
PolyPoly
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
ahmed oumezzine
 

Similaire à Assemblage par vues de composants (20)

Nagios
NagiosNagios
Nagios
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Guide projet Iset
Guide projet IsetGuide projet Iset
Guide projet Iset
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Rapport Sdec Pi64
Rapport Sdec Pi64Rapport Sdec Pi64
Rapport Sdec Pi64
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Analyses factorielles.pdf
Analyses factorielles.pdfAnalyses factorielles.pdf
Analyses factorielles.pdf
 
Développement d’une application pour la gestion de stock.pdf
Développement d’une application pour la gestion de stock.pdfDéveloppement d’une application pour la gestion de stock.pdf
Développement d’une application pour la gestion de stock.pdf
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
Algo
AlgoAlgo
Algo
 
8.02 introduction to electrodynamics 3e-griffiths
8.02 introduction to electrodynamics 3e-griffiths8.02 introduction to electrodynamics 3e-griffiths
8.02 introduction to electrodynamics 3e-griffiths
 
cours de Matlab
 cours de Matlab cours de Matlab
cours de Matlab
 
Liste instruction
Liste instructionListe instruction
Liste instruction
 
courspython3.pdf
courspython3.pdfcourspython3.pdf
courspython3.pdf
 
Rapport
RapportRapport
Rapport
 
Poly
PolyPoly
Poly
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 

Plus de karousn

Modl2 rap pfe_esti
Modl2 rap pfe_estiModl2 rap pfe_esti
Modl2 rap pfe_estikarousn
 
Assemblage par vues de composants
Assemblage par vues de composantsAssemblage par vues de composants
Assemblage par vues de composantskarousn
 
2009 m1 ensta_projet_bases_de_donnees
2009 m1 ensta_projet_bases_de_donnees2009 m1 ensta_projet_bases_de_donnees
2009 m1 ensta_projet_bases_de_donneeskarousn
 
Template _rapport_pfe - new_copi
Template  _rapport_pfe - new_copiTemplate  _rapport_pfe - new_copi
Template _rapport_pfe - new_copikarousn
 
Modl2 rap pfe_esti
Modl2 rap pfe_estiModl2 rap pfe_esti
Modl2 rap pfe_estikarousn
 
2009 m1 ensta_projet_bases_de_donnees
2009 m1 ensta_projet_bases_de_donnees2009 m1 ensta_projet_bases_de_donnees
2009 m1 ensta_projet_bases_de_donneeskarousn
 
Template _rapport_pfe - new
Template  _rapport_pfe - newTemplate  _rapport_pfe - new
Template _rapport_pfe - newkarousn
 
Javascript
JavascriptJavascript
Javascriptkarousn
 

Plus de karousn (9)

Modl2 rap pfe_esti
Modl2 rap pfe_estiModl2 rap pfe_esti
Modl2 rap pfe_esti
 
Assemblage par vues de composants
Assemblage par vues de composantsAssemblage par vues de composants
Assemblage par vues de composants
 
2009 m1 ensta_projet_bases_de_donnees
2009 m1 ensta_projet_bases_de_donnees2009 m1 ensta_projet_bases_de_donnees
2009 m1 ensta_projet_bases_de_donnees
 
Template _rapport_pfe - new_copi
Template  _rapport_pfe - new_copiTemplate  _rapport_pfe - new_copi
Template _rapport_pfe - new_copi
 
Modl2 rap pfe_esti
Modl2 rap pfe_estiModl2 rap pfe_esti
Modl2 rap pfe_esti
 
2009 m1 ensta_projet_bases_de_donnees
2009 m1 ensta_projet_bases_de_donnees2009 m1 ensta_projet_bases_de_donnees
2009 m1 ensta_projet_bases_de_donnees
 
Template _rapport_pfe - new
Template  _rapport_pfe - newTemplate  _rapport_pfe - new
Template _rapport_pfe - new
 
Php
PhpPhp
Php
 
Javascript
JavascriptJavascript
Javascript
 

Assemblage par vues de composants

  • 1. Assemblage par vues de composants logiciels Alexis M ULLER Mémoire de DEA Informatique - Équipe GOAL Laboratoire d’Informatique Fondamentale de Lille Alexis.Muller@lifl.fr
  • 2.
  • 3. Remerciements Je tiens à remercier ici toutes les personnes qui m’ont permis de réaliser ce mémoire ainsi que toutes celles qui le liront. Je remercie donc Jean-Marc Geib, pour m’avoir permis d’effectuer mon stage de DEA dans son équipe. Je tiens à remercier tout particulièrement mes responsables, Olivier Caron, Bernard Carré et Gilles Van- wormhoudt pour ce qu’ils m’ont appris du métier de chercheur et pour toute la précieuse aide qu’ils m’ont apporté. Merci également à Jean-Luc Dekeyser pour m’avoir permis d’effectuer ce DEA. Merci aussi à toute l’équipe GOAL, ceux de mon bureau (Jean-François Roos, Bassem Kosayba, Em- manuel Renaux et Olivier Caron) et les autres, pour leur accueil et pour leur(s) machine(s) à café. Enfin merci à mes camarades de DEA, particulièrement Florent Fareneau, Stéphane Patureau et Patrick Tessier d’avoir supporté mes blagues à l’heure du midi, ainsi que Jérémie Hattat pour avoir été mon binome au premier semestre et pour nos soirées passées à . . . travailler.
  • 4.
  • 5. Table des matières Introduction 5 1 Problématique et positionnement 7 1.1 Composants, ACCORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Vues, SOP / AOP, Catalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 Rapprochement vues/composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 Modèle, Méta-Modèle, MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2 Le modèle abstrait 17 2.1 Le méta-modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Description des éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Contraintes OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3 Réalisation du Profil UML 21 3.1 Identification du sous-ensemble UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Les éléments du profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4 Ciblage 25 4.1 Du modèle abstrait aux composants CCM . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.1 Le modèle de composants CORBA . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.2 Règles de transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 Du modèle abstrait aux composants EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1 Le modèle de composants EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.2 Règles de transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Conclusion et Perspectives 41 A Le code J 45 B La démarche MDA 57 1
  • 6. 2 Table des matières
  • 7. Table des figures 1.1 Location de voitures - Approche objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 Location de voitures - Structuration par contextes . . . . . . . . . . . . . . . . . . . . . . 10 1.3 Bibliothèque universitaire - Approche objet . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4 Bibliothèque universitaire - Structuration par contextes . . . . . . . . . . . . . . . . . . . 11 1.5 Composant de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.6 Location de voitures - Approche composants vues . . . . . . . . . . . . . . . . . . . . . . 13 1.7 Bibliothèque universitaire - Approche composants vues . . . . . . . . . . . . . . . . . . . 14 1.8 Les quatre niveaux de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.9 Application de MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1 Le méta-modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Méta-modèle virtuel des ExternalFeature . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Méta-modèle virtuel des ViewClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Méta-modèle virtuel des viewOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4 Méta-modèle virtuel des ViewAttribute . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.5 Méta-modèle virtuel des ViewAssociation . . . . . . . . . . . . . . . . . . . . . . . 23 3.6 Méta-modèle virtuel des Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.7 Le module Objecteering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1 Composant abstrait CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 L’architecture EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 Modèle abstrait vers EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3
  • 8. 4 Table des figures
  • 9. Introduction Il existe aujourd’hui plusieurs modèles technologiques de composants : CCM (OMG), EJB, .NET, ... Le problème de l’hétérogénéité de ces modèles se pose aujourd’hui et une recherche consiste à définir un modèle abstrait commun de composants et d’assemblage par contrats, comportant des spécifications de haut niveau, indépendantes des plates-formes technologiques. Les moyens d’expression de l’assemblage, pour spécifier un système d’information dans son entier, restent assez pauvres et l’assemblage n’est généralement pas représenté. Le contrat d’assemblage d’un composant se limite souvent à une interface de services unitaires. Nous proposons ici une approche de la problématique de l’assemblage, guidée par la conception par vues de systèmes d’information (SI). Ce mode de conception favorise le découpage fonctionnel de SI en rapport avec un référentiel d’enti- tés qui le caractérise. Chaque vue décrit une fonction du système. Par exemple, un système d’information d’entreprise peut se décomposer en grandes fonctions : comptable, commerciale, décisionnelle, ... Les sys- tèmes de vues ont été très étudiés dans le monde des bases de données à objets, en particulier dans l’équipe [1]. Il s’agit ici de structurer modulairement le schéma du système d’information en schémas vues (corres- pondant aux fonctions du système), d’en gérer la cohérence et les interactions. Une telle conception vise la traçabilité des besoins fonctionnels (localisés dans les vues correspondantes) et l’évolution du système par greffage de nouvelles vues. Ces qualités sont pour beaucoup communes aux deux approches et l’idée consiste à faire le lien entre la notion de vues fonctionnelles et la notion de composants métiers et d’appliquer les principes de composition de vues au problème de l’assemblage de tels composants. Les bénéfices espérés sont réciproques. Les composants apportent leurs propriétés d’autonomie, d’auto-description, de réutilisation et de dynamicité. La conception par vues apporte quant à elle des règles d’assemblage de vues métiers pour former un SI dans son entier. Dans un premier temps nous présentons, brièvement, les notions de composants et de vues, position- nons notre travail dans ce paysage et introduisons les notions de modèle, méta-modèle et l’approche MDA. Nous détaillons ensuite, dans le deuxième chapitre, le modèle abstrait et le méta-modèle virtuel que nous avons réalisés. Les chapitres suivants présentent respectivement leur mise en œuvre par le profil UML correspondant et le ciblage de l’exemple vers les plates-formes EJB et CCM (IDL3). Enfin, nous discu- tons des perspectives d’évolutions de notre approche que nous pouvons attendre du travail sur le MDA, notamment la version 2.0 d’UML, qui doit introduire la notion de composant, ainsi que les techniques de transformation de modèles. 5
  • 10. 6 Introduction
  • 11. Chapitre 1 Problématique et positionnement 1.1 Composants, ACCORD L’origine des composants logiciels n’est pas nouvelle. Certains pensent qu’ils ont toujours existé sous différentes formes pour la construction de systèmes logiciels [2]. Pour d’autres cette notion est apparue dans les années 70 en réponse à la deuxième crise du logiciel afin de réduire les coûts et d’améliorer la qualité des logiciels [3]. L’idée des composants logiciels s’inspire largement de ce qui existe dans les autres domaines industriels (électronique, automobile...), le but est de pouvoir concevoir une application par assemblage comme on assemble un téléviseur ou une voiture, à l’aide de composants existants en limitant les développements spécifiques au strict minimum. Si cette capacité de réutilisation avait été attribuée à la programmation objet, du fait du très bas niveau de mise en œuvre (celui du code source), elle n’a jamais pu être réellement utilisée sauf pour des structures de données simples (listes, piles, ...) ou pour des traitements très “standard” (comme les services objets communs de CORBA [4]) ainsi que dans le domaine des interfaces hommes- machines (IHM). En se plaçant à un niveau de granularité beaucoup plus important, la conception par composants logiciels doit permettre la réutilisation de structures plus complexes et ce de façon naturelle en les rendant disponibles le plus tôt possible dans le cycle de vie. Ce type de composants, suffisamment complexes pour contenir un certain “savoir faire”, est appelé composant métier. Ce sont eux qui nous semblent le plus intéressant et que nous considérons dans notre approche. Les bénéfices attendus sont multiples : – Diminuer considérablement les coûts et le temps de conception en généralisant la réutilisation ou l’achat de composants déjà réalisés. – Augmenter la fiabilité des logiciels par l’utilisation de composants largement testés. – Faciliter et réduire les coûts de maintenance et d’évolution des systèmes, par le remplacement de composants. – Enfin, rentabiliser les développements par la vente de COTS Component (Commercial-off-the-shelf Component ou composants sur étagère). Il n’y a pas encore de définition consensuelle dans le domaine des composants comme c’est le cas pour les objets. Cependant, la vision minimale suivante est toujours retenue. Un composant logiciel est une unité qui rend des services grâce à des interfaces externes et utilise d’autre services grâce à des interfaces requises. Afin d’obtenir un système complet il faut donc assembler un certain nombre de composants en reliant leurs interfaces externes et leurs interfaces requises. C’est pour cette phase d’assemblage qu’il reste encore beaucoup de problèmes à résoudre. Comment formaliser les connexions entre les composants ? Comment décrire un système dans son ensemble ? Il existe pour répondre à ces questions plusieurs travaux de recherche notamment sur les ADL (Application Definition Language) [5]. Cependant, ils imposent l’utilisation (et donc l’apprentissage) de leur propre langage. D’autres problèmes sont à résoudre si l’on souhaite réellement profiter de la grande promesse 7
  • 12. 8 Chapitre 1. Problématique et positionnement des composants, c’est à dire la réutilisation. En effet, il faut être capable de choisir les composants qui répondent à nos besoins et de savoir si ils sont “compatibles”. Actuellement, la description d’un composant est le plus souvent résumée à la liste de ses interfaces, ce qui est insuffisant pour espérer “comprendre” le composant. Il devient donc indispensable de développer la notion de contrat. Ces contrats doivent décrire les besoins et capacités d’un composant, mais il n’existe pas encore de méthode formelle pour les spécifier. De plus, les méthodes de conception actuelles ne sont pas adaptées [3], elles poussent le plus souvent à spécifier des composants alors qu’ils sont, la plupart du temps, déjà disponibles. Pour répondre à ces problèmes et du fait de l’hétérogénéité des modèles technologiques de composants, une recherche consiste à définir un modèle abstrait commun de composants et d’assemblage par contrats. L’équipe participe à ce titre à un projet national (RNTL ACCORD pour “Assemblage de Composants par Contrats en environnement Ouvert et Réparti”) visant à définir un tel modèle abstrait et ses projections technologiques, en particulier vers CCM et EJB. Pour qu’un modèle de composants permette réellement la réutilisation, il doit fournir les moyens de spécifier des composants génériques et de représenter leur configuration. La généricité est le concept par lequel un composant peut être défini indépendamment des contextes dans lesquels il sera utilisé. La confi- guration, au contraire, permet d’intégrer le composant dans un contexte particulier. Il apparaît donc que ces deux concepts soient indissociables et indispensables. 1.2 Vues, SOP / AOP, Catalysis Dans l’approche CROME [1] qui constitue le point de départ de ce mémoire, le mécanisme des vues permet à chaque utilisateur de manipuler un système avec une vision qui lui est propre, adaptée en fonction de ses besoins. Dans cette approche, le schéma de base correspond aux éléments communs aux différentes fonctions du système. Les schémas vues quant à eux ajoutent au schéma de base un certain nombre d’élé- ments propres à leur fonction. Cette approche permet de tenir compte de l’orthogonalité objets/fonctions. En effet, pour un système donné les objets peuvent intervenir dans plusieurs fonctions et celles-ci peuvent utiliser un certain nombre d’objets. Mais il est évident que tous les objets n’interviennent pas dans toutes les fonctions de même les fonctions n’utilisent pas systématiquement tous les objets [6, 7]. Si l’approche objet permet de découper naturellement le système en entités distinctes, elle ne permet pas de séparer les diffé- rentes fonctions à l’intérieur des objets. Le mécanisme des vues ajoute ce découpage et rend ainsi possible de concevoir les fonctions du système indépendamment des autres tout en garantissant leur compatibilité. Pour illustrer cette orthogonalité, considérons l’exemple d’un système de location de voitures (cf figure 1.1). Grâce à l’approche objet, le découpage en entités distinctes est bien représenté, mais toutes les fonc- tions sont confondues. L’activité de gestion des voitures (transfering, add, remove) , par exemple, n’a pas d’intérêt à considérer la liste des clients. De même, l’activité consistant à rechercher à quelle agence est rat- tachée un client ne doit pas être perturbée par la durée ou le nombre de locations de celui-ci. Une approche “à la CROME” permet de séparer les fonctions du système et permet de les réaliser indépendamment les unes des autres (cf figure 1.2). Les attributs communs à toutes les fonctions sont déclarés dans le plan de base, les autres attributs et méthodes sont déclarés dans le plan où ils sont utilisés. Prenons en exemple la classe Agency, les attributs Name et adresse, qui sont utiles à toutes les fonctions du système, sont déclarés dans le plan de base. L’attribut capacity et les méthodes add, transfering et remove, qui ne servent qu’à la gestion des ressources, sont déclarés dans le plan correspondant. D’autres approches comme l’AOP [8] (Aspect-Oriented Progamming) ou le SOP [9] (Subject-Oriented Programming) permettent de mieux découper les systèmes en “séparant les préoccupations” (sécurité, au- thentification...). Elles suggèrent de développer séparément les différentes fonctions du système puis de les assembler, cette étape est appelée le tissage. Contrairement à la conception par vues, qui s’applique au niveau conception, la programmation par aspects (comme son nom l’indique) est destinée à être utilisée au niveau des langages de programmation. Clarke [9] propose le découpage d’un système en activités au niveau modèle, à l’aide du langage UML. Chaque activité est représentée par un paquetage indépendant. Celui-ci contient uniquement les éléments nécessaires à son activité. Contrairement à l’approche par vues, il n’y a pas de paquetage de référence, si un élément est utile à plusieurs paquetages, il est représenté dans chacun d’eux. L’application complète peut être retrouvée par “l’assemblage” de tous les paquetages au travers d’un jeu d’opérateurs de composition (override, merge, ...), la correspondance entre les différents
  • 13. 1.2. Vues, SOP / AOP, Catalysis 9 Base Agency Client Name Name adresse date own 0..* capacity phone adresse Client* findAll() Car* findAll() Agency location() void transfering(Client c) Client findByDate() void add(Agency a) Client findByName() void remove(Agency a) int nbRenting() manage 0..* reference Car immatriculation 0..* date constructor Rent model From Agency location() due_date Car findByDate() contain return_date 0..* Car findByImmatriculation() int nbRenting() bool free(date from, date to) F IG . 1.1 – Location de voitures - Approche objet
  • 14. 10 Chapitre 1. Problématique et positionnement Agency Client Car Rent att: Name, att: Name, att: date, model, Plan de date, phone, base adresse immatriculation, adresse constructor Plan de mth: findAll mth: location, recherche findByDate, client findByKey Plan de mth: findAll mth: location, recherche findByDate, voiture findByKey Plan de att: capacity gestion des mth: add, resources transfering, remove Plan de mth: free, att: att: From, locations nbRenting maximum_ due_date, duration return_date mth: nbRenting F IG . 1.2 – Location de voitures - Structuration par contextes éléments étant indiquée grâce à un nommage identique dans les différents paquetages. Dans l’approche Catalysis [10], il est également question de découpage fonctionnel. Elle propose le découpage d’un schéma UML (par exemple, d’un système de ventes) en “composants à gros grains” (paiement, base de contact, vente...). D’après les auteurs, avant de penser à réutiliser des composants existants, nous avons besoin d’un modèle spécifiant ce qu’ils font. Malheureusement, actuellement ils ne sont jamais accompagnés d’un tel modèle. L’approche Catalysis diffère de celles de CROME et de [9] par le fait que le découpage n’est pas effectué au niveau des attributs et des méthodes, mais au niveau des classes dans leur intégralité. L’assem- blage des composants est modélisé par les associations qui traversent les frontières des ces composants, c’est à dire, par les associations entre des classes ne faisant pas partie du même composant. Toutes ces approches permettent de mieux structurer le système en fonction de ses activités, mais n’apportent rien au niveau de la généricité. Il n’y a pas de réutilisation dans ces méthodes, tout doit être réévalué d’un système à l’autre. 1.3 Rapprochement vues/composants Nous proposons de considérer les approches composants et vues dans un même modèle, la première apportant le principe de généricité et de configuration, la seconde, une méthode de structuration cohérente et plus riche que l’approche objet traditionnelle. Pour illustrer les bénéfices d’une telle approche, considé- rons l’exemple d’une bibliothèque universitaire (cf figure 1.3). Il est possible de découper ce système en contextes comme nous l’avons fait pour l’exemple précédent (cf figure 1.4). Il apparaît ici clairement qu’un certain nombre de fonctions sont communes aux deux systèmes, même s’ils utilisent des noms différents, et qu’il serait intéressant de pouvoir disposer de composants génériques pour les implémenter. L’approche conception par vues permet de représenter un système à base de composants en associant à chaque composant un schéma vue. Le schéma de base représente le système déjà en place auquel on sou- haite ajouter des fonctions par application de composants. Dans le cas d’un nouveau système, le schéma de base peut représenter le cœur de l’application, c’est à dire la partie “stable”, qui a peu de chance d’évoluer dans le temps. Notre modèle d’assemblage s’inspire donc largement de la notion de vues, cependant il diffère sur
  • 15. 1.3. Rapprochement vues/composants 11 Base Location Team indentifiant name adresse capacity Document* findAll() void transfering(ResourceOwner o) Researcher void add(Document r) name void remove(Document r) arrival_date publishes 1..* 0..* 0..* Document Rent Contain 0..* title From publication_date due_date return_date Location location() Document findByDate() Document findByKey() 0..* int nbRenting() reference bool free(date from, date to) Client Book Periodical name ISBN number inscription_date int nbRenting() F IG . 1.3 – Bibliothèque universitaire - Approche objet Location Client Document Rent Plan de att: adresse, att: Name, att: title, base identifiant inscription_ publication_date date Plan de mth: findAll mth: location, recherche findByDate, document findByKey Plan de att: capacity gestion des mth: add, resources transfering, remove Plan de mth: free, att: att: From, locations nbRenting maximum_ due_date, duration return_date mth: nbRenting F IG . 1.4 – Bibliothèque universitaire - Structuration par contextes
  • 16. 12 Chapitre 1. Problématique et positionnement <<Component>> Search <<ViewClass>> <<ViewClass>> DateResource Location identifiant <<ViewAttibute>> name <<ViewAttribute>> date <<ViewAttribute>> adresse <<ViewAttribute>> store 0..* Location location() DateResource* findAll() DateResource findByDate() DateResource findByKey() F IG . 1.5 – Composant de recherche certains points. Contrairement à un schéma vue qui “importe” systématiquement tous les éléments du schéma de base, un composant vue doit préciser les éléments (classes, attributs, associations) du schéma de base qu’il souhaite manipuler, il les contextualisent. L’interface requise correspond donc à un “schéma requis”, celui-ci est matérialisé par les ViewClass, ViewAttribute et ViewAssociation du composant (cf figure 1.5). Les éléments vues du compo- sant Search indiquent que celui-ci ne pourra s’appliquer qu’à un schéma de base contenant une classe (jouant le rôle de location) contenant au moins deux attributs pour matérialiser les ViewAttribute Name et adresse, et une autre classe (jouant le rôle de DateRessource) avec des attributs matérialisant iden- tifiant et date. Ces deux classes devant être liées par une association pour matérialiser la ViewAssociation store. La définition formelle des éléments vues ainsi que les règles auxquelles ils sont soumis sont détaillées dans le deuxième chapitre de ce mémoire. L’interface externe est quant à elle matérialisée par le schéma constitué des éléments publiques du composant. A partir des exemples précédents, il est possible d’extraire trois fonctions communes : recherche, ges- tion des ressources et location, et d’en faire des composants. Pour cela, il faut les rendre génériques et pouvoir les configurer afin de les appliquer aux deux exemples. Dans notre modèle, la généricité est intro- duite par l’utilisation d’éléments “externes” et la phase de configuration est représentée par un mécanisme de connexion. Les modèles obtenus pour chacun des deux exemples sont représentés figure 1.6 pour l’agence de location de voitures et 1.7 pour la bibliothèque universitaire. L’application d’un composant vue à la base se fait par la connexion entre chaque ViewClass du composant et la classe de la base qui la matérialise. Ces connexions sont représentées sur les figures par les flèches pointillées. Pour être complètes, les connexions doivent également être effectuées entre chaque ViewAttribute et l’attribut de la base qui le matérialise, de même pour les ViewAssociation et les associations (ces connexions ne sont pas représentées par souci de clarté). Les connexions, pour être valides, doivent vérifier un certain nombre de contraintes. Celles- ci sont détaillées pour chaque élément vue dans le deuxième chapitre. On retrouve dans les deux exemples les mêmes composants fonctionnels Search, ResourceManager et Renting, ce qui illustre leur réutilisation sur différentes bases. La généricité permet également d’utiliser le même composant à plusieurs “endroits” de la même application, illustré ici par l’application du composant Search entre Agency et Car et entre Agency et Client dans le premier exemple. De façon conforme à l’approche par vues, les données spécifiques à une fonction particulière du système sont regroupées dans le composant correspondant (la classe Rent par exemple fait partie du composant Renting et non de la base).
  • 17. 1.3. Rapprochement vues/composants 13 <<Component>> Search <<ViewClass>> <<ViewClass>> DateResource Location identifiant <<ViewAttibute>> name <<ViewAttribute>> <<ViewAssociation>> date <<ViewAttribute>> adresse <<ViewAttribute>> store 0..* Location location() DateResource* findAll() DateResource findByDate() DateResource findByKey() <<Component>> Search <<Component>> ResourceManager Base <<ViewClass>> <<ViewClass>> ResourceOwner Location Client Agency identifiant <<ViewAttribute>> name <<ViewAttribute>> Name Name own capacity 0..* date adresse <<ViewAttribute>> adresse phone void transfering(ResourceOwner o) DateResource* findAll() adresse void add(Resource r) <<ViewAssociation>> void remove(Resource r) store manage 0..* <<ViewAssociation>> 0..* <<ViewClass>> manage Car DateResource 0..* immatriculation identifiant <<ViewAttibute>> date <<ViewClass>> date <<ViewAttribute>> constructor Resource Location location() model identifiant <<ViewAttribute>> DateResource findByDate() DateResource findByKey() <<Component>> Renting Rent From due_date return_date 0..* 0..* contain reference <<ViewClass>> <<ViewClass>> Product Client identifiant <<ViewAttribute>> identifiant <<ViewAttibute>> maximum_duration int nbRenting() bool free(date from, date to) int nbRenting() F IG . 1.6 – Location de voitures - Approche composants vues
  • 18. 14 Chapitre 1. Problématique et positionnement <<Component>> ResourceManager <<ViewClass>> ResourceOwner <<ViewClass>> <<ViewAssociation>> Resource identifiant <<ViewAttribute>> capacity identifiant <<ViewAttribute>> store 0..* void transfering(ResourceOwner o) void add(Resource r) <<Component>> Search void remove(Resource r) <<ViewClass>> Base Location name <<ViewAttribute>> adresse <<ViewAttribute>> Location Team DateResource* findAll() indentifiant adresse name <<ViewAssociation>> store 0..* <<ViewClass>> 0..* DateResource Researcher Document identifiant <<ViewAttribute>> name title 0..* publishes 1..* date <<ViewAttribute>> arrival_date AddToBase publication_date Location location() Client DateResource findByDate() DateResource findByKey() name inscription_date Book Periodical ISBN number <<Component>> Renting Rent From due_date return_date 0..* 0..* contain reference <<ViewClass>> <<ViewClass>> Product Client identifiant <<ViewAttribute>> identifiant <<ViewAttibute>> int nbRenting() int nbRenting() bool free(date from, date to) F IG . 1.7 – Bibliothèque universitaire - Approche composants vues
  • 19. 1.4. Modèle, Méta-Modèle, MDA 15 Il existe des entités qui Niveau M3 Méta-méta-modèle peuvent avoir des relations entre elles Une classe désigne un Niveau M2 Méta-modèle ensemble d’objets qui peuvent avoir des attributs Une voiture a une couleur Niveau M1 Modèle et une immatriculation Cette voiture Niveau M0 Instances rouge immatriclée 12 XY 59 F IG . 1.8 – Les quatre niveaux de modélisation 1.4 Modèle, Méta-Modèle, MDA Nous décrivons notre modèle abstrait à l’aide d’un méta-modèle, nous introduisons donc ici les bases des techniques de modélisation et de méta-modélisation avant de le détailler. Les méthodes de méta- modélisations sont basées sur quatre couches [11] (cf figure 1.8). Chaque niveau est décrit à l’aide du niveau supérieur. Le niveau M0 correspond à celui des instances, aux données réellement manipulées. C’est, par exemple, à ce niveau qu’est décrit une voiture particulière, immatriculée ’12 XY 59’, de couleur rouge... Le niveau M1 est celui des modèles, c’est lui qui est utilisé pour concevoir un logiciel. Un diagramme écrit en UML correspond à ce niveau. Pour reprendre notre exemple, c’est le niveau qui définit le type voiture, qu’elle doit avoir une immatriculation, une couleur... On ne décrit pas une voiture en particulier mais son concept. Le niveau M2 est le niveau des méta-modèles, c’est par exemple à ce niveau qu’est décrite la syntaxe du langage UML, le fait qu’une classe a un nom, qu’elle est composée d’attributs... Le dernier niveau, M3, a la particularité de se décrire lui même. Il serait sinon possible d’avoir une infinité de niveaux. Ce niveau est celui des méta-méta-modèles, c’est certainement le niveau le plus difficile à comprendre. Il permet de décrire le niveau M2, qu’il existe des entités (classes, attributs...) qui peuvent avoir des relations entre elles. Pour résumer, on peut dire que le niveau M0 correspond à une application en cours d’exécution, le niveau M1 au schéma UML d’une application en particulier, le niveau M2 à la façon de représenter une application en général et enfin le niveau M3 à introduire les concepts nécessaires au niveau M2. Il existe deux grandes techniques de méta-modélisations, le MOF (Meta Object Facilities) [12] et les profils UML. Le MOF est un langage de niveau M3, il permet donc d’introduire de nouveaux concepts pour le niveau M2. La méta-modélisation par profils est une technique plus “légère” prévue par le langage UML, elle ne permet pas vraiment d’introduire de nouveaux méta-concepts mais de spécialiser, en les étiquetant par des “stéréotypes”, les méta-concepts existants. L’approche MDA (Model Driven Architecture) [13, 14, 15] de l’OMG (Object Managment Group) [16] définit une méthode de conception basée sur les modèles permettant d’obtenir à partir d’un schéma de base unique sa réalisation sur n’importe quelle plate-forme (supportée par le MDA). La principale motivation est de rester indépendant d’un système donné afin de suivre l’évolution des technologies et des intergiciels sans perdre ce qui a déjà été réalisé. Pour obtenir ce résultat, le MDA introduit deux types de modèles : les PIMs (Platform Independent Model) qui doivent représenter l’application en utilisant uniquement des concepts indépendants de toutes plates-formes, et les PSMs (Platform Specific Model) qui sont des projections des PIMs pour une plate- forme donnée. Nous avons réalisé dans le cadre du projet ACCORD un état de l’art de l’approche MDA, celui-ci est disponible en annexe de ce mémoire. En proposant une approche qui définit un modèle de composants abstraits (PIM) tout en permettant sa projection vers des plates-formes existantes (PSM), nous respectons la philosophie du MDA. De plus, en utilisant l’UML et les profils, nous sommes “compatibles” avec les choix technologiques de l’OMG, ce qui facilite l’utilisation de notre modèle (outils, XMI...). La figure 1.9 illustre l’articulation des différents modèles dans notre approche. L’interconnexion de nos composants au niveau PIM permet l’interopérabilité au niveau binaire.
  • 20. 16 Chapitre 1. Problématique et positionnement View UML Base UML connexion vérification des contraintes PIM PSM Modèle CCM avec XML+ associations IDL Java XML Binaire Binaire Base Binaire Base Binaire CCM EJB(++) CCM EJB(++) BDR F IG . 1.9 – Application de MDA
  • 21. Chapitre 2 Le modèle abstrait 2.1 Le méta-modèle La figure 2.1 représente les concepts du modèle de composant vues. Ce méta-modèle introduit la notion de connexions entre un élément et sa vue, grâce aux associations viewOf et root. Les sémantiques de ces deux types de relation sont différentes. Une association viewOf indique que l’élément source (de type Component ou ViewClass) est une extension de l’élément qu’il désigne (respectivement de type Package ou Class). Par contre, une association root signifie que l’élément source (de type ViewAttribute ou ViewAssociation) n’est qu’une représentation de l’élément désigné (respectivement de type Attribute ou Association). Dans ce modèle, un composant est donc un ensemble de ViewClass et de Class que l’on peut appliquer à un ensemble (Package) de Class. Grâce au mécanisme de connexions, un composant peut être modélisé indépendamment des Package sur lesquelles il sera appliqué. Les seuls règles à suivre lors de cette phase de modélisation sont décrites par les règles de conception, néanmoins pour que le système obtenu par la “fusion” des Package et des Component soit cohérent, les règles de connexion doivent être vérifiées. Ce découpage correspond respectivement aux phases de conception et d’assemblage du composant. Les contraintes OCL sont présentées pour chacun des concepts à la fin de ce chapitre. 2.2 Description des éléments Component Un Composant est une spécialisation de la méta-classe UML Package. Son rôle est de regrouper toutes les ViewClass, Class ainsi que tout autre élément UML nécessaire à la modé- lisation du composant. ViewClass Une ViewClass est une spécialisation de la méta-classe UML Classifier. Une instance de celle-ci peut contenir les mêmes éléments qu’un autre Classifier ainsi que des ViewAttribute. L’association viewOf (entre une ViewClass et une Class) indique dans quelle Class les Attribute racine (root) des ViewAttribute de la ViewClass doivent se trouver. Pour reprendre l’analogie avec la structuration par contextes, une Class correspond au plan de base et, une ViewClass qui lui est connectée correspond à son extension dans un autre plan. ExternalFeature et ExternalStructuralFeature Une ExternalFeature est un élément abstrait consti- tuant d’un Classifier au même titre qu’une StructuralFeature ou qu’une BehavioralFeature, son rôle est de désigner, par l’association root, une autre Feature. L’élément ExternalStructuralFeature spécialise ExternalFeature en imposant une StructuralFeature comme racine (root). 17
  • 22. 18 Chapitre 2. Le modèle abstrait Component Package (from UML) 0..* +viewOf AssociationEnd (from UML) 0..* isNavigable * Association (from UML) ordering Classifier (from UML) +connection aggreagation +participant +association targetScope 2..* * * multiplicity changeability +specification +specifedEnd visibility +root 0..1 0..* 0..* +owner ViewAssociation +type +feature Feature (from UML) ownerScope ViewClass Class (from UML) 0..* visibility isActive +viewOf connection 0..* +root 0..* StructuralFeature (from UML) ExternalFeature multiplicity changeability targetScope ExternalStructuralFeature Attribute (from UML) initialValue ViewAttribute F IG . 2.1 – Le méta-modèle Ce sont les éléments de base de notre modèle, qui permettent “d’importer” des données de l’exterieur et qui permettent ainsi la conception du composant. ViewAttribute Un ViewAttribute est un ExternalStructuralFeature dont le lien racine (root) ne peut porter que sur un Attribute. Un ViewAttribute ne peut appartenir qu’à une ViewClass. C’est le seul élément de type ExternalFeature qui ne soit pas abstrait, donc le seul à pouvoir apparaître dans un modèle de conception. ViewAssociation Une ViewAssociation est une spécialisation de la méta-classe UML Association. Une instance de celle-ci permet de contextualiser une Association du Package auquel s’ap- plique (par le lien viewOf) le Component. Une ViewAssociation est utilisée dans un composant pour “imposer” et manipuler l’Association conrrespondante entre les classes de la base. 2.3 Contraintes OCL ExternalFeature et ExternalStructuralFeature Contraintes de conception [1] La racine d’un ExternalStructuralFeature doit être un StructuralFeature. self.root.oclIsKindOf(StructuralFeature);
  • 23. 2.3. Contraintes OCL 19 ViewClass Contraintes de conception [2] Toutes les ViewClass doivent être dans un Component. self.package.oclIsKindOf(Context); Contraintes de connexion [3] Tous les ViewAttribute d’une ViewClass doivent avoir le même propriétaire de leur racine que la viewOf. self.allFeatures->select( f | f.oclIsKindOf(ViewAttribute) ) ->forAll ( f : ViewAttribute | f.root.owner = self.viewOf ); ViewAttribute Contraintes de conception [4] Le propriétaire d’un ViewAttribute doit être une ViewClass. self.owner.oclIsKindOf(ViewClass); Contraintes de connexion [5] Le propriétaire de la racine d’un ViewAttribute doit être une Class. self.root.owner.oclIsKindOf(Class); ViewAssociation Contraintes de conception [6] Une ViewAssociation ne peut être que dans un Component self.namespace.oclIsKindOf(Context); Contraintes de connexion [7] S’il existe dans le Component une ViewClass dont la viewOf participe à ViewAssociation.root alors cette ViewClass participe à la ViewAssociation. self.namespace.allContents->select( v | v.oclIsKindOf(ViewClass) ) ->forAll( v : ViewClass | self.root.allConnections->collect( type ) ->includes(v.viewOf) implies self.allConections->collect( type ) ->includes(v)); Component Contraintes de connexion [8] Toutes les ViewClass d’un Component doivent avoir le même Package de leur viewOf que la viewOf du Component. self.allReferencedElements->select( v | v.oclIsKindOf(ViewClass) ) ->forAll ( v : ViewClass | v.viewOf.package = self.viewOf ); [9] Il ne peut pas y avoir deux ViewClass de la même Class dans un Component self.allReferencedElements->select( v | v.oclIsKindOf(ViewClass) ) ->forAll ( v1, v2 : ViewClass | not v1.viewOf = v2.viewOf );
  • 24. 20 Chapitre 2. Le modèle abstrait [10] Si deux ViewClass (v1, v2) sont dans le même Component et qu’il y a une Association entre v1.viewOf et v2.viewOf alors il y a une ViewAssociation entre v1 et v2 self.allReferencedElements->select( v | v.oclIsKindOf(ViewClass) ) ->forAll ( v1, v2 : ViewClass | v1.viewOf.allAssociations ->intersection(v2.viewOf.allAssociations)->size = v1.allAssociations->intersection(v2.allAssociations) ->select( va | va.oclIsKindOf(ViewAssociation) )->size);
  • 25. Chapitre 3 Réalisation du Profil UML Comme il a été présenté dans le premier chapitre, il existe deux méthodes de méta-modèlisation, le MOF et les profils. Nous présentons ici la réalisation de notre modèle abstrait grâce aux profils. Vous pour- rez trouver en annexe, la réalisation de celui-ci avec l’outil Objecteering de la société Softeam, partenaire du projet ACCORD. Actuellement, le langage OCL n’est pas supporté par cet outil, les contraintes ont donc été traduites en J1 , le langage spécifique à Objecteering. Le module résultant de cette réalisation (cf figure 3.7), utilisable avec la version gratuite d’Objecteering, est disponible en ligne. (http ://www.lifl.fr/ mullera/ViewComponents.prof).   3.1 Identification du sous-ensemble UML Le profil de composant vues étend le paquetage UML core en se basant sur les méta-classes suivantes : – Package – Classifier – Feature – Class – StructuralFeature – Attribute – Association – Dependency 3.2 Les éléments du profil Les ExternalFeature et ExternalStructuralFeature sont représentées dans notre profil UML par une Feature stéréotypée respectivement par «ExternalFeature» et «ExternalStructuralFeature». La valeur marquée de nom root s’applique au stéréotype «ExternalFeature» ainsi qu’aux stéréotypes héritant de celui-ci («ExternalStructuralFeature» et «ViewAttribute»). La valeur de type chaîne de caractères associée à ce tag contient le nom de la Feature racine de l’élément. Cette valeur marquée est indispensable pour représenter la connexion. Une ViewClass est représentée dans notre profil par une Class stéréotypée par «ViewClass». L’as- sociation entre une ViewClass et la Class à laquelle elle se réfère est représentée par une Dependency entre elles stéréotypée par «viewOf». 1 Disponible en annexe 21
  • 26. 22 Chapitre 3. Réalisation du Profil UML Stéréotype s’applique à Définition «ExternalFeature» Feature Indique que la Feature est externe. «ExternalStructural Feature Spécialise «ExternalFeature». Feature» Indique que la racine porte sur un élément structurel. Tag s’applique à Définition root «ExternalFeature» Nom d’une Feature Désigne la racine de l’élément. TAB . 3.1 – Stéréotypes et valeurs marquées pour les méta-types ExternalFeature et ExternalStructuralFeature. <<baseElement>> Feature {From UML} «stereotype» ExternalFeature <<tagged value>> root: string <<baseElement>> «<<stereotype>>» ExternalStructuralFeature <<baseElement>> «stereotype» ViewAttribute F IG . 3.1 – Méta-modèle virtuel des ExternalFeature Stéréotype s’applique à Définition «ViewClass» Class Indique que la Class est une vue. «viewOf» Dependency Permet d’indiquer une dépendance entre une classe et sa vue. TAB . 3.2 – Stéréotypes pour le méta-type ViewClass. Classifier {From UML} <<baseElement>> «stereotype» ViewClass F IG . 3.2 – Méta-modèle virtuel des ViewClass Un ViewAttribute est représenté par un Attribute UML stéréotypé par «ViewAttribute». En spécialisant «ExternalStructuralFeature», le stéréotype «ViewAttribute» hérite de la valeur marquée root, qui doit ici contenir le nom d’un Attribute.
  • 27. 3.2. Les éléments du profil 23 Dependency {From UML} <<baseElement>> «stereotype» viewOf F IG . 3.3 – Méta-modèle virtuel des viewOf Stéréotype s’applique à Définition «ViewAttribute» Attribute Spécialise «ExternalStructuralFeature». Indique que l’attribut est une vue. TAB . 3.3 – Stéréotype pour le méta-type ViewAttribute. Attribute {From UML} <<baseElement>> «stereotype» ViewAttribute F IG . 3.4 – Méta-modèle virtuel des ViewAttribute Une ViewAssociation est représentée par une Association UML stéréotypée par «ViewAssociation». Une valeur marquée de nom root lui est appliquée. La valeur de type chaîne de caractères associée à ce tag contient le nom de l’Association racine. Celle-ci permet de manipuler, dans le composant, l’association définie dans le paquetage de base. Stéréotype s’applique à Définition «ViewAssociation» Association Indique que l’association est une vue. Tag s’applique à Définition root «ViewAssociation» Nom d’une Association Désigne la racine de la ViewAssociation. TAB . 3.4 – Stéréotypes et valeurs marquées pour le méta-type ViewAssociation. Association {From UML} <<baseElement>> «stereotype» ViewAssociation <<tagged value>> root: string F IG . 3.5 – Méta-modèle virtuel des ViewAssociation Un composant est représenté par un Package UML stéréotypé par «Component». Son application à un Package est représenté par une Dependency entre eux stéréotypée par «viewOf».
  • 28. 24 Chapitre 3. Réalisation du Profil UML Stéréotype s’applique à Définition «Component» Package Indique que le Package est un composant vue. «viewOf» Dependency Permet d’indiquer un dépendance entre un paquetage et un composant. TAB . 3.5 – Stéréotypes pour le méta-type Component. Package {From UML} <<baseElement>> «stereotype» Component F IG . 3.6 – Méta-modèle virtuel des Component F IG . 3.7 – Le module Objecteering
  • 29. Chapitre 4 Ciblage Pour tester notre modèle, nous avons mis en œuvre l’exemple de la bibliothèque universitaire présentée dans le premier chapitre sur les plates-formes CCM et EJB. La première réalisation (vers CCM) ne produit pas de code éxecutable, uniquement les spécifications (IDL 3) mais elle est entièrement automatisée. La seconde (vers EJB) n’a pas fait l’objet d’une automatisation, mais a été entiérement spécifiée. Les sections suivantes présentent ces travaux. 4.1 Du modèle abstrait aux composants CCM Nous proposons ici une génération automatique des descriptions UML des composants vues vers des composants CCM. Plus précisément, l’atelier UML génère : – La spécification IDL3 des composants CCM issus d’un composant de base. – La spécification IDL3 des composants CCM issus d’un composant vue. – La spécification IDL3 des composants CCM d’assemblage entre un composant vue et un composant de base. Après une description succinte du modèle de composants CORBA (cf 4.1.1), nous détaillons les différentes règles de transformation d’un schéma UML profilé vers la spécification IDL3 (cf 4.1.2). 4.1.1 Le modèle de composants CORBA Les modèles à objets ont progressivement montré leurs limites. Certains industriels, comme Microsoft, Sun et l’OMG, ont fait évoluer leurs modèles vers les composants, dans le but de simplifier le dévelop- pement d’applications. La réponse de l’OMG [16] est le "CORBA Component Model" (CCM) modèle de base du futur standard CORBA 3 [17, 18, 19]. Dans un but de compatibilité ascendante, l’OMG a défini son modèle de composants comme une extension du modèle objet de CORBA 2. Les composants CORBA représentent donc une spécialisation des objets CORBA tels que nous les connaissons aujourd’hui. La spé- cification de ce standard n’est pas encore achevée ; cependant, le chapitre sur le modèle de composants a été finalisé à l’OMG en janvier 2002. C’est donc l’un des plus jeunes modèles de composants mais aussi l’un des plus riches en comparaison avec d’autres modèles. La spécification du CCM, qui représente plus de 1000 pages, est découpée en quatre modèles et un méta-modèle. Ce document décrit : Le modèle abstrait offre aux concepteurs le moyen d’exprimer les interfaces (fournies et utilisées) et les propriétés d’un type de composant. Pour cela, le langage OMG IDL a été étendu pour prendre en compte les nouveaux concepts introduits dans le CCM (le langage IDL3). Un type de composant (component) regroupe la définition d’attributs et de ports. Les attributs représentent les propriétés 25
  • 30. 26 Chapitre 4. Ciblage configurables du type de composant. Un port représente une interface (au sens CORBA 2) soit four- nie, soit requise, par le type de composant. Quatre types de ports sont définis dans le contexte du CCM : – Une facette est une interface fournie par un type de composant et qui est utilisée par des clients en mode synchrone. – Un réceptacle est une interface utilisée par un type de composant en mode synchrone. – Un puit d’événement est une interface fournie par un type de composant et utilisée par ses clients en mode asynchrone. – Une source d’événement est une interface utilisée par un type de composant en mode asynchrone. La figure 4.1 illustre un composant abstrait CCM doté de plusieurs ports. Référence de Réceptacle Composant Composant CCM Composant Implémentation Références des facettes Puit d’événement de facettes Source d’événement Composant Attributs F IG . 4.1 – Composant abstrait CCM Le modèle de programmation spécifie le langage CIDL (Component Implementation Definition Lan- guage) à utiliser pour définir la structure de l’implantation d’un type de composant, ainsi que cer- tains de ses aspects non-fonctionnels (persistance, transactions, sécurité). L’utilisation de ce langage est associée à un framework, le CIF (Component Implementation Framework), qui définit comment les parties fonctionnelles (programmées) et non-fonctionnelles (décrites en IDL / CIDL et générées) doivent coopérer. Il inclut aussi la manière dont l’implantation d’un composant interagit avec le conteneur. Le modèle de déploiement définit un processus qui permet d’installer une application sur différents sites d’exécution de manière simple et automatique. Ce modèle s’appuie sur l’utilisation de paquetages de composants, ainsi que de descripteurs OSD (Open Software Description, un vocabulaire XML), les paquetages étant déployables et composables. Le modèle d’exécution définit l’environnement d’exécution des instances de composants. Le rôle princi- pal des conteneurs est de masquer et prendre en charge les aspects non-fonctionnels des composants qu’il n’est alors plus nécessaire de programmer. 4.1.2 Règles de transformation Pour la génération automatique, nous nous sommes basés sur le langage IDL3 permettant de décrire le modèle abstrait CCM. De plus, nous nous sommes interressés uniquement aux ports synchrones du modèle (facettes et réceptacles). Génération du composant de base Le tableau 4.1 énumère la transformation de chaque concept UML vers des concepts IDL3. Un com- posant de base défini par un paquetage UML est spécifié par un module CCM.
  • 31. 4.1. Du modèle abstrait aux composants CCM 27 Chaque classe UML de ce paquetage est spécifiée par un composant CCM, ce composant dispose d’une facette décrite par une interface IDL contenant toutes les descriptions publiques (attributs et opérations) de la classe UML. Les attributs d’une classe sont transformés en attributs primitifs CORBA (l’atelier UML vérifiant que les attributs définis dans le modèle sont des attributs simples). Ces attributs sont spécifiés dans l’interface cor- respondante à l’unique facette du composant CCM. Les opérations UML sont également transformées en opérations contenues dans l’interface IDL de la fa- cette du composant Les associations sont exprimées par des opérations primitives de manipulation de l’association (add, get , remove) définies dans l’interface IDL correspondante à la facette du composant. ces associations sont également gérées par l’introduction de réceptacles au niveau des composants participants à l’association (l’atelier UML se limite aux associations binaires) Concept modèle abstrait UML spécification IDL3 correspondante paquetage UML X module CCM X classe X component X doté d’une facette de nom serviceX de l’interface IX et d’une maison de composant homeX attributs publiques UML attributs IDL3 dans l’interface IX opérations publiques UML opérations IDL3 dans l’interface IX association UML opérations de gestion des associations, réceptacle pour l’extrémité de l’association. TAB . 4.1 – Correspondance composant UML de base et composants CCM Exemple : Nous illustrons cette génération par l’exemple de la bibliothèque universitaire et en se limitant aux classes UML Location et Document reliée par une association de nom manage, la spé- cification IDL3 générée par l’atelier UML est la suivante : module Base { interface ILocation ; interface IDocument ; typedef sequence<IDocument> IDocuments ; interface ILocation { attribute string identifiant ; attribute string adresse ; public void addManage(IDocument value) ; public IDocuments getManage() ; public void removeManage(IDocument value) ; } ; interface IDocument { attribute string title ; attribute string publication_date ; public void setManage(ILocation value) ; public ILocation getManage() ; public void removeManage() ; } ; component Location { provides ILocation serviceLocation ; uses multiple IDocument manage ; } ;
  • 32. 28 Chapitre 4. Ciblage component Document { provides IDocument serviceDocument ; uses ILocation manage ; } ; home LocationHome manages Location { } ; home DocumentHome manages Document { } ; } ; Génération du composant vue Pour un composant vue, les règles de transformation définies pour un composant de base sont intégra- lement applicables pour les constructions UML standards. Le tableau 4.2 énumère la transformation de chaque concept UML étendu (viewClass, viewAttribute, . . .) vers des concepts IDL3. Une classe «viewClass» est spécifiée par un composant CCM, ce composant dispose d’une fa- cette décrite par une interface IDL contenant toutes les descriptions publiques (attributs et opérations) de la classe UML et dispose d’un réceptacle correspondant à toutes les descriptions requises (constructions «viewAttribute» et «viewAssociation»). Concept modèle abstrait UML spécification IDL3 correspondante «viewClass» X component X dotée d’une facette de nom serviceX de l’interface IX et d’un réceptacle de nom receptX de l’interface RX et d’une maison de composant homeX «viewAttribute» spécifié dans l’interface IX si public spécifié dans l’interface RX «viewAssociation» opérations de manipulation de l’association spécifiés dans l’interface IX et RX TAB . 4.2 – Correspondance composant UML vue et composants CCM Exemple : Pour illustrer la spécification IDL3 suivante décrit le composant vue resourceManager : module ResourceManager { interface IResourceOwner ; interface IResource ; typedef sequence<IResource> IResources ; interface IResourceOwner { attribute string identifiant ; attribute long capacity ; public void addStore(IResource value) ; public IResources getStore() ; public void removeStore(IResource value) ; public void transfering(IResourceOwner o) ; } ; interface RResourceOwner { attribute string identifiant ; public void addStore(RResource value) ; public RResources getStore() ; public void removeStore(RResource value) ;
  • 33. 4.1. Du modèle abstrait aux composants CCM 29 } ; interface IResource { attribute string identifiant ; public void setStore(IResourceOwner value) ; public IResourceOwner getStore() ; public void removeStore() ; } ; interface RResource { attribute string identifiant ; public void setStore(RResourceOwner value) ; public RResourceOwner getStore() ; public void removeStore() ; } ; component ResourceOwner { provides IResourceOwner serviceResourceOwner ; uses RResourceOwner receptResourceOwner } ; component Resource { provides IResource serviceResource ; uses RResource receptResource ; } ; home ResourceOwnerHome manages ResourceOwner { } ; home ResourceHome manages Resource { } ; } ; Génération du composant d’assemblage Comme l’illustre les exemples, composants de bases et composants vues sont parfaitement indépen- dants. Les constructions UML détaillant la connexion d’un composant vue à un composant de base vont permettre de générer les composants CCM d’assemblage : ce sont en fait, des composants adaptateurs qui vont permettre de relier un réceptacle d’un composant CCM vue à la facette du composant CCM de base. Le pattern classique adaptateur [20] est utilisé pour les connexions comme le montre le code exemple suivant permettant de connecter un composant vue X à un composant de base Y : component AdaptX_Y { provides RX serviceAdaptX ; uses IY receptAdaptY ; } Exemple : voici l’exemple du composant d’assemblage permettant de connecter le composant vue ResourceManager au composant de base Base de la bibliothèque universitaire : import ResourceManager ; import Base ; module adapt { component AdaptResourceOwner_Location {
  • 34. 30 Chapitre 4. Ciblage provides ResourceManager::RResourceOwner serviceAdaptResourceOwner ; uses Base::Ilocation receptAdaptLocation ; } ; component AdaptResource_Document { provides ResourceManager::RResource serviceAdaptResource ; uses Base::IDocument receptAdaptDocument ; } ; home AdaptResourceOwner_LocationHome manages AdaptResourceOwner_Location {} ; home AdaptResource_Documenthome manages AdaptResource_Document {} ; 4.2 Du modèle abstrait aux composants EJB Dans cette section, nous présentons une seconde projection des composants de notre modèle abstrait. Il s’agit d’une projection vers la plate-forme EJB qui propose des composants orientés vers le développe- ment d’applications au-dessus d’un système d’informations d’entreprise. En plus de proposer des règles pour générer la spécification, des composants, cette projection introduit aussi des règles pour produire leur implantation. La projection proposée produit le code Java d’implantation de composants EJB correspondant aux classes ViewClass d’un composant connecté à un composant de base au niveau modèle. Un composant de notre modèle sera matérialisé par une archive empaquetant ces composants EJB avec des descripteurs de déploiement1. Les composants EJB résultant de la projection présentent les caractéristiques suivantes 2 . – Ils sont connectables localement ou à distance avec des composants EJB implantant les classes du composant de base pour lesquels la connexion a été vérifiée ; – Ils mettent en oeuvre des traitements pour préserver la sémantique de vues à l’exécution ; – Ils sont manipulables pour les outils EJB standard d’empaquetage et de déploiement sur un serveur. – Ils définissent un schéma abstrait de persistance qui permet de définir un descripteur pour leur sau- vegarde (état, associations) dans une base de donnée quelconque. Dans la prochaine section, nous présentons les grandes lignes de la norme EJB. Cette partie permettra d’introduire les notions utilisées lors de la projection. Ces notions sont illustrées en implantant le composant de base de la bibliothèque sous forme de composants EJB. La section suivante décrit le choix de mise en oeuvre et les règles de générations qui en découlent pour les composants vues. 4.2.1 Le modèle de composants EJB La norme EJB (Enterprise Java Bean) a été proposée par SUN Microsystems pour répondre aux be- soins de l’industrie en matière de construction de serveurs d’applications d’entreprise. Cette norme (qui en est à sa version 2.0) décrit une architecture normalisée pour le développement et le déploiement de ces applications à base de composants "Bean" écrits en Java. L’apport principal de cette norme est d’accorder une grande importance à la prise en change des aspects non fonctionnels requis par les composants de ce type d’applications à savoir la persistance des données, la sécurité et la gestion des transactions. Cette prise en charge permet au développeur de se concentrer sur les aspects métiers de ces composants. Un composant EJB est un ensemble de définitions JAVA (interfaces et classes) et des descripteurs XML empaquetés - dans une archive de type jar - qui sont déployés sur un serveur d’applications. Le serveur 1 dans sa version actuelle, la projection ne produit pas le descripteur de déploiement des composants EJB mais cette opération est tout à fait envisageable 2 La production de composants EJB qui seraient génériques par rapport à plusieurs composants de base implantées avec des composants EJB est envisageable mais réclame l’utilisation d’outils puissants comme la réflexivité. Nous laissons l’étude de tels composants pour des travaux futurs
  • 35. 4.2. Du modèle abstrait aux composants EJB 31 utilise les informations contenues dans le descripteur pour instancier le composant EJB dans un container dont la fonction est de fournir une interface entre le composant et son environnement, prenant en charge un certain nombre d’aspects non-fonctionnels. F IG . 4.2 – L’architecture EJB Un composant EJB offre des services exposés aux clients sous la forme d’une interface Java de type EJBObject (pour des client distants) ou EJBLocalObject (pour des clients locaux, c’est-à-dire s’exécutant dans la même machine virtuelle). Un client d’un EJB peut être n’importe quel programme susceptible de communiquer par le protocole RMI-IIOP et notamment un autre EJB ou encore un ensemble de servlet et de pages JSP. Le container se charge de transformer les requêtes distantes du client en appels réels aux composants, en les enveloppant éventuellement dans un contexte transactionnel. Le code suivant présente l’interface de services proposée par des composants EJB implantant respecti- vement la classe Document et la classe Location appartenant au composant de base de notre exemple. Les méthodes spécifiées par chaque interface donne accès aux attributs et aux associations définis à ce niveau. public interface Document extends EJBLocalObject { public String getDocumentId(); public String getTitle(); public void setTitle(String title); public Date getPublicationDate(); public void setPublicationDate(Date d); public Location getLocation(); public void setLocation(Location loc); public Collection getAuthors(); public void addAuthor(Researcher r); } public interface Location extends EJBLocalObject { public String getLocationId(); public String getAddress(); public void setAddress(String a); public Collection getDocuments(); public void addDocument(Document d); } A chaque composant EJB est également associée une maison de composant qui est chargée de la construction effective des composants, de leur destruction et éventuellement de leur recherche. Ces mai- sons correspondent à la notion bien connue de fabrique. Elles sont généralement localisables par un client,
  • 36. 32 Chapitre 4. Ciblage par exemple au travers d’un service de nommage, et offre une interface uniforme de type EJBHome (des- tinée aux clients distants) ou EJBLocalHome (destinée aux clients locaux) pour la gestion des instances de composants associés. Le code suivant présente les interfaces de fabrique pour la création (méthodes de nom "create") et la recherche (méthodes ayant un nom préfixé par "find") d’instances de composants EJB implantant respecti- vement la classe Document et la classe Location du composant de base. public interface LocalDocumentHome extends EJBLocalHome { public Document create(String id, String title, Date publication Date) throws CreateException; public Document create(String id, String title, Date publicationDate, Location loc) throws CreateException; public Document findByPrimaryKey(String id) throws FinderException; public Document findByDate(Date d) throws FinderException; } public interface LocationHome extends EJBLocalHome { public Location create(String id, String address) throws CreateException; public Location findByPrimaryKey(String id) throws FinderException; } La norme EJB définit trois types de composants qui se différentient principalement par rapport à leur utilité et la gestion de leur cycle de vie par le conteneur : il s’agit des beans "session", des beans "orientés message" (message-driven) et des beans "entité". Les bean "session" sont des composants existants pour une session demandée par le client. Ils peuvent être avec état ou sans état ce qui, dans ce dernier cas, permet au conteneur de les partager entre plusieurs clients (sous forme de pool). Les beans "orientés message" sont des réceptables de messages asynchrones gérés par file d’attente. Les beans "entité" sont des composants représentant des données d’une base de données dont ils permettent d’obtenir une vue orientée objet. Etant donné que les beans "entité" sont les seuls beans à être employés lors de la projection, nous nous focalisons sur les caractéristiques de ce type de bean dans le reste de la présentation, notamment ceux qui sont liées à la gestion de la persistance. L’association des beans "entité" avec les éléments d’une base de données leur confère deux caractéris- tiques principales. La première caractéristique est d’être identifié de manière unique par un clé primaire. La présence de cette clé permet aux clients de rechercher un bean entité donné par sa clé primaire. Il suffit pour cela que le client s’adresse à la maison liée au bean. Cette clé primaire peut-être n’importe quel objet sérialisable. La seconde caractéristique est d’être persistant ce qui signifie que l’état du bean et ses associations avec d’autres beans peuvent être sauvegardés dans la base de données. Pour la gestion de cette persistance, la norme EJB propose deux approches : une gestion par le bean et une gestion par le conteneur que nous privilégions. Dans ce second cas, le container collabore avec le gestionnaire de la base pour mettre en oeuvre un schéma de persistence qui leur est fourni au travers du descripteur de bean. Schématiquement, le descripteur définit des sources de données, des champs de données et des relations (à la manière d’un schéma de base de données) qui sont identifiés au niveau de la classe d’implantation du bean par des méthodes d’accès abstraites nommées selon des conventions particulières. Il appartient au conteneur et au gestionnaire de la base de créer et de mettre à jour effectivement et automatiquement les données lors de la création et l’exécution des beans. Le code suivant présente les classes d’implantation des composants EJB Document et Location (sans code d’implantation pour plus de clarté). Ces classes héritent de EntityBean pour indiquer que ceux sont