INF5153

Génie logiciel: conception

Naouel Moha
Hiver 2011

Chapitre 4 – Conception architecturale

© Yann-Gaël Guéhéneuc 2009, Naouel Moha 2011

Plan du cours
1. Introduction
2. Processus Unifié
3. Modélisation UML (Rappels)
4. Conception architecturale
5. Conception détaillée
6. Conception Web
7. Persistance des données
8. Concepts avancés
2

1
Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
3

1. Introduction
 Qu’est-ce qu’une architecture logicielle ?
– L’architecture d’un logiciel est la structure ou l’ensemble
des structures (modules) d’un système
– Elle inclut
• Les composants logiciels
• Les propriétés externes visibles de ces composants
• Les relations entre ces composants
Cf. [Bass, Clements, and Kazman (1998) ]

2
Introduction
 Qu’est-ce que la description d’une architecture
logicielle ?
– La description de l’architecture logicielle consiste à:
• Décrire l’organisation générale d’un système et sa
décomposition en sous-systèmes ou composants
• Déterminer les interfaces entre les sous-systèmes
• Décrire les interactions et le flot de contrôle entre les sous-
systèmes
• Décrire également les composants utilisés pour implanter les
fonctionnalités des sous-systèmes
– Les propriétés de ces composants
– Leur contenu (e.g., classes, autres composants)
– Les machines ou dispositifs matériels sur lesquels ces modules
seront déployés
5

Introduction
 Pourquoi développer une architecture logicielle ?
– 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é

3
Introduction
 Utilité d’une architecture logicielle [Garlan 2000]
– Compréhension
– Réutilisation
– Construction
– Évolution
– Analyse
– Gestion

Architecture: une confluence

d’influences

Développement et Usager final: Marketing: Client: faible coût

maintenance: fonctionnalités, fonctionnalité, d’acquisition,
faible coût, performance, faible prix de vente, d’opération et
préserver sécurité, fiabilité time-to-market, d’évolution
les emplois différentiation

Architecte
8

4
Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
9

2. Modéliser avec UML

 Les vues (structurelles) d’une architecture
logicielle
– Vue logique. Description logique du système décomposé
en sous-systèmes (modules + interfaces)
• UML : diagramme de paquetages
– Vue d’implémentation. Description de l’implémentation
(physique) du système logiciel en termes de composants
et de connecteurs
• UML : diagramme de composants
– Vue de déploiement. Description de l’intégration et de la
distribution de la partie logicielle sur la partie matérielle
• UML: diagramme combiné de composants et de déploiement

10

5
Rappel : vues d’un système
Diagramme Diagramme de
de classes composants

Diagramme Diagramme de
combiné de Vue structurelle packages
déploiement/
(modèle statique)
composants

Vue des cas d’utilisation

(modèle fonctionnel des exigences)

Vue du comportement et des interactions

Diagramme de (modèle dynamique) Diagramme de
séquence cas d’utilisation

interaction comportement
Diagramme Diagramme
d’états Diagramme de
communication d’activités
comportement comportement
interaction
11

Modéliser l’architecture avec UML

 Décrire l’architecture avec UML
– Tous les diagrammes UML peuvent être utiles pour
décrire les différents aspects du modèle architectural
– Trois des diagrammes UML sont particulièrement utiles
pour décrire une architecture logicielle
• Diagramme de packages
• Diagramme de composants
• Diagramme de déploiement

12

6
Modéliser l’architecture avec UML
 Diagramme de paquetages

13

Modéliser l’architecture avec UML

 Diagramme de composants

14

7
Modéliser l’architecture avec UML
 Diagramme combiné de déploiement/composants

15

Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
16

8
Paquetages (« Package »)

 Un « package »: -element ModelElement

un groupement
0..*
logique
d’éléments de
modèles UML,
constituant un 1 Package Class Association

espace de -package
nommage

17

Paquetages (« Package »)

Nom package
+ classe 1
Éléments + classe 2
publics + classe 3
(exportés) + use case 1
+ règles d’affaires 1
Éléments - classe 4
privés - classe 5

18

9
Relations entre paquetages
 Inclusion
Pack A

Pack A

Pack B Pack C

Pack B Pack C

19

Relations entre paquetages

<<use>> <<access>>

Package A Package B Package A Package B

«import» <<trace>>

Package A Package B Package A Package B

 « use » : un élément de A utilise (« use ») un élément public de B (superclasse,

interface, paramètre, attribut, composant, etc.). Non transitive.
 « import » : les éléments publics de B sont ajoutés comme éléments publics à
A, et on y fait référence sans qualification. Transitive.
 « access » : les éléments publics de B sont ajoutés comme éléments privés de
A, et on y fait référence sans qualification. Non transitive.
 « trace » : montre un historique de développement (e.g. analyse → conception).
Transitive. 20

10
 Architecture fonctionnelle
 Objectif: organiser les classes d’analyse en un ensemble
de paquetages (modules) cohésifs, lesquels sont organisés
en partitions et couches
 Qu’est ce qu’une bonne modularisation:
– Une bonne cohésion des modules
– Un faible couplage entre modules
Partitions

«uses» «uses»

gestion des dossiers patients gestion du personnel medical gestion des rendez-vous

«uses»
«uses»
«uses» «uses» «uses»

Couches
Dossier patients Dossier personnel medical actes medicaux

21

Trouver les paquetages

 Identifier les groupes de classes exhibant un lien
sémantique assez fort
 Critères pour le regroupement de classes:
– Beaucoup de liens / associations entre éléments du
même groupe candidat
– Peu de liens entre éléments appartenant à deux groupes
candidats différents
– Manipulés par les mêmes cas d’utilisation

22

11
Trouver les paquetages
 Commencer par un premier découpage
 Raffiner le découpage pour maximiser la cohésion
et minimiser le couplage entre paquetages:
– Minimiser le nombre d’éléments publics
– Minimiser les dépendances
– Enlever les dépendances cycliques C

«uses» «uses»

«uses»

A B

«uses»
«uses»
A B

AB

23

Diagramme de composants
 Diagramme de composants
– Offre une vue de haut niveau de l’architecture du
système
– Utilisé pour décrire le système d’un point de vue
implémentation
– Permet de décrire les composants d’un système et les
interactions entre ceux-ci
– Illustre comment grouper concrètement et physiquement
les éléments (objets, interfaces, etc.) du système au sein
de modules qu’on appelle composants

24

12
Composants
composant
port

connecteur

Comp_A Comp_B
interface interface
requise fournie
«realisation»
dépendance

Classe_C

configuration

 Deux ou plusieurs composants interagissent via un connecteur

 Chaque élément architectural possède une structure et/ou
comportement pouvant être décrit par un modèle UML approprié

25

Composants
compA

 Composant
– Encapsule un traitement et/ou des données
– Encapsule un sous-ensemble de fonctionnalités et/ou de
données du système
– Restreint l’accès à ce sous-ensemble au moyen d’une
interface définie explicitement
– Possède des dépendances explicitement définies pour
exprimer les contraintes requises par son contexte
d’exécution ou sa réalisation

26

13
Composants
 Composant
– Unité autonome servant de bloc de construction pour le système
– Les composants implémentent typiquement des services
spécifiques à l’application
– La manifestation concrète d’un composant est appelé artéfact
(instance du composant déployée sur le matériel)
• N’importe quel type de code sur n’importe quel support numérique
• Code source, fichiers binaires, scripts, fichiers exécutables, bases de
données, applications, etc.

«manifestation»
Order
Order.jar

27

Composants
 Les composants et le principe de séparation des
préoccupations
– La séparation des préoccupation est le principe qui assure l’intégrité
fonctionnelle d’un composant
• Chaque composant réalise une, et seulement une fonction au sein du
système, mais peut néanmoins exposer plusieurs méthodes.
Typiquement, chaque composant est défini par une interface qui
constitue son seul moyen d’interagir avec les autres composants
• L’utilisation d’une interface pour communiquer avec les autres
composants du système facilite la maintenance puisqu’on peut alors en
changer l’implémentation sans affecter les autres composants (induit un
couplage plus faible du composant avec le reste du système)
• Les classes d’un composant devrait être vues comme un patron cohésif
qui implémente la fonctionnalité du composant

28

14
Interface de composant
 Interface de composant
– Permet à un composant d’exposer les moyens à utiliser
pour communiquer avec lui
– Types d’interfaces
• Interface offerte : définit la façon de demander l’accès à un
service offert par le composant
• Interface requise : définit le type de services (aide) requis par le
composant
– Une interface est attachée à un port du composant
• Port = point de communication du composant
• Plusieurs interfaces peuvent être attachées à un même port

29

Dépendances entre composants

 Dépendances entre composants
– Dépendance = relation entre deux composants
– Types de dépendances
• Un composant peut dépendre d’un autre composant
qui lui fournit un service ou une information
• Un composant peut dépendre d’une classe qui
implémente une partie de son comportement.
Dépendance de réalisation
• Un composant peut dépendre d’un artefact (code
source, fichier .jar, etc.) qui l’implante concrètement.
Dépendance de manifestation

30

15
Connecteur
 Connecteur
– Définition : élément architectural qui définit le type d’interactions
entre les composants et les règles gouvernant ces interactions
– Un connecteur relie les ports de deux ou plusieurs composants
– Un connecteur décrit un mécanisme de connexion indépendant de
l’application
• Représente un concept abstrait, paramétrable et indépendant des
composants spécifiques qu’il relie
– Les attributs du connecteur décrivent ses propriétés
comportementales
• E.g. sa capacité, le temps de latence, le type d’interaction (binaire/n-
aire, asymétrique/symétrique, détails du protocole), etc.

31

Connecteur
 Connecteur
– Un connecteur peut avoir un ou plusieurs rôles
• Communication :rôle le plus fréquent
• Coordination : contrôle du calcul, de la transmission des données, etc.
Orthogonal aux autres rôles
• Conversion : permet l’interaction entre composants développés
indépendamment dans des langages différents par exemple
• Facilitation : permet l’interaction entre composants conçus pour
interagir ensemble. Synchronisation, accès contrôlés aux données
partagées, etc.
– Selon le(s) rôles qu’il doit remplir et le type de communication
souhaitée entre deux composants, choix d’un type
• Procedure call (comm + coord) , Data access (comm + conv), Event,
Stream, Linkage, Distributor, Arbitrator, Adaptor (conv)

32

16
Connecteur
Type de Valeurs
Rôle Attributs
connecteur d’attributs

Software Architecture: Foundations, Theory, and Practice; R. N. Taylor, N. Medvidovic, and E. M. Dashofy; © 2008 John Wiley & Sons, Inc. 33

Exemple d’un diagramme de

composants

34

17
Diagramme de déploiement
 Objectif
– Montrer l’affectation d’artefacts logiciels (e.g. fichiers
exécutables) à des nœuds de traitement (éléments
possédant des services de traitement)

– Présenter le déploiement des éléments logiciels sur

l’architecture physique ainsi que la communication (en
général, réseau) entre des composants physiques

35

Diagramme de déploiement

noeuds
M2:MachineX
Communication
GPS satellite sans fil
S:Serveur

M1:MachineX
C1:Client TCP/IP lien

C2:Client

36

18
Diagramme de déploiement
 2 types de nœuds
– Nœud physique (ou équipement) : entité physique doté
de services de traitement et de mémoire destinés à
exécuter un logiciel
– Exemples: ordinateur, téléphone

– Nœud d’environnement d’exécution : ressource de

traitement logiciel qui s’exécute au sein d’un nœud
physique et offrant un service pour héberger et exécuter
d’autres logiciels
– Exemples: OS, machine virtuelle, navigateur Web

37

Diagramme de déploiement

Source: Larman, 2005, UML 2 et les design patterns

38

19
Choix d’une architecture
 Choix d’une architecture
– Dépend des exigences fonctionnelles et non
fonctionnelles du logiciel
– Choix favorisant la stabilité : l’ajout de nouveaux
éléments sera facile et ne nécessitera en général que
des ajustements mineurs à l’architecture
– Influencé par certains « modèles connus » de
décomposition en composants (styles architecturaux) et
de mode d’interactions (e.g., orienté objet)

39

Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
40

20
4. Style architecturaux
 Un style architectural
– Est un patron décrivant une architecture logicielle
permettant de résoudre un problème particulier
– 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.
41

Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
42

21
Architecture pipeline
 Convient bien aux systèmes de traitement et de transformation de
données
 Composants = filtre ; Connecteur = canal
– Filtre
• Traitement indépendamment et asynchrone
• 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
• Fonctionnent en concurrence. Chacun traite les données au fur et mesure qu’il les reçoit
– Canal
• Unidirectionnel au travers duquel circulent un flot de données (stream).
• Synchronisation et utilisation d’un tampon parfois nécessaire pour assurer la bon
fonctionnement entre filtre producteur et filtre consommateur
– Exemples : application de traitement de texte, de traitement de signaux. Compilateur
(analyse lexicale, syntaxique, sémantique)

Filtre

canal de synchro
communication 43

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

44

22
Architecture pipeline
 Avantages  D’un point de vue conception
– Bon pour traitement en lot (batch) – Diviser pour régner : les filtres
– Très flexible peuvent être conçus séparément
– Analyse facilitée : performance, – Cohésion : les filtres sont un type de
synchronisation, goulot cohésion fonctionnelle
d’étranglement, etc. – Couplage : les filtres n’ont qu’une
– Se prête bien à la décomposition entrée et une sortie en général
fonctionnelle d’un système – Abstraction : les filtres cachent
 Inconvénients généralement bien leurs détails
internes
– Mauvais pour le traitement interactif
– Réutilisabilité : les filtres peuvent
très souvent être réutilisés dans
d’autres contextes
– Réutilisation : il est souvent possible
d’utiliser des filtres déjà existants
pour les insérer dans le pipeline

45

Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
46

23
Architecture avec référentiel de
données (shared data)
 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
– Connecteur : relie un accesseur à un référentiel
• Rôle de communication, mais aussi possiblement de coordination et de
conversion

Référentiel1 Référentiel2

A A A A A 47

Architecture avec référentiel

 Variantes
– Style tableau noir : les référentiels sont des agents
actifs. Lorsqu’ils reçoivent une donnée, ils informent tous
les accesseurs concernés
– Style référentiel : les référentiels sont passifs. Simple
vocation de stockage. Les composants accèdent aux
référentiels comme ils le désirent
– Exemples : application de bases de données, systèmes
Web, systèmes centrés sur les données (e.g. système
bancaire, système de facturation ,etc.), environnement
de programmation

48

24
Architecture avec référentiel
 Environnement de programmation
Analyseur Compilateur
syntaxique Analyseur
lexical
Générateur
Analyseur Optimiseur
de code
sémantique

Référentiel

Arbre Table de
syntaxique symboles

Éditeur
Débogueur
syntaxique
49

Architecture avec référentiel

 Avantages
– Avantageux pour les applications impliquant des tâches
complexes sur les données, nombreuses et changeant
souvent. Une fois le référentiel bien défini, de nouveaux
services peuvent facilement être ajoutés
 Inconvénients
– Le référentiel peut facilement constituer un goulot
d’étranglement, tant du point de vue de sa performance
que du changement

50

25
Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
51

Architecture Modèle-Vue-Contrôleur
(MVC)
 Séparer la couche interface utilisateur des autres parties du
système (car les interfaces utilisateurs sont beaucoup plus
susceptibles de changer que la base de connaissances 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/afficher les données du modèle dans
l’interface utilisateur
– Contrôleur : contient les fonctionnalités nécessaires pour gérer et
contrôler les interactions de l’utilisateur avec la vue et le modèle

52

26
Architecture Modèle-Vue-Contrôleur

créer et
View mettre à jour

notifier événements
Consulter l’état
(i.e. les données) Contrôleur
notifier changements

Modèle modifier

53

Architecture Modèle-Vue-Contrôleur
 Exemple: température

Source: http://csis.pace.edu/~bergin/mvc/mvcgui.html
54

27
Architecture Modèle-Vue-Contrôleur
 Avantages :  D’un point de vue conception
– approprié pour les systèmes – Diviser pour régner : les
interactifs, particulièrement ceux composants peuvent être conçus
impliquant plusieurs vues du même indépendamment
modèle de données. – Cohésion : meilleure cohésion que
– Peut être utilisé pour faciliter la si les couches vue et contrôle
maintenance de la cohérence entre étaient dans l’interface utilisateur.
les données distribuées – Couplage : le nombre de canaux de
communication entre les 3
 Inconvénient : composants est minimal
– goulot d’étranglement possible – Réutilisabilité : la vue et le contrôle
peuvent être conçus à partir de
composants déjà existants
– Flexibilité : il est facile de changer
l’interface utilisateur
– Testabilité : il est possible de tester
l’application indépendamment de
l’interface
55

Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
56

28
 Architecture multi-couches
 Composants : chaque composant réalise un service
– Une couche offre un service (serveur) aux couches externes (client)
– Met à profit 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
– 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

 Exemples : souvent utilisé pour les systèmes implémentant

des protocoles de communication (TCP/IP)

57

Architecture multi-couches
Encrypter/décrypter un fichier
1. Entrée d’un mot de passe 4. Cryptographie
2. Obtention d’une clef d’accès 3. Interface de fichiers
3. Encryptage/décryptage du fichier 2. Gestion de clefs
4. Fonctions d’encryptage/décryptage 1. Authentification

 Chaque couche est un composant avec une interface bien définie utilisée par la couche
juste au dessus (i.e., externe)
 La couche supérieure (externe) voit la couche inférieure (interne) comme un ensemble de
services offerts
 Un système complexe peut être construit en superposant les couches de niveau
d’abstraction croissant
 Il est important d’avoir une couche séparée pour l’IU
 Les couches juste au dessous de l’IU offrent les fonctions applicatives définies par les
cas d’utilisation
 Les couches les plus basses offrent les services généraux
E.g., communication réseau, accès à la base de données

58

29
Architecture multi-couches
 Système fermé
– Reference Model of Open Systems Interconnection (OSI
model)

Application Client mail, FTP, Navigateur Internet

Formatage des données, négociation des
Présentation types de données (encryption,etc.)

Gestion et synchronisation des sessions

Session

Gestion des communications

Transport de bout en bout

Gestion des communications Réseau

de proche en proche
( routage et adressage des paquets)
Liaison de données
Gestion des flux, interprétation
et encodage des données physique
Physique
Transmission effective des signaux
59

Architecture multi-couches

Application

Swing

AWT

X11

60

30
Architecture multi-couches
Application
Interface programs
utilisateur
Screen display
facilities
Logique
applicative
User account
management
Communication
Accès au réseau
système File system
d’exploitation Accès à la
base de données
Kernel
(handling processes
and swapping)

61

Architecture multi-couches
 D’un point de vue conception – Réutilisation : on peut souvent
– Diviser pour régner : les couches réutiliser des couches développées
peuvent être conçues séparément par d’autres et qui proposent le
service requis
– Cohésion : si elles sont bien
conçues, les couches présentent – Flexibilité : il est facile d’ajouter de
une cohésion par couche nouveaux services construits sur les
services de plus bas niveau
– Couplage : des couches inférieures
bien conçues ne devraient rien – Anticipation du changement : en
savoir à propos des couches isolant les composants dans des
supérieures et les seules couches distinctes, le système
connexions autorisées entre devient résistant
couches se font via les API – Portabilité : tous les services relatifs
– Abstraction : on n’a pas à connaître à la portabilité peuvent être isolés
les détails d’implémentation des – Testabilité : les couches peuvent
couches inférieures être testées indépendamment
– Réutilisabilité : les couches – Conception défensive : les API des
inférieures peuvent être conçues de couches constituent des endroits
façon à offrir des solutions stratégiques pour insérer des
génériques réutilisables assertions de vérification
62

31
Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
63

Architecture n-niveaux
 Pour les systèmes distribués
– Comparable à une architecture par couches… dont les couches
seraient distribuées !
• N.b. L’architecture multi-couches 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
– Par abus de langage, la notion de tier a pris le sens de couche
distribuée
– Composants : chaque niveau 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 communications distantes (e.g.,
requêtes RPC, HTTP, TCP/IP)
– Exemples
• Client-serveur, Trois niveaux, Quatre niveaux
64

32
Architecture n-niveaux
 Architecture 2-niveaux (client-serveur ou client lourd)

Client Serveur
requête de service

 Architecture 3-niveaux (client léger)

Navigateur Logique Serveurs

Web applicative de
requête requête base de données
de service de service
de B.D.
 Architecture 4-niveaux
Logique
Présentation Applicative Bases de
Client
(partie web) (calculs, données
business)

65

Architecture n-niveaux
 Architecture client-serveur
– Exemple typique : un système d’informations utilisant
une base de données centrale (cas spécial de
l’architecture avec référentiel)
• Clients : reçoivent les données de l’utilisateur, initient les
transactions, etc.
• Serveur : exécute les transactions, assure l’intégrité des
données
– Architecture pair-à-pair = une généralisation de
l’architecture client-serveur
• Les composants peuvent tous à la fois être client et serveur
• Conception plus difficile: flot de contrôle plus complexe dû à la
possibilité d’interblocage…
66

33
 Client Serveur
Architecture n-niveaux requête de service

 Architecture client-serveur
<<communication>>
Client2 <<communication>>
chercher adresse
Échanger msg

Serveur
Client1
<<communication>>
Échanger msg
<<communication>> <<communication>>
Échanger msg chercher adresse
Client3

netscape:WebBrowser diro:WebServer

iexplo:WebBrowser

www.cmu.edu:WebServer
lynx:WebBrowser
67

Architecture n-niveaux
Navigateur Logique Serveurs
Web applicative de
requête requête
base de données
de service de service
 Architecture 3-niveaux de B.D.

– Organisation en trois couches

• Couche interface: Composé d’objets interfaces pour interagir
avec l’utilisateur (fenêtres, formulaires, pages Web, etc.)
• Couche logique applicative : Comporte tous les objets de
contrôle et d’entités nécessaire pour faire les traitements, la
vérification des règles et les notifications requises par
l’application
• Couche de stockage : réalise le stockage, la récupération et la
recherche des objets persistants

– Avantage sur l’architecture client-serveur

• Permet le développement et la modification de différentes
interfaces utilisateurs pour la même logique applicative
68

34
Architecture n-niveaux
Navigateur Logique Serveurs
Web applicative de
requête requête
base de données
de service de service
 Architecture 3-parties de B.D.

Réseau

Client X
Base de
Serveur de données
B.D. Unix corporative

Marché de
données

Client Windows Serveur Serveur de Dépôt de

Windows NT B.D. Unix données
Logique
applicative
69

Architecture n-niveaux
 Architecture 3-niveaux  À noter que la tendance veut
que la partie cliente soit
– De plus en plus mince, i.e., le
Interface client ne fait qu’afficher un
gestionnaire
contenu HTML
– La logique applicative est alors
responsable de créer les pages
Gestion Web à afficher par le client
des dossiers – Il faut dissocier logique
applicative et présentation des
données

Base de
données clients

70

35
Architecture n-niveaux Logique
Présentation Applicative Bases de
Client
(partie web) (calculs, données
business)
 Architecture 4-niveaux
– Architecture dont la couche logique applicative est décomposée en
• Couche Présentation (JSP, servlets)
– Présentation du contenu statique: Contenu HTML ou XML affiché par le
client
– Présentation du contenu dynamique : contenu organisé et créé
dynamiquement par le serveur web (pour ensuite être affiché en
HTML/XML par le client)
• Couche Logique applicative (calculs purs) : réalise le cœur des
traitements de l’application
– Avantage sur l’architecture 3-niveaux
• Permet de supporter un grand nombre de formats de présentation
différents (propres à chaque client), tout en réutilisant certains des
objets de présentation entre les clients. Réduction des redondances…
• Bien adaptée pour les applications Web devant supporter plusieurs
types de clients
71

Java Server Pages

- Partie cliente
Architecture n-niveaux Logique
- Partie serveur

Présentation Applicative Bases de

Client
(partie web) (calculs, données
business)

 Architecture 4-niveaux
Serveur de base
Clients Serveur de données

Interface <<build>> Présentation

ATM Serveur

Accès base de
<<submit>>
Interface <<build>> données comptes clients
Web
Gestion
<<submit>> opérations bancaires
Interface
<<build>>
employé
de la banque <<submit>>
72

36
Architecture n-niveaux
 D’un point de vue conception  Flexibilité : il est assez facile
– Diviser pour régner : de façon d’ajouter de nouveaux clients et
évidente, client et serveur peuvent serveurs
être développées séparément  Portabilité : on peut développer de
– Cohésion : le serveur peut offrir des nouveaux clients pour de nouvelles
services cohésifs au client
plateformes sans devoir porter le
– Couplage : un seul canal de serveur
communication existe souvent entre
client et serveur  Testabilité : on peut tester le client

– Réutilisation : il est possible de et le serveur indépendamment

trouver une bibliothèque de  Conception défensive : on peut
composants, interfaces, etc. pour introduire des opérations de
construire les systèmes vérification dans le code traitant les
• Toutefois, les systèmes client- messages reçus de part et d’autre
serveur dépendent très souvent de
nombreuses considérations liées
intimement à l’application

73

Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
74

37
5. Développer un modèle architectural
 Commencer par faire une esquisse de l’architecture
– En se basant sur les principaux requis des cas d’utilisation ; décomposition
en sous-systèmes
– Déterminer les principaux composants requis
– Sélectionner un style architectural
 Raffiner l’architecture
– Identifier les principales interactions entre les composants et les interfaces
requises
– Décider comment chaque donnée et chaque fonctionnalité sera distribuée
parmi les différents composants
– Déterminer si on peut réutiliser un cadriciel existant (réutilisation) ou si on
peut en construire un (réutilisabilité)
 Considérer chacun des cas d’utilisation et ajuster l’architecture pour
qu’il soit réalisable
 Détailler l’architecture et la faire évoluer

75

Références
 Software Architecture : Perspectives on an Emerging
discipline, M. Shaw and D. Garlan, 1996.

 Software Architecture in Practice, L. Bass, P. Clements, R.

Kazman, 1998.

76

38