Facult des Sciences et des Sciences de lingnieur Dpartement dinformatique N dordre : Srie: Mmoire Prsent en vue de lobtention du diplme Magister en Informatique Option: Informatique Industrielle SUJET DU MMOIRE : Prsent le : 14 / 06 / 2009 Par : ZERNADJI Tarek Composition du jury: Mr. BELATTAR Brahim Prsident (Matre de Confrence lUniversit de Batna) Mr. CHAOUI Allaoua Rapporteur(Matre de Confrence lUniversit de Constantine) Mr. BILAMI AzzeddineExaminateur(Matre de Confrence lUniversit de Batna). Mr. KAZAR OkbaExaminateur(Matre de Confrence lUniversit de Biskra). Une approche de modlisation des logiciels base de composants par les rseaux de Petri REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIREMinistre de lEnseignement Suprieur et de la Recherche Scientifique Universit El Hadj Lakhdar BATNA Remerciements Jaimerais dabord remercier mon encadreur qui ma soutenu tout au long de la rdaction de ce mmoire, pour son coute et ses conseils pertinents. Je remercie galement lensemble des membres du jury pour avoir consacrer leur temps examiner ce travailmalgr leurs nombreuses responsabilits, je leur suis reconnaissant pour lattention quils ont porte mon travail.

Je tiens aussi remercier ma famille et mes amis pour leur soutient inconditionnel et leur prsence continue. Enfin je remercie tous ceux qui mont aid de prs ou de loin pour la ralisation de ce travail. SOMMAIRE INTRODUCTION GENERALE........................................................................................................1 CHAPITRE I : DEVELOPPEMENT LOGICIEL A BASE DE COMPOSANTS......................5 1.INTRODUCTION.......................................................................................................................5 2.PROCESSUS LOGICIEL..........................................................................................................5 2.1ACTIVITES GENERIQUES DU CYCLE DE VIE DUN LOGICIEL...............................6 2.2MODELES DE CYCLE DE VIE DUN LOGICIEL ...........................................................6 2.2.1Modles squentiels ...................................................................................................... 7 2.2.2Modles volutionnistes................................................................................................ 7 2.2.3Processus unifi............................................................................................................. 8 3.APPROCHE DE REUTILISATION........................................................................................9 3.1DEVELOPPEMENT BASE COMPOSANT CBD...............................................................9 3.2RACINES DU CBD............................................................................................................10 3.3PROCESSUS DE DEVELOPPEMENT DAPPLICATIONS BASES COMPOSANTS ..11 3.3.1Notion de rutilisation................................................................................................. 12 3.3.2Processus de rutilisation ............................................................................................ 14 3.3.3Cycle de vie pour le CBD ........................................................................................... 17 3.4INGENIERIE LOGICIELLE BASEE COMPOSANT (CBSE) .........................................22 3.4.1Concepts de base ......................................................................................................... 22 3.4.2Relation entre concepts ............................................................................................... 27 3.4.3Notion de composant................................................................................................... 28 4.CONCLUSION .........................................................................................................................33 CHAPITRE II : ECATNETS ET LOGIQUE DE REECRITURE.............................................34 1.INTRODUCTION.....................................................................................................................34 2.RESEAUX DE PETRI..............................................................................................................35 2.1DEFINITIONS DE BASE...................................................................................................35 2.2REGLE DE FRANCHISSEMENT.....................................................................................35 2.3REPRESENTATION GRAPHIQUE DUN RESEAU DE PETRI ....................................36 2.4PROPRIETES COMPORTEMENTALES DUN RDP......................................................36 3.RESEAUX DE PETRI DE HAUT NIVEAU..........................................................................37 3.1DEFINITION DUN HLPN................................................................................................37 3.2RESEAUX DE PETRI ALGEBRIQUES DE HAUT NIVEAU.........................................38 4.LOGIQUE DE REECRITURE ET MAUDE.........................................................................39 4.1DEFINITIONS DE BASE...................................................................................................39 4.2SYSTEMES DE REECRITURE.........................................................................................40 4.3LOGIQUE DE REECRITURE ...........................................................................................41 4.3.1Rseau de Petri dans la logique de rcriture.............................................................. 43 4.3.2Maude.......................................................................................................................... 45 5.ECATNETS...............................................................................................................................50 5.1DEFINITION FORMELLE DUN ECATNETS................................................................51 5.2SYNTAXE DES ECATNETS.............................................................................................52 5.3SEMANTIQUE DES ECATNETS .....................................................................................53 5.4EXEMPLES DE MODELISATION AVEC LES ECATNETS..........................................57 5.4.1Prsentation de lexemple1 ......................................................................................... 57 5.4.2Prsentation de lexemple2 ......................................................................................... 60 6.CONCLUSION .........................................................................................................................61 CHAPITRE III : MODELISATION DES LOGICIELS A BASE DE COMPOSANTS AVEC LES ECATNETS .................................................................................................................63 1.INTRODUCTION.....................................................................................................................63 2.TRAVAUX VOISINS...............................................................................................................63 3.PRESENTATION DE LAPPROCHE DE MODELISATION ...........................................65 3.1SPECIFICATION DU SYSTEME......................................................................................66 3.1.1Service requis (Rceptacle)......................................................................................... 68 3.1.2Service offert (facette)................................................................................................. 69 3.1.3Evnement offert (source)........................................................................................... 70 3.1.4Evnement requis (puit) .............................................................................................. 70 3.1.5Spcification des connexions ...................................................................................... 71 3.2GENERATION DES REGLES DE REECRITURE...........................................................73 3.3VERIFICATION DU SYSTEME.......................................................................................73 4.ETUDE DE CAS .......................................................................................................................74 4.1PRSENTATION DE LEXEMPLE1................................................................................75 4.1.1GetButton .................................................................................................................... 76 4.1.2PutButton..................................................................................................................... 78 4.1.3MyBuffer..................................................................................................................... 78 4.1.4PutTextField................................................................................................................ 81 4.1.5GetTextField................................................................................................................ 82 4.1.6PutAdapter et GetAdapter ........................................................................................... 83 4.2PRESENTATION DE LEXEMPLE 2...............................................................................87 4.2.1Spcification du systme............................................................................................. 88 4.2.2Gnration des rgles de rcriture ............................................................................. 94 4.2.3Vrification du systme............................................................................................... 95 5.CONCLUSION .......................................................................................................................102 CONCLUSION GENERALE ET PERSPECTIVES..................................................................103 REFERENCES...............................................................................................................................105 LISTE DES FIGURES FIGURE 1 LE MODELE SEQUENTIEL.......................................................................................7 FIGURE 2 LES QUATRE PHASES DE LUP ET CES ACTIVITES ..........................................8 FIGURE 3 INGENIERIE POUR LA REUTILISATION ET INGENIERIE PAR REUTILISATION..............................................................................................................................17 FIGURE 4 MODELE EN V ADOPTE POUR LE DEVELOPPEMENT BASE COMPOSANT ...................................................................................................................................19 FIGURE 5 MODELE EN Y POUR LE DEVELOPPEMENT LOGICIEL BASE COMPOSANT ...................................................................................................................................20 FIGURE 6 EXEMPLE DE DEFINITION DINTERFACE EN IDL...........................................24 FIGURE 7 LA STRUCTURE DU PATTERN OBSERVER.......................................................26 FIGURE 8 RELATION ENTRE LES CONCEPTS POUR UNE APPLICATION BASEE COMPOSANTS....................................................................................................................27 FIGURE 9 REPRESENTATION GRAPHIQUE DUN RDP MODELISANT UNE REACTION CHIMIQUE..................................................................................................................36 FIGURE 10 RDP DUNE MACHINE VENDEUSE DE TARTES ET DE POMMES.................44 FIGURE 11 REPRESENTATION GENERIQUE DUN ECATNET............................................52 FIGURE 12 CELLULE DE PRODUCTION..................................................................................57 FIGURE 13 MODELE ECATNET DE LA CELLULE DE PRODUCTION................................59 FIGURE 14 MODELE ECATNET DU MODULE DEBUT DE TRANSMISSION DUNE STATION EMETTRICE ETHERNET.................................................................................60 FIGURE 15 ETAPES DE LAPPROCHE DE MODELISATION DES LOGICIELS A BASE DE COMPOSANTS................................................................................................................66 FIGURE 16 SPECIFICATION DUN COMPOSANT LOGICIEL...............................................67 FIGURE 17 SPECIFICATION DUN SERVICE REQUIS (RECEPTACLE) ..............................68 FIGURE 18 SPECIFICATION DUN SERVICE OFFERT (FACETTE) .....................................69 FIGURE 19 MODELE GENERALE DUN SERVICE OFFERT (FACETTE)...........................70 FIGURE 20 SPECIFICATION DUN EVENEMENT SOURCE..................................................70 FIGURE 21 SPECIFICATION DUN EVENEMENT PUIT.........................................................70 FIGURE 22 SPECIFICATION DUNE CONNEXION : EVENEMENT SOURCE /PUIT..................................................................................................................................................71 FIGURE 23 SPECIFICATION DUNE CONNEXION : SERVICES OFFERTS / REQUIS..............................................................................................................................................72 FIGURE 24 INTERFACE UTILISATEUR DE LEXEMPLE......................................................75 FIGURE 25 SYNTAXE IDL3 POUR UN SOURCE.....................................................................76 FIGURE 26 SYNTAXE IDL3 POUR UN PUIT............................................................................76 FIGURE 27 SPECIFICATION DU COMPOSANT GETBUTTON EN IDL3..............................76 FIGURE 28 MODELE ECATNET DU COMPOSANT GETBUTTON.......................................77 FIGURE 29 SPECIFICATION FORMELLE DU COMPORTEMENT DU COMPOSANT GETBUTTON ..........................................................................................................77 FIGURE 30 SPECIFICATION DU COMPOSANT PUTBUTTON EN IDL3..............................78 FIGURE 31 SYNTAXE IDL3 POUR UNE FACETTE.................................................................79 FIGURE 32 SPECIFICATION DU COMPOSANT MYBUFFER EN IDL3................................79 FIGURE 33 MODELE ECATNET DU COMPOSANT MYBUFFER..........................................80 FIGURE 34 SPECIFICATION FORMELLE DU COMPORTEMENT DU COMPOSANT MYBUFFER.............................................................................................................80 FIGURE 35 SPECIFICATION DU COMPOSANT PUTTEXTFIELD EN IDL3 ........................81 FIGURE 36 MODELE ECATNET DU COMPOSANT PUTTEXTFIELD..................................81 FIGURE 37 SPECIFICATION FORMELLE DU COMPORTEMENT DU COMPOSANT PUTTEXTFIELD .....................................................................................................82 FIGURE 38 SPECIFICATION DU COMPOSANT GETTEXTFIELD EN IDL3 ........................82 FIGURE 39 MODELE ECATNET DU COMPOSANT GETTEXTFIELD..................................82 FIGURE 40 SPECIFICATION FORMELLE DU COMPORTEMENT DU COMPOSANT PUTTEXTFIELD .....................................................................................................83 FIGURE 41 SYNTAXE IDL3 POUR UNE FACETTE.................................................................83 FIGURE 42 SPECIFICATION DU COMPOSANT GETADAPTER EN IDL3 ...........................83 FIGURE 43 SPECIFICATION DU COMPOSANT PUTADAPTER EN IDL3............................83 FIGURE 44 MODELE ECATNET : (A) GETADAPTER, (B) PUTADAPTER...........................84 FIGURE 45 SPECIFICATION FORMELLE DU COMPORTEMENT DU COMPOSANT ...................................................................................................................................84 FIGURE 46 ASSEMBLAGE FORMEL DES COMPOSANTS ....................................................85 FIGURE 47 SPECIFICATION COMPORTEMENTALE FORMELLE DE LASSEMBLAGE DE COMPOSANTS ...........................................................................................86 FIGURE 48 DIAGRAMME DACTIVITE UML DU PROCESSUS DE RESERVATION ................................................................................................................................87 FIGURE 49 MODELE ECATNET DU COMPOSANT AGNECEVOYAGE..............................88 FIGURE 50 MODELE ECATNET DU COMPOSANT RESERVHOTEL...................................89 FIGURE 51 MODELE ECATNET DU COMPOSANT RESERVVOL........................................90 FIGURE 52 ASSEMBLAGE FORMEL DES COMPOSANTS ....................................................91 FIGURE 53 SPECIFICATION COMPORTEMENTALE FORMELLE DE LASSEMBLAGE DE COMPOSANTS ...........................................................................................92 FIGURE 54 SPECIFICATION EN MAUDE DU MODULE FONCTIONNEL DUN COMPOSANT ECATNETS..............................................................................................................95 FIGURE 55 SPECIFICATION EN MAUDE DU MODULE SYSTEME DE LAPPLICATION..............................................................................................................................96 FIGURE 56 CHARGEMENT DE LA SPECIFICATION PAR LA COMMANDE LOAD ..............................................................................................................................................98 FIGURE 57 RESULTAT DEXECUTION DE LA SPECIFICATION.........................................98 FIGURE 58 RESULTAT DEXECUTION DE LA COMMANDE SEARCH .........................100 FIGURE 59 RESULTAT DEXECUTION DE LA COMMANDE SHOW PATH..................101 Introduction gnrale 1 Introduction gnrale Noussommestmoindunenormeexpansiondanslutilisationdulogicieldansles entreprises, lindustrie, ladministration, la recherche et mme dans la vie quotidienne. Le logiciel nest plus utilis marginalement dans les systmes techniques ; au lieu de cela il est devenuunfacteurcentraldansbeaucoupdedomaines.Lessystmesbasssurdes fonctionnalitslogiciellesdeviennentlefacteurleplusimportantdansunmarch comptitif. Cette tendance, a augment les exigences sur les produits logiciels tels quune rentabilitmeilleure,larobustesse,lafiabilit,laflexibilit,ladaptabilit,etune installationetundploiementplussimpledecesderniers.Aumomentoucesdemandes augmentefortement,lacomplexitdesprocessusquelelogicieldoitcontrleraugmente avec la demande pour lintgration des processus de diffrents secteurs. Par consquent, les programmeslogicielsdeviennentdeplusenplusgrandsetcomplexe.Ledfiprincipal pourlesdveloppeursdelogicielsaujourdhuiestdefairefacelacomplexitetde sadapter rapidement au changement.Lesapprochesclassiquesdedveloppementdelogicielontadresslesdfisdela complexitcroissantesetdeladpendancedeslogicielsexternesensefocalisantsurun systmelafois,etsurlasatisfactiondescontraintestemporellesetfinanciresde livraisonduproduitsansconsidrerlesbesoinsvolutionnistesdusystme[1].Se concentrersurunsystmelafois et ngliger les changements qui peuvent se produire a menuncertainnombredeproblmes:lchecdelamajoritdesprojetsasatisfairela contraintededatelimite(deadline),debudget,dequalitaussibienquelaugmentation continue des cots associe la maintenance du logiciel. Une solution cl ces problmes est le Dveloppement Bas Composant DBC1. Cette approchemergentedudomainedelingnierielogicielleestbasesurlarutilisation, o les systmes logiciels sont construits en assemblant des composants dj dvelopps et prpars pour lintgration. Ainsi, elle possde lavantage de fournir des systmes logiciels dequalitmeilleureenuntempspluscourt.Construireuneapplicationestdonc considre, non pas comme un dveloppement intgral et complet ( partir de zro), mais commeunassemblagedepicesrutilisables.Danscedomaine,lestechnologiesqui supportelaconstructionetlassemblagedecomposantsontatteintunpremierniveaude maturit,enparticulieraveclapparitiondestechnologiesdecomposantsstandardstelles

1 Nous utiliserons dans le reste de ce mmoire lacronyme anglais CBD (Component-Based Development) la place de lquivalent franais DBC. Introduction gnrale 2 queEJB(EnterpriseJavaBeans),CCM(CORBAComponentModel),ou(D)COM( (Distributed) Component Object Model). LecurduCBDestlecomposant.Uncomposantlogicielestconsidrcommeune boitenoireetestdcritparcesinterfacestraverslesquellesilpeutinteragiravecles autres composants dans le systme. Il offre des services et requiert dautres pour accomplir cesfonctionnalits.Lebutultimedudveloppementlogicielbascomposantest lassemblageeffectuparlestiercesparties.Pourcefaire,ilestncessairedtreen mesuredespcifierlescomposantsdefaoncequenouspouvonsraisonnersurleurs constructions et leurs compositions [46]. Les spcifications de composants utiliss dans la pratique du dveloppement logiciels, sontaujourdhuiessentiellementlimitescequenousappelionslesspcifications syntaxiques.Cetteformedespcificationcomprendlesspcificationsutilisesdansdes technologiescommeCOM,CORBA,etJavaBeans[1].Lesdeuxpremiresutilisentles IDLs(InterfaceDescriptionLangage),alorsqueletroisimeutiliselelangagede programmationJava.Or,lesspcificationssyntaxiquesnoffrepassuffisamment dinformationssurlasmantiquedesoprationsquidfinissentlesinterfacesdun composant,cequipeutaidermieuxlesinspects,lesvalus,etcomprendreleurs comportements. Lesmthodesdespcificationformellessontdebonscandidatspourlaspcification descomposantslogiciels.Onentendparmthodesformelles,leslangages,techniques,et les outils bass sur la logique mathmatique [47]. En effet la base des mthodes formelles est de nous permettre de construire des modles mathmatiques avec une smantique bien dfiniedusystmeanalyser.LesrseauxdePetrisontconsidrscommedes formalismesdespcificationdotsdunedfinitionformellepermettantdeconstruiredes modlesexemptsdambigut.Ilspossdentungrandpouvoirdexpressionfacilitantla description des systmes complexes, concurrent et distribus. LesECATNets[48](ExtendedConcurrentAlgebraicTermNets)constituentune catgoriedesrseauxdeptrialgbriquesdehautsniveaux.Ilsonttproposscomme tant une manire pour la spcification, la modlisation, et la validation des applications du domainedesrseauxdecommunication,laconceptiondesordinateurs,etdautres systmescomplexes.Ilssontconstruitsautourdunecombinaisondetroisformalismes. Les deux premiers formalismes constituent un modle rseau/donnes, et sont utiliss pour ladfinitiondelasyntaxedusystme,endautrestermespourcapturersastructure.Le modledurseau,quiestuntypederseauxdePetriavanc,estutilispourdcrire larchitectureduprocessusdusystme,lemodlededonnes,quiestunformalisme algbriqueestutilispourspcifierlesstructuresdedonnesdusystme.Letroisime formalisme,quiestunelogiquedercritureestutilispourdfinirlasmantiquedu systme, en dautres termes, pour dcrire son comportement. Introduction gnrale 3 Lobjectifdelingnierielogiciellebasecomposant(CBSE)estdaccrotrela productivit, la qualit, et le temps de mise sur le march dans le dveloppement logiciels. Les techniques dingnierie logicielles base composant dans les phases, de modlisation, devrification,oudevalidationdessystmeslogicielsbasedecomposantsrestent insuffisantes et demande plus defforts de recherche. Notre travail sinscrit dans le vaste domaine du gnie logiciel base de composants. Sonobjectif,estdeproposeruneapprocheformellepourlamodlisationdeslogiciels basedecomposantenutilisantlesECATNets.NotrechoixsurlesECATNetsestmotiv dune part, par la puissance dexpression de ces derniers dus leurs notations syntaxiques trsrichesbasessurunformalismealgbrique,permettantdefournirdesmodles hautement compacts. Dautre part, ils possdent une smantique saine dfinit en terme de lalogiquedercriturepermettantdexprimerremarquablementetintuitivementle comportementdynamiqueetleparalllismequicaractriselessystmesdistribus.Elle donneaussilapossibilitdappliquerlavrificationformelleparlebiaisdespcification excutable exprime en langage Maude, le langage de la logique de rcriture. Dansnotreapprochenousdistinguonstroistapes ;lapremireconsisteenla spcificationdesinterfacesdechaquecomposantdanslesystmebasedecomposants ainsi que, les connexions entre eux en utilisant les notations proposes. Le rsultat de cette tapeestunmodleECATNetreprsentantlaspcificationdunassemblagede composants. Dans la deuxime tape, le comportement dynamique du systme est exprim pardesrglesdercrituregnrespartirdumodlespcifidansltapeprcdente. La dernire tape reprsente la vrification du systme via une spcification excutable en langageMaudequiintgrelesrglesdercritureengendresdansltapeprcdente.A travers ce travail nous esprons atteindre les objectifs suivants : Premirement,offrirunenotationconvenablepourdcrirelecomportement interne des composants logiciels concurrents et distribus. Deuximement,offrirunesmantiqueformellenonambigupourles caractristiques des composants logiciels. Troisimement,offrirunraisonnementformelsurlassemblagedescomposants logiciels. Quatrimement, permettre la vrification formelle du systme modlis.Ce mmoire est structur suivant trois chapitres : -Danslepremierchapitrenousallonsintroduirelesapprochesclassiquesdu dveloppementlogiciel,ensuitenousprsenteronslapprochededveloppement logicielbasedecomposantsetlesnotionsquiluisontreliestellanotionde rutilisation,composantlogiciel,etc.Nousparleronsventuellementdesracinesde cetteapprocheetdequelquesmodlesdecyclesdeviequionttpropossdansson contexte. Introduction gnrale 4 -LedeuximeestdestinlaprsentationdesECATNetsetlalogiquedercriture. NouscommenonsparunbrefsurvolsurlesRdPs,puisnousintroduisonslalogique dercritureetsonlangageMaudecommetantunFrameworkquiintgreles ECATNets. Ensuite nous dtaillons ces derniers et nous montrerons comment peuvent-ils tre utiliss pour la spcification des systmes.-Ledernierchapitreestconsacrlaprsentationdenotreapprochepourla modlisation des logiciels base de composants. -Le prsent mmoire est achev par une conclusion gnrale et des perspectives. CHAPITRE I Dveloppement logiciel base de composants 5 CHAPITRE I : Dveloppement logiciel base de composants 1.Introduction Lessystmeslogicielsmodernessontdeplusenplusgrands,complexesetmal contrls, ce qui a entran des cots de dveloppement levs, une faible productivit, et unequalitincontrlabledesproduitslogiciels[8].Parconsquent,ilyaunedemande croissante pour la recherche dun nouveau paradigme du dveloppement logiciel, efficace et rentable. Une solution cl ces problmes est le Dveloppement Bas Composant CBD. Cette approchemergentedudomainedelingnierielogicielleestbasesurlarutilisation, o les systmes logiciels sont construits en assemblant des composants dj dvelopps et prpars pour lintgration. Cette approche va tre le sujet de ce chapitre dans lequelnous allonsprsentplusdedtails,maisavantcela ;ilestintressantdecepositionnerdans lchelle de la chronologie des choses, et jeter un coup dil sur les approches classiques dedveloppementlogicielparunhistoriquenondtaillsurcesderniersquimontreleur volution dans le temps. 2.Processus logiciel Toutlogiciel,particulirementlesgrandslogicielsproduitsparbeaucoupdegens, devrait tre produit en utilisant un certain type de mthodologie. Une mthodologie est une maniresystmatiquedefaireleschoses.Cestunprocessusrptitifquenouspouvons suivrepartirdespremierspasdudveloppementlogicieljusqulamaintenancedun systme oprationnel [2]. Un systme logiciel peut tre considr dun point de vue cycle de vie. Ceci signifie quon observe le systme depuis la premire notion de son existence jusqusonfonctionnementetsagestion[1].Plusieursdiffrentesapprochesontt proposespourledveloppementducycledeviedunlogiciel,cesderniressonttoutes basessurlesmmesactivitsetsediffrentseulementparlamaniredontellessont ralises. CHAPITRE I Dveloppement logiciel base de composants 6 2.1 Activits gnriques du cycle de vie dun logicielCest sans doute Royce (1970) qui, tait le premier, a propos un modle du cycle de vie. Depuis, de nombreuses amliorations et modifications y ont t apportes [49]. Il y a uncertainnombredephasescommuneschaquedveloppement,indpendammentdela mthodologie,encommenantparlacapturedesbesoinsetfiniraveclamaintenance. Nousallonsessayerdanscequisuitdeprsenterunebrvedescriptiondesdiffrentes phases constituant le cycle de vie dun systme logiciel daprs [1]. a.Analyse de besoins et spcification du systmeDanscettephaselesservices,lescontraintes,etlesobjectifsdusystmesonttablis. Ils sont dfinis en dtail et servent de spcification au systme. b.Conception du systme et du logiciel Laconceptiondulogicielimpliquedidentifieretdedcrirelesabstractions fondamentales du systme logiciel et les relations entre elles. Une architecture globale pour le systme est dfinie suivie dune conception dtaille. c.Implmentation et tests unitaires La formalisation de la conceptionsous une forme excutable. Elle peut tre compose de petites units. Les units sont vrifies vis--vis de leurs spcifications. d.Intgration, vrification du systme et validation Les units du systme sont intgres;le systme complet est vrifi, valid, et dlivr au client. e.Opration de support et maintenanceLesystmeestoprationnel.Ilrequiertunsupportcontinuetdesoprationsde maintenance.f.Suppression du systme Cetteactivitestsouventoublie dans le cycle de vie dun systme. Elle concerne la suppression propre du systme et ventuellement son remplacement par un autre. 2.2 Modles de cycle de vie dun logiciel Ilfautuntempsconsidrablepourdvelopperungrandsystmelogicielqui, dailleurs,serautilispendanttrslongtemps.Onidentifiedoncuncertainnombre dtapesdistinctesdanscettepriodededveloppementetdutilisation ;cestapes constituent le cycle de vie du logiciel. Plusieurs diffrentes approches pour le cycle de vie de dveloppement dun logiciel sont considres ci-dessous ainsi quune brve description de leurs caractristiques de base. Dans la littrature en trouve plusieurs classification de ces approches les sparant en deux classes : modles linaire et modles non linaire, ou bien modles squentiel et modles volutionnistes. Nous avons adopt la deuxime appellation qui est la plus utilise. CHAPITRE I Dveloppement logiciel base de composants 7 2.2.1Modles squentiels Lemodlesquentiel(parexemple,lemodleencascadedeRoyce1970)suitune approchesquentiellesystmatiquequicommenceauniveaudusystmeetprogresse successivementdelanalysejusqularalisation.Chaqueactivitdoittreconsidre commeapprouveavantquelaprochaineactivitcommence.Lasortieduneactivitest lentre de la prochaine. Cette approche pour le dveloppement de logiciel (figure 1) est la plus vieille et la plus rpandue. Beaucoupdeproblmesmajeursdanslingnierielogiciellersultentdufaitquilest difficilelutilisateurdexprimerexplicitementtouslesbesoins.Lemodlesquentiel exige la spcification complte des besoins ce quipeut causer des difficults dadaptation facelincertitudenaturellequiexisteaudbutdebeaucoupdeprojets.Ilestgalement difficile dajouter ou changer des besoins durant le dveloppement car, une fois ralises, lesactivitssontconsidrescommeaccomplies.Unautreproblmeparfoisrencontr quand un modle squentiel est appliqu est la rponse en retard au client. Cette approche rigide souffrira toujours du fait dtre concentr rsoudre un problme particulier, ce qui rend la tache de produire du code rutilisable plus difficile et par consquent mal adapte au monde composant [3]. 2.2.2Modles volutionnistes Lesmodlesvolutionnistepermettentdedvelopperunsystmegraduellementpar itrationssuccessives.Achaquetape,lersultatdusystmeestmontrses commanditaires et leurs remarques sont prises en compte pour faire voluer le systme [3]. Lintrt de ce type de modle est de rduire fortement le risque de dcouvrir un problme crucial tard dans le cycle de dveloppement. Il permet galement une meilleure gestion des changements de besoins apparaissant durant le processus de dveloppement. Le problme decetypedeprocessusestquilpeutengendrerunnombrecoteuxditrations.Ilpeut, parexemple,tredifficilededterminerlenombreexactditrationslavance,etde nouvellesitrationspeuventtreajoutessilesbesoinschangentouvoluent.Ilexiste plusieurs types de modles volutionnistes. Lapproche itrative, le modle incrmental, le modle par prototypage, et enfin, le modle spirale dfini par Boehm [4]. Fig. 1 Le modle squentiel [1] Analyse Conception Implmentation Intgration Test CHAPITRE I Dveloppement logiciel base de composants 8 2.2.3Processus unifi Le processus de dveloppement logiciel unifi (UP2) dfinit par Jacobson et al [5] est unprocessusdedveloppementdesystmeoptimispourlesapplicationsobjetsetles systmes base de composants. Il sagit dun dveloppement incrmental itratif compos de quatre phases : 1.Analysedesbesoins,cestlaphaseolesystmeestdcritdunemanire formalise, fournissant ainsi une base pour le dveloppement ultrieur; 2.Elaboration, lors de cette phaselarchitecture du systme est dfinie et cre; 3.Construction,ledveloppementdesproduitscompltementnouveaux,avecdes possibilits de rutilisation; 4.Transition,concernelalivraisondusystmeauclient.Cettephaseinclut linstallation du systme et la formation de ses utilisateurs. Pourchacunedecestapes,ilyaplusieursitrationsdesactivitsclassiques.Ces activitsseproduisentdanschacunedesquatrephases,Analysedesbesoins,laboration, construction, et transition. Cest la partie itrative de lUP. La partie incrmental est base surlefaitquelesitrationsrussiesaurontcommeconsquenceledgagementdun systme.Cemodleestmieuxadaptaumondecomposant.Deplus il est souvent utilis avecUML,dontlaversion2.0prendencomptelaconceptiondesapplicationsbasede composant.

2 Unified Process Implmentation Analyse desbesoins Expression des besoins Analyse ConceptionFig. 2 Les quatre phases de lUP et ces activits [1] Une itration dans la phase Test Elaboration Construction Transition Phases Itrations CHAPITRE I Dveloppement logiciel base de composants 9 3.Approche de rutilisation Lessystmeslogicielsmodernesdeviennentdeplusenplusgrands,complexeet difficile contrler, rsultant en un cot de dveloppement lev, une productivit faible, unequalitincontrlabledulogicieletlegrosrisquepoursedplacerversunenouvelle technologie[8].Parconsquence,ilyaunedemandecroissantesurlarecherchedun nouveau paradigme efficace, et rentable pour le dveloppement de logiciel. Une des solutions les plus prometteuses est aujourdhui lapproche de dveloppement delogicielbascomposant(CBD).Cetteapprocheestbasesurlidequelessystmes logicielssontconstruitsenassemblantdescomposantsdjdveloppsetprparspour lintgrationavecunearchitecturelogicielbiendfinit[1].Cettenouvelleapprochede dveloppementdelogicielestdiffrentedesapprochestraditionnellesdanslesquellesles systmes logiciels sont construits partir de zro.3.1 Dveloppement bas composant CBDLespraticiensdfinissent ledveloppement bas composant (CBD) comme approche danslaquelletoutArtefact(codeexcutable,spcificationdinterface,architectures, modles, et partant du plus haut niveau des applications et des systmes complets jusquau niveau des composants individuels) peut tre construit en assemblant, adaptant, et en liant les composants existant ensemble dans une varit de configurations [12]. Cettedfinitionmetenreliefunaspectimportantdudveloppementbascomposant (CBD),savoirlacapacitdeconstruiredessystmesparassemblagesdecomposants prexistants.Dautrepart,afindepouvoirassemblerdescomposants,cescomposants doiventdabordexister.Plusieursorganismesprtendentquilsconstruisentdeslogiciels en utilisant une approche base composant, et que lindustrie entire est apparemment dans unefrnsiedadoptionduCBD.UneautredfinitionquiatdonneauCBDestla suivante :Ledveloppementbascomposantestuneapprochededveloppementlogicielo tous les aspects et phases du cycle de vie y compris lanalyse de besoins, la conception, la ralisation,test,dploiement,lesinfrastructurestechniquessupports,etgalementla gestion de projet, sont bass sur les composants [12]. Cette dfinition montre explicitementque le dveloppement bas composant consiste en la construction de logiciel en utilisant un raisonnement bas composant dans la mesure o tout le dveloppement logiciel sera centr sur les composants. CBD est extrmement bnficial non seulement quand les composants sont disponibles pour lassemblage, mais aussi si ces composants doivent tre construits en tantdeslmentsduprojet.Eneffet,penserunsystmedinformationentermesde composants, mme si ces composants nexistent pas, est la meilleure manire de matriser les complexits de dveloppement de grand systme distribu aujourdhui. CHAPITRE I Dveloppement logiciel base de composants 10 3.2 Racines du CBD Construire des systmes complexes partir de composants plus simples nest pas une inventiondelindustrielogicielle.Ilyaplusdedeuxsicles,EliWhitneyaproposla fabrication de fusils avec des pices remplaables spcifis clairement selon des modles, aulieudeconstruirechaquefusilindividuellement.Largementconsidrcommele commencementdefabricationensrie,cettestratgiedescomposantsremplaablesa menuneaugmentationimpressionnantedelacapacitdeproduction,enoutreellea fournit des avantages additionnels tel que, des oprations fiables et une maintenance facile dans divers secteurs industriels, et elle est devenu une approche standard dans par exemple la construction de divers dispositifs lectroniques et dans lingnierie des systmes avancs [10].Dansledomainedelingnieriedessystmesdinformation,leCBDestgalement considr comme une approche volutionniste plutt que rvolutionnaire.Il a exist dans uneformeouuneautrependantuncertainnombredannes.Lidedeconstruireun systmelogicielmodulaireatlongtempsreconnuecommeavantageuseauseindela communautsoftware. Ceci remonte aux jours de la programmation structure en utilisant dessous-programmesetdesbibliothquesservantdecomposants.Lesprogrammesont tconstruitsencrantunprogrammeprincipalpourcontrler(ouappeler)uncertain nombre de sous-programmes. Pour rduire les efforts de programmation, les programmeurs dans une quipe de projet rutilisaient des sous-programmes durant la ralisation du projet [11]. Durant la confrence de lOTAN de lingnierie logicielle, en 1968, M. D. Mcilory a prsent le concept de composants logiciels. Ces derniers ont t vus comme solution pour la crise logicielle [10]. Depuislafindesannes70jusquauxannes80,lesingnieursutilisaientune mthodologiededveloppementlogicielstructurepourdiviserunsystmeenuncertain nombredemodulesensebasantsursesbesoinsfonctionnelles.Aprsquelesmodules aienttdvelopps,ilslesintgrentpourformerunsystme.Durantcettepriodede temps,beaucoupdebibliothquesdefonctiononttdveloppesenlangagede programmationFortrancommetantdespackagesrutilisablespoursupporterle dveloppement dapplications scientifiques. Ces packages peuvent tre considrs comme la premire gnration de composants logiciels [11]. Durantlesannes90lestechniquesorientesobjetonttconsidrescommeun moyenpuissantpourrsoudreleproblmedelacriselogiciellegrceauniveaulevde rutilisationetdemaintenanceatteintparcesderniers.Quelquesauteursontcitquele CBD est une extension et volution naturelle du paradigme orient objet, et quil contient beaucoup de caractristiques et de concepts semblables. Dautres insistent sur lchec de la technologieobjetpourrsoudrelesproblmesderutilisationdeslogicielsetsurlancessitdintroduireunnouveauparadigmededveloppementdecomposant[10].Le travail ralis par Nierstrasz (1995) qui est en relation avec la composition logicielle pour lessystmesouvertsdistribus,peuttreconsidrcommeuneimportantecontribution CHAPITRE I Dveloppement logiciel base de composants 11 aux futurs concepts et ides du CBD. Au cours des dernires annes la recherche lie aux composants a galement t mene sur divers sujets tels que les langages dinterconnexion demodule(MILs3),spcificationetanalysedesinterfacesdemodule,gnrateursde logiciel,lesFrameworksorientsobjetsetlespatterns,langagesdedescription darchitecture (ADLs4). Lescomposantsonttinitialementintroduitsauniveauimplmentationpourla constructionrapidedinterfaceutilisateurgraphiqueenutilisantVBX(VisualBasic eXtensions)ouJava.Aprs,MicrosoftActiveX/DCOM/COM,objetsetservicesde CORBA,etJavaBeans,suivisdeMicrosoftCOM+/.NET,lescomposantsCORBAet EntrepriseJavaBeans(EJB)onttproposscommedestechnologiesdecomposants standards.Lobjectif commun de toutes ces initiatives est de basculer depuis le dveloppement de petitssystmesmonolithiquescentralissversledveloppementdesystmescomplexescompossdunitsfonctionnellesdployessurlesnoeudsduWeb.Lesdeuxconcepts principaux qui ont merg sont [10]: 1.Les composants en tant que entits dun systme de granularit forte. 2.LesarchitecturesetlesFrameworkscommemodlesdesystmedcrivantses principaux modules et la manire de les composer en un tout cohrent. 3.3 Processus de dveloppement dapplications bass composants UndesobjectifsduCBDestdegnraliserlarutilisationdemoduleslogiciels. Lintrtmajeurdelarutilisationestderduireleffortdedveloppementenrutilisant despartiesdelogicielsdjdveloppes.Plusuncomposantestrutilis,plusles ventuels bogues quil pouvait contenir peuvent avoir t dtects et corrigs.Leprocessusdedveloppementdesapplicationsbasescomposantsrepose globalementsurlesmmesactivitsqueledveloppementduneapplicationclassique. Cependant, il diffre des dveloppements traditionnels notamment travers sa focalisation surlidentificationdentitsrutilisablesetlesrelationsentre-ellesetce,notamment partirdelanalysedesbesoins.Larutilisationdecomposantsimpliqueunprocessus didentification et de slection du composant rutiliser, voir un processus de spcification decelui-cienvuedesondveloppementdanslecasoilnexisteraitpas.Laspect modularit implique un effort important de la conception de larchitecture de lapplication, cequintaitpasforcmentlecasdanslesdveloppementsclassiques.Lesmodlesde dveloppement classiques se prtent plus ou moins supporter le dveloppement base de composants.

3 Module Interconnection Languages 4 Architecture Description Languages CHAPITRE I Dveloppement logiciel base de composants 12 Comme on la cit plus haut dans ce chapitre, le modle squentiel correspond une tudesquentielledusystme,delaphasederecueillementdesbesoinsjusqulafindu cycledevie.Chaqueactivitesttermineavantdepasserlasuivante.Cetteapproche rigideestmaladapteaumondecomposant.Eneffet,ledveloppementbasede composantsesttypiquementundveloppementodesphasespeuventtremenesen parallle.Parexemple,silaphasedanalysedterminelebesoinspcifiquedun composant particulier, le modle squentiel implique de terminer la phase danalyse avant despcifierlecomposantdvelopper.Or,ilauraitpeuttretaitplusprudentde commanderledveloppementdececomposant,unventuelfournisseur,leplustt possible, de manire tenir compte de son temps de dveloppement.Outrelemodlesquentiel,lesmodlesvolutionnistesaussisontmaladaptsau mondecomposantcarellesnontpastaientconuesautourdelaproblmatiquedela rutilisation. Le processus unifi est mieux adapter au monde composant car il estsouvent utilisavecUML(UnifiedModellingLanguage)dontlaversion2.0prendencomptela conceptiondesapplicationsbasedecomposantcommedjmentionnplushaut. Cependant[3],ilnetraiterellementlesaspectsrutilisationquelorsdelaphase dimplmentation, ce qui est trop tard la plus part du temps, pour une rutilisation efficace. Les modles de lingnierie logicielle classique pouvaient tre utiliss comme base pour le dveloppementdapplicationbasedecomposants.Ilssonttoutefoismaladaptset notammentsurdeuxaspects[13].Premirement,larutilisationdecomposantsest gnralement envisage trop tard dans le cycle de vie du logiciel, notamment aprs que la conceptiondtailleaittfinalise,alorsquunerutilisationoptimaledescomposants requiertgalementlarutilisationdesarchitectureslogicielles.Deuximement,aucune mthode existante ne donne de consigne prcise sur la manire dont un composant doit tre dvelopp pour tre rutilisable. Les mthodes classiques devront donc tre adaptes pour prendre en compte les particularits de ce type de dveloppement, notamment en insistant surlesaspectsdveloppementdecomposantsrutilisables,maisaussisurlesaspects dveloppement de systmes partir de composants [14]. Nousallonsessayerdanslesprochainessectionsdexpliquerleprocessusde dveloppement des applications base de composants et de prsenter quelques modles de cycledeviepourledveloppementbascomposant,cesderniersreprsententlesefforts deschercheursdurantcesderniresannesdanslingnierielogiciellebasecomposant CBSE5.Maisavantcelanousnouspenchonssurquelquesaspectsimportantqui caractrisent le processus de dveloppement des applications base de composants. 3.3.1Notion de rutilisationLedveloppementbascomposantCBD,provientdelarutilisation.Lapprochede rutilisation nest pas nouvelle. La rutilisation est la philosophie de trouver des ressources appropries, telle des modles, des diagrammes, des fragments de code, ou de composants,

5 Nous utiliserons dans le reste de ce mmoire lacronyme anglais CBSE (Component-Based Software Engineering) la place de lquivalent franais ILBC.CHAPITRE I Dveloppement logiciel base de composants 13 quipeuventfournirunesolutiondedpart.Larutilisationestunephilosophiede dveloppementdesystmesquipeuttreadoptedansuneorganisationsielleveut atteindre son potentiel en termes dune rduction du temps de dveloppement du projet et dune minimisation des cots [16]. La rutilisation fut voque en 1968 par M. McIlroy dans une confrence de lOTAN surlingnieriedulogiciel,suiteaunchecpatentdelapartdedveloppeurspourlivrer deslogicielsdequalitatempsetaprixcomptitifs.Ellevisedonctroisobjectifs: diminuerlescotsdedveloppementetdemaintenance,rduireletempsdemisesurle march(time-to-market),etamliorerlaqualitdulogiciel.Larutilisationsedfinit comme une nouvelle approche de dveloppement de systmes, qui propose notamment de construireunsystmenouveaupartirdecomposantslogicielssurtagre(COTS, CommercialOffTheShelf)quisedfinissentcommetantuntypeparticulierde composant.Ellesopposeainsiauxapprochestraditionnellesdedveloppement,dans lesquelles la construction dun nouveau systme part de rien (from scratch) et ncessite de rinventer de grandes parties dapplications a chaque fois. Depuis,cetteidesestimposeetlarutilisationconstitueunenjeumajeurde rechercheeningnieriedessystmesbasedecomposants.Lesrecherchessurla rutilisation ont progressivement volu ces dernires annes, passant de la rutilisation de codelarutilisationdeconnaissancesetdedmarchesderaisonnementdediffrents niveaux.Cettepratiquepressenteunenjeusupplmentairepourgarantirunemeilleure qualit des dveloppements [15].En parlant de composants logiciels dont nous nous somme intress dans ce mmoireetquiconstituentlundestypesdecomposantsparmiceuxclassifisdanslalittrature( nousavonsprislechoixdattarderleursprsentationdanscechapitrepourdesraisons purement pdagogiques), il est utile de distinguer entre la rutilisation bote blanche dans laquellelimplmentationdes composantsrutilissestexposeuncertaindegr, etla rutilisation bote noire, dans laquelle les composants ne peuvent tre rutiliss que selon une interface de rutilisation spcialement fournit, oucontrat6 [13]. Unerutilisationdetypebotenoireconsisterutiliserlecomposanttelquel sansaucunevisiondelamaniredontilestimplmentetsansaucune modification de code de la part du dveloppeur de lapplication. Larutilisationparapprocheboteblanche,paroppositionlapproche prcdente,consisterutiliseruncomposantenayantaccsson implmentationetenpermettantsamodification(adaptation).Cetypefait lespritdestechnologiesopensource:ilestpossiblederutiliserdes technologies pour les adapter ses propres besoins.Desauteursdanscedomaineontmontruneprfrencepourlarutilisationboite noire tel est le cas pour Nierstrasz [13]. La facilit dutilisation est obtenue en fournissant

6 La notion de contrat sera explique plus loin dans ce chapitreCHAPITRE I Dveloppement logiciel base de composants 14 desinterfacesboitenoireauxcomposantsqui,dune partlimitelafaondontles composantspeuvent tre utiliss, et dautre part, limite le besoin de comprendre les dtails dimplmentationdes composants.Lavisionhistoriquedelarutilisationlogicielsestla cration de systmes logiciels partir dlments logiciels prexistant au lieu deles cres partirdezro.Leprocessusdelarutilisationlogicielssediviseendeuxparties correspondantes: lingnierie pour la rutilisation, et lingnierie avec la rutilisation [17]. La section suivante traite ces types de rutilisation. 3.3.2Processus de rutilisation Deuxprocessuscomplmentairessontconsidrsdansledveloppementbas composant:lingnieriedecomposantsrutilisables(designforreuse)etlingnieriede systmesparrutilisationdecomposants(designbyreuse).Nousallonsdiscuterces processussparment.Dansdessituationsrelles,ilsseront combins,etpeuventnepas tredistingus,commetantdesactivitsspares.Toutefois,lasparationdeces processus est une caractristique particulire de lapproche base composant [1]. a.Ingnierie de systmes par rutilisation (Design by Reuse) Le dveloppement de systmes par assemblage de composants est similaire celui des applicationsquinesontpasbasessurlescomposants.Ilyatoutefois,unediffrence crucialedansleprocessusdedveloppementdesystmesbasedecomposant.Lintrt nestpasfocalissurlimplmentationdusystmeconu,maissurlarutilisationde composantsprexistants.[18]dfinitledveloppementdesystmeslogicielspar rutilisationcommeledveloppementdesystmesenutilisantdescomposants rutilisables.Lingnieriedesystmesparrutilisationcouvrelestachesderecherche,de slectionoudecrationdecomposantspropritairecommealternative,dadaptationpour intgration,decompositionetdploiementdescomposants,etremplacementde composants.1)Recherche de composants La recherche de composants consiste rechercher un composant parmi une collection, permettantderpondreunproblmeparticulier.Elletientdonccomptedubesoindu dveloppeur.Pouraccompliravecsuccscetteprocdure,ungrandnombredventuels candidats de composants doivent tre disponibles ainsi que les outils pour les trouver. 2)SlectionSlectionnezlescomposantsquirpondentauxexigencesdusystme.Souvent,les exigencesnepeuventpastresatisfaitescompltementetuneffortsupplmentaire danalyse est ncessaire pour adapter larchitecture du systme et de reformuler les besoins pour permettre lutilisation des composants existants. CHAPITRE I Dveloppement logiciel base de composants 15 3)Cration de composantsAlternativement, la cration de composants propritaires qui vont tre utiliss dans le systmepeuseproduireaulieuduneslectiondunentreptdecomposants.Dansune approcheCBD,cetteprocdureestmoinsattrayantecarelleexigeplusdeffortsetde temps.Toutefois,lescomposantesdebaseincluantlesfonctionnalitsduproduitsont susceptiblesdtredveloppeseninternedufaitquilspeuventfournirunaspect comptitif du produit. 4)Adaptation Une fois slectionn, le composant doit tre adapt au contexte du systme en cours de dveloppement. Il doit correspondre au modle de composant existant ou la spcification desbesoins.Certainscomposantspeuventtredirectementintgrsausystme,dautre doivent tre modifis par un processus de paramtrisation, certains auraient besoin de code glupourladaptation.Lecodegluestlecodeajoutauxcomposantsafindelesrendre compatiblesavec unenvironnement dans lequel ils nont pas t conus pour fonctionner [3]. 5)Composition et dploiement (intgration) Diteaussiphasedintgration.Laphasedintgrationdusystmeestlaphasedurant laquellelescomposantsslectionnsetdveloppssontcomposs(cest--direassembls entreeux)pourcrerlesystmeetcelaenutilisantunFrameworkpourlescomposants. Typiquement, les modles de composants fournissent ces fonctionnalits. 6)RemplacementLeremplacementdesversionsdecomposantsanciennesparlesnouvelles.Cela correspond la phase de maintenance du systme. Les bugs sont limins et de nouvelles fonctionnalits peuvent tre ajoutes au systme.b.Ingnierie de composants rutilisables (Design for Reuse) Ellevisedvelopperdesmthodesetdesoutilspoursupporterleprocessusde productiondecomposantsmisenuvreparleconcepteurdesystmesderutilisation [19].Lingnieriedecomposantsrutilisablesrecouvrelestachesdidentification,de spcification,dequalification,dorganisationetdimplmentationdecomposants. Lensemble de ces taches est essentiel, puisquil a pour objectif de produire les ressources ncessaires la mise en uvre dune approche dingnierie par rutilisation. 1)IdentificationLidentificationdesressourcescandidateslarutilisation,soitparltudede systmesexistants,soitparlanalysededomaine.Lesconnaissancessusceptiblesde CHAPITRE I Dveloppement logiciel base de composants 16 contenirdeslmentsrutilisablesetapprouvspeuventtredesproduitsde dveloppementexistants(programmes,modlesconceptuels,etc.),oudesexpressionsde connaissances (documents techniques, etc.). 2)Spcification Laspcificationdoitfavoriserlarutilisationdescomposantstoutenfournissant lensemble des informations utiles et ncessaires leurs bonnes utilisations (telles que les indications et les contraintes dutilisation, les forces de la solution propose,). Elledoit permettre de dcider, par exemple, de la pertinence dutiliser un composant ou un autre au moment de la recherche de ceux-ci. La rutilisation des composants est plus efficace sils sontassociesaunespcificationpertinente.Deuxtechniquessontutilisesdanstout modledespcificationpourlaspcificationdescomposants :labstractionetla gnricit.Lapremireconsistedistinguerdeuxtypesdeconnaissancesdansla spcificationduncomposant:lesconnaissanceseffectivementrutilisables(unmodle silsagitduncomposantconceptuelparexemple,ouunfragmentdeprogrammesil sagitduncomposantlogiciel)etcellesrequisespouruneutilisationcorrectedecelui-ci [15]. La deuxime introduit une forme de variabilit dans la spcification des composants. En effet, le plus souvent, la solution propose par un composant noffre quune ralisation possibledecelui-ci.Pouraugmentersarutilisation,uncomposantdoitoffrirplusieurs ralisationspossibles:sasolutiondoitainsitreflexibleafindepouvoirladapteraux spcificits du systme en cours de dveloppement. 3)Qualification La qualification des composants sapparente une forme de validation de ceux-ci. Elle consiste vrifier la qualit de composants identifis du point de vue de leur rutilisation. 4)Organisation Lorganisationdescomposantstraitediffrentstypesdeliensentreceux-ci,afinde pouvoirutiliserconjointementplusieurscomposantspourobtenirdesarchitecturesplus importantes.Elleadoncuneinfluencedirectesurlamaniredexploiterlescomposants dansleprocessusdingnieriedesystmesbasedecomposant.Ellefacilitelaslection de composants et amliore leur rutilisation. 5)Implmentation Limplmentationdescomposantsconsisteaoutillerlarutilisation(gestion automatiquedeleurscollections,recherche,slection,composition,adaptation,)de ceux-ci. Ces diffrentes techniques contribuent la mise en place de bases de composants pour capitaliserdessavoirsetdessavoir-fairerutilisablesdanslecadreduneingnieriepar rutilisation. CHAPITRE I Dveloppement logiciel base de composants 17

Lobjectifdudveloppementpourlarutilisationestdeconstruiredescomposants rutilisablesquirpondentunensembledecontraintesdequalitetderutilisation.Le dveloppementdecomposantsrutilisablessefocalisesurlescritresdequalitau dtriment des cots de production du composant [18]. Les activits de dveloppement parrutilisationsefocalisentsurlensembleduprocessusdedveloppement,de lidentification,etlarecherchedecomposantsrutilisablesdanslabasedecomposants rutilisables,jusqulaconstructiondenouveauxcomposants(pasncessairementceux rutilisables) par ladaptation ou la composition de composants rutilisables. 3.3.3Cycle de vie pour le CBD LingnierielogiciellebasecomposantCBSEabordedesdfisetdesproblmes similairesceuxrencontrseningnierielogicielle.Beaucoupdemthodes,doutilset principes en ingnierie logicielle utiliss dans dautres types de systme sont utiliss dune manire identique ou similaire dans la CBSE. Il y a toutefois, une diffrence: la CBSE se concentresurlesquestionsrelativesauxcomposantset,danscesens,elledistinguele processus de dveloppement des composants de celui du dveloppementde systme avec des composants [14]. Ilestimportantderemarquerquelesdiffrentesactivitsconstituantlesdeux processuspeuventtreralisesindpendammentlesunesdesautres.Enralit[1],les deuxprocessussontrellementsparsparcequedenombreuxcomposantssont dveloppspardestiercesparties,indpendammentdudveloppementdusystme. Cependant, dans des situations relles ils sontcombins et peuvent ne pas tre distingus comme activits spares.Fig. 3 Ingnierie pour la rutilisation et ingnierie par rutilisation [19] CHAPITRE I Dveloppement logiciel base de composants 18 Commeleslogicielssontdeplusenpluscomplexes,ilenvademmepourleffort ncessaire pour leur production, et dans ce sensdenombreuxmodlesdecycledeviede logiciel ont t proposs. Leur principale utilit est didentifier et dorganiser les phases et lestapesimpliquesdansledveloppementetlvolutiondeslogiciels[20].Ilyaune diffrencesignificativeentrelapprochededveloppementlogicielbascomposantetles approchesdedveloppementlogicieltraditionnelles.Unestandardisationtechniqueest ncessaire, et une mthode adapte au CDB doit tre suivi [21]. Les processus de cycle de vieincluenttouteslesactivitsdunproduitouunsystmeduranttoutesavie,en commenant depuis lide de lentreprise pour son dveloppement, jusqu son utilisation et sa mise hors service. Diffrents modles ont t proposs et exploits dans lingnierie logicielle.Nousavonsmentionndanslasection2.2quedeuxprincipauxgroupesde modlespeuventtredistingus:squentieletvolutionniste.Lesmodlessquentiels dfinissentunesquencedactivitsdanslaquellelepassageversuneautreactivitnese faitquaprsachvementdecelleencours.Lesmodlesvolutionnistespermettent lexcutiondeplusieursactivitsenparalllesanslexigencedecomplteruneactivit pourpouvoircommenceruneautre.Cesmodlespeuventtreappliqusdansle dveloppementbascomposant,maisdoiventtreadaptsauxprincipesdelapproche basecomposant[22].Danscecadre,diversmodlesdecycledeviepourle dveloppement bas composant ont t proposs. Nous allons prsenter brivement dans la sectionsuivantelaphilosophiegnraledequelquesun.Indpendammentdutypede modle,nouspouvonsidentifierles activits de base prsentes dans tout modle de cycle de vie quon a prsent dans la section 2.1. a.Modle en V DanslemodleenV(figure4)adoptpourlapprochededveloppementbase composantpropospar[22],durantlecycledeviedunproduitlogiciel(franchissantles phasesdedveloppementetdemaintenance),unentreptdecomposantsestmis disposition depuis lequel les composants peuvent tre slectionns dans les phases initiales, etdanslequellescomposantspeuventtreajoutsdanslesphasesultrieures(les composants nouvellement dvelopps pour une application) [21].Dans ce modle le processus commence dune manire habituelle par lingnierie des besoinsetlaspcificationdesbesoins,olesanalystesessayentdetrouver,partirdun entreptdecomposants(chercherpuisslectionner)ceuxpouvantsatisfairelesbesoins spcifis.Dansuneapprocheclassiqueleprocessuscontinueraitaveclaconception, limplmentationetlestests.Sidetelscomposantsnesontpasdisponibles,alorsles besoinssontprobablementngocisetmodifisafindepouvoirutiliserlescomposants logiciels disponibles. CHAPITRE I Dveloppement logiciel base de composants 19 b.Modle en Y LemodleenY(figure5)atproposcommealternativeviablepouradresserla rutilisationdelogicielsdurantlaproductiondesystmeslogicielsbascomposant[20]. La cration de logiciels se caractrise par le changement et linstabilit, par consquent la reprsentationschmatiquedumodleenYpermetlerecouvrementdephasesetdes itrationsquandcestncessaire.Bienquelesphasesprincipalespeuventserecouvriret litrationestpermise,lesphasesprvuessont:ingnieriededomaine,tablissementde Framework, assemblage, archivage, analyse du systme, conception, implmentation, test, dploiement et maintenance.Lacaractristiqueprincipaledecemodledecycledeviedunlogicielestsa focalisationsurlarutilisationpendantlacrationetlvolutiondulogicieletla productiondecomposantspotentiellementrutilisablesquipeuventtreutilesdansde futurs projets logiciels. La rutilisation dans ce cycle de vie est plus efficace que dans les modles traditionnels parce quil intgre dans son noyau lintrt pour la rutilisation et les mcanismes pour la raliser [20].

Fig. 4 Modle en V adopt pour le dveloppement bas composant [22] CHAPITRE I Dveloppement logiciel base de composants 20 c.Lapproche EPIC (Evolutionary Process for Integrating COTS) Cestuneformemodifieduprocessusrationnelunifi(RUP7).Poursadapteraux changements continus induits par le march des COTS (Commercial Off The Shelf), EPIC utiliselemodleenspiralebassurlagestiondesrisques.Lesutilisateursdelapproche EPICgrentlacollectedinformationsdumarchetraffinentcesinformationspar lanalyse et la ngociation dans une solution cohrente qui est incorpore dans une srie de reprsentationsexcutablesdurantlavieduprojet[21].Lesquatrephasessont,comme dans RUP, Analyse des besoins, laboration, construction, et transition.1)Lebutdelaphasedanalysedesbesoinsestdatteindrelaconcurrenceentreles utilisateursaffectssurlesobjectifsdecycledeviepourleprojet.Laphase danalysedesbesoinstablitlafaisabilittraverslecasdaffairesquimontre quune ou plusieurs solutions candidates existent. 2)Lebutdelaphasedlaborationestdatteindreunestabilitsuffisanteauniveau de larchitecture et des besoins;pour slectionner et acqurir des composants;et pour minimiser les risques de sorte quune solution simple de haute fiabilit puisse tre identifie avec le cot prvu. 3)Le but de la phase de construction est de dgager un produit de qualit prt pour la communaut dutilisateur concern.La solution choisie est prpare pour sa mise sur terrain. 4)Lebutdelaphasedetransitionestlalivraisondelasolutionsesutilisateurs.La solution choisie est mise sur terrain la communaut dutilisateur.

7 Rational Unified ProcessFig. 5 Modle en Y pour le dveloppement logiciel bas composant [20] CHAPITRE I Dveloppement logiciel base de composants 21 BeaucoupdegensdanslindustrielogicielcommencentvoirleCBDcomme nouvelleapprochepassionnanteaudveloppementdapplicationquioffrelapromessede rduireladureducyclededveloppementdelogiciel,etamliorelaqualitdes applicationsfournies[9].LeCBDabeaucoupdavantages.Ceux-ciincluentunegestion plusefficacedelacomplexit,rduireletempsdemisesurlemarch,unemeilleure productivit,unequalitamliore,etunlargespectredutilisation.Cependant,ilya plusieursinconvnientsetrisquesdanslutilisationduCBDquipeutcompromettreson succs [14] :Letempsetleffortncessairepourledveloppementdescomposants.Parmiles facteurs qui peuvent dcourager le dveloppement des composants rutilisables est letempsetleffortcroissantexig,laconstructionduneunitrutilisablea ncessite de trois cinq fois leffort exig pour dvelopper une unit pour un usage spcifique. Les besoins peu clairs et ambigus.En gnral, la gestion des besoins est une partie importante du processus de dveloppement, son objectif principal est de dfinir les besoinscompletsetconsistentdescomposants.Pardfinition,lescomposants rutilisablesdoiventtreutilissdansdiffrentesapplications,dontcertains peuventencorenepastreconnuesetdontleursbesoinsnepeuventpastre prvus. Ceci sapplique aux besoins fonctionnels et non fonctionnels.Conflit entre la rutilisation et la rutilisabilit.Pour tre largement rutilisable, un composantdoittresuffisammentgnral,extensibleetadaptableetdoncplus complexeutiliser,etdemandeplusderessourcesinformatiques,doncilestplus chreutiliser.Lebesoindelarutilisabilit,quiconsistedgager,pourle composant,unpotentieltreaismentrutilisable[3],peutmeneruneautre approchededveloppement,parexempletablirunnouveauniveau,plusabstrait qui donne moins de flexibilit, mais atteint une meilleure simplicit.Lescotsdemaintenancedescomposants.Tandisquelescotsdemaintenance dapplicationpeuventdiminuer,cellesdescomposantspeuventtretrsleves puisque le composant doit rpondre diffrents besoins de diffrentes applications fonctionnantdansdesenvironnementsdivers,avecdesexigencesentermesde fiabilit diffrentes. Fiabilit et sensibilit aux changements.Comme les composants et les applications ont des cycles de vie spars et diffrents types de besoins, il y a un certain risque quuncomposantnerpondrapascompltementauxexigencesduneapplication ouquilpeutincluredescaractristiquescachesnonconnuespourles dveloppeursdapplications.Onintroduisonsdeschangementsauniveau dapplicationtelquelamisejourdusystmedexploitation,lamisejour dautrescomposants,etc.,ilyaunrisquequelechangementeffectucausera lchec du systme. Cependant,lapparitiondenouvellestechnologiesaaugmentdefaonremarquable lespossibilitsdeconstruiredessystmesetdesapplicationspartirdecomposants rutilisables.LesclientsetlesfournisseurssattendaientbeaucoupduCBD,maisleurs CHAPITRE I Dveloppement logiciel base de composants 22 espoirs nont pas t toujours satisfaits. Lexprience a montr que le dveloppement bas composantexigeuneapprochesystmatiquepoursefocalisersurlesaspectsde composants dans un dveloppement logiciel [14]. Lesdisciplinestraditionnellesdelingnierielogicielledoiventtreajustessurla nouvelleapproche,etdenouvellesprocduresdoiventtredveloppes.Lingnierie logicielle base composant CBSE est devenue une nouvelle sous discipline de lingnierie logicielle. 3.4 Ingnierie logicielle base composant (CBSE) IlestvidentqueleCBDetleCBSEsontdanslespremiresphasesdeleur expansion. CBD est connue comme tant une nouvelle approche puissante qui na amlior de manire significative si ce nest pas rvolutionner le dveloppement et lutilisation des logiciels en gnral.LesconceptsdeCBDetdeCBSEsontparfoisutilisscommedessynonymes. Pourtantleurssignificationnestpaslamme.LeCBDtraduitlidedecrationdune applicationparutilisation/rutilisationdecomposants.LaCBSEdsignelesmthodes, techniquesetoutilspermettantlaconceptionetlamiseenuvredapplicationsbases composants.ElleaainsipermisauCBDdepasserduneapprocheartisanaleune approche industrielle [3]. Les principales missions de la CBSE sont les suivantes [1] : fournir un support pour le dveloppement des composants ; supporterledveloppementdescomposantsentantquentitsrutilisables,cest--dire anticiper la rutilisation et concevoir la rutilisabilit ; faciliterlamaintenanceetlvolutiondessystmesenpermettantlamodification et le remplacement de leurs composants. LesdfinitionsdesconceptsinhrentslaCBSEsontencoremalformaliseset portentparfoisconfusion.Leflouquientourecertainesdfinitionsvientdelamanire dont la CBSE a t cre et a volu, aux confins de plusieurs domaines. Nous citonsles deuxprincipaux:lapprocheorienteobjetetlestravauxportantsurlesarchitectures logicielles.Lexpriencetiredelapprocheobjetatfondatricepourlapriseen considration de laspect rutilisation dans la CBSE.3.4.1Concepts de baseLa CBSE est base sur le concept de composant.Dautres termes, tels que linterface, lecontrat,leFramework,etlepatron,sontdecefaittroitementliesaudveloppement logiciel bas composant.CHAPITRE I Dveloppement logiciel base de composants 23 Uncomposantestuneunitrutilisablededploiementetdecomposition.Unevue communeestquuncomposantesttroitement liunobjetetqueleCBDestdoncune extensiondudveloppementorientobjet.Cependant,beaucoupdefacteurs,telsquela granularit,lesconceptsdecompositionetdedploiement,etmmelesprocessusde dveloppement, distinguent clairement les composants des objets [1]. Nous allons essayer de prsenter une vue densemble sur ces termes, et leurs dfinitions.3.4.1.1InterfaceUncomposantdoittreclairementdiffrencidesautrescomposantsetdeleur contexte dexcution. Le mcanisme permettant cela est linterface. Les interfaces sont un mcanismedecontrledesdpendancesexistantesentrelesdiffrentsmodulesdun programmeoudunsystme[3].Uneinterfaceduncomposantpeuttredfiniecomme une spcification de ses points daccs [23]. Cest--dire quelle offre la liste des services fournisourequisparlecomposant.Lesclientsaccdentauxservicesfournisparle composant en utilisant ces points.Il est important de noter quune interface noffre aucune implmentation daucune de ses oprations. Au lieu de cela, elle se prsente sous la forme dune collection de noms doprations. Elle fournit une description pour chaque opration. Cettesparationentrelimplmentationducomposantetsoninterfacepermetde: remplacer la partie implmentation sans changer linterface, et de cette faon amliorer les performances du systme sans reconstruire le systme; et, dajouter de nouvelles interfaces (etdesimplmentations)sanschangerlimplmentationexistante,etdecettefaon amliorer ladaptabilit du composant. Les interfaces dfinies dans les technologies de composants standard (par exemple, le langage de dfinition dinterface IDL8 de CORBA ou COM) peuvent seulement exprimer les proprits fonctionnelles, et cela on se focalisant seulement, partiellement sur la partie syntaxique[23].Engnral,lespropritsfonctionnellesincluentunepartiedesignature danslaquellelesoprationsfourniesparuncomposantsontdcrites,etunepartiede comportement,danslaquellelecomportementducomposantestspcifi.Nouspouvons distinguerdeuxtypesdinterfaces.Lescomposantspeuventexporteretimporterdes interfaces depuis et vers lenvironnement qui peut inclure dautres composants.Une interface exporte dcrit les services fournis par un composant lenvironnement, alorsquuneinterfaceimportespcifielesservicesrequisparuncomposantde lenvironnement [1]. La mise en uvre de la notion dinterface est maintenant aise car de nombreuxlangagesdeprogrammationrcentslasupportent,commeparexempleJava. Danslecascontraire,deslangagesdespcificationdinterfacesonttgalement dvelopps, indpendamment de tout type de langage, comme le langage IDL dfinit par le DCE(DistributedComputingEnvironment).Unexempledespcificationdinterfaceen IDLestdonndanslafigure6.Ellereprsenteuneinterfacedeservicefournie (ProvIneterPAM)duncomposantsimple(unpiloteautomatiquedebateau).Cette interface dcrit deux oprations : setCap et setTarget.

8 Interface Definition languageCHAPITRE I Dveloppement logiciel base de composants 24 3.4.1.2Contrat LaplupartdestechniquespourdcrirelesinterfacestellesqueIDLsontseulement concernesparlapartiedesignature,danslaquellelesoprationsfourniesparun composantsontdcrites.Ilsnedcriventpaslecomportementglobalducomposantmais justelalistedecesservices[1].Lanotiondecontratpermetnotammentdepalliercette lacune. Il est admisque les contrats permettent de spcifier de manire plus rigoureuse le comportement des composants.Uncontratlistelescontraintesglobalesquelecomposantdoitmaintenir(invariants) [30]. Pour chaque opration dun composant, un contrat liste galement les contraintes qui doiventtreassuresparleclient(pr-conditions)etcellesquelecomposantpromet dtablir en retour (post-conditions). Les pr-, post-conditions et invariants constituent une spcificationducomportementduncomposant[23].Audeldesspcificationsdu comportementduncomposantsimple,lescontratspeuventgalementtreutilisspour spcifierlesinteractionsdansunecollectiondecomposants.Uncontratspcifieles interactions entre composants, en termes de [1]: Lensemble de composants participant; Lerledechaquecomposanttraverssesengagementscontractuels,telsqueles engagements de type, qui exigent du composant de supporter certaines variables et une interface, et les engagements causals, qui exigent du composant de raliser une squenceordonnedactions,ycomprislenvoidemessagesauxautres composants. Linvariant maintenir par les composants; La spcification des mthodes qui font linstanciation du contrat. Lutilisation des contrats pour spcifier les interactions entre les composants ncessite lutilisationdelangage.Eiffelestunexempledelangagequipermetladescriptiondes interfaces par contrats. Les contrats permettent aux dveloppeurs de logiciel disoler et de spcifierexplicitement,unhautniveaudabstraction,lesrlesdediffrentscomposants dansuncontexteparticulier.Ensecondlieu,lesdiffrentscontratspermettentla modificationetlextensiondesrlesdechaqueparticipantindpendamment.Finalement lesnouveauxcontratspeuventtredfinisenassociantdiffrentsparticipantsavec diffrents rles. Fig. 6 Exemple de dfinition dinterface en IDL [3] 1 interface ProvIneterPAM { 2void setCap (out int iCap) ;3void setTarget (in float iLattitude , in float iLongitude) ; 4} ;CHAPITRE I Dveloppement logiciel base de composants 25 3.4.1.3Composition La composition de composants permet de crer soit une application base composants, soitdeconstruireuncomposantdegranularitplusimportante.Ilexistedenombreuses dfinitionsdelanotiondecomposition.Parmicelles-ci,ladfinitionsuivante: la compositionlogicielestlaconstructiondapplicationslogiciellespartirdecomposants qui implmentent des abstractions concernant un problme de domaine particulier9 [3]. La composition logicielle y est dcrite comme un mcanisme, sans prciser lequel, permettant la construction dune application partir de composants. Selon [3], il existe deux niveaux de composition :La composition haut niveau, ou composition conceptuelle, concerne la phase danalyse etlaconceptionglobaledusystme.Ontraitelactivitdidentificationetdedescription des abstractions fondamentales du systme logiciel (composants) et les relations entre elles (compositions). Il sagit de considrer la composition au niveau modle et donc de prparer etguiderlassemblageauniveauprogrammation.Leslangagesdemodlisationetde spcification permettent la ralisation de cette phase. La composition bas niveau, ou composition logicielle, concerne : La description de larchitecture globale du systme et la spcification de la conception dtaille.CettephasepeuttreraliseconjointementavecdesADL(Architecture Description Language) et des langages de modlisation et de spcification. Limplmentation et le dploiement des compositions. Cette phase peut tre ralise laidedesmodlesdecomposants,deslangagesdescriptoudeglu,ouencorede simples langages de programmation. 3.4.1.4PatronUnarchitectenommChristopherAlexanderaintroduitpourlapremirefoisle nouveau concept de patron dans la fin des annes 70. Dans ce contexte, un patron dfinit unesolutionrcurrentepourunproblmercurrent.Lespatronsdeconceptionforment une mthode de rutilisation des informations de conception. Ils ont t introduits dans le mondeOO(OrientObjet).Gammaetal[24]ontraffinaprscettedfinitionen spcifiant les caractristiques dun patron et ses objectifs. On peut tablir quatre catgories de patrons. Chaque catgorie est base sur le niveau dabstraction partir duquel ils sont utiliss [23] : 1)Lespatronsdarchitecturetravaillentsurlespropritsglobalesetarchitecturales du systme. Ils dcrivent la structure globale du systme, et fournissent des moyens dedcrirelensembledessous-systmes,despcifierleurrleetdedcrireles relations existant entre eux ;

9Enanglais Softwarecompositionistheconstructionofsoftwareapplicationsfromcomponentsthat implement abstractions pertaining to a particular problem domain CHAPITRE I Dveloppement logiciel base de composants 26 2) Lespatronsdeconceptionraffinentlastructureetlescomportementsdessous-systmes et des composants. Par leur aspect gnrique, les patrons sont considrs commedesmicroarchitecturesvisantrduirelacomplexit,promouvoirla rutilisationetfournirunvocabulairecommunauxconcepteurs.Ilsdcriventla structure et le comportement du systme et des composants et les communications entre eux ;3)Les patrons de programmation sont dpendants des paradigmes et des langages de programmation utiliss.La figure 7 montre un exemple dun type de parton de conception de Gamma nomm le pattern Observer.

Lespatronsonttappliqusdanslaconceptiondebeaucoupdesystmesorients objet,etsontconsidrscommedesmicroarchitecturesrutilisablesquicontribuentdans larchitectureglobaledunsystme.Cependant,lutilisationdespatronsdeconception nestpassansproblmes.Lepremierproblmeestquelaconnaissancecodedansle patrondeconceptionestuneconnaissancenonstructureporteusedenombreuses ambiguts en raison de la description informelle des solutions. La relation existante entre patrons de conception et composants peut tre vue comme suit : les patrons de conception, dansleprocessusdeconceptiondesapplicationsbasescomposants,aidentdterminer lesunitsrutilisableset,lecaschant,lesidentifiersouslaformedecomposants existants,oulesdveloppersouslaformedunitsrutilisables.Enfin,lespatronsde conceptionpeuventtreutilisspourdcrirelescompositionsdecomposants[1].Ilest envisageablededcriredansdespatrons,diffrentscasdecompositiontypequelon pourrait utiliser. 3.4.1.5Framework Tout comme la dfinition de composant, la notion de Framework, est un autre moyen aidantraliseruneapplicationbasecomposants.CBSEsignifiequenousconstruisons deslogicielsassemblantplusieurspicesensemble.Dansuntelenvironnementilest essentielquuncontexteexistedanslequellespicespeuventtreutilises.Les Frameworkconstituent unmoyen pour fournir de tels contextes. Un Framework peut tre Fig. 7 La structure du Pattern Observer [24] Subject Attach (Observer) Detach(Observer) Notify( ) ObserverUpdate() ConcreteObserver ObserverState ConcreteSubject SubjectState GetState ( ) SetState ( ) Observers for all o in observers{Obsupdate(); } Return SubjectState observerState= subjectGetState() Subject CHAPITRE I Dveloppement logiciel base de composants 27 vu comme une conception rutilisable dune partie dun systme, fournissant un ensemble declassesabstraitesainsiquelesmoyensdelesfaireinteragir.Ilpeuttreutilispour dcrirequelquechosequiestutilisable,nonseulementtelqueldansunesituation particulire, mais galement, aprs modification, dans une situation similaire la situation conueinitialement.Cettemodificationpeutavoirlieudurantlaphasedeconceptionou dexcution,etestappeleinstanciationduFramework[1].Lacontributionmajeuredes Frameworksestquilsforcentlescomposantseffectuerleurstcheslaidede mcanismescontrlsparlecanevaslui-mme,cequirenforcelerespectdesprincipes architecturaux[3].UnexempledecanevasdapplicationsleJAF(pourJavaBeansTM Activation Framework). Les Frameworks dcrivent une situation rutilisable typique au niveau modle, tandis quelesFrameworksdecomposantsconstituentunecartecircuitavecdesslotsvidesen attentepourtreremplidecomposants.QuandceciestfaitleFrameworkestinstanci [23]. On distingue trois types ou niveaux de Frameworks [23] : 1)LesFrameworkstechniquesquisontsemblablescequisenommeautrefoisdes Frameworks dapplication; 2)Les Frameworks industriels ; 3)Les Frameworks dapplication. 3.4.2Relation entre concepts Dans la communaut du CBSE, il y a souvent des confusions sur les concepts de base quonaprsents.Parexemple,leconcept desmodlesdecomposantsestsouventsujet de confusion avec le concept des Frameworks de composants. La figure 8 dfinit le modle de composant comme un ensemble de types de composant, leurs interfaces, et, en plus, la spcificationdeleurspartenairesdinteractionparmilestypesdecomposants.Un Frameworkdecomposantfournitunevaritdeservicesdedploiementetdexcution poursupporterlemodledecomposant.Lafigure8tirede[25]schmatiselarelation entre les concepts abords plus haut.

Fig. 8 Relation entre les concepts pour une application base composants [25] CHAPITRE I Dveloppement logiciel base de composants 28 Un composant (1) est une implmentation logicielle mettant en uvre un ensemble de servicesdcritsparuneouplusieursinterfaces(2).Lescomposantsrespectentcertaines obligationsquisontdcritespardescontrats(3).Ceux-ciassurentquedescomposants dvelopps indpendamment obissent des rgles dinteraction, et peuvent tre dploys dans un environnement de compilation et dexcution standard (4). Une application base composants est construite partir dinstances de composants. Chaque composant est bas sur un type de composants (5). Un modle de composants (6) est un ensemble de types de composants,deleursinterfaces,etventuellementdepatronsdeconceptiondcrivantles interactions entre les diffrents types de composants. Un canevas dapplications (7) fournit unensembledecritresdedploiementetdexcution(8)commesupportaumodlede composants.3.4.3Notion de composant LescomposantsreprsententlecurdelaCBSE,etonabesoindunedfinition prcisedecequecestuncomposantafindecomprendrelesbasesduCBSE.Plusieurs dfinitionsduconceptdecomposantpeuventtretrouvesdanslalittrature.Ces dfinitions diffrent naturellement en fonction du domaine dapplication et en fonction de la comprhension qui peut tre attache aux composants [27]. 3.4.3.1Dfinition dun composant Dansledomainedelarutilisationdulogicielparexemple,uncomposantestvu commenimportequelleentitquipeuttrerutilise.Lesconcepteursvoientles composantscommedeslmentsdeconception.Lesdployeurslesconsidrentcomme des units de dploiement. Dans dautres considrations, un composant peut tre galement vucommeunlmentdunprojet,commeuneconfigurationoummecommeune documentation.Alheureactuelle,ilnexistepasdenormalisationdelanotionde composant.GnralementuncomposantrutilisableestdfinicommeUneunitde conception(denimportequelniveaudabstraction)identifieparunnom,avecune structuredfinieetdesdirectivesdeconceptionsouslaformededocumentationpour supportersarutilisation[28].Ladocumentationduncomposantillustrelecontexte dans lequel il peut tre utilis en spcifiant les contraintes et les autres composants dont il a besoin pour offrir sa solution.Cettedfinitionduconceptdecomposantestgnralecarelleadmetlapossibilit dutiliserleconceptdecomposantdansdesniveauxdabstractionautresqueleniveau dimplantation. Dune manire gnrale, un composant est vu comme une solution teste et acceptepourrsoudreunproblmefrquemmentrencontrelorsdudveloppementde systmes [15]. 3.4.3.2Type de composant Pourintgrerlarutilisationdans tout le processus de dveloppement des systmes base de composant, une grande varit de composants rutilisables a t propose. Il existe CHAPITRE I Dveloppement logiciel base de composants 29 troistypesdecomposant quonpeuttrouverdanslalittrature:lescomposants conceptuels, les composants logiciels et les composants mtier.a. Composant conceptuel Un composant conceptuel est une solution un problme conceptuel sous la forme dun modle (ou une partie dun modle) destine tre rutilise . Suivant lapproche de modlisationutilise,lasolutionpeuttrespcifieaveclelangageUML(Unified ModelingLanguage)outoutautrelangagedemodlisation.Lescomposantsconceptuels peuvent tre de deux types : Lescomposantsproduit:uncomposantproduitestunepartiecohrente dun modle qui peut tre rutilise avec dautres composants produit pour assemblerunmodlecomplet.Unproduitcorrespondaubutatteindre lorsquonutiliselasolutionofferteparlecomposantproduit.Parexemple, lepatroncompositedeGamma[24]peuttreconsidrcommeun composant conceptuel produit. Lescomposantsprocessus:uncomposantprocessusestunepartie cohrentedunprocessusquipeuttrerutiliseavecdautrescomposants processuspourassemblerunprocessuscomplet.Unprocessuscorrespond aucheminparcourirpouratteindrelasolutionofferteparlecomposant processus.Parexemple,lepatronrevuetechniquedAmblerestun composant conceptuel processus [29].b. Composant mtier A lheure actuelle, il nexiste pas de normalisation de la notion de composant mtier. Leconceptdecomposantmtierrsultedeceluidobjetmtier.Ainsi,lOMG(Object ManagementGroup)dfinitlanotiondobjetmtiercommesuit:BusinessObjectsare representationsofthenatureandbehaviourofrealworldthingsorconceptsintermsthat are meaningful to the enterprise. Customers, products, orders, employees, trades, financial instruments,shippingcontainersandvehiclesareallexamplesofreal-worldconceptsor things that could be represented by Business Objects [33]. Dautres spcialistes dfinissent un composant mtier comme une unit de rutilisation deconnaissancesdedomaines,dunpointdevueconceptueluniquement,parexemple, Casanave dans la dfinition suivante [26]: Uncomposantmtierestvucommeunereprsentationdelanatureetdu comportementdentitsdumondereldansdestermesissusduvocabulairedune entreprise [34]. CHAPITRE I Dveloppement logiciel base de composants 30 c. Composant logiciel Lescomposantslogicielssontdfinisdediversesmaniresetilsnontpasde dfinitionuniversellementaccepte.Parmicellesproposes,nousavonschoisisde prsenterquelquesdfinitionslesplusconnuesdonnesparlesexperts.Lunedes premires dfinitions est donne par Gready Booch : Un composant logiciel rutilisable est un module logiquement cohsif et faiblement coupl qui dnote une simple abstraction 10. Cettedfinitionrefltelidequuncomposantrutilisableestunmodulelogiciel encapsulcomprenantdeslmentstroitementlis[11].Plustard,ClmentSzyperskia prsent sa clbre dfinition dun composant logiciel dans la Confrence europenne sur la programmation oriente objet en 1996. Uncomposantlogicielestuneunitdecompositionavecdesinterfaces contractuellementspcifiesetdesdpendancesexplicitesaucontexte.Uncomposant logiciel peut tre dploy indpendamment et est sujet une tierce composition . Cettedfinitionestlapluscourammentadmiseparmicelleproposes.Ellemontre trois proprits dun composant : 1)Un composant encapsule totalement son implmentation et communique avec son environnementautraversdesesinterfaces.Lesinterfacesspcifientles fonctionnalitsfourniesparlecomposant,etpourassurercesfonctionnalits, certainesdpendancesversdautrescomposantsoummeverslenvironnement doivent tre rsolues2) Un composant est une unit de composition et est sujet composition. il doit donc treconupourlacomposition,cest--direpourtrecombinavecdautres composants afin de construire des entits logicielles de taille plus importante.3)Uncomposantpeuttredploydunemanireindpendante.Ilnestpas ncessaire de lintgrer dans une application pour pouvoir le dployer.En 2000, une notion plus gnrale dun composant logiciela t dfinit par Alan W. Brown[9]: unepartiefonctionnelleindpendammentdlivrequipermetlaccsses services travers des interfaces.11 Rcemment,BillCouncilletGeorgeT.Heinemanontdonnunenouvelledfinition qui souligne limportance, dun modle de composants et de son standard de composition dans la construction de composant et de logiciel base de composant [11].

10 En anglais A reusable software component is a logically cohesive, loosely coupled module that denotes a single abstraction . 11 En anglaisAn independently deliverable piece of functionality providing access to its services through interfaces. CHAPITRE I Dveloppement logiciel base de composants 31 Un composant logiciel est un lment logiciel conforme un modle de composants etpeuttreindpendammentdployetcompossansmodificationselonunstandardde composition. 3.4.3.3Modle de composants Un modle de composants consiste en un ensemble de conventions respecter dans la constructionetlutilisationdescomposants[26].Lobjectifdecesconventionsestde permettrededfiniretdegrerdunemanireuniformelescomposants.Ellescouvrent touteslesphasesducycledeviedunlogicielbasedecomposants:laconception, limplantation,lassemblage,ledploiementetlexcution.Concrtement,unmodlede composantsdcritcertainsaspectsdescomposantscommeladfinitiondecomposants partirdobjets(classes,modules,etc.),lesrelationsentrelescomposants,lesproprits fonctionnelles et non fonctionnelles de chaque composant, les techniques dassemblage des composants, le dploiement et lexcution dun logiciel base de composants, etc. Dans la pratique, un modle de composants donn est spcifique une phase du cycle devieducomposantetdulogiciel.Ontrouveainsidesmodlesdecomposantspourla phase de conception (patrons de conception), et dautres pour les phases dimplantation et dedploiement(EJB,CCM,etc.)[26].Danslasectionsuivantedesexemplessurdes standards de composants logiciels sera prsent.3.4.3.4Technologies Standards pour le CBDNous prsentons dans cette section quelques exemples de modles de composants : a.Component Object Model COM(ComponentObjectModel)[31]estunmodledecomposantsdvelopppar Microsoften1995.Sonobjectifestdepermettreledveloppementdapplicationsen assemblant des composants pouvant tre crits en diffrents langages, et communiquant en COM.Cescomposants,pourquilspuissentinteragir,doiventadhrerunestructure binaire commune, spcifie par Microsoft. Ceci signifie que les compilateurs des diffrents langages de programmation, gnrent les composants suivant le mme format binaire. Un composantCOM,critdansunlangagedonn,peutainsiinteragiravecunautre composant, mme sil est crit dans un langage diffrent [27].b.Java Beans Le modle des Java Beans a t propos par Sun Microsystems en 1996. Son premier etprincipaldomainedapplicationestlaconstructiondinterfacesgraphiques,maisson utilisation peut tre tendue dautres domaines. SuivantladfinitiondeSunMicrosystems,unJavaBeanestuncomposantlogiciel rutilisablequipeuttremanipulvisuellementtraversunoutillogiciel[7].UnJava CHAPITRE I Dveloppement logiciel base de composants 32 Beanpossdeuneinterfacequidcritsesmthodesetsesattributs.Lacompositiondes instances repose sur la notification et lcoute dvnements. Le modle des Java Beans a contribulvolutiondelanotiondecomposantsurtagre.Lemodlede communicationparvnementsarvolutionnlafaondassemblerdescomposants logiciels. CetteformedecompositionpermetdesJavaBeansntantpasinitialementconus pour fonctionner ensemble, dtre composs a posteriori : il suffit que lun soit producteur etlautreconsommateurdunmmetypedvnement.Pourfaciliterunassemblagea posteriori, il faut videmment possder des types dvnements standards partir desquels les Java Beans sont dfinis [7]. c.Enterprise Java Bean LemodledescomposantsEJB(EnterpriseJavaBean)estlefruitduntravailde normalisation,publidanssaversioninitialeenjuin1998(spcification1.0).Ilestddi audveloppement,lagestionetlvolutiondecomposantsserveursausein dapplications distribues 3-tiers (clients/serveurs/bases de donnes) [7].Plusparticulirement,unEJBestuncomposantlogicielcritenJava,etsexcutant ductserveur.LanormeEJBestessentiellementorienteversledveloppement dapplications offrant des services complmentaires au dessus dun systme dinformation dentreprise[27].Lacoucheclientcomportelesapplications(applets,applicationsJava, pagesHTML)quipermettentauxutilisateursdinteragiraveclesdonnesde lentreprise.Lacouchedonneconcernelesbasesdedonnesdelentreprise.Enfin,la couche serveur joue le rle dintermdiaire entre les deux autres couches. Elle englobe un serveurWebincluantlesJSP(JAVAserverpage),lesservletsJAVA,etunserveurde composants mtiers li des conteneurs EJB [27]. d.CORBA Component Model LemodlecomposantsdeCORBA(CCM)ajouteunecoucheaudessusde lintergiciel CORBA permettant de dfinir larchitecture dune application distribue sous formedecompositiondinstancesdecomposant[32].Ladescriptiondunecomposition, appeleAssembly,estralisedefaondclarativeetpermetdeguiderledploiement, sur plusieurs emplacements, des classes de composant ainsi que la cration, configuration, connexionetactivationdesinstancesdecesderniers.Uneautrecaractristiquedece modleestquilsupportelimplmentationde composantsdansdiffrentslangages;ceci est facilit par lutilisation dun langage abstrait pour la description dinterfaces (IDL). LemodleCCMreposesurdeuxpointsessentiels:lepremierestquuncomposant CCM est une boite noire dont on ne sait rien de limplantation; le second que la structure ducomposantdoittreentirementdcriteenIDL[7].Lastructureestdfinitenterme dinterfaces fournies (i.e. que le composant implmente) et dinterfaces requises (i.e. dont le composant requiert lutilisation). A chaque interface, fournie ou requise, correspond un CHAPITRE I Dveloppement logiciel b