NFE107 - Cours U ARSI 5 - Vision Informatique Logique - Architecture Logicielle - V1.0

Chapitre 5
Vision Informatique Logique

Architectures Applicative et Logicielle
NFE107
Chapitre 5
5.4 Architecture Logicielle
Dfinitions
Architecture Logicielle
Approche bote blanche
Elle se consacre structurer et concevoir une application partir de ses spcifications fonctionnelles
Elle structure et dcompose de faon logique chaque application en couches
Elle introduit les notions et concepts de dcoupage en couches, modules, composants, design patterns et
frameworks
Dcoupage interne du bloc applicatif en couches motifs de conception (Design Patterns)

Framework ( cadre de travail ) et services techniques (gestion des transactions, logs, traces, gestion
des fichiers de configuration...)
Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0
Construire en assemblant
A lorigine, les matriaux de base de larchitecte logiciel sont les langages de programmation et
les librairies associes
La capitalisation et la rutilisation ayant toujours t des proccupations majeures de lindustrie

informatique, larchitecte dispose aujourdhui dune palette bien plus large :
La conception des couches se base fortement sur des pratiques prouves (design patterns ou motifs de
conception) valids par lindustrie et rpondant gnralement des problmatiques rcurrentes
En associant motifs de conception et librairies, les frameworks constituent le cadre de travail
La standardisation aidant, les composants deviennent un ingrdient essentiel de cet

assemblage. Certains diteurs proposent, pour des domaines fonctionnels verticaux, de
vritables progiciels supportant les standards
Rfrences
Design Patterns, par Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison-Wesley)
Core J2EE Patterns : http://java.sun.com/blueprints/corej2eepatterns/index.html
Microsoft .NET Patterns : http://msdn.microsoft.com/architecture/
Une dmarche en 4 tapes

De manire itrative et incrmentale larchitecte va dans la phase

darchitecture logicielle:
1.
2.
3.
Dfinir le modle darchitecture en couches et en tiers mettre en uvre pour

chacun des blocs applicatifs
Prconiser des motifs de conception mettre en uvre pour les couches
Prconiser les librairies, composants, frameworks et outils utiliser pour :

4.
Limplmentation des couches logicielles (prsentation / coordination / services /

domaine / persistance, gestion de logs, )
La fabrication de lapplication (conception, dveloppement, tests unitaires, intgration,
packaging)
La mise en production et le suivi (dploiement, configuration, surveillance, suivi de la
qualit de service, suivi des erreurs)
Guider les phases de conception et de dveloppement en sassurant que les

concepteurs et les dveloppeurs ont bien compris larchitecture
Guider la conception et le dveloppement

Larchitecte doit :
veiller ce que larchitecture conue soit bien apprhende par les quipes de conception et de dveloppement
cadrer la dmarche de conception et de dveloppement.
Sa mission consiste
A bien documenter son architecture, afin que les quipes de conception et de dveloppement soient guides
respectivement dans la conception et limplmentation des couches et lutilisation des motifs de conception, composants et
frameworks
Proposer le framework du projet, constitu de motifs de conception et de librairies, qui va cadrer :

Une couche dabstraction permettant de rendre limplmentation indpendante des librairies ou briques choisies trouvera
tout naturellement sa place dans un tel socle (notion de mta-framework).
Larchitecte doit prconiser les outils qui seront utiliss :
Les concepteurs dans leur conception du fonctionnel et

les dveloppeurs dans leur implmentation du fonctionnel.
par les concepteurs pour spcifier (conception UML, intranet documentaire)

par les dveloppeurs lors du dveloppement et des tests (environnement de dveloppement, gestionnaires de sources,
tests unitaires, automatisation des dploiements).
La productivit est une proccupation grandissante dans les projets. Larchitecte, pourra prconiser dans son
architecture de dveloppement les outils de productivit (gnrateurs, L4G personnaliss, ) compatibles
avec les contraintes du projet (budgets, culture des personnes).
Larchitecte peut imposer des pratiques (tests unitaires, documentation automatique) qui permettent de mieux
assurer la qualit de la ralisation.
Larchitecte participe dcrire dans le dtail le processus de dveloppement de bout en bout (de la
conception lintgration : guides de dveloppement, patterns, mthodologie dintgration continue) en
contraignant lutilisation des outils, des librairies, composants et frameworks dans le contexte du projet
Framework de dveloppement
La mise en uvre dun framework de dveloppement est un lment fondamental

pour la russite du projet.
Un framework (cadre de travail) correspond un ensemble doutils du march, de

bibliothques spcifiques et de mthodologies qui visent faciliter, cadrer et
acclrer les dveloppements du projet.
Le framework de dveloppement, labor en phase dtude et consolid en phase

dimplmentation, est fondamental la bonne russite du projet :
il dfinit le cadre de travail et les engagements de chacune des parties, fonctionnelles et

techniques, en spcifiant le processus de dveloppement
il permet de mieux dcorrler les aspects techniques de limplmentation des fonctionnalits
il contraint et standardise les dveloppements
il diminue les risques lis au projet
Chapitre 5
5.5 Structuration des applications
Structurer
La structuration du systme peut tre vue sous diffrents angles, selon que lon
considre :
le dcoupage logique hors de tout contexte dexcution (machines, OS et rseaux)

le dcoupage physique (prenant en compte le contexte dexcution)
Larchitecte structure le systme selon plusieurs vues :

1.
Vue en couches (layer view) : vue logique montrant le dcoupage des fonctions de
lapplication

2.
elle est indpendante des considrations physiques

la littrature propose des modles standards de structuration qui couvrent les types classiques
dapplications
le modle de rfrence est le modle 5 couches, qui sapplique aux applications munies dune
interface graphique manipulant des donnes persistantes
Vue en niveaux (tier view) : vue physique de la structuration de lapplication
La vue en couches
La structuration des applications en couches permet :
de matriser la complexit des applications (dveloppement, changes entre les applications, interactions
entre objets)
doptimiser les temps de dveloppement, en factorisant certaines briques applicatives
disoler les problmatiques denchanements de processus en dfinissant et en dlimitant le primtre du
contrle de lintgrit transactionnelle (locale et distribue)
de favoriser la communication :

10
lintrieur dune application, en structurant les changes entre les diffrentes couches
entre les applications en prcisant les principes de communication lie aux couches de diverses applications
Le passage dune couche vers une autre doit imprativement se faire via des interfaces qui
reprsentent chacune un service daccs (introduction de la notion de contrats de services)
La cohrence entre lurbanisme (qui conoit les plans des SI dans une perspective de
fonctionnement rationnel et dvolutivit) et larchitecture dun projet (qui en construit les blocs
applicatifs), est dautant plus aise assurer si lon parvient dcouper les blocs applicatifs
selon les couches du modle de larchitecture applicative logique
Modle en 5 couches
La structuration des applications se traduit par une dcomposition logique de chaque

application en 5 couches :
11
Prsentation
Contrleur
Services
Domaine
Persistance
Chaque couche a ses propres responsabilits et utilise la couche situe en dessous

delle
En fonction du projet, les architectes enrichissent et laguent le modle. La

structuration est alors guide par les contraintes exprimes et existantes
Couche prsentation
La couche Prsentation gre et assure l'affichage de l'interface graphique utilisateur ou les

Interfaces Homme-Machine (IHM : fentres, pages, composants graphiques...)
Cette couche intgre principalement :
L'interface graphique du systme est compose de deux parties :

1.
2.
12
la gestion du domaine visuel

l'interaction avec les utilisateurs
l'interception des vnements utilisateurs et l'appel la couche Contrleur
la gestion du multicanal (web, voix, mobile, fax)
les services de portail (agrgation dIHM, bouquets de services)
les services dimpression (impressions PDF, gestion de templates)
Les crans, qui assurent la restitution de l'tat du systme sur un terminal graphique et permettent la
saisie de donnes et la demande d'excution de traitements
Les ditions, qui assurent la restitution de l'tat du systme en vue d'une impression. Un cran de
prvisualisation accompagne gnralement chaque dition
Couche Prsentation (suite)

On distingue trois catgories d'IHM pour les applications interactives :
Client lger :

Client lourd :

Dans ce modle, l'ensemble des crans de l'application sont stocks ou gnrs sur le poste client et doivent avoir
t dploys sur celui-ci pralablement l'excution
Ce type de client n'impose priori pas de restriction sur le contenu et l'ergonomie des crans
En rgle gnrale, une complexit croissante va de pair avec une taille croissante de l'application tlcharger
Client riche (Smart Client) :

13
Dans ce modle, aucun dploiement n'est ralis sur le poste client l'exception d'un navigateur Web
Les diffrents crans de l'application sont gnrs en temps rel ct serveur et tlchargs par le poste client
Ce modle constitue un compromis entre le client lger et le client lourd

Il prsente une ergonomie comparable celle d'un client lourd tout en limitant les problmatiques de dploiement
inhrentes ce dernier
Plusieurs options sont disponibles pour le dveloppement d'IHM riches, savoir Adobe Flex, Microsoft Silverlight,
Google Web Toolkit qui permettent dexcuter directement le code dans le navigateur
Couche Contrleur
La couche Contrleur gre :
Dans certains frameworks, la couche Contrleur peut prendre en compte la langue et le type de
terminal de lutilisateur
Larchitecture applicative de gestion des interactions utilisateur est gnralement mise en uvre
autour du motif de conception MVC (Modle-Vue-Contrleur):
14
le contrle de la cinmatique des crans

linvocation des appels de services
les erreurs et les exceptions qui peuvent tre leves
les sessions / espace de travail utilisateur
les habilitations et les droits daccs
le Modle reprsente lensemble des composants qui sont chargs de raliser des appels la couche
Services et de mettre les rsultats de lappel la disposition de la Vue
la Vue reprsente l'interface utilisateur.
le Contrleur gre la synchronisation entre la Vue et le Modle. Le contrleur ragit aux actions de
lutilisateur en effectuant les actions ncessaires sur le Modle. Le Contrleur surveille les modifications
du modle et informe la Vue des mises jour ncessaires.
Le modle MVC
15
Couche Services
La couche Services correspond aux traitements queffectue lapplication
Elle reprsente limplmentation de la logique des cas dutilisation (use-case

fonctionnels) proprement parler
Cette couche doit :
Elle gre les services mtiers qui enchanent des rgles mtiers (processus mtier) et
des appels la couche Domaine
16
implmenter la logique mtier

grer la scurit applicative
grer les transactions tendues (processus, compensation)
grer lintgrit transactionnelle (transactions locales et distribues)
grer les appels aux objets mtiers de la couche Domaine
Exemple : virement de compte compte

Couche Domaine
La couche Domaine gre l'intgrit du modle mtiers . Cette couche intgre

principalement:
la gestion des rgles mtiers lmentaires (sans tat, sans processus)

la fourniture des moyens d'accs l'information (SGBDR, Mainframe...)
le respect des proprits transactionnelles de la couche persistance
La couche Domaine recense les objets mtiers manipules par lapplication
La couche Domaine est concentre sur le mtier de lentreprise, commun toutes les
applications
Elle contient les Objets Mtier qui implmentent le modle mtier. Ils offrent la couche
Services une abstraction pour la manipulation unitaire ou multiple des occurrences de
donnes, ainsi que la mise en uvre des rgles de gestion associes
Exemple bancaire : lopration de virement de compte compte

17
lopration de virement de compte compte est un lment de la couche Services

le compte bancaire et le client et leurs rgles de gestion respectives, se situent dans la couche
Domaine
Couche Persistance
La couche Persistance intgre principalement :
Elle contient un niveau dabstraction de donnes les DAO (Data Access Object) qui
prennent en charge l'accs la source de donnes (SGBDR, fichiers XML, CICS, ).
Ils offrent une vision objet des occurrences dentits du modle physique de donnes
La couche Persistance offre les fonctionnalits de base qui permettent :
18
la persistance complte du Systme d'Informations (donnes structures ou non

structures, gres entre autres via un SGBDR, annuaire LDAP, transaction CICS, ...)
La fourniture des services de stockage des donnes, moteurs relationnels, bases objets,
bases XML
la cration, la modification, la suppression d'occurrences des objets mtiers
de crer, rechercher, modifier et supprimer des composants objets mtiers dans le respect
des proprits transactionnelles classiques
dutiliser le mcanisme de projection objet vers relationnel (mapping Objet / Relationnel) qui
consiste en la transformation de la reprsentation des donnes en une reprsentation objet
doffrir le support, des contextes transactionnels issus de la couche domaine
Couches Transverses
Couche Scurit
Services de scurit : SSO, authentification, gestion des habilitations, intgrit, nonrpudiation La scurit nest pas une couche isole, mais transverse aux autres couches:

Couche Services Techniques (Core Services)
Indpendamment des fonctionnalits des applications et de leur dcoupage en couches

logicielles, on retrouve des composants et services de base communs (Core Services) et
transverses lensemble des couches :

19
authentification des utilisateurs et contrle des habilitations au niveau des services IHM,
scurisation des traitements (authentification, habilitations grosse maille et habilitations fines),
scurisation des changes, scurisation des donnes
gestion des traces

statistiques et logs
gestion des erreurs
gestion des proprits de configuration
gestion des fichiers de messages (internationalisation, messages derreurs)
monitoring
Architecture en couches pour une application

complexe
Les architectes peuvent tre amens effectuer des dcoupages plus fins lorsque les
contraintes deviennent plus industrielles
Un tel dcoupage sexplique par :
20
La sparation des traitements dans une couche Service a pour objectif de permettre leur rutilisation
entre des processus automatiques (arrive de messages en provenance de systmes externes) et
des oprations manuelles effectues via les IHMs
Une couche Domaine est pertinente dans le cas o les traitements effectuer sont nombreux, portent sur
des entits mtiers identifies, rcurrentes et ont une importante dure de vie
Le recours une couche Echanges (comprenant les couches Connectivit, Transformation et
Routage) permet dintgrer des sources dinformations multiples et htrognes, en les transformant en
un ensemble plus rduit de formats pivots pour les router vers les traitements adquats. Elle propose des
services dchanges entre traitements (changes synchrones, asynchrones), entre systme de
persistance (synchronisation de rfrentiels, ETL, ...), services de garantie de livraison de message,
Message Broker (Transformation, Routage, DataFlow), services de gestion de transactions tendues
(processus, compensation)
La vue en niveaux
21
La vue en niveaux (la tier view) donne une vision plus physique de la structuration
de lapplication. Les niveaux (ou tiers) peuvent tre rpartis physiquement sur
diffrents composants matriels.
On identifie un changement de niveau ds quun module logiciel doit passer par

un intermdiaire de communication (middleware) pour en invoquer un autre. Si
lutilisation du middleware est en gnral transparente pour les dveloppeurs, elle
nest pas sans impact sur larchitecture. Larchitecte doit donc matriser les
caractristiques (client/serveur, publication/abonnement, scurit, support du
transactionnel, ) et en justifier lusage.
Des modles standards de rpartition de niveaux ont t dfinis dans les projets par
lindustrie au fur et mesure de lvolution des capacits matrielles et des besoins
Modle 1 tiers
22
Le modle 1 niveau (ou tiers) correspond un binaire dans lequel sexcutent

toutes les couches, de la prsentation la persistance.
Cest lexemple de lapplication utilise en monoposte ou sur un rseau de serveurs

de fichiers, ainsi que de lapplication sur systme central.
Les donnes sont stockes sur un fichier local ou partages sur un serveur de
fichiers
Le modle 2 tiers
23
Le modle 2 niveaux (ou tiers), encore appel client/serveur premire

gnration , repose sur lutilisation de moteurs de bases de donnes relationnelles.
Ces moteurs permettent de distribuer la gestion de la persistance sur un serveur
Ce modle a typiquement permis de mieux rpondre au besoin daccs concurrents

et de supporter dimportants volumes
Cest avec ce type darchitectures que lon a pu gagner en flexibilit et se passer des
onreux systmes centraux
Lapplication dentreprise peut ainsi tre accde depuis un ordinateur personnel

avec des standards de prsentation moderne
Modle n-tiers
24
La littrature parle du modle gnrique N-tiers (ou N-niveaux)
Le modle N-tiers est celui mis en uvre dans le cadre des projets web
Exemple : tiers impliqus dans le modle darchitecture J2EE
Chapitre 5
5.6 Qualit de service
Qualit de service
Les points concernant la qualit de service doivent tre abords ds les phases darchitecture
applicative logique et logicielle, notamment sur les problmatiques suivantes :
Scurit
Faire apparatre les blocs applicatifs impacts par les aspects scurit :
Performances

Mentionner les points lis aux temps de rponse.

En ce qui concerne dventuels mcanismes de rpartition de charge, faire apparatre les composants progiciels
impacts par ces mcanismes, et les composants applicatifs galement impacts par ces mcanismes (faire
apparatre notamment les ventuels besoin de gestion daffinit de session)
Continuit de Service
26
identification,
authentification,
gestion des habilitations,
intgrit, confidentialit et non rpudiation (donnes et changes)
Faire apparatre les composants produits impacts par les mcanismes de basculement sur incident (transparent ou
non), et les composants applicatifs galement impacts par ces mcanismes (faire apparatre lventuel besoin de
partage/rplication de contexte de session,
Identifier les besoins en termes de Haute disponibilit (mcanismes de loadbalancing, gestion du fail-over)
Chapitre 5
5.7 Typologies dArchitecture
Architecture Oriente Objets
28
Dans une architecture oriente manipulation dobjets, on remarque tout de suite le nombre de
liens entre la couche Coordination et les objets mtiers de la couche Domaine.
Le code client doit traiter directement avec le modle objet de la couche Domaine, ce qui a pour
consquence de lier celle-ci trs fortement un modle spcifique et requiert un nombre
d'appels important entre les deux couches.
La multiplication des appels entre couches pose problme lors de la mise disposition
distance des objets mtiers. De plus le nombre d'objets manipuler rduit l'indpendance entre
couches et complexifie la prise en main de la couche mtier
LArchitecture Oriente Services (SOA)

Larchitecture SOA consiste traiter toute application du systme dinformation comme un

fournisseur de services
Le principal enjeu de la SOA tant la rutilisation des services, ceux-ci doivent tre penss non
seulement en fonction dun projet immdiat, mais aussi sur le long terme pour servir dautres
applications
Les applications daujourdhui ne sont plus monolithiques et doivent sintgrer harmonieusement
dans le systme dinformation de lentreprise
Cela implique linteraction avec lexistant (systmes, plates-formes et applications), et une
ouverture vers une rutilisation future des nouveaux modules fonctionnels ou techniques
Les axes majeurs de la SOA sont :
29
La rutilisation et la composition : partage de modules entre applications

La prennit : implique le support des technologies existantes et venir
L'volutivit : la majeure partie des applications sont amenes voluer dans le temps afin de pouvoir
rpondre aux nouveaux besoins fonctionnels
L'ouverture et l'interoprabilit : partager des modules applicatifs entre plates-formes et
environnements
La distribution : pouvoir utiliser ces modules distance et les centraliser au sein de l'entreprise par
exemple
La performance
SOA (suite)
30
Dans une SOA un niveau d'indirection supplmentaire est introduit sous la forme de la couche
Services.
La couche Coordination ne manipule plus directement les objets mtiers, mais passe par des
appels de services. Les objets mtiers se trouvent dans des bibliothques de classes
directement charges dans le mme processus que les services, le cot des appels aux objets
mtiers est alors trs faible.
Les services agissent comme des boites noires faisant abstraction de la complexit du
modle objet, prsentant un ensemble de fonctionnalits restreints et permettant de rduire les
changes entre les couches
SOA (suite)
Un service (local ou distant) est un module :

Un service doit assurer un rle bien dfini et non redondant (les services doivent tre factoriss)
Un contrat de service prcisant le contrat dinterface et la qualit de service doit tre dfini entre
le(s) fournisseur(s) de services et le(s) consommateur(s)
Un service doit pouvoir tre utilis par plusieurs types de consommateurs :

31
Pouvant tre invoqu en mode synchrone ou asynchrone

Charg d'une fonction particulire
Prsentant une interface bien dfinie
Internes ou
Externes (clients, filiales, partenaires, )
Un service doit pouvoir tre utilis par exemple pour un traitement batch (asynchrone multivalu) et pour un traitement TP (synchrone mono-valu)
Le terme service a un sens plus large que son utilisation dans le cadre de Services Web. On
peut faire de la SOA sans Service Web. Lorientation service renvoie une faon de concevoir
le SI avant de renvoyer une implmentation technique de cette conception
SOA (suite)
Un service est cr dans le contexte d'une application, mais il doit tre conu de
faon pouvoir tre utilis dans d'autres contextes
Les services doivent tre conus pour tre utiliss aussi bien en local qu' distance
Dcouplage entre les couches et optimisation des changes afin dassurer de plus
grandes facilits dvolutivit et de rutilisation, il convient de dcoupler les couches
les unes des autres
32
La communication entre les couches dpend de larchitecture physique de lapplication.

Lorsque les couches se trouvent sur des machines physiquement distinctes, des
mcanismes tels que le remoting ou les Services Web peuvent tre mis en uvre
Lorsque les couches dune application se trouvent toutes sur la mme machine, il convient
doptimiser la performance en privilgiant des appels directs entre les couches

NFE107 - Cours U ARSI 5 - Vision Informatique Logique - Architecture Logicielle - V1.0

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

NFE107 - Cours U ARSI 5 - Vision Informatique Logique - Architecture Logicielle - V1.0

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 5

Vision Informatique Logique

5.4 Architecture Logicielle

Approche bote blanche

Dcoupage interne du bloc applicatif en couches motifs de conception (Design Patterns)

Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0

La capitalisation et la rutilisation ayant toujours t des proccupations majeures de lindustrie

La standardisation aidant, les composants deviennent un ingrdient essentiel de cet

Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0

Une dmarche en 4 tapes

De manire itrative et incrmentale larchitecte va dans la phase

Dfinir le modle darchitecture en couches et en tiers mettre en uvre pour

Limplmentation des couches logicielles (prsentation / coordination / services /

Guider les phases de conception et de dveloppement en sassurant que les

Guider la conception et le dveloppement

Larchitecte doit prconiser les outils qui seront utiliss :

Les concepteurs dans leur conception du fonctionnel et

par les concepteurs pour spcifier (conception UML, intranet documentaire)

La mise en uvre dun framework de dveloppement est un lment fondamental

Un framework (cadre de travail) correspond un ensemble doutils du march, de

Le framework de dveloppement, labor en phase dtude et consolid en phase

il dfinit le cadre de travail et les engagements de chacune des parties, fonctionnelles et

5.5 Structuration des applications

le dcoupage logique hors de tout contexte dexcution (machines, OS et rseaux)

Larchitecte structure le systme selon plusieurs vues :

elle est indpendante des considrations physiques

Vue en niveaux (tier view) : vue physique de la structuration de lapplication

Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0

La structuration des applications en couches permet :

La structuration des applications se traduit par une dcomposition logique de chaque

Chaque couche a ses propres responsabilits et utilise la couche situe en dessous

En fonction du projet, les architectes enrichissent et laguent le modle. La

Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0

La couche Prsentation gre et assure l'affichage de l'interface graphique utilisateur ou les

Cette couche intgre principalement :

L'interface graphique du systme est compose de deux parties :

la gestion du domaine visuel

Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0

Couche Prsentation (suite)

On distingue trois catgories d'IHM pour les applications interactives :

Client riche (Smart Client) :

Ce modle constitue un compromis entre le client lger et le client lourd

Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0

La couche Contrleur gre :

le contrle de la cinmatique des crans

Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0

La couche Services correspond aux traitements queffectue lapplication

Elle reprsente limplmentation de la logique des cas dutilisation (use-case

Cette couche doit :

implmenter la logique mtier

Exemple : virement de compte compte

La couche Domaine gre l'intgrit du modle mtiers . Cette couche intgre

la gestion des rgles mtiers lmentaires (sans tat, sans processus)

La couche Domaine recense les objets mtiers manipules par lapplication

lopration de virement de compte compte est un lment de la couche Services

La couche Persistance intgre principalement :

La couche Persistance offre les fonctionnalits de base qui permettent :

la persistance complte du Systme d'Informations (donnes structures ou non

Couche Services Techniques (Core Services)

Indpendamment des fonctionnalits des applications et de leur dcoupage en couches

gestion des traces

Cours U&ARSI 5 - Vision Informatique Logique Architecture Applicative - v1.0

Architecture en couches pour une application

Un tel dcoupage sexplique par :