Vous êtes sur la page 1sur 36

`

Styles et Patrons
Architecturaux
M. Bassirou NGOM

ESTM
3ème année Télé-Informatique
2019-2020 1
❑Les Vues Architecturales(1/4)
❑ Une Vue,
Une vue définit un raffinement d’une architecture, d’un
environnement ou d’un système en fonction d’un axe d’intérêt.
❑ L’architecture est donc étudiée selon un point de vue particulier (aussi,
appelée une facette), ce qui facilite sa définition et sa mise eu point.
❑ Il est important de séparer la description de l'architecture en différents
points de vue afin qu'un seul acteur puisse comprendre les différents
aspects de l'architecture.
❑Philippe Krutchen de Rational software divise l’architecture en 5 vues
appelé aussi le modèle de vue 4+1
❑ Vue logique(Logical view) qui décrit les besoins fonctionnels, c’est à
dire les services à rendre aux utilisateurs
❑ Vue Procedurale(Process view) qui décrit les aspects de concurrence,
de synchronisation, de tolérance aux fautes et de performance.
2
❑Les Vues Architecturales(2/4)
❑ Vue de distribution(physical view) qui décrit le placement du logiciel
sur le matériel et décrit les aspects répartis.
❑ Vue développement (development view) qui décrit l’organisation
statique des composants logiciels et de l’environnement de
développement.
❑ Les scenarios(use case) qui sont des exemples de mise en pratique des
quatre vues précédentes.

3
❑Les Vues Architecturales(3/4)

4
❑Les Vues Architecturales(4/4)

❑ L’utilisation de toutes les vues n’est pas obligatoire.


Chacune de ces vues utilisent ses propres notations et un
ou plusieurs styles architecturaux.
❑ Chaque architecte gère donc différentes vues contenant des
éléments qui sont adaptés à son métier.
❑ Il en résulte donc une simplicité de conception (chaque
vue isolant une seule facette du problème)
❑ et un meilleur travail en groupe (chaque spécialiste d’une
facette d’un système concevant son modèle en utilisant un
style architectural adapté et pas forcément uniforme à
toutes les vues).
5
❑Styles et Patrons d’architecture

❑ Styles(Macro pattern)
• Structure de haut niveau pour décrire un logiciel de
point de vue global
• Exemple : Modele en couches, MVC, etc.
❑ Patrons(Micro pattern)
• Solutions abstraites application à différents contextes
mais qui offrent les avantages à chaque utilisation
• Exemple : les design patterns
❑ Idiomes : décrivent les bonnes pratiques liées à:
• Un formalisme de programmation
• A un langage particulier

6
Styles architecturaux
❑ Patrons de structures génériques fréquemment rencontrées
dans la pratique
• Ces patrons ont des propriétés biens définies qui permettent la
réutilisation
❑ Architecture = composantes + connecteurs
❑ Spécification d’une décomposition en composantes qui sont
en interrelation.
❑ Permettre d’atteindre des objectifs de conception
❑ Une compréhension de ces styles peut simplifier le choix et
la conception d’une architecture logicielle
• La plupart des systèmes de grande échelle sont hétérogènes
• Ils ne correspondent pas à un style architectural unique
7
Avantages d’utiliser des styles architecturaux
❑ Réutilisation d’un design
• Des solutions bien comprises appliquées à de nouveaux
problèmes

❑ Réutilisation de code
• Partage de l’implémentation des aspects invariants d’un style

❑ Compréhension de l’organisation d’un système


• Une expression comme client-serveur communique beaucoup
d’information

❑ Interopérabilité
• Supporté par la standardisation d’un style
8
Propriétés des architectures
❑ Les objectifs de conception de l’architecture sont caractérisés
par les propriétés que l’on désire obtenir pour le système
❑ Propriétés fonctionnelles
• Fonctionnalites requises du système
❑ Propriétés non-fonctionnelles
• Maintenabilites
• Evolution, adaptation ou correction du système
• Disponibilité
• Performance
• Interopérabilité
• Robustesse
• Gestion des erreurs
• Tolérance aux fautes
• Sécurité
9
Principaux styles architecturaux
❑ En couche
• Machine virtuelle ❑ Interactif
• Client-Serveur • MVC, MVVM, MVI
• N-tiers ❑ Embarqué
❑ Data-flow • Sense-Compute-Control
• Batch sequential ❑ Interpreteur
• Pipe and filter • Interpréteur
❑ Shared memory • Code Mobile
• Blackboard ❑ Invocation Implicite
• Systemes à base de règles • Event-based
❑ Adaptatif • Publish-subscribe
• MicroKernel ❑ Peer to peer
• Reflexive
• Plug-in

10
Architecture en Couche(Layers)
❑ Couches (Layers)
• Organisation en couches de composantes offrant des groupes de
services
• Échanges limités aux composantes de la couche sous- jacente
• Principe des machines virtuelles

11
Architecture en Couche(Layers)
❑ Client-Serveur
• Modele à deux couches
• La base des systèmes distribues
• Les données sont distribuées dans un ensembles de composantes
• Le traitement est reparti parmi les composantes

• Composantes
• Serveurs : fournissent des services
• Clients : utilisent ces services

• Connecteurs
• RPC
• Protocole réseau

12
Architecture en Couche(Layers)
❑ Modèle 3-tiers
• Cas particulier d’un :
• Modele en couche
• Modele client-serveur

• Autre denomination :
• State-Logic-Display

• Roles des niveaux:


• Representation
• Logique d’application
• Données(état du système)

13
Style d’architecture Interactif
❑ Model-Vue-Controler
• Applications interactives - GUI
• Modele :
• Représente les données et les fonctionnalités du domaine de l’application

• Vues :
• Représentations visuelles des données qui forment l’application
• Il peut y avoir plus d’une vue pour un même modèle
• Controleurs:
• traitent les entrées (événements) en provenance des vues et du système et
les traduit en operations effectuées sur le modele
• Un contrôleur pour chacune des vues

14
❑Architecture Modèle-Vue-Contrôleur

15
Style d’architecture Interactif
❑ Model-Vue-Controler

16
Style d’architecture Interactif
❑ Model-Vue-Controler

17
❑Architecture Modèle-Vue-Contrôleur

18
Style d’architecture flow de données
❑ Batch sequential
• Style de flot de données (dataflow)
• Un des style le plus anciens
• Repose sur la conversion d’un flux de données
• Pour les applications de systèmes financiers

19
Style d’architecture flow de données
❑ Pipelines (Pipes and filters)
• Inspiré de la composition de fonctions en unix
• ls /dev | grep -e tty | sort
• Composantes de transformation (Filtres)
• Les filtres sont des unites de traitement qui sont spécifiées uniquement pas
les entrees qu’elles acceptent est les sorties qu’elles produisent
• Les filtres ne partage pas d’état entre eux
• Les filtres n’ont pas d’interactions entre eux
• Composantes de communication(Pipes)
• Les pipes sont des connecteurs
• Ils relient les composantes sources et composantes réceptrices
• Ils propagent les données entre elles

20
Style d’architecture Embarque
❑ Sense-Compute-Control

21
Styles architecturaux en couche

❑ Une application peut être découpée en trois niveaux d’abstraction


❖ Niveau présentation
❖ Niveau logique applicative
❖ Niveau données

Traitements

globaux
Locaux

Données
Présentations

Logique applicative

22
❑Niveaux d’abstraction
❑ La couche de présentation, ou IHM (Interface Homme Machine),
permet l'interaction de l'application avec l'utilisateur. Ce sont : les saisies
au clavier, avec la souris et l’affichage des informations à l'écran.
❑ La logique applicative décrit les traitements à réaliser par l'application
pour répondre aux besoins des utilisateurs.
❑ Traitements locaux: les contrôles effectués au niveau du dialogue
avec l'IHM (formulaires, champs, boutons radio…)
❑ Traitements globaux: les règles de l’application, appelées aussi
logique métier (Business Logic).

❑ L'accès aux données permet la gestion des informations stockées par


l'application. Fonctions classiques d’un SGBD : Définition de données,
Manipulation de données, Sécurité de données et Gestion de
transactions.
23
❑Architectures logicielles
Le découpage et la répartition de 3 niveaux d’abstraction permettent de
distinguer les architectures suivantes.
❑ Architecture 1-tiers : MainFrame
❑ Architecture 2-tiers : Client/Serveur
❑ Architecture 3-tiers et N-tiers
❑ Architecture orientée service

24
❑Architecture 1-tier : Mainframe
❑ Les utilisateurs se connectent aux applications exécutées par le serveur
central (mainframe) à l'aide de terminaux passifs.
❑ le serveur central prend en charge la gestion des données et des
traitements, y compris l'affichage qui est transmis sur des terminaux
passifs.
❑ Architecture adoptée durant les année 1970-1980.

Mainframe AS/400

21
❑Architecture 2-tiers: Client/serveur
■ Architecture 2-tiers ou Client/Serveur. Les applications de cette
architectures sont réparties sur deux types de machines:
❖ Machine Client:
❑ Elle Effectue une demande de service auprès du serveur (requêtes)

❑ Elle initie le contact (parle en premier), ouvre la session

❖ Machine serveur :
❑ Elle est la partie de l'application qui offre un service
❑ Elle est à l'écoute des requêtes clientes
❑ Elle répond au service demandé par le client (réponse)

26
❑Architecture Client/serveur (2)
❑ Classes des applications Client/ serveur selon Gartner Group

Présentation Présentation Présentation Présentation Présentation


Traitement Traitement Traitement
Données

Présentation
Traitement Traitement Traitement
Données Données Données Données Données

Classe 1 Classe 2 Classe 3 Classe 4 Classe 5


BD distribuée BD distante Traitement Présentation Présentation
Distribué distante Distribué

27
❑Architecture Client/serveur (3)

❑ Avantages
❖ Utilisation d'une interface utilisateur riche,
❖ Appropriation des applications par l'utilisateur,
❖ Introduction de la notion d'interopérabilité

❑ Inconvénients
❖ Problèmes d’intégration
❖ Efforts de sécurité
❖ Problèmes d’administration réseau
❖ Coûts de déploiement et de maintenance

28
❑Architecture 3-tiers: Web dynamique

❑ La présentation est toujours prise en charge par le poste client.


❑ La logique applicative est prise en charge par un serveur
intermédiaire : c’est le serveur applicatif.
❑ Les données sont toujours gérées de façon centralisée. Elles sont
gérées par un système de gestion de bases de données

29
❑Architecture N-tiers(1)
❑ Le serveur d’application de l’architecture 3-tiers est décomposé en
plusieurs serveurs d’application( par exemple un serveur par
région ).
❑ L’avantage de l’architecture N-tiers par rapport à celle 3-tiers est
en terme de performance. C’est-à-dire, le délai de réponse aux
requêtes Clients.

30
❑Architecture N-tiers(2)

Principales fonctionnalités d’un serveur Web :

❑ Réceptionner la requête
❑ Ré-router les requêtes dynamiques
❑ Rechercher les pages statiques
❑ Encapsuler les pages dans la réponse
❑ Émettre la réponse

31
❑Architecture N-tiers(3)

Les principales fonctionnalités d’un serveur d’application sont :

❑ Réceptionner la requête
❑ Construire la réponse dynamique
❑ Renvoyer la réponse au serveur Web

32
❑Architecture N-tiers (4)

■ Les fonctionnalités d’un serveur d’application :


La production de contenu dynamique
Le support des plates-formes
L'ouverture vers l'existant
Le pooling de connexions
Le respect des standards
L'administration
La reprise sur incident
La répartition de charges
La sécurité
La gestion de contexte

33
❑Architecture N-tiers(5)

❑ Avantages
❖ Le poste client ne supporte plus des traitements à réduire les coûts liés au
déploiement et à la maintenance.
❖ les ressources réseau sont mieux exploitées. En effet, les traitements
applicatifs sont centralisés
❖ la fiabilité et les performances de certains traitements sont améliorées par
leur centralisation.
❖ Prise en charge simple d’une forte montée en charge en renforçant le
service applicatif.
❑ Inconvénients
❖ Une expertise de développement, plus longue que dans le cadre d'une
architecture 2-tiers, est nécessaire.
❖ Les coûts de développements sont plus élevés que pour du 2-tiers.

34
❑Architecture orientée services (SOA)

❑ Style d’architecture distribuée qui permet de fournir ou


consommer un processus métier en tant que service.
❑ Offre des services réutilisables et interopérables via des interfaces
standards (construites autour de XML).
❑ Plusieurs partenaires peuvent communiquer et échanger des
données dans le contexte de SOA indépendamment des
Plateformes et langages.

35
❑Architecture orientée services (SOA) (2)
❑ Paradigme de SOA
publication
recherche Registre de
service

Fournisseur de
Consommateur service
de service invoque

❑ Fournisseur de service :
❖ Fournit un service accessible via une adresse
❖ publie son contrat dans le registre de services
❖ et exécute les requêtes des consommateurs
❑ Consommateur de service : application, service…
❖ Cherche le service dans le registre (son adresse)
❖ Se lie dynamiquement au service (binding)
❖ Invoque le service via une requête conforme au contrat
❑ Registre de services : Annuaire des contrats de services
❖ un Contrat décrit le format d’échange (format des requête/réponse, les pré
et post conditions du service et sa QoS, ex: temps de réponse). 32

Vous aimerez peut-être aussi