Approche composant de la spécification à limplantation

Institut de la Francophonie pour l'Informatique Hanoi, Vietnam LORIA Nancy, France Approche Composant : de la spÈcication ‡ l'implantation MÈmoire de n d'Ètudes Thi Minh Tuyen Nguyen Lieu de stage : Équipe DEDALE, LORIA Campus Scientique, BP 239 F-54506 Vand˜uvre lËs Nancy Cedex Sous la direction de : Arnaud Lanoix Jeanine SouquiËres Nancy, le 14 novembre 2008 Remerciements Je voudrais tout d'abord remercier Jeanine SouquiËres de m'avoir accueillie au sein de l'Èquipe de recherche DEDALE du Laboratoire Lorrain de Recherche en Informatique et ses Applications (LORIA) Je tiens Ègalement ‡ remercier tout particuliËrement Arnaud Lanoix et Jeanine SouquiËres pour m'avoir encadrÈe pendant ces neuf mois Je les remercie de leur contact chaleureux, leurs conseils et encouragements, leur soutien permanent et la libertÈ de recherche qu'ils ont bien voulu me laisser Mes plus sincËres remerciements vont Ègalement ‡ tous les professeurs et les personnels de l'Institut de la Francophonie pour l'Informatique (IFI) pour m'avoir donnÈe des cours de trËs grande 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 au cours des neuf mois de ce stage, et plus particuliËrement ‡ Samuel Colin Je remercie chaleureusement mes camarades de la promotion XII pour leur amitiÈ sans faille et je leur souhaite bonne chance pour la soutenance Finalement j'adresse un grand merci ‡ toute ma famille et mes amis pour leur soutien et leur encouragement de tout l'instant RÈsumÈ L'Èquipe DEDALE du LORIA travaille sur les approches de vÈrication d'architectures logicielles ‡ base de composants Les composants sont des boÓtes noires pour lesquelles seules leurs interfaces sont connues Une interface dÈcrit les fonctionnalitÈs oertes et/ou requises par 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 Ítre compatibles Mon travail de stage a portÈ sur la liaison entre les travaux de l'Èquipe DEDALE sur l'assemblage 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Ènition d'adaptateurs ‡ partir des EJBs existants ; celui de la spÈcication avec la dÈnition de la compatibilitÈ entre mÈthodes ‡ l'aide de Java Modeling Language (JML) Mots-clÈs : composant, adaptateur, spÈcication, compatibilitÈ, EJB, JML Abstract The DEDALE team, a research group at LORIA institute, works on componentbased software verication approaches Components are considered as black-boxes communicating through required and/or provided interfaces which describe their visible behaviors A provided interface 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 be composed and have to be connected in an appropriate way, this means that their interfaces must be compatible We have studied how to etablish a relationship between the work of the DEDALE team about 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 using EJB 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 Introduction 1.1 ProblÈmatique 1.2 Objectif 1.3 Contribution 1.3.1 1.3.2 1.4 Environnement de stage 1.5 Contenu du mÈmoire État de l'art 2.1 Adaptateur et B 2.1.1 2.1.2 2.1.3 2.1.4 2.2 Enterprise Java Beans 2.2.1 2.2.2 2.2.3 2.3 Java Modeling Language 2.3.1 2.3.2 2.3.3 2.4 CompatibilitÈ de spÈcications 2.4.1 2.4.2 2.4.3 Propositions 3.1 DÈnition d'un adaptateur au niveau EJB 3.1.1 3.1.2 3.1.3 3.1.4 3.2 CompatibilitÈ au niveau signatures 3.3 CompatibilitÈ au niveau comportements avec 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 Invariant MÈthode pure, mÈthode impure et clause a VisibilitÈ Comportements possibles dans une mÈtho Exceptions Conclusion et perspectives 4.1 Conclusion 4.2 Perspectives 4.2.1 4.2.2 Table des gures 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 ModËle B InteropÈrabilitÈ entre OTS1 et OTS2 Adaptation vue comme le dÈveloppement d'un nouveau composa Un composant EJB DiÈrence entre @Remote et @Local Exemple de composant EJB Code source des interfaces IB et IC Code source des composants B et C Code source de l'application A Forme gÈnÈrale d'une spÈcication JML d'une mÈthode Java Interface PI_MLights en JML IdÈe de compatibilitÈ plug-in 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 Exemples d'assemblage UML Correspondance entre l'achitecture UML et EJB - Cas Correspondance entre l'achitecture UML et EJB - Cas Correspondance entre l'achitecture UML et EJB - Cas Adaptateur - Cas Adaptateur - Cas Adaptateur - Cas Adaptateur - Cas Adaptateur - Cas Étude de cas Étude de cas exprimÈe dans EJB Code source des interfaces RI_Lights et PI_Lights Code source de l'adaptateur AdapterBean Exemple des interfaces BankAccount et Account Exemple des interfaces MoneyComparable et MoneyOps Liste des tableaux 2.1 DiÈrences entre Stateless Session Beans et Stateful Session Beans 2.2 CaractÈristiques des trois types de Beans 3.1 DiÈrences entre les trois types de Bean 3.2 RÈsumÈ la compatibilitÈ entre deux mÈthodes avec exception(s) Chapitre Introduction 1.1 ProblÈmatique Les mÈthodes d'ingÈnierie basÈes sur l'assemblage de composants indÈpendants rÈpondent aux besoins de l'ÈvolutivitÈ des architectures logicielles gr‚ce aux avantages de l'ingÈnierie ba-sÈe sur les composants tels que la rÈutilisabilitÈ des composants logiciels certiÈs, la rÈduction du co˚t de dÈveloppement, la exibilitÈ des systËmes dÈveloppÈs Les technologies telles que les 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 composants rÈutilisables NÈanmoins, les approches basÈes sur l'ingÈnierie des composants sont encore peu supportÈes par des mÈthodes de conception, de vÈrication et d'intÈgration adaptÈes ‡ cette nouvelle 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 Une interface dÈcrit les fonctionnalitÈs oertes et/ou requises par le composant considÈrÈ Pour que diÈrents composants puissent Ítre dÈployÈs et travailler ensemble, ils doivent pouvoir coopÈrer, c'est-‡-dire que leurs interfaces doivent Ítre compatibles Pour dÈcrire les interfaces des composants et les interactions entre composants, l'Èquipe DEDALE 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'aide d'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 l'as-semblage de composants au niveau UML/B et les composants logiciels usuels tels que les Enterprise Java Beans ou les composants NET, objectifs du stage que j'ai eectuÈ dans l'Èquipe DEDALE 1.2 Objectif L'objectif de mon sujet de stage est dans un premier temps d'Ètudier les diÈrentes technologies ‡ base de composants : Corba, Enterprises JavaBeans, NET, puis d'Ètablir un lien avec le modËle d'assemblage UML/B actuellement promu par l'Èquipe DEDALE pour rÈpondre aux 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Èrentes plateformes ? Comment s'eectue l'assemblage des composants ? L'expressivitÈ du modËle de composants UML 2.0 / B proposÈ dans l'Èquipe DEDALE est-elle susante pour permettre le passage vers les technologies existantes ‡ base de composants ? 1.3 Contribution Pour rÈpondre aux objectifs du sujet, nous Ètablissons une liaison ‡ deux diÈrents ni-veaux du cycle de dÈveloppement : au niveau spÈcication et au niveau programmation Notre contribution est divisÈe en deux parties selon ces niveaux 1.3.1 Au niveau programmation Parmi les technologies basÈes sur les composants existants, nous avons ÈtudiÈ les Enter-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 dont l'adaptateur est une notion importante Il est donc nÈcessaire de dÈnir l'adaptateur entre des composants existants au niveau programmation A l'aide des connaissances sur les composants EJBs, nous choisissons le type Bean comme ÈlÈment moteur de notre travail Puis nous 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 1.3.2 Au niveau spÈcication Il existe un langage de spÈcication pour Java : Java Modeling Language (JML) [9] Une caractÈ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 des outils de vÈrication pour les programmes Java qui utilisent des annotations de JML tel que Krakatoa ([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 une UnitÈ Mixte de Recherche commune ‡ plusieurs Ètablissements : CNRS (Centre National de Recherche Scientique), INPL (Institut National Polytechnique de Lorraine), INRIA (Institut National de Recherche en Informatique et en Automatique), UHP (UniversitÈ Henri PoincarÈ, Nancy 1) et Nancy (UniversitÈ Nancy 2) FondÈ en 1997, le LORIA se concentre sur ses trois missions principales : la recherche fondamentale et appliquÈe au niveau international dans le domaine des Sciences et Technologies de l'Information et de la Communication, la formation par la recherche en partenariat avec les 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 la s˚retÈ des logiciels L'objectif de cette Èquipe est d'Ètudier les mÈcanismes de construction de spÈ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 de spÈ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 du cahier 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 une construction prouvÈe, comprendre et dÈcrire des mÈthodes de dÈveloppement en utilisant les langages de spÈ-cications existants et les outils associÈs ‡ ces langages tout au long du dÈveloppement, 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 de spÈcications formelles SpÈcication de systËmes par composants avec preuve de leur interopÈrabilitÈ [4, 8, 12, 14, 15] SpÈcication et vÈrication de systËmes multi-agents situÈs [20] 1.5 Contenu du mÈmoire 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 Java Modeling Language Nous prÈsentons aussi des travaux concernant la compatibilitÈ de signatures et de spÈcications qui jouent un rÙle important dans la compatibilitÈ entre interfaces Le chapitre prÈsente la contribution de notre stage ‡ deux niveaux d'expression : le niveau programmation et le niveau spÈcication Nous terminons ce mÈmoire par une conclusion et des perspectives Cas Cas La notion d'exception n'est pas utilisÈe ici 40 Cas Il existe une (plusieurs) exceptions(s) dans la spÈcication d'une mÈthode de l'inter-face fournie Soit l'exemple suivant : public interface IP{ /@ public p u b l i c i n t e r f a c e IR { normal_behavior @ @ requires a > && b > ; e n s u r e s \ r e s u l t == a+b ; @a l s o @p u b l i c e x c e p t i o n a l _ b e h a v i o r @ requires a b; e n s u r e s \ r e s u l t == a b ; @ also @ public exceptional_behavi or @ r e q u i r e s a