Chapitre 2: Architectures logicielles
Transcript of Chapitre 2: Architectures logicielles
Chapitre 2: Architectures logicielles
1
Introduction
qObjectifs:Passaged’unearchitectureapplicativeversunearchitecturelogicielle
qArchitectureApplicativeq ellestructureleSIenblocsapplicatifscommunicantsq elledécritsousl’angletechniquelesapplications,lesfluxetlesmessageséchangésentreapplications
qArchitectureLogicielleq elleseconsacreàstructureretàconcevoiruneapplicationàpartirdesesspécificationsfonctionnelles
q ellestructureetdécomposedefaçonlogiquechaqueapplicationencouchesq elle introduitlesnotionsetconceptsdedécoupageencouches,composants,Frameworketdesignpatterns
2
Laméthodologie
qDansledomainedel’architecturedeSIaucuneméthodologien’aréussiàs’affirmeravecsuccès.
qApproche«topdown»(duprocessusaucode),avecdeuxcourantsprincipaux:q Approche«Données/Traitements»(Zachman,Merise...):l’approche«Données/Traitements»centrel’analysed’un problème surladonnéemanipulée;
q Approche«Composants»(RM-ODP,Catalysis...)quiadresseplusspécifiquement lesarchitecturesdessystèmes distribués :cemodèle aéteélaboresousl’influenceduframework ZachmanmaisguidéparleparadigmeOrienté Objet.
q Cesdeuxcourantsn’ontpasréussiàs’imposerpourdeuxprincipauxgriefs:qledogmatisme:lacroyancedansunedémarche top-down séquentielle (delastratégie aucode)
qlalourdeurdecesméthodologies :méthodologies verbeuses,manquantdepragmatisme
3
Laméthodologie
qDansledomainedel’architecturelogicielleunconsensuss’estcréecesdernièresannées autourduparadigmeobjetetdesméthodologiesbaséessurUML(Unified Process,RUP)oueXtreme Programming (XP)principalementpourlesraisonssuivantes:q Utilisationd’unlangagedemodélisation formeletstandardisé:UML(Unified ModelingLanguage)
q Puissanceetadéquation duparadigmeobjet(abstraction,encapsulation)pourlesac]vitésd’analyseetdeconceptionquipermetlamodélisationàdesniveauxsuccessifsd’abstraction
q Démarche itérative,etnonséquentielle,entrelesphasesderecueildesbesoins,analyse,conception,grace notammentauxniveauxd’abstractionproposés parlesmodèles
q Unificationdulangagedemodélisation UMLetdeslangagesdedéveloppement (Java,C#,etc.)autourd’unmeme paradigme(l’objet),cequifavoriselacontinuiteentrelesphasesdeconceptionetlesphasesd’implémentation
q Largeutilisationdepatternsdanslesphasesd’analyseetdeconception(Analysis Patterns,DesignPatterns)
4
Lerôledel’architecte
qIlapourrole de:
q Recenserlesbesoinstechniques(analysedel’existant,contraintes,besoinsexprimés)
q Définir lesprincipesdirecteursdel’architectureq Elaborerl’architectureapplicative,logicielleetphysiqueq Argumenterseschoixtechnologiquesq Identifierlesbesoinsenproduitstiersetframeworks techniques
5
Principesdirecteursdel’ArchitectureApplicativeqArchitectureApplicative
q EllestructureleSIenblocsapplicatifscommunicantsq Elledécrit sousl’angletechniquelesapplications,lesfluxetles messageséchangésentreapplications
qBlocapplicatifqModulelogicielexécutable ayantuneidentite,proposantdesservicesetayantuneinterface(prise)biendéfinie Approche«boite noire»
q ApprocheboitenoireqConnaissancedesentrées etsortiesdublocapplicatifqConnaissancedesfonc]onnalités etdestechnologiesqDanscettephaselesdétails dudécoupage internedublocapplicatifencouchesn’estpasétudie
6
Principesdirecteursdel’ArchitectureApplicativeqPourdéfinir lesfluxéchangés,nousallonsnousbasersurlesprincipesdirecteursdel’architecture
qExemples:qToujoursprivilégier l’utilisationdesstandardstechniquesdumarchéHTTP,XML,XSL,HTML, Javascript,DOM/DHTML,WebServices(SOAP,WSDL,UDDI),J2EE,.NET,FTP,…
qUtilisationdeslangagesXML(XML,XMLSchema,SOAP,WSDL,ebXML,...)commeformatpivotpourlesmessageséchangés
qLeséchanges synchronesentreblocsapplicatifssontréalisés enutilisantSOAP/HTTP
qLeséchanges asynchronesentreblocsapplicatifssontréalisés enutilisantunMOM...
7
Unedémarcheen4étapes
• Décrire defacon détaillée (fonctionnelle,applicativeettechnique)chacundesblocsapplicatifs(interne,externe,filialeoupartenaire).• Construireunecartographieapplicativedétaillée présentant touslesflux(synchrones/asynchrones,TP/batch)etmessageséchangés entrelesblocsapplicatifs(interne,externe,filialeoupartenaire)• Construirelamatricedesfluxàpartirdelacartographieapplicativedesflux• Apartirdescasd’utilisationidentifierunnombrelimitédecinématique représentativedel’utilisationdusystème
8
Définitions:Architecturelogicielle
qArchitectureLogicielleq Elleseconsacreàstructureretàconcevoiruneapplicationàpartirdesesspécificationsfonctionnelles
q Ellestructureetdécomposedefaçonlogiquechaqueapplicationencouchesq Elleintroduitlesnotionsetconceptsdedécoupageencouches,modules,composants,designpatternsetFrameworks
qApproche«boîteblanche»q Découpageinternedublocapplicatifencouchesmotifsdeconception(DesignPatterns)
q Framework(«cadredetravail»)etservicestechniques(gestiondestransactions,logs,traces,gestiondesfichiersdeconfiguration...)
9
Construireenassemblant
qLacapitalisationetlaréutilisationayanttoujoursétédespréoccupationsmajeuresdel’industrieinformatique,l’architectedisposeaujourd’huid’unepalettebienpluslarge:q Laconceptiondescouchessebasefortementsurdespratiqueséprouvées(designpatternsoumotifsdeconception)validésparl’industrieetrépondantgénéralementàdesproblématiquesrécurrentes
q Enassociantmotifsdeconceptionetlibrairies,lesframeworks constituentle«cadredetravail»
10
Unedémarcheen4étapes
qDemanièreitérativeetincrémentalel’architectevadanslaphased’architecturelogicielle:1. Définirlemodèled’architectureencouchesetentiersàmettreenœuvrepourchacundes
blocsapplicatifs2. Préconiserdesmotifsdeconceptionàmettreenœuvrepourlescouches3. Préconiserleslibrairies,composants,Frameworks etoutilsàutiliserpour:
qL’implémentation descouches logicielles (présentation/coordination/services/ domaine/persistance, gestiondelogs,...)
qLafabricationde l’application (conception,développement, testsunitaires, intégration,packaging)qLamiseenproductionetle suivi(déploiement, configuration, surveillance, suividelaqualitedeservice, suivideserreurs)
4. Guiderlesphasesdeconceptionetdedéveloppementens’assurantquelesconcepteursetlesdéveloppeursontbiencomprisl’architecture
11
Frameworkdedéveloppement
q Lamiseenœuvred’unframeworkdedéveloppementestunélémentfondamentalpourlaréussiteduprojet.
q Unframework (cadredetravail)correspondàunensembled’outilsdumarché,debibliothèques,despécifiquesetdeméthodologiesquivisentàfaciliter,cadreretaccélérerlesdéveloppementsduprojet.q Leframeworkdedéveloppement,élaboréenphased’étudeetconsolidéenphased’implémentation,estfondamentalàlabonneréussiteduprojet:q ildéfinitlecadredetravailetlesengagementsdechacunedesparties,fonctionnellesettechniques,enspécifiantleprocessusdedéveloppement
q ilpermetdemieuxécorréler lesaspectstechniquesdel’implémentationdesfonctionnalités
q ilcontraintetstandardiselesdéveloppementsq ildiminuelesrisquesliésauprojet
12
Structurationdesapplications
q L’architectestructurelesystèmeselonplusieurs«vues»:q Vueencouches(layerview):vue«logique»montrantledécoupagedesfonctionsdel’application• Chaquecoucheasespropresresponsabilités etutiliselacouchesituée endessousd’elle• Enfonctionduprojet,lesarchitectesenrichissentetélaguent lemodèle.• Lastructurationestalorsguidée parlescontraintesexprimées etexistantesPrésentation Controleur Services DomainePersistance
q Vueenniveaux(tier view):vue«physique»delastructurationdel’application(n-tiers)
13
Structurationdesapplications (suite)
• Lastructurationdesapplicationssetraduitparunedécompositionlogiquedechaqueapplicationen5couches:• Présentation• Contrôleur• Services• Domaine• Persistance
• Préconisationdemodèlesetmotifsdeconception(exp.MVC)
14
LacouchePrésentation
• LacouchePrésentationgèreetassurel'affichagedel'interfacegraphiqueutilisateuroulesInterfacesHomme-Machine(IHM:fenêtres,pages,composantsgraphiques...)• Cettecoucheintègreprincipalement:
• lagestiondudomainevisuel• l'interactionaveclesutilisateurs• l'interceptiondesévènementsutilisateursetl'appelàlacoucheContrôleur• lagestiondumulticanal(web,voix,mobile,fax)• lesservicesdeportail(agrégation d’IHM,bouquetsdeservices)• lesservicesd’impression(impressionsPDF,gestiondetemplates...
15
LacoucheContrôleur
• LacoucheContrôleurgère:• lecontrôledelacinématiquedesécrans• l’invocationdesappelsdeservices• leserreursetlesexceptionsquipeuventêtrelevées• lessessions/espacedetravailutilisateur• leshabilitationsetlesdroitsd’accès
• DanscertainsFramework,lacoucheContrôleurpeutprendreencomptelalangueetletypedeterminaldel’utilisateur
16
LacoucheServices
• LacoucheServicescorrespondauxtraitementsqu’effectuel’application• Ellereprésentel’implémentationdelalogiquedescasd’utilisation(use-casefonctionnels.• Cettecouchedoit:
• implémenter lalogiquemétier• gérer lasécuriteapplicative• gérer lestransactionsétendues (processus,compensation)• gérer l’intégritetransactionnelle(transactionslocalesetdistribuées)• gérer lesappelsauxobjetsmétiers delacoucheDomaine
17
LacoucheDomaine
• LacoucheDomainegère l'intégritedumodèle «métiers ».Cettecoucheintègreprincipalement:• lagestiondesrègles métiers «élémentaires »(sansétat,sansprocessus)• lafournituredesmoyensd'accèsàl'information(SGBDR,Mainframe...)• lerespectdespropriétés transactionnellesdelacouchepersistance
• LacoucheDomainerecenselesobjetsmétiers manipuléesparl’application• LacoucheDomaineestconcentréesurlemétier del’entreprise,communàtouteslesapplications
18
LacouchePersistance
• LacouchePersistanceintègre principalement:• Lapersistancecomplète duSystème d'Informations(données structurées ounonstructurées,gérées entreautresviaunSGBDR,annuaireLDAP,transactionCICS,...)• Lafournituredesservicesdestockagedesdonnées,moteursrelationnels,basesobjets,basesXML...• Lacréation,lamodification,lasuppressiond'occurrencesdesobjetsmétiers
• Ellecontientunniveaud’abstractiondedonnées lesDAO(DataAccessObject)quiprennentenchargel'accèsàlasourcededonnées(SGBDR,fichiersXML,CICS,...).Ilsoffrentunevisionobjetdesoccurrencesd’en]tés dumodèle physiquededonnées
19
LescouchesTransverses
• CoucheSécurite• Servicesdesécurite:SSO,authentification,gestiondeshabilitations,intégrite,non-répudiation...Lasécuriten’estpasunecoucheisolée,maistransverseauxautrescouches:• authentification desutilisateurs etcontrole des habilitations auniveaudes services IHM,sécurisation
des traitements(authentification, habilitations grossemaille ethabilitations fines...),• sécurisation deséchanges, sécurisation desdonnées...
• CoucheServicesTechniques(Core Services)• Indépendamment desfonc]onnalités desapplicationsetdeleurdécoupage encoucheslogicielles,onretrouvedescomposantsetservicesdebasecommuns(Core Services)ettransversesàl’ensembledescouches:• gestion des traces• statistiques etlogs• gestion des erreurs• gestion des propriétés deconfiguration• gestion des fichiers demessages (internationalisation, messages d’erreurs) monitoring...
20
Typologies des Architectures
21
L’ArchitectureOrientéeObjets
• Dansunearchitectureorientéemanipulationd’objets,onremarquetoutdesuitelenombredeliensentrelacoucheCoordinationetlesobjetsmétiersdelacoucheDomaine.
• Lecodeclientdoittraiterdirectementaveclemodèle objetdelacoucheDomaine,cequiapourconséquencedeliercelle-citrès fortementàunmodèle spécifique etrequiertunnombred'appelsimportantentrelesdeuxcouches.
• Lamultiplicationdesappels entrecouchesposeproblème lorsdelamiseàdispositionàdistancedesobjetsmétiers.Depluslenombred'objetsàmanipulerréduit l'indépendance entrecouchesetcomplexifielapriseenmaindelacouchemétier
22
L’ArchitectureOrientéeServices(SOA)
• L’architectureSOAconsisteàtraitertouteapplicationdusystèmed’informationcommeunfournisseurdeservices• LeprincipalenjeudelaSOAétant laréutilisation desservices,ceux-cidoiventetre pensés nonseulementenfonctiond’unprojetimmédiat,maisaussisurlelongtermepourserviràd’autresapplications• Celaimpliquel’interactionavecl’existant(systèmes,plates-formesetapplications),etuneouvertureversuneréutilisation futuredesnouveauxmodulesfonctionnelsoutechniques.• DansuneSOAunniveausupplémentaireestintroduitsouslaformedelacoucheServices.
23
L’ArchitectureOrientéeServices(SOA)(Suite)
• LacoucheCoordinationnemanipuleplusdirectementlesobjetsmétiers,maispassepardesappelsdeservices.Lesobjetsmétiers setrouventdansdesbibliothèquesdeclassesdirectementchargées danslememe processusquelesservices,lecout desappelsauxobjetsmétiersestalorstrès faible• Lesservicesagissentcommedes«boitesnoires»faisantabstractiondelacomplexitédumodèleobjet,présentantunensembledefonctionnalitésrestreintsetpermettantderéduire leséchanges entrelescouches
24
Bibliographie:•DesignPatterns,parErichGamma,RichardHelm,RalphJohnson,JohnVlissides (Addison-Wesley)•Core J2EEPatternshttp://java.sun.com/blueprints/corej2eepatterns/index.html•Microsoft.NETPatternshttp://msdn.microsoft.com/architecture/
25