Classe : DSI 21
Manel HAMZA
ISET Nabeul
Ann e universitaire :2019-2020
1
} Au cours de ce module l tudiant doit tre
capable :
Connaitre les diff rents types des architectures
ainsi que leurs composants
Comprendre les principaux design patterns et leurs
utilisation
2
} Au cours de ce module l tudiant doit tre
capable :
Connaitre les diff rents types des architectures
ainsi que leurs composants
Comprendre les principaux design patterns et leurs
utilisation
3
=>?
4
} Crit res de qualit dun bon logiciel:
Validit
Fiabilit
Extensibilit (maintenance)
R utilisabilit
Compatibilit
Efficacit
Portabilit
V rifiabilit
Int grit
Facilit demploi
5
Validit ou conformit ou ad quation : aptitude dun produit logiciel remplir
exactement les fonctions d finies par le cahier des charges et les sp cifications.
Fiabilit : aptitude dun produit logiciel fonctionner dans des conditions anormales
sans dysfonctionnements et sans erreurs.
Extensibilit ou maintenance ou volution : facilit avec laquelle un logiciel se pr te
sa maintenance, cest -dire une modification ou une extension des fonctions qui
lui sont demand es.
R utilisabilit : aptitude dun logiciel tre r utilis , en tout ou en partie, dans de
nouvelles applications.
6
Compatibilit : facilit avec laquelle un logiciel peut tre combin avec
dautres logiciels.
Efficacit : laptitude dun logiciel bien utiliser ses ressources mat riels et
logiciels. pas de gaspillage de ressources.
Portabilit : facilit avec laquelle un logiciel peut tre transf r sous
diff rents environnements mat riels et logiciels.
V rifiabilit : facilit de pr paration des proc dures de test.
Int grit : aptitude dun logiciel prot ger son code et ses donn es contre
des acc s non autoris s.
Utilisabilit ou Facilit demploi : facilit dapprentissage, dutilisation, de
pr paration des donn es, dinterpr tation des erreurs et de rattrapage en cas
derreur dutilisation.
7
8
9
10
11
} Un logiciel est un ensemble de
programmes,
proc d s et r gles,
et ventuellement de la documentation,
relatifs au fonctionnement d'un ensemble de
traitement de donn es (J. O., Vocab. de l'informat.,
17 janv. 1982).
12
Publicité
13
14
} Dans le domaine du g nie civil, on n'imagine
pas se lancer dans la construction d'un
b timent sans avoir
pr vu son apparence,
tudi ses fondations et son quilibre,
tudi les mat riaux utiliser ainsi que leur
limites
etc.
} Dans le cas contraire, on va au-devant de
graves d sillusions...
15
Dans le domaine du g nie civil, les objectifs
de l'architecture sont que le b timent
construit
- r pond aux besoins qu'il remplit,
- soit robuste dans le temps
- et agr able lSil.
16
Par Analogie :
} Le logiciel cr doit
r pondre aux besoins
et r sister aux nombreuses modifications qu'il
subira au cours de son cycle de vie.
} Les deux objectifs principaux de toute
architecture logicielle sont
la r duction des co ts (cr ation et maintenance)
l'augmentation de la qualit du logiciel.
17
} Architecture logicielle =Software architecture
: est la structure ou les structures du
syst me, comprenant:
les composantes logicielles,
les propri t s expos es de ces composantes,
et les interactions entre celles-ci.
(Bass, Clements et Kazman 2003)
18
" Pour permettre tous de mieux comprendre
le syst me
" Pour permettre aux d veloppeurs de
travailler sur des parties individuelles du
syst me en isolation
" Pour pr parer les extensions du syst me
" Pour faciliter la r utilisation et la
r utilisabilit
} Pour faciliter la maintenance du syst me
19
} l'architecture
conception pr liminaire
elle r duit la complexit du syst me abord en le
structurant en composants logiciels
20
} Cest un professionnel de haut niveau
} Il est le responsable de la cr ation du mod le
d'architecture qui d crit les diff rents
composants d'un ou de plusieurs syst mes
informatiques, leurs interrelations et leurs
interactions.
} Assurer la stabilit et la robustesse du syst me
} Permettre une maintenance relativement facile
} Permettre les volutions futures
} Contenir les co ts
} Minimiser les complications
} Guider les programmeurs dans leurs efforts de
d veloppement
21
De mani re g n rale, toute application informatique est donc
confront e trois probl matiques :
} G rer les interactions avec l'ext rieur, en particulier l'utilisateur :
Publicité
G rer les saisies au clavier et la souris et laffichage des
informations sur l cran. C'est la probl matique de pr sentation.
} Effectuer les traitements n cessaires pour r pondre aux besoins
des utilisateurs. C'est la probl matique des traitements :
Il ya deux types de traitements :
traitements locaux: les contr les effectu s au niveau du dialogue avec
l'IHM (formulaires, champs, boutons radio&)
traitements globaux:
les donn es des
op rations (calculs) en rapport avec les r gles m tier ("business logic").
} Acc der et stocker les informations qu'il manipule, notamment
traitements effectu s sur
entre deux utilisations. C'est la probl matique des donn es.
22
23
} Le d coupage et la r partition des 3 niveaux
dabstraction permettent de distinguer les architectures
suivantes
Architecture 1-tier,
Architecture 2-tiers,
Architecture 3-tiers,
Architecture n-tiers.
24
} les trois niveaux (pr sentation, traitement, donn es)
sont fortement li s et s'ex cutent sur la m me
machine.
} Cest lexemple de lapplication utilis e en monoposte
ou sur un r seau de serveurs de fichiers, Les donn es
sont stock es sur un fichier local ou partag es sur un
serveur de fichiers
25
Architecture 1 tiers
} Limites
Conflits lors de la consultation ou de la modification
simultan e
Difficult d'assurer la confidentialit des donn es
} Solution
D couper lapplication en parties distinctes et
coop rantes :
gestion centralis e des donn es
gestion locale de l'interface utilisateur
=>Naissance du concept du client/serveur
26
} Architecture 2-tiers ou Client/Serveur
g n ration ou Client/Serveur de donn es
Le client soccupe de la pr sentation et la logique applicative
Le serveur soccupe de la gestion des donn es
de premi re
} Exemple : Application de gestion de stock fonctionnant sur
Windows ou Linux et exploitant un SGBD (oracle)
centralis .
La gestion des donn es est prise en charge par un SGBD centralis ,
s'ex cutant le plus souvent sur un serveur d di
=> serveur de donn es
Le serveur de donn es est interrog en utilisant un langage de
requ te qui est, le plus souvent, SQL
=> Le dialogue entre client et serveur se r sume donc l'envoi de
requ tes et au retour des donn es correspondant aux requ tes.
27
" Echange de messages travers le r seau reliant
les deux machines
28
Limites:
} L'exp rience a d montr qu'il tait co teux et
contraignant de vouloir faire porter l'ensemble des
traitements applicatifs par le poste client. On en
arrive aujourd'hui ce que l'on appelle le client lourd,
avec un certain nombre d'inconv nients :
Publicité
} On ne peut pas soulager la charge du poste client, qui
traitements
la grande majorit des
supporte
applicatifs,
29
Limites :
} Le poste client est fortement sollicit , il devient de plus en
plus complexe et doit tre mis jour r guli rement pour
r pondre aux besoins des utilisateurs,
} Les applications se pr tent assez mal aux fortes mont es en
charge car il est difficile de modifier l'architecture initiale,
} La relation troite qui existe entre le programme
client et l'organisation de la partie serveur complique les
volutions de cette derni re,
} Ce type d'architecture est grandement rigidifi par les
co ts et la complexit de sa maintenance.
30
Limites des arch. 2-tiers
Charge importante du poste client qui r alise l'ensemble des
traitements applicatifs
Maintenance et mises jour difficiles g rer
Conversation entre client et serveur est assez bruyante
} Ces limites proviennent de type du client : client lourd
} Solution : utilisation d'un poste client simple
communicant avec le serveur par le biais d'un
protocole standard.
31
} L'architecture 3-tiers, ou C/S de 2 me g n ration,
s pare
} l'application en 3 niveaux
Niveau 1 : l'affichage et les traitements locaux (contr les de
saisie, mise en forme de donn es... ) sont pris en charge par le
poste client
Niveau 2 : les traitements applicatifs globaux sont pris en
charge par le service applicatif : serveur dapplication
Niveau 3 : les services de base de donn es sont pris en
charge le serveur de donn es
Pr sentation
Traitement
s locaux
Traitement
s globaux
Donn es
32
33
34
} Dans larch 3-tiers le client est l ger, prend en charge
La pr sentation de l'application
Les traitements locaux permettant une v rification imm diate
de la saisie et la mise en forme des donn es
} Les volutions de l'application ne n cessitent pas la
modification de la partie cliente
} viter l'installation des applications sur le poste
utilisateur
Utiliser un navigateur web
Communiquer avec le serveur dapplication via une fa ade
web
35
} Environnement d'ex cution des traitements c t serveur
} Le code applicatif, ou code m tier,
est stock sur le serveur dapplication,
est d ploy et g r de mani re centralis e
} La communication avec le SGBD met en Suvre les
m canismes des applications client-serveur de donn es
} Exemple :
Serveur dapplication JEE : Apache Tomcat, GlassFish,
Jboss, IBM WebSphere, JOnAS&
Publicité
36
} Le poste client prend la forme d'un
navigateur Web
Le serveur dapplication n cessite une couche
web, appel serveur web, pour communiquer avec
le navigateur
37
} Fonctionnement
Le serveur web transmet au client, lui ayant fait une demande
HTTP via URL , les fichiers statiques pr sents sur son disque dur
(pages HTML , images, fichiers CSS,...)
Lorsque le client demande un traitement, page dynamique, le
serveur web aiguille cette demande vers la couche applicative
dans le serveur d'application
Une fois le traitement effectu , le serveur d'application renvoie la
page HTML au serveur web qui se charge de la router vers le client
38
39
} Facilit de d ploiement :
L'application en elle m me n'est d ploy e que sur la partie
serveur (serveur applicatif et serveur de base de donn es).
Le client ne n cessite qu un navigateur web compatible avec
l'application pour quil puisse acc der l'application
r duction du co t de d ploiement
volution r guli re du syst me.
- Cette volution ne n cessitera que la mise jour de l'application sur
le serveur applicatif.
40
} Am lioration de la s curit :
Dans un syst me client-serveur tous les clients acc daient la
base de donn es ce qui la rendait vuln rable.
Avec une architecture 3-tiers l'acc s la base n'est effectu que
par le serveur dapplication.
Ce serveur est le seul connaitre la fa on de se connecter cette base.
Il ne partage aucune des informations permettant l'acc s aux donn es,
en particulier le login et le password de la base.
Il est alors possible de g rer la s curit au niveau de ce serveur
applicatif, par exemple en maintenant la liste des utilisateurs avec
leurs mots de passe ainsi que leurs droits d'acc s aux fonctions
du syst me
On peut m me am liorer encore la s curit par la mise en place
d'une architecture r seau interdisant totalement l'acc s au serveur
de base de donn es pour les utilisateurs finaux. La mise en place
de firewall correctement configur permettra ceci.
41
} Le serveur dapplication r alise la majorit
des traitements
Probl me de gestion de la mont e en charge
42
} Inconv nients architecture 3-tiers :
Le serveur dapplication r alise la majorit des traitements
Probl me de gestion de la mont e en charge
=> le client est soulag , mais le serveur est fortement
sollicit
} L quilibrage de la charge entre client et serveur semble
atteint avec la g n ration suivante :Les architectures
n-tiers
43
} Objectif :
pallier aux limitations de larchitecture 3-tiers et
concevoir des applications puissantes et simples
maintenir.
} Solution :
distribuer la logique applicative pour une meilleure
r partition de la charge entre tous les niveaux.
44