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