Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
3
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
4
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)pourlesacavité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)
5
Lerôledel’architecte
qIlapourrole de:
q Recenserlesbesoinstechniques(analysedel’existant,contraintes,besoinsexprimés)
q Définir lesprincipesdirecteursdel’architectureq Elaborerl’architectureapplicative,logicielleetphysiqueq Argumenterseschoixtechnologiquesq Identifierlesbesoinsenproduitstiersetframeworks techniques
6
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 etsortiesdublocapplicatifqConnaissancedesfoncaonnalités etdestechnologiesqDanscettephaselesdétails dudécoupage internedublocapplicatifencouchesn’estpasétudie
7
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...
8
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
9
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...)
10
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»
11
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
12
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
13
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)
14
Structurationdesapplications (suite)
• Lastructurationdesapplicationssetraduitparunedécompositionlogiquedechaqueapplicationen5couches:• Présentation• Contrôleur• Services• Domaine• Persistance
• Préconisationdemodèlesetmotifsdeconception(exp.MVC)
15
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...
16
LacoucheContrôleur
• LacoucheContrôleurgère:• lecontrôledelacinématiquedesécrans• l’invocationdesappelsdeservices• leserreursetlesexceptionsquipeuventêtrelevées• lessessions/espacedetravailutilisateur• leshabilitationsetlesdroitsd’accès
• DanscertainsFramework,lacoucheContrôleurpeutprendreencomptelalangueetletypedeterminaldel’utilisateur
17
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
18
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
19
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’enatés dumodèle physiquededonnées
20
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 desfoncaonnalité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...
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
23
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.
24
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
25