15/04/2011

Institut Supérieur des Etudes Technologiques de

Mahdia

Cours Architecture
Logicielle

Présenté par : Mlle. Nourhène ALAYA

2010-2011

Chapitre 2:
Styles architecturaux

1. Introduction
2. Styles Généraux : pipe and filters, Architecture
avec référentiel, multi-couche.
3. Styles Interactifs : Basée évènement, Model
View Controller.
4. Styles Distribués : n-tiers, broker, SOA.

1
 15/04/2011

Style architectural
 Est un patron (modèle) décrivant une architecture
logicielle permettant de résoudre un problème particulier
et récurrent.

 Définit
 Un ensemble de composants et de connecteurs (et leur
type)
 Les règles de configuration des composants et connecteurs
(topologie)
 Une spécification du comportement du patron
 Des exemples de systèmes construits selon ce patron

 Constitue un modèle éprouvé et enrichi par l’expérience

de plusieurs développeurs
 Compréhensibilité, maintenance, évolution, réutilisation,
performance, documentation, etc.
3

Principales familles
 Les styles d’architectures logicielles se
répartirent sur quatre familles comme suit:

1. Styles Généraux : Filtres/Canaux (Pipeline),

Architecture avec référentiel, multicouches.
2. Styles Interactifs : Basé évènement, Model View
Controller (MVC).
3. Styles Distribués : n-tiers, SOA.
4. Adaptatifs : micro-kernel, réflexion.

2
 15/04/2011

Styles Architecturaux généraux

1. Architecture Pipeline
2. Architecture avec référentielle
3. Architecture multicouches

1. Architecture Filtres/Canaux : Pipeline

 Convient bien aux systèmes de traitement et de
transformation de données.
 Composants = filtre ; Connecteur = canal

 Filtre
 Reçoit ses données d’un ou plusieurs canaux d’entrée, effectue
la transformation/traitement des données et envoie les données
de sortie produites sur un ou plusieurs canaux de sorties.
 Canal
 Unidirectionnel au travers duquel circulent un flot de données
6
(stream).

3
 15/04/2011

1. Architecture Pipeline
 Exemples : application de traitement de texte, de
traitement de signaux. Compilateur (analyse lexicale,
syntaxique, sémantique), modèle de communication entre
processus Linux.

 Avantages
 Bon pour traitement en lot.
 Très flexible
 Analyse facilitée : performance, synchronisation, etc.
 Se prête bien à la décomposition fonctionnelle d’un
système
 Inconvénients
 Mauvais pour le traitement interactif (Interface utilisateur)
7

1. Exemple d’architecture Pipeline

 Système de traitement du son

Encodeur pour
sortie de microphone

Égaliser les
Filtrer Filtrer Retirer les
les intervalles
l’écho le bruit fréquences non vocales
dynamiques

Encodeur de
bruit ambiant

Décompresser Recevoir Transmettre Compresser

Encoder la sortie
des haut-parleurs

4
 15/04/2011

2. Architecture avec référentielle

 Utilisée dans le cas où des données sont partagées et
fréquemment échangées entre les composants

 Deux types de composants : réf érentiel de données et accesseur de

données
Les référentiels constituent le medium de communication entre les
accesseurs (demandant accès aux données)

 Connecteur : relie un accesseur à un réf érentiel

Rôle de communication, mais aussi possiblement de coordination, de
conversion et de facilitation

2. Architecture avec référentielle

 Variantes

 Style tableau noir (Blackboard) : les référentiels sont des

agents actifs. Lorsqu’ils reçoivent une données, ils
informent tous les accesseurs concernés afin de
synchroniser l’accès.
 Exemple: Environnement de programmation (compilateur), JVM (Java) ,
Le noyau du système Linux.

 Style référentiel passif: les référentiels sont des simples

vocations de stockage. Les composants accède aux
référentiels comme ils le désirent.
 Exemples: application de bases de données, systèmes centrés sur les
données (e.g. système bancaire, système de facturation ,etc.),

10

5
 15/04/2011

3. Architecture multicouche

 C’est une décomposition logique d’un système en couches.

 Composants : chaque couche réalise un service

 Une couche of f re un service (serveur) aux couches externes (client)

 Service créé indépendamment du logiciel
 Met à prof it la notion d’abstraction, les couches externes sont plus
abstraites (haut niveau) que les couches internes

 Connecteurs : dépendent du protocole d’interaction souhaité entre

couches

 Exemple: Modèle OSI, le protocole (TCP/IP), Décomposition d’application

en couches applicatives.
11

3. Architecture multicouches
 On distingue deux variantes du système multicouche:

 Système fermé : une couche n’a accès qu’aux couches adjacentes. Les
connecteurs ne relient que les couches adjacentes
 Système ouvert : toutes les couches ont accès à toutes les autres. Les
connecteurs peuvent relier deux couches quelconques

Système Fermé Système Ouvert

12

6
 15/04/2011

3. Architecture multicouches:
Notion de couches applicatives
 La structuration des applications se traduit par une décomposition
logique en couches applicatives (couches logicielles) au sein d'une
même application ou système.

 Le découpage en couche permet de modif ier l'implémentation d'une

couche sans impacter les autres couches applicatives.

 Les couches communiquent entre elles au travers d'un modèle

d'échange « les contrôleurs » , et chacune d'entre elles propose un
ensemble de services rendus.

3. Architecture multicouches: Couche de Présentation

 Elle gère et assure l'af f ichage des Interf aces Homme-Machine (IHM :
f enêtres, pages, composants graphiques...)

 On distingue trois catégories d'IHM pour les applications interactives :

 Client léger :
 Aucun déploiement n'est réalisé sur le poste client à l'exception d'un navigateur
Web (page HTML simple statique)
 Les différents écrans de l'application sont générés en temps réel côté serveur et
téléchargés par le poste client.

 Client lourd :
 L'ensemble des écrans de l'application sont stockés ou générés sur le poste
client et doivent avoir été déployés sur celui-ci préalablement à l'exécution:
(Applets,Flash..)

 Client riche (Smart Client) :

 Compromis entre le client léger et le client lourd
 Plusieurs options sont disponibles pour le développement d'IHM riches, à savoir
Ajax, Flex, Microsoft Silverlight, Google Web Toolkit qui permettent d’exécuter
directement le code dans le navigateur
14

7
 15/04/2011

3. Arch. Multicouche: Couche Métier

 Elle correspond aux traitements qu’effectue l’application.

 Implémentation de la logique des cas d’utilisation (use-case

fonctionnels)

 Cette couche doit :

 implémenter la logique métier
 gérer la sécurité applicative
 gérer les transactions
 gérer les appels aux objets métiers.

 Exemple bancaire :
 Services métiers: l’opération de virement de compte à compte.
 Objets métiers: le compte bancaire et le client et leurs règles
de gestion respectives.
15

3. Arch. multicouche: Couche de Persistance

 Nommée aussi couche d’accès aux données. Elle prend en charge l'accès
à la source de données (SGBDR, fichiers XML, LDAP, …).

 La couche Persistance offre les fonctionnalités de base qui permettent:

 de créer, rechercher, modifier et supprimer des composants objets

métiers dans le respect des propriétés transactionnelles classiques.

 d’utiliser le mécanisme de projection objet vers relationnel (mapping

Objet / Relationnel) qui consiste en la transformation de la
représentation des données en une représentation objet.
16

8
 15/04/2011

3. Arch. multicouches: Couche de persistance

• Le mapping objet relationnel crée une illusion d’une BD Orientée
Objet à partir d’une BD relationnelle

Donc on peut bénéficier de l’orienté objet public class Obj {

et gérer une BD relationnelle d’une façon private int id;
transparente. private String name;

public Obj(){
}
public Obj(String name) {
this.name = name;
}
public void setId(int i) {
id = i;
Table }
….
}
Il existe plusieurs Framework de mapping
objet/relationnel : Java Persistance API, TopLink,
Classe Java correspondante
Java Data Object, Hibernate, Object Relational
Bridge…

Style architectural interactif

1. Architecture basée événements

2. Architecture MVC

18

9
 15/04/2011

1. Architecture basée événements

 Composant: ils sont de nature abstraite, exposant des procédures et des
événements.
 Procédure: Composant graphique
 Evénement = clic de souris, détection d’un signal par un capteur, arrivée d’un message,
etc.

 Connecteur: Des liaisons entre des procédures et des événements. Un

composant annonce un événement et tous les composants qui se sont enregistrés
comme observateurs de cet événement sont prévenus.

 Appropriée pour les systèmes dont les composants doivent interagir avec
l’environnement.

 Exemples : La bibliothèque de composants graphiques Qt, Eclipse, Ajax, Erlang,

JoCaml, Triggers de BD.

19

2. Architecture Modèle-Vue-Contrôleur (MVC)

 Séparer la couche interface utilisateur des autres parties

du système

 Composé de trois types de composants

 Modèle : rassemble des données du domaine, des connaissances
du système. Contient les classes dont les instances doivent être
vues et manipulées

 Vue : utilisé pour présenter/af f icher les données du modèle dans

l’interf ace utilisateur

 Contrôleur : contient les f onctionnalités nécessaires pour gérer et

contrôler les interactions de l’utilisateur avec la vue et le modèle
20

10
 15/04/2011

2. Architecture Modèle-Vue-Contrôleur (MVC)

Utilisateur
utilise
Est perçue par

agit sur
Vue Contrôleur

Modèle Manipule
Met à jour

 La notification des changements d'état se font de façon asynchrone

 entre le modèle et les vues et
 entre la vue et les contrôleurs
21

2. MVC avec les composants graphiques

11
 15/04/2011

2. Architecture Modèle-Vue-Contrôleur (MVC)

• Exemple du MVC pour le Web

23

Styles architecturaux distribués

1. Architecture n-tiers
2. Architecture SOA

12
 15/04/2011

1. Architecture n-tiers
 La vue en niveaux (tiers) donne une vision plus «physique» de la structuration de
l’application. Les niveaux peuvent être répartis physiquement sur différents
composants matériels:

 N.b. L’architecture multicouches est généralement utilisée pour décrire la structure

interne (non distribuée) d’un composant qui peut lui-même appartenir à une
architecture (distribuée) n-partie.

 Composants : chaque niveaux est représenté par un composant qui joue le rôle
de client et/ou de serveur

 Connecteurs : relient un client à un serveur. Connexion asymétrique. Doit

supporter les communication distantes (e.g., requêtes RPC, HTTP, TCP/IP)

 Exemples:
 Architecture 1-tiers
 Architecture 2-tiers
 Architecture 3-tiers
 Architecture n-tiers

25

1. Architecture: 1 tiers
 Architecture Centralisée
 Les trois couches applicatives sont liées et s'exécutent sur
le même ordinateur.
• Serveur (Mainframe) :
• Client léger : passif utilisé pour l’af f ichage terminale .

• Inconvénients:
• Dépendance totale d’un système
centralisé

• Dépendance d’un constructeur

• Coûts de maintenance très

élevés
• Possibilités graphiques et
26
multimédia très limitées

13
 15/04/2011

Architecture: 2-tiers
• Architecture Décentralisée
• L’ensemble des traitements applicatifs est géré par le poste
client : Client lourd
• La gestion des données est prise en charge par un SGBD
centralisé.

 Avantages:
 Environnement graphique et multimédia avancé
 Intégration f acile de la micro inf ormatique
 Inconvénients
 Risque de surcharge du client
27
 Syndrome du «client obèse»

Architecture 3-tiers
Navigateur
 Architecture Distribuée

Présentation Tier 1 : Client

 Tous ces niveaux étant indépendants,
ils peuvent être implantés sur des
machines dif f érentes:
Tier 2:Serveur
 Le poste client ne supporte plus Traitement d’applications
l'ensemble des traitements (client
riche ou léger)
données Tier 3:Base
de données
 Facilité de déploiement Base de données

 Sécurité : pas d ’exposition du Client: Gestion de la présentation

schéma de la base de données
Serveur applicatif: lien entre clients
et plusieurs serveurs de BD
 La manipulation des données est
Serveur de données: Gestion accès
indépendante du support physique à BD
28 de stockage.

14
 15/04/2011

Architecture: n-tiers
 La littérature parle du modèle générique «N-tiers» (ou N-
niveaux)
 Rajoute des étages / couches en plus
 La couche applicative n'est pas monolithique
 Le modèle N-tiers est celui mis en œuvre dans le cadre
des projets web
 Exemple : tiers impliqués dans le modèle d’architecture
J2EE

29

Résumé sur l’architecture multi-tiers

(client riche)

30

15
 15/04/2011

2. Architecture orientée services: SOA

 Dans une SOA un niveau d'indirection supplémentaire est introduit sous
la f orme de la couche Services.

 Composant: Services
 Connecteurs : Techniques et protocoles de communication entre
service : Bus de communication, HTTP,

 Les services agissent comme des « boites noires », encapsule ces

traitements et données et masque ainsi l’hétérogénéité du système
d’inf ormation.

31

2. Architecture orientée services: SOA

 Un service n’est pas nécessairement un web service
 il peut être local ou distant.
 Les services sont interopérables
 peuvent interagir même s’ils sont hétérogènes de point de vue implémentation (≠
langages) et architecture.

32

16
 15/04/2011

2. Architecture orientée services: SOA

 Les partenaires de SOA

 Le fournisseur de services
 crée le service Web, puis publie son interface ainsi que les
informations d'accès au service, dans un annuaire de services
Web.
(Ex: Google, Yahoo)
 L'annuaire de services
 rend disponible l'interface du service ainsi que ses informations
d'accès, pour les demandeurs potentiels du service.
 Le demandeur de service (Consommateur)
 accède à l'annuaire de service
 recherche afin de trouver le service désiré.
 se lier au fournisseur pour invoquer le service.
33

2. Architecture orientée services: SOA

 Les partenaires de SOA

34

17
 15/04/2011

2. Architecture orientée services: SOA

Bus de
communication
Services existants
disponibles sur le Web

Services
implémentés pour l’application
35

18