Approche composant de la spécification à limplantation

Pour que diérents composants puissent être déployés et tra-vailler ensemble, ils doivent pouvoir coopérer, c'est-à-dire que leurs interfaces doivent êtrecompatibles.Mon travail de stage

Nancy, le 14 novembre 2008

LORIANancy, France

Institut de la Francophonie pour l'Informatique

Hanoi, Vietnam

Approche Composant :

de la spécication à l'implantation

Mémoire de n d'étudesThi Minh Tuyen Nguyen

Lieu de stage : Équipe DEDALE, LORIA

Campus Scientique, BP 239F-54506 Vand÷uvre lès Nancy Cedex

Sous la direction de : Arnaud Lanoix

Jeanine Souquières

Je voudrais tout d'abord remercier Jeanine Souquières de m'avoir accueillie au sein del'équipe de recherche DEDALE du Laboratoire Lorrain de Recherche en Informatique et sesApplications (LORIA)

Je tiens également à remercier tout particulièrement Arnaud Lanoix et Jeanine Souquièrespour m'avoir encadrée pendant ces neuf mois Je les remercie de leur contact chaleureux, leursconseils et encouragements, leur soutien permanent et la liberté de recherche qu'ils ont bienvoulu me laisser

Mes plus sincères remerciements vont également à tous les professeurs et les personnels del'Institut de la Francophonie pour l'Informatique (IFI) pour m'avoir donnée des cours de trèsgrande qualité et pour leur soutien tout au long de mes études à l'IFI

Un grand merci aux post-doctorants et thésards de l'équipe DEDALE qui m'ont aidée aucours des neuf mois de ce stage, et plus particulièrement à Samuel Colin

Je remercie chaleureusement mes camarades de la promotion XII pour leur amitié sansfaille et je leur souhaite bonne chance pour la soutenance

Finalement j'adresse un grand merci à toute ma famille et mes amis pour leur soutien etleur encouragement de tout l'instant

RésuméL'équipe DEDALE du LORIA travaille sur les approches de vérication d'architectureslogicielles à base de composants Les composants sont des boîtes noires pour lesquelles seulesleurs interfaces sont connues Une interface décrit les fonctionnalités oertes et/ou requisespar le composant considéré Pour que diérents composants puissent être déployés et tra-vailler ensemble, ils doivent pouvoir coopérer, c'est-à-dire que leurs interfaces doivent êtrecompatibles.

Mon travail de stage a porté sur la liaison entre les travaux de l'équipe DEDALE sur semblage de composants au niveau UML/B et les composants Enterprise Java Bean (EJB).Nous avons proposé une liaison à diérents niveaux : celui de la programmation avec la dé-

l'as-nition d'adaptateurs à partir des EJBs existants ; celui de la spécication avec la dél'as-nition

de la compatibilité entre méthodes à l'aide de Java Modeling Language (JML)

Mots-clés : composant, adaptateur, spécication, compatibilité, EJB, JML

AbstractThe DEDALE team, a research group at LORIA institute, works on component-basedsoftware verication approaches Components are considered as black-boxes communicatingthrough required and/or provided interfaces which describe their visible behaviors A providedinterface of one component can be connected with a required interface of another component

if the former oers the services needed to implement the latter Software components can becomposed and have to be connected in an appropriate way, this means that their interfacesmust be compatible

We have studied how to etablish a relationship between the work of the DEDALE teamabout component assembly with UML/B and Enterprise Java Bean (EJB) We have proposed

a relationship at dierent levels : at the programing level with the denition of adapters usingEJB existing components ; at the specication level with the denition of method compatibi-lity using the Java Modeling Language (JML)

Keywords : component, adapter, specication, matching, EJB, JML

Table des matières

1.1 Problématique 7

1.2 Objectif 7

1.3 Contribution 8

1.3.1 Au niveau programmation 8

1.3.2 Au niveau spécication 8

1.4 Environnement de stage 8

1.5 Contenu du mémoire 9

2 État de l'art 10 2.1 Adaptateur et B 10

2.1.1 Vue générale 10

2.1.2 Méthode B 10

2.1.3 Interopérabilité entre composants 12

2.1.4 Diérents assemblages de composants 12

2.2 Enterprise Java Beans 13

2.2.1 Dénition 13

2.2.2 Présentation d'un composant EJB 13

2.2.3 Exemple 16

2.3 Java Modeling Language 17

2.3.1 Dénition 17

2.3.2 Spécication 17

2.3.3 Exemple 20

2.4 Compatibilité de spécications 21

2.4.1 Dénition 21

2.4.2 Compatibilité au niveau signatures 22

2.4.3 Compatibilité au niveau comportements 22

3 Propositions 25 3.1 Dénition d'un adaptateur au niveau EJB 25

3.1.1 Schéma d'achitecture de composant 25

3.1.2 Correspondance entre l'achitecture UML et EJB 25

3.1.3 Diérents types d'adaptateurs en fonction des EJBs manipulés 28

3.1.4 Étude de cas 33

3.2 Compatibilité au niveau signatures 35

3.3.1 Invariant 36

3.3.2 Méthode pure, méthode impure et clause assignable 37

3.3.3 Visibilité 38

3.3.4 Comportements possibles dans une méthode 38

3.3.5 Exceptions 40

4 Conclusion et perspectives 46 4.1 Conclusion 46

4.2 Perspectives 47

4.2.1 Niveau programmation 47

4.2.2 Niveau spécication 47

Table des gures

2.1 Modèle B 11

2.2 Interopérabilité entre OTS1 et OTS2 12

2.3 Adaptation vue comme le développement d'un nouveau composant 12

2.4 Un composant EJB 13

2.5 Diérence entre @Remote et @Local 14

2.6 Exemple de composant EJB 16

2.7 Code source des interfaces IB et IC 16

2.8 Code source des composants B et C 16

2.9 Code source de l'application A 17

2.10 Forme générale d'une spécication JML d'une méthode Java 19

2.11 Interface PI_MLights en JML 21

2.12 Idée de compatibilité plug-in 24

3.1 Exemples d'assemblage UML 26

3.2 Correspondance entre l'achitecture UML et EJB - Cas 1 26

3.3 Correspondance entre l'achitecture UML et EJB - Cas 2 27

3.4 Correspondance entre l'achitecture UML et EJB - Cas 3 27

3.5 Adaptateur - Cas 1 29

3.6 Adaptateur - Cas 2 30

3.7 Adaptateur - Cas 3 31

3.8 Adaptateur - Cas 4 31

3.9 Adaptateur - Cas 5 32

3.10 Étude de cas 33

3.11 Étude de cas exprimée dans EJB 33

3.12 Code source des interfaces RI_Lights et PI_Lights 34

3.13 Code source de l'adaptateur AdapterBean 34

3.14 Exemple des interfaces BankAccount et Account 35

3.15 Exemple des interfaces MoneyComparable et MoneyOps 35

Liste des tableaux

2.1 Diérences entre Stateless Session Beans et Stateful Session Beans 14

2.2 Caractéristiques des trois types de Beans 15

3.1 Diérences entre les trois types de Bean 25

3.2 Résumé la compatibilité entre deux méthodes avec exception(s) 44

du cỏt de développement, la exibilité des systèmes développés Les technologies telles queles Enterprise Java Beans (EJB) de Java/Sun [22, 23], les composants NET de Microsoft [18],CORBA défendu par l'OMG [26, 27], permettent de développer et de déployer des composantsréutilisables Néanmoins, les approches basées sur l'ingénierie des composants sont encore peusupportées par des méthodes de conception, de vérication et d'intégration adaptées à cettenouvelle problématique.

L'équipe DEDALE du LORIA (voir section 1.4) travaille sur la conception de méthodes

de développement pour la vérication d'architectures logicielles à base de composants [4] :les composants sont des boỵtes noires pour lesquelles seules leurs interfaces sont connues Uneinterface décrit les fonctionnalités oertes et/ou requises par le composant considéré Pourque diérents composants puissent être déployés et travailler ensemble, ils doivent pouvoircoopérer, c'est-à-dire que leurs interfaces doivent être compatibles

Pour décrire les interfaces des composants et les interactions entre composants, l'équipeDEDALE utilise les diagrammes de composants UML 2.0 An de vérier formellement l'in-teropérabilité entre composants, les interfaces sont décrites de manière plus précise à l'aided'un langage formel de haut niveau, la méthode B (voir section 2.1) La vérication de l'inter-opérabilité entre les composants s'eectue grâce aux techniques de ranement et aux outils

de preuve associés à la méthode B

Il est donc nécessaire d'établir un lien plus précis entre les travaux de l'équipe sur semblage de composants au niveau UML/B et les composants logiciels usuels tels que lesEnterprise Java Beans ou les composants NET, objectifs du stage que j'ai eectué dansl'équipe DEDALE

l'as-1.2 Objectif

L'objectif de mon sujet de stage est dans un premier temps d'étudier les diérentes logies à base de composants : Corba, Enterprises JavaBeans, NET, puis d'établir un lien avec

techno-le modètechno-le d'assemblage UML/B actueltechno-lement promu par l'équipe DEDALE pour répondreaux questions suivantes :

 Quelles sont les diérences majeures entre les technologies basées composants existantes :Corba, Enterprises Java Beans, NET ? Existe-il des liens, des passerelles entre elles ?

 Comment les composants logiciels implantés interagissent-ils au sein de ces diérentesplateformes ? Comment s'eectue l'assemblage des composants ?

 L'expressivité du modèle de composants UML 2.0 / B proposé dans l'équipe DEDALEest-elle susante pour permettre le passage vers les technologies existantes à base decomposants ?

1.3 Contribution

Pour répondre aux objectifs du sujet, nous établissons une liaison à deux diérents veaux du cycle de développement : au niveau spécication et au niveau programmation Notrecontribution est divisée en deux parties selon ces niveaux

ni-1.3.1 Au niveau programmation

Parmi les technologies basées sur les composants existants, nous avons étudié les prise Java Beans (EJB), technologie très connue utilisant Java La méthode B est une mé-thode formelle permettant de vérier formellement l'interopérabilité entre composants dontl'adaptateur est une notion importante Il est donc nécessaire de dénir l'adaptateur entredes composants existants au niveau programmation A l'aide des connaissances sur les com-posants EJBs, nous choisissons le type Bean comme élément moteur de notre travail Puisnous essayons de mettre en correspondance l'architecture d'assemblage UML/B avec les EJBs.Enn, nous dénissons des types d'adaptateurs en fonction des EJBs manipulés

Enter-1.3.2 Au niveau spécication

Il existe un langage de spécication pour Java : Java Modeling Language (JML) [9] Unecaractéristique commune à B et JML : ce sont des langages de spécication haut niveau,permettant d'exprimer des propriétés de type pré/post conditions Il existe actuellement desoutils de vérication pour les programmes Java qui utilisent des annotations de JML tel queKrakatoa ([10]) Néanmoins, la spécication et la vérication de l'adaptation à l'aide de JML

au niveau interface ne sont pas prise en compte Notre travail consiste à étudier la compatibilitéentre méthodes de l'interface requise et celles de l'interface fournie en utilisant JML

1.4 Environnement de stage

Le LORIA, Laboratoire Lorrain de Recherche en Informatique et ses Applications, est uneUnité Mixte de Recherche commune à plusieurs établissements : CNRS (Centre National deRecherche Scientique), INPL (Institut National Polytechnique de Lorraine), INRIA (InstitutNational de Recherche en Informatique et en Automatique), UHP (Université Henri Poincaré,Nancy 1) et Nancy 2 (Université Nancy 2)

Fondé en 1997, le LORIA se concentre sur ses trois missions principales : la recherche damentale et appliquée au niveau international dans le domaine des Sciences et Technologies

fon-de l'Information et fon-de la Communication, la formation par la recherche en partenariat avecles Universités lorraines et le transfert technologique par le biais de partenariats industriels

et par l'aide à la création d'entreprises

L'équipe DEDALE, au sein de LORIA, est une équipe travaillant sur la qualité et lasûreté des logiciels L'objectif de cette équipe est d'étudier les mécanismes de construction despécications et de programmes, dans le but d'acquérir une meilleure maîtrise de la production,

de l'évolution et de la qualité des logiciels L'idée sous-jacente est que les développements despécications et de programmes sont des objets à part entière que l'on peut étudier, modéliser,construire, modier et réutiliser L'objectif principal est d' :

 apporter des aides dans la démarche de construction d'un logiciel, depuis l'analyse ducahier des charges fourni par le client jusqu'à la production d'une spécication for-melle, avec un intérêt particulier pour les aspects de vérication et de qualité via uneconstruction prouvée,

 comprendre et décrire des méthodes de développement en utilisant les langages de cications existants et les outils associés à ces langages tout au long du développement,

spé-et pas uniquement lorsque la spécication est terminée

Les axes thématiques de l'équipe concernent la :

 Dénition de guides méthodologiques pour l'expression des besoins et le passage assisté

à une spécication formelle

 Intégration des outils de validation et de vérication dans le processus de développement

La mémoire est structuré de la manière suivante

Dans le chapitre 2, nous présentons des travaux existants concernant notre approche : B

et les adaptateurs (approche proposée par l'équipe DEDALE), Enterprise Java Beans et JavaModeling Language Nous présentons aussi des travaux concernant la compatibilité de signa-tures et de spécications qui jouent un rôle important dans la compatibilité entre interfaces

Le chapitre 3 présente la contribution de notre stage à deux niveaux d'expression : leniveau programmation et le niveau spécication

Nous terminons ce mémoire par une conclusion et des perspectives

2.1.1 Vue générale

L'approche composant est une approche de développement de logiciels intéressante [24].Une application à composants consiste en une composition de composants, chaque compo-sant est considéré comme une boîte noire Des composants logiciels sont développés parassemblage et adapatation pour produire un système complet

Les composants communiquent via leurs interfaces Il existe deux types d'interface decomposants : une interface fournie qui ore des fonctionnalités, une interface requise quiutilise les fonctionnalités d'un autre composant pour implanter ses propres fonctionnalités.Une interface fournie peut être connectée avec une interface requise si la première ore toutesles fonctionnalités permettant d'implanter la seconde An de garantir l'interopérabilité entrecomposants, il est nécessaire d'avoir une description appropriée des interfaces et de vérier

la correction de cette connexion Le terme correction d'une connexion peut s'exprimer entermes d'un ranement : l'interface fournie doit "raner" l'interface requise La méthode B[1] est une méthode qui supporte la spécication formelle des interfaces et permet aussi lapreuve de leur interopérabilité [4, 15]

Dans l'ingénierie des composants, la notion de réutilisation est très importante Les faces fournies et requises des composants existants peuvent rarement être connectées directe-ment Pour répondre au besoin de connexion entre composants, il faut intercaler un adaptateur(ou médiateur) entre composants ou bien développer un nouveau composant par assemblage

inte-de plusieurs composants existants

2.1.2 Méthode B

a) Dénition

Initiée par Jean-Raymond Abrial au début des années 80, B [1] est une méthode formellebasée sur la logic du premier ordre et la théorie des ensembles, permettant un développement

incrémental de spécications grâce au ranement Un développement commence avec la nition d'une spécication abstraite qui est ensuite ranée pas à pas jusqu'à l'obtention d'uneimplantation Les caractéristiques principales de B sont les suivantes :

dé- des fondements mathématiques en logique du premier ordre avec théorie des ensembles,qui forment un corpus formel connu et compris depuis longtemps et permettant deréaliser des vérications formelles ;

 la modularité qui facilite le développement par morceaux de systèmes complexes ;

 le ranement pour un développement incrémental du niveau de détail, ainsi que pour

la génération de code

La méthode B a été utilisée pour des applications industrielles complexes, en particulierdans le domaine du ferroviaire, comme le projet METEOR [3] ou le métro Val [2] Elle s'appuiesur des outils robustes [21, 5] basés sur la preuve Nous rappelons ici comment un modèle estdéveloppé grâce à la méthode B

b) Construction d'un modèle B

Le principe d'un modèle tient dans l'expression de propriétés du système qui doiventrester vraies après toute étape d'évolution du modèle La correction du modèle signie lapréservation de ses propriétés, exprimées par un invariant

MODEL example SEES seen_model INCLUDES included_model VARIABLES var1, var2 INVARIANT inv INITIALISATION init OPERATIONS out1, out2 ←− method1(in1, in2) = b PRE pre1

THEN body1 END END

Fig 2.1  Modèle B

Un modèle B commence par la clause MODEL pour déclarer le nom du modèle Lespropriétés sont spéciées dans la clause INVARIANT du modèle et l'évolution de ce modèleest spéciée dans plusieurs opérations situées dans la clause OPERATIONS Soit le modèlegénérique présenté gure 2.1 : il dispose de variables var1 et var2 (déclarées par la clauseVARIABLES) dont les propriétés sont indiquées dans l'invariant inv Le modèle contientune opération method1 qui précise comment var1 et var2 sont modiées en fonction desparamètres in1 et in2 Elle peut aussi retourner une ou plusieurs valeurs out1 et out2 Laprécondition pre1 de method1 permet d'indiquer quelles sont les contraintes sur l'état dumodèle (et les paramètres de l'opération) lors de l'appel de l'opération Le corps de l'opérationbody1 est spécié selon la syntaxe du langage des substitutions de B

Les autres clauses du modèle générique de la gure 2.1 ont trait à la modularité : seen_model

de la clause SEES est un modèle B qui peut être vu mais dont l'état ne peut pas être modié.included_model de la clause INCLUDES est un autre modèle B dont l'état est visible etdont les changements peuvent être contrôlés en appelant ses opérations

2.1.3 Interopérabilité entre composants

Pour vérier l'interopérabilité entre deux composants, c'est-à-dire, qu'ils peuvent êtreconnectés via leur interfaces respectives, il faut s'assurer que ces interfaces sont compatibles.Plus précisément, il s'agit de montrer que l'interface fournie implante bien les fonctionnalitésnécessaires à l'interface requise

En d'autres termes, nous pouvons dénir l'interopérabilité entre composants de la manièresuivante à l'aide de B [4]

Soient deux composants OTS11 et OTS2 avec leur interfaces RI_ots1 et PI_ots2 tives Ils sont interopérables si et seulement si le modèle B de PI_ots2 est un ranement decelui de RI_ots1 [15]

respec-Fig 2.2  Interopérabilité entre OTS1 et OTS2Dans le cas ó deux composants ne sont pas compatibles, le développement d'un adapta-teur ou celui d'un nouveau composant à partir de composants existants sont nécessaires Cesdeux manières de développement sont considérées équivalentes [15]

Fig 2.3  Adaptation vue comme le développement d'un nouveau composant

Développer un adaptateur qui assure la bonne connexion entre un composant OTS1 et uncomposant OTS2, revient à développer un nouveau composant DEV qui fournira l'interfaceRI_ots1 en utilisant le composant OTS2 via son interface fournie PI_ots2, comme illustré

gure 2.3

2.1.4 Diérents assemblages de composants

Dans une approche de réutilisation, les composants existants ont rarement des interfacesdirectement compatibles Un  nouveau  composant est nécessaire pour les rendre compa-tibles Le développement de ce composant peut être plus ou moins complexe, en fonction dunombre et du type de composants existants à assembler La dénition des diérents cas d'ar-chitecture et des schémas pour assembler un ou plusieurs composants et vérier la correction

1 Nous nommons les composants existants OTS pour  O-The-Shelf .

de l'assemblage est présentée dans l'article [15] Notre objectif est de mettre en correspondanceces diérents assemblages de composants avec les Enterprise Java Beans.

2.2 Enterprise Java Beans

2.2.1 Dénition

Écrite en Java, la technologie Enterprise Java Beans (EJB) [22] est une architecture decomposants logiciels côté serveur pour la plateforme de développement J2EE2 Cette archi-tecture propose un cadre pour créer des composants distribués (c'est-à-dire déployés sur desserveurs distants) hébergés au sein d'un serveur d'applications3permettant de représenter desdonnées (EJB dit entité), de proposer des services avec ou sans mémorisation d'états entreles appels (EJB dit session), ou encore d'accomplir des tâches de manière asynchrone (EJBdit message) En d'autres termes, EJB est un modèle de composants pour le développementdes applications d'entreprises telles que des sites web (de commerce en ligne, de travail colla-boratif, communautaires, etc.), des systèmes d'information, des applications de gestion, etc

La notion de "Bean" est considérée comme un EJB ou un composant

Dans ce contexte, la question posée est : qu'est-ce qu'un composant ? Nous disposons d'uncomposant A muni de deux interfaces : une interface fournie IA et une interface requise IB.Dans ce composant, la classe Java ABean implante l'interface IA et importe l'interface IB(voir gure 2.4)

Fig 2.4  Un composant EJB

2.2.2 Présentation d'un composant EJB

Une diérence entre les composants EJBs et la notion de composants dans d'autres nologies (Corba, NET, etc.) est l'existence de types de composants diérents selon leur uti-lisation Il existe trois types de Beans : Session Bean, Message-Driven Bean et Entity Bean.Nous détaillons les caratéristiques de chaque type

tech-2 Java Platform, Enterprise Edition.

3 Un serveur d'applications est un serveur sur lequel sont installées les applications utilisées par les usagers Ces applications sont chargées sur le serveur d'applications et accédées à distance.

Les principales diérences entre ces deux types de Session Beans sont présentés dans letableau 2.1.

Stateless Session Beans Stateful Session Beans

- Ne conservent pas d'information entre

deux appels successifs

- Mémorisent les informations

- Deux instances quelconques d'un tel

Bean sont équivalentes

- Même instance pendant toute la duréed'une session avec un client

- Une instance par appel - Une instance par client

Tab 2.1  Diérences entre Stateless Session Beans et Stateful Session Beans

Dans le composant de type Session Bean, nous déclarons aussi le type d'utilisation : locale(@Local) ou à distance (@Remote) via des annotations Java Ce sont deux notions que nousutiliserons souvent dans l'application client/serveur Nous présentons la diérence entre cesdeux types d'utilisation dans la gure 2.5

Fig 2.5  Diérence entre @Remote et @LocalPour le type d'utilisation à distance, l'application côté client et les composants EJBsqu'elle utilise sont déployés sur des machines diérentes alors que dans l'utilisation locale, ilssont déployés sur le même machine

b) Message-Driven Beans

Les Message-Driven Beans eectuent des actions comme les Session Beans La diérenceentre ces deux types de composants, c'est que les Message-Driven Beans sont appelés à l'aided'un système de messages, c'est-à-dire qu'il n'existe pas de chemin direct pour appeler uneméthode d'un Message-Driven Bean

c) Entity Beans

Ils modélisent les données métiers Ce sont des noms correspondant aux objets

Les Entity Beans n'ont pas d'interface Ils sont utilisés localement Ils peuvent aussi êtreutilisés à distance à l'aide les Session Beans.

d) Synthèse

Le tableau 2.2 présente les diérences entre les trois types de Beans [7]

Session Beans Message-Driven Beans Entity Beans

- S'exécutent au nom d'un

client simple a

- S'exécutent selon l'accusé de réception d'un message d'un client simple

- Font partie d'un modèle de domaine, fournissent une vue d'objet de données dans la base

de données

- Modient des données

parta-gées dans la base de données

- Peuvent modier des données partagées dans la base de don- nées

- Ne représentent pas

direc-tement des données partagées

dans la base de données quoi

qu'ils peuvent y accéder et les

modier

- Ne représentent pas tement des données partagées dans la base de données quoi- qu'ils peuvent y accéder et les modier

direc Durent peu de temps - Durent peu de temps - Durent longtemps (leur durée

de vie est la même que celle des données de la base de données)

- Sont détruits avec le

conte-neur d'EJB Le client doit

réta-blir un nouvel objet de session

pour continuer les calculs

- Sont détruits avec le neur d'EJB Le conteneur doit rétablir un nouvel objet de Message-Driven pour continuer les calculs

conte L'entité et sa clé primaire survivent après destruction du conteneur d'EJB Si l'état d'une entité est modié par une tran- saction lors de la destruction du conteneur, l'état de l'entité est reconstitué à partir de l'état de

la dernière transaction eectuée

- Sont appelés de manière chrone

asyn Sans état

- Un conteneur d'EJB

ty-pique fournit un environnement

d'exécution (runtime

environ-ment) pour un grand nombre

d'objets de sessions

concur-rentes La spécication EJB

dé-nit les Stateful et Stateless

Session Beans

- Un conteneur d'EJB pique fournit un environnement d'exécution pour un grand nombre d'objets de Message- Driven de manière concurrente

ty Un conteneur d'EJB et le serveur fournissent un environ- nement d'exécution pour un grand nombre d'objets d'entités concurrentes

a single client en anglais, c'est-à-dire que chaque instance de Session Bean supporte seulement un client Si deux clients appellent une même instance de Session Bean, il y a une erreur.

Tab 2.2  Caractéristiques des trois types de Beans

Fig 2.7  Code source des interfaces IB et ICLes composants B et C (gure 2.8) sont déclarés en utilisant des annotations d'EJB.

@ S t a t e l e s s

@Local

p u b l i c c l a s s CBean implements IC {

p u b l i c void methodeC ( ) {

} }

Fig 2.8  Code source des composants B et CDans la classe BBean du composant B, @Stateless précise qu'il s'agit d'un Stateless SessionBean La clause @Remote précise que l'application A (qui utilise B) et le composant B nesont pas déployés la même machine

Le composant C est déni de la même manière que B Dans la classe CBean, nous déclarons

@Local parce que B (qui utilise C ) et C sont sur le même serveur

L'application A côté client (voir gure 2.9) déclare @EJB pour utiliser des composantsEJBs côté serveur

import j a v a x e j b EJB ; import component_B IB ;

} }

Fig 2.9  Code source de l'application A

2.3 Java Modeling Language

2.3.1 Dénition

Java Modeling Language (JML) est un langage de spécications formelles de ments d'interface pour Java Il permet de spécier formellement le comportement d'une classeJava Le comportement décrit ce qui se passe quand une méthode est appelée Le comporte-ment d'une méthode est spécié à l'aide de préconditions et postconditions [16, 17, 28]

comporte-2.3.2 Spécication

Il y a trois notions importantes dans une spécication JML :

 Invariant : propriété toujours vraie quel que soit l'état du système

 Précondition : propriété qui doit être vériée avant l'appel d'une méthode

 Postcondition : propriété vériée après l'exécution d'une méthode

Dans la suite, nous présentons en détail les notions relatives à notre travail :

 Constraintes historiques (clause constraint predicatJ M L) : expriment la propriété entre

un état visible et l'état visible précédent ; elle doit être vraie dans tous les états dusystème (invariant dynamique)

Spécication de méthodes C'est la partie dynamique du modèle, elle contient des priétés relatives aux comportements autorisés des méthodes, exprimées à l'aide des clausessuivantes :

pro- Précondition (clause requires predicatJ M L) : condition qui doit être remplie par lesystème et les paramètres de la méthode pour que la méthode puisse être exécutée

 Divergence (clause diverges predicatJ M L) : condition sous laquelle la méthode peut nepas terminer, i.e boucles innies

 Champs modiés (clause assignable predicatJ M L) : liste des attributs qui sont modiéspar l'exécution de la méthode

 Postcondition normale (clause ensures predicatJ M L) : condition que la méthode gage à établir lorsqu'elle termine normalement, c'est-à-dire sans lever d'exceptionb) Méthodes pures

s'en-Une méthode qui ne modie aucun attribut est dite pure et peut être utilisée dans lesprédicats JML Elle ne doit pas changer l'état du système an d'éviter des eets de bord Lesméthodes de consultation des classes de l'API Java5 sont considérées comme pures On peutdéclarer qu'une méthode est pure à l'aide du modieur "pure" Le modieur pure a le mêmesense que :

Dans JML, pour dénir une (plusieurs) exception(s) d'une méthode, nous utilisons lanotion Postcondition exceptionnelle, exprimée par l'expression suivante :

signals (Exception1 exp) predicatJ M L

Le predicatJ M Lindique la postcondition qui doit être vériée à la n de la méthode quandcelle-ci se termine en levant une exception exp de type Exception1

Une autre notion est celle d'Exceptions autorisées :

signals_only E1, E2

indique que E1, E2 sont les seules exceptions autorisées à être levées par la méthodeconsidérée

La forme générale d'un comportement est dénie dans le gure 2.10

5 Java Application Programming Interface

Fig 2.10  Forme générale d'une spécication JML d'une méthode Java

d) Visibilité de Java et visibilité de JML

Dans Java, nous avons plusieurs niveaux de visibilité pour les attributs et les méthodes :

 par défaut : visible depuis toutes les classes du package

 public : visible depuis n'importe quelle autre classe

 private : visible uniquement à l'intérieur de la classe

 protected : visible depuis la classe, les sous-classes et n'importe quelle classe du packageLes annotations JML sont vues comme externes à la classe et doivent donc respecterles contraintes de visibilités de Java Pour modier la visibilité des attributs et des méthodesuniquement au niveau spécication, JML dénit les deux modieurs suivants :

 spec_public

 spec_protected

e) Plusieurs comportements pour une méthode

Nous pouvons dénir plusieurs comportements pour une méthode à l'aide de "also" quicombine les comportements de manière disjointe (ou) :

}

Sa sémantique est la suivante :

f) Comportements spéciques

Nous pouvons distinguer les comportements normaux et les comportements exceptionnels

en utilisant deux notions :

 normal_behavior indique que le comportement décrit correspond à un cas ó la méthodetermine normalement sans déclancher d'exception Cela veut dire que dans JML, lacondition de la clause signals est false :

signals (Exception) false

 exceptional_behavior indique que le comportement décrit correspond à un cas ó laméthode termine en déclenchant une exception En d'autres termes, la condition de laclause ensures est false :

ensures false

2.3.3 Exemple

Nous présentons un exemple de spécication utilisant JML à partir d'une interface PI_Lights

gure 2.11

Dans cet exemple, nous avons utilisé des annotations JML, disposées entre des annotations

de commentaires sous formes /*@ @*/ Il est aussi possible d'utiliser la forme //@ pourdéclarer des annotations JML sur une seule ligne

Dans une interface Java, il n'existe pas de vraies variables Pour représenter des variablesutilisées dans les comportements, nous déclarons ces variables à l'aide du modieur model

Le modieur model exprime qu'un attribut est déclaré seulement au niveau spécication.Dans l'interface PI_MLights, les deux variables color et ml_state sont déclarées au niveauspécication de la manière suivante :

//@ public model ML_Color color ;

//@ public model MLights_STATES ml_state ;

Pour chaque méthode, nous avons une précondition (exprimée par requires) et une condition (exprimée par ensures) Pour la méthode change(ML_Color newColor) :

post- La précondition : color != newColor

 La postcondition : color == newColor

Cela veut dire qu'avant l'appel de cette méthode, les valeurs des variables color et newColordoivent être diérentes et elles seront identiques après l'exécution La clause assignable danscette méthode exprime que la variable color peut être modiée

//@ model import org j m l s p e c s models ∗ ;

p u b l i c i n t e r f a c e PI_MLights { //@ p u b l i c model ML_Color c o l o r ; //@ p u b l i c model MLights_STATES ml_state ; /∗@ r e q u i r e s c o l o r != newColor ;

@ a s s i g n a b l e ml_state

@ e n s u r e s ml_state = MLights_STATES ML_Off ;

@∗/

p u b l i c void o f f ( ) ; }

Fig 2.11  Interface PI_MLights en JML2.4 Compatibilité de spécications

Nous présentons certains détails des travaux d'A M Zaremski et J M Wing [30, 31]

en relation avec notre approche, en vue de les appliquer pour dénir la compatibilité entreméthodes spéciées en JML

 Sous-type : Quand est-ce qu'un objet d'un type est un sous-type d'un autre objet ?

La spécication d'un composant C est divisée en deux niveaux, sa signature Csig et soncomportement Cspec

Soient deux composants, C = <Csig, Cspec> et C' = <C0

sig,C0 spec> La compatibilité entreces deux composants C et C' est dénie par :

Match : Component, Component → Bool

M atch(C, C0) = match (C , C0 ) ∧ match (C , C0 ) (2.1)

2.4.2 Compatibilité au niveau signatures

M : Library Type, Query Type → Boolean

M (τl, τq) = ∃Tl and Tq such that Tl(τl) R Tq(τq) (2.2)Dans lequel :

 Tl et Tq sont des transformations appliquées pour le type de la bibliothèque et celui de

la requête

 R est une relation entre Tl(τl) et Tq(τq), par exemple =T, ≤ ou ≥

La compatibilité de signatures est fonction de la relation R entre τl et τq et des mations Tl, Tq

transfor-b) Types de compatibilité de signatures

Deux types de compatibilité de signatures sont distingués

Compatibilité exacte A partir de la formule 2.2, si :

 τl est une suite de renommages des variable V,

 τq est la fonction identité,

 R est =T

La compatibilité est dite exacte :

matchE(τl, τq) = ∃ a sequence of variable renamings, V, such that

Compatibilité relâchée Ce type est divisé en trois sous-types de compatibilité : patibilité Généralisée (Generalized Match), Compatibilité Spécialisée (Specialized Match) etCompatibilité Uniée (Unify Match) Dans notre travail, nous n'utilisons que le type Compa-tibilité Spécialisée, déni par

Com-matchspec(τl, τq) = τl≤ τq (2.4)Intuitivement, un type disponible en bibliothèque est compatible avec celui de la requête

si le type de la requête est plus général que celui de bibliothèque

2.4.3 Compatibilité au niveau comportements

a) Dénition

Soient une bibliothèque de spécications S(Spre, Spost) et une requête Q(Qpre, Qpost) Deuxnotions de compatibilité sont distinguées :

Dénition 1 La formule générale de compatibilité pré/post matchpre/post(S, Q) la pluscommune pour les méthodes est dénie par :

matchpre/post(S, Q) = (Qpre R1 Spre) ∧ ( bS R2 Qpost) (2.5)Avec :

 R1 est la relation entre Qpre et Spre

 R2 est la relation entre Qpost et Spost

 R1 et R2 sont soit une équivalence (⇔) soit une implication (⇒)

 Sbest soit Spostsoit Spre∧Spost, en fonction du type de compatibilité Dans notre travail,b

S = Spost

Dénition 2 La formule générale de compatibilité de prédicats est utile dans le cas ónous avons besoin de considérer une relation de spécications plutơt qu'une relation entre desparties correspondantes de spécications :

matchpred(S, Q) = Spred R Qpred (2.6)Avec :

 Spred = Spre ⇒ Spost

 Qpred = Qpre ⇒ Qpost

 R, relation entre Spred et Qpred est soit une équivalence (⇔) soit une implication (⇒)b) Types de compatibilité pré/post

Pour dénir l'interopérabilité directe entre les interfaces, nous avons besoin de deux types

de compatibilité :

Compatibilité pré/post exacte C'est le cas le plus simple lorsque la précondition et lapostcondition de chaque méthode de l'interface requise et celle fournie sont équivalentes Apartir de la formule 2.5, avecSb= Spost et R1 et R2 sont une équivalence, nous obtenons laformule de Compatibilité pré/post exacte suivante :

matchE−pre/post(S, Q) = (Qpre⇔ Spre) ∧ (Spost ⇔ Qpost) (2.7)Illustrons ce cas de compatibilité à l'aide de l'exemple suivant :

@ e n s u r e s \ r e s u l t == a+b ;

@∗/

p u b l i c i n t addP ( i n t a , i n t b ) ; }

La précondition et la postcondition de deux méthode addR de l'interface interfaceR etaddP de l'interface interfaceP sont les mêmes Donc, addRpre ⇔ addPpre et addPpost ⇔addRpost, correspondant à la compatibilité exacte

Fig 2.12  Idée de compatibilité plug-in

Compatibilité plug-in L'idée de compatibilité plug-in est exprimée gure 2.12

Soit deux méthodes : une méthode Q <Qpre, Qpost> d'une interface requise ; une méthode

S <Spre, Spost>d'une interface fournie Les eches signient une implication Selon cette

gure, pour que Q puisse utiliser S :

Qpre est plus forte que Spre

Spost est plus forte que Qpost

À partir de la formule 2.5, avecSb= Spost; R1 et R2 sont une implication, nous avons laformule de Compatibilité plug-in

matchplug−in(S, Q) = (Qpre⇒ Spre) ∧ (Spost ⇒ Qpost) (2.8)

La compatibilité plug-in est illustrée par l'exemple suivant :

@ e n s u r e s \ r e s u l t == a+b ;

@∗/

p u b l i c i n t addP ( i n t a , i n t b ) ; }

Dans cet exemple, addRpre ⇒ addPpre( addPpre= true, addRpreest plus forte que addPpre

), addPpost ⇔ addRpost En d'autres termes, nous pouvons dire (addRpre ⇒ addPpre) ∧(addPpost⇒ addRpost) , la compatibilité entre addR et addP est donc plug-in

c) Types de compatibilité de prédicats

Compatibilité exacte À partir de formule 2.6, la compatibilité exacte correspond au cas

ó R est une équivalence :

matchpred(S, Q) = Spred⇔ Qpred (2.9)Compatibilité généralisée Correspond à la formule 2.6 avec R est une implication :

matchpred(S, Q) = Spred⇒ Qpred (2.10)