ISET Nabeul Année universitaire :2019-2020
capable :
Connaitre les différents types des architectures ainsi que leurs composants
Comprendre les principaux design patterns et leurs utilisation
2
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é d’un bon logiciel:
Validité Fiabilité Extensibilité (maintenance) Réutilisabilité Compatibilité Efficacité Portabilité Vérifiabilité Intégrité Facilité d’emploi
5
Validité ou conformité ou adéquation : aptitude d’un produit logiciel à remplir
exactement les fonctions définies par le cahier des charges et les spécifications.
Fiabilité : aptitude d’un 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, c’est à-dire à une modification ou à une extension des fonctions qui
lui sont demandées.
Réutilisabilité : aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de
nouvelles applications.
6
d’autres logiciels.
Efficacité: l’aptitude d’un 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 d’un logiciel à protéger son code et ses données contre
des accès non autorisés.
Utilisabilité ou Facilité d’emploi : facilité d’apprentissage, d’utilisation, de
7
8
9
10
11
programmes,
procédés et règles,
et éventuellement de la documentation, relatifs au fonctionnement d'un ensemble de
Publicité
traitement de données (J. O., Vocab. de l'informat., 17 janv. 1982).
12
13
14
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
de l'architecture sont que le bâtiment construit
répond aux besoins qu'il remplit,
soit robuste dans le temps
et agréable à l‘œil.
16
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
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
conception préliminaire
elle réduit la complexité du système abordé en le structurant en composants logiciels
20
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
Publicité
Permettre une maintenance relativement facile
Permettre les évolutions futures
Contenir les coûts
Minimiser les complications
Guider les programmeurs dans leurs efforts de
21
confrontée à trois problématiques :
Gérer les interactions avec l'extérieur, en particulier l'utilisateur :
Gèrer les saisies au clavier et à la souris et l’affichage 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: traitements effectués sur 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
entre deux utilisations. C'est la problématique des données .
22
23
Le découpage et la répartition des 3 niveaux d’abstraction 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. C’est l’exemple de l’application 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 l’application 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
génération ou Client/Serveur de données
Le client s’occupe de la présentation et la logique applicative
Le serveur s’occupe de la gestion des données
Exemple : Application de gestion de stock fonctionnant sur
Publicité
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 : On ne peut pas soulager la charge du poste client, qui supporte la grande majorité des traitements 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
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'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 d’application
Niveau 3 : les services de base de données sont pris en charge le serveur de données
32
34
Dans l’arch 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 d’application via une façade
35
Le code applicatif, ou code métier,
est stocké sur le serveur d’application,
est déployé et géré de manière centralisée
La communication avec le SGBD met en œuvre les mécanismes des applications client-serveur de données Exemple :
Serveur d’application JEE : Apache Tomcat, GlassFish, Jboss, IBM WebSphere, JOnAS…
36
Publicité
Le poste client prend la forme d'un navigateur Web
- Le serveur d’application 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
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 qu’il 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
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 d’application.
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
des traitements
- Problème de gestion de la montée en charge
42
Inconvénients architecture 3-tiers :
Le serveur d’application 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
pallier aux limitations de l’architecture 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