Architecture
matériel
et
logiciel
2


Architectures


Venera
Arnaoudova

 Concep8on
architecturale

1.  Introduc8on

2.  Modéliser
l’architecture
avec
UML

3.  Éléments
architecturaux

4.  Styles
architecturaux

1.  Architecture
pipeline

2.  Architecture
avec
référen8el
de
données

3.  Architecture
MVC

4.  Architecture
mul8‐couches

5.  Architecture
n‐niveaux

5.  Développer
un
modèle
architectural


1/20/10 2
 1.
Introduc8on

•  Qu’est‐ce
qu’une
architecture
logicielle
?

–  L’architecture
d’un
logiciel
est
la
structure
des

structures
(modules)
d’un
système

–  Elle
inclut


•  Les
composants
logiciels

•  Les
propriétés
externes
visibles
de
ces
composants

•  Les
rela8ons
entre
ces
composants

Cf.
[Bass,
Clements,
and
Kazman
(1998)
]


1/20/10 3
 Introduc8on

•  Qu’est
que
la
descrip8on
d’une
architecture
logicielle
?

–  La
défini8on
de
l’architecture
logicielle
consiste
à:

•  Décrire
l’organisa8on
générale
d’un
système
et
sa
décomposi8on
en

sous‐systèmes
ou
composants

•  Déterminer
les
interfaces
entre
les
sous‐systèmes

•  Décrire
les
interac8ons
et
le
flot
de
contrôle
entre
les
sous‐systèmes

•  Décrire
également
les
composants
u8lisés
pour
implanter
les

fonc8onnalités
des
sous‐systèmes

–  Les
propriétés
de
ces
composants

–  Leur
contenu
(e.g.,
classes,
autres
composants)

–  Les
machines
ou
disposi8fs
matériels
sur
lesquels
ces
modules
seront

déployés


1/20/10 4
 Introduc8on


•  Pourquoi
développer
une
architecture

logicielle
?


–  Pour
perme`re
à
tous
de
mieux
comprendre
le

système

–  Pour
perme`re
aux
développeurs
de
travailler
sur

des
par8es
individuelles
du
système
en
isola8on

–  Pour
préparer
les
extensions
du
système

–  Pour
faciliter
la
réu8lisa8on
et
la
réu8lisabilité


1/20/10 5
 Introduc8on


•  U8lité
d’une
architecture
logicielle
[Garlan
2000]


–  Compréhension
:
facilite
la
compréhension
des
grands
systèmes

complexes
en
donnant
une
vue
de
haut‐niveau
de
leur
structure
et
de

leurs
contraintes.
Les
mo8va8ons
des
choix
de
concep8on
sont
ainsi

mis
en
évidence

–  Réu8lisa8on
:
favorise
l’iden8fica8on
des
éléments
réu8lisables,

par8es
de
concep8on,
composants,
caractéris8ques,
fonc8ons
ou

données
communes

–  Construc8on
:
fournit
un
plan
de
haut‐niveau
du
développement
et
de

l’intégra8on
des
modules
en
me`ant
en
évidence
les
composants,
les

interac8ons
et
les
dépendances


1/20/10 6
 Introduc8on


•  U8lité
d’une
architecture
logicielle
[Garlan
2000]

–  Évolu8on
:
met
en
évidence
les
points
où
un
système
peut
être

modifié
et
étendu.
La
sépara8on
composant/connecteur
facilite
une

implémenta8on
du
type
«
plug‐and‐play
»

–  Analyse
:
offre
une
base
pour
l’analyse
plus
approfondie
de
la

concep8on
du
logiciel,
analyse
de
la
cohérence,
test
de
conformité,

analyse
des
dépendances

–  Ges8on
:
contribue
à
la
ges8on
générale
du
projet
en
perme`ant
aux

différentes
personnes
impliquées
de
voir
comment
les
différents

morceaux
du
casse‐tête
seront
agencés.
L’iden8fica8on
des

dépendances
entre
composants
permet
d’iden8fier
où
les
délais

peuvent
survenir
et
leur
impact
sur
la
planifica8on
générale


1/20/10 7
 Introduc8on

•  D’où
vient
l’architecture?


–  Décisions
techniques

–  Décision
commerciaux

•  De
quoi
dépendent
les
décisions
de

l’architecte
:

–  Echéancier

–  Type
de
système
(ex.
temps
réel)

–  Expérience


1/20/10 8
 Introduc8on

•  De
quoi
dépendent
les
décisions
de

l’architecte
(suite):

–  Organisa8on
(budget,
forma8on
des

développeurs)

–  Environnement
technique

•  Les
architectures
influencent
les
facteurs
qui

les
influencent?!


1/20/10 9
 Introduc8on

•  Les
par8es
prenantes
influencent
l’architecte
:

-  Client
(coût
peu
élevé,
développement
rapide,
pas

beaucoup
de
changements
par
la
suite)

-  U8lisateur
final
(performance,
sécurité,
fiabilité,

usabilité)

-  Développeur
(facile
à
développer)

-  Chef
de
projet
(coût
peu
élevé,
développeurs

occupés)

-  Développeurs
qui
main8ennent
le
logiciel

(maintenance
facile)

1/20/10 10
 Introduc8on

•  Propriétés
prises
en
compte
par
l’architecte:

–  Performance

–  Fiabilité

–  Disponibilité

–  Compa8bilité
des
plateformes

–  U8lisa8on
mémoire

–  U8lisa8on
réseau

–  Sécurité

–  Etc.

1/20/10 11
 Introduc8on

•  Ac8vités
de
l’architecture
logiciel:

–  Créer
les
business
cases
du
système

•  évaluer
le
marché,


•  es8mer
un
prix,

•  
temps
visé,


•  collabora8ons
éventuelles
avec
d’autre
systèmes


1/20/10 12
 Introduc8on

•  Ac8vités
de
l’architecture
logiciel
(suite):

–  Comprendre
les
requis


•  suivant
le
type
du
système,


•  requis
de
qualité,


•  réu8liser
ou
par8r
de
rien
–
gamme
de
produits,


•  prototypes

–  Créer
ou
sélec8onner
une
architecture


1/20/10 13
 Introduc8on

•  Ac8vités
de
l’architecture
logiciel
(suite):

–  Communiquer
l’architecture
aux
par8e
prenantes

–  Evaluer
l’architecture

•  Architecture
Tradeoff
Analysis
Method
(ATAM)

•  Cost
Benefit
Analysis
Method
(CBAM)

–  Implémenter
l’architecture

–  Assurer
la
conformité
à
l’architecture


1/20/10 14
 2.
Modéliser
avec
UML


•  Les
vues
(structurelles)

d’une
architecture
logicielle

–  Vue
logique.
Descrip8on
logique
du
système
décomposé

en
sous‐systèmes
(modules
+
interface)

•  UML
:
diagramme
de
paquetages

–  Vue
d’implémenta8on.
Descrip8on
de
l’implémenta8on

(physique)
du
système
logiciel
en
termes
de
composants
et

de
connecteurs

•  UML
:
diagramme
de
composants

–  Vue
de
déploiement.
Descrip8on
de
l’intégra8on
et
de
la

distribu8on
de
la
par8e
logicielle
sur
la
par8e
matérielle

•  UML:
diagramme
combiné
de
composants
et
de
déploiement


1/20/10 15
 Rappel
:
vues
d’un
système

Diagramme Diagramme de
de classes composants

Diagramme Diagramme de
combiné de Vue structurelle packetages
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
1/20/10 interaction 16
 Modéliser
l’architecture
avec
UML

•  Diagramme
de
paquetages


1/20/10 17
 Modéliser
l’architecture
avec
UML

•  Diagramme
de
composants


1/20/10 18
 Modéliser
l’architecture
avec
UML

•  Diagramme
combiné
de
déploiement/
composants


1/20/10 19
 3.
Éléments
architecturaux

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é


1/20/10 20
 Éléments
architecturaux

•  Composant
 compA

–  Encapsule
un
traitement
et/ou
des
données

–  Encapsule
un
sous‐ensemble
de
fonc8onnalité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écu8on
ou
sa
réalisa8on


1/20/10 21
 Éléments
architecturaux

•  Composant

–  Unité
autonome
servant
de
bloc
de
construc8on
pour
le
système

–  Les
composants
implémentent
typiquement
des
services
spécifiques
à

l’applica8on

–  La
manifesta8on
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,
applica8ons,
etc.


«manifestation»
Order
Order.jar

1/20/10 22
 Éléments
architecturaux

•  Interface
de
composant

–  Permet
à
un
composant
d’exposer
les
moyens
à
u8liser

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
a`achée
à
un
port
du
composant

•  Port
=
point
de
communica8on
du
composant

•  Plusieurs
interfaces
peuvent
être
a`achées
à
un
même
port


1/20/10 23
 Éléments
architecturaux

•  Dépendances
entre
composants

–  Dépendance
=
rela8on
entre
deux
composants

–  Types
de
dépendances

•  Un
composant
peut
dépendre
d’un
autre
composant

qui
lui
fournit
un
service
ou
une
informa8on

•  Un
composant
peut
dépendre
d’une
classe
qui

implémente
une
par8e
de
son
comportement.

Dépendance
de
réalisa8on

•  Un
composant
peut
dépendre
d’un
artefact
(code

source,
fichier
.jar,
etc.)
qui
l’implante
concrètement.

Dépendance
de
manifesta8on


1/20/10 24
 Éléments
architecturaux

•  Connecteur

–  Dans
les
systèmes
complexes,
les
interac8ons
peuvent
cons8tuer
un
enjeu

encore
plus
important
que
les
fonc8onnalités
des
composants
individuels

–  Défini8on
:
élément
architectural
qui
définit
le
type
d’interac8ons
entre

les
composants
et
les
règles
gouvernant
ces
interac8ons

–  Un
connecteur
relie
les
ports
de
deux
ou
plusieurs
composants

–  Un
connecteur
décrit
un
mécanisme
de
connec8on
indépendant
de

l’applica8on

•  Représente
un
concept
abstrait,
paramétrable
et
indépendant
des
composants

spécifiques
qu’il
relie

–  Les
a`ributs
du
connecteurs
décrivent
ses
propriétés
comportementales

•  E.g.
sa
capacité,
le
temps
de
latence,
le
type
d’interac8on
(binaire/n‐aire,

asymétrique/symétrique,
détails
du
protocole),
etc.


1/20/10 25
 Éléments
architecturaux

•  Connecteur

–  Un
connecteur
peut
avoir
un
ou
plusieurs
rôles

•  Communica8on
:rôle
le
plus
fréquent

•  Coordina8on
:
contrôle
du
calcul,
de
la
transmission
des
données,
etc.

Orthogonal
aux
autres
rôles

•  Conversion
:
permet
l’interac8on
entre
composants
développés

indépendamment
dans
des
langages
différents
par
exemple

•  Facilita8on
:
permet
l’interac8on
entre
composants
conçus
pour
interragir

ensemble.
Synchronisa8on,
accès
contrôlées
aux
données
partagées,
etc.

–  Selon
le(s)
rôles
qu’il
doit
remplir
et
le
type
de
communica8on

souhaitée
entre
deux
composants,
choix
d’un
type

•  Procedure
call
(comm
+
coord)
,
Data
access
(comm
+
conv),
Event,

Stream,
Linkage,
Distributor,
Arbitrator,
Adaptor
(conv)


1/20/10 26
 Éléments
architecturaux

Type de Valeurs
Rôle Attributs
connecteur d’attributs

1/20/10 27
Software Architecture: Foundations, Theory, and Practice; R. N. Taylor, N. Medvidovic, and E. M. Dashofy; © 2008 John Wiley & Sons, Inc.
 Exemple
d’un
diagramme
de

composants


1/20/10 28
 Choix
d’une
architecture


•  Choix
d’une
architecture


–  Dépend
des
exigences
fonc8onnelles
et
non
fonc8onnelles

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écomposi8on
en
composants
(styles
architecturaux)
et
de

mode
d’interac8ons
(e.g.,
orienté
objet)


1/20/10 29
 4.
Style
architecturaux


•  Un
style
architectural


–  Est
un
patron
décrivant
une
architecture
logicielle
perme`ant

de
résoudre
un
problème
par8culier

–  Définit

•  Un
ensemble
de
composants
et
de
connecteurs
(et
leur
type)

•  Les
règles
de
configura8on
des
composants
et
connecteurs
(topologie)

•  Une
spécifica8on
du
comportement
du
patron

•  Des
exemples
de
systèmes
construits
selon
ce
patron

–  Cons8tue
un
modèle
éprouvé
et
enrichi
par
l’expérience
de

plusieurs
développeurs

•  Compréhensibilité,
maintenance,
évolu8on,
réu8lisa8on,

performance,
documenta8on,
etc.


1/20/10 30
 Architecture
pipeline

•  Convient
bien
aux
systèmes
de
traitement
et
de
transforma8on
de
données


•  Composants
=
filtre
;
Connecteur
=
canal

–  Filtre

•  Traite
indépendamment
et
asynchrone

•  Reçoit
ses
données
d’un
ou
plusieurs
canaux
d’entrée,
effectue
la
transforma8on/traitement


des
données
et
envoie
les
données
de
sor8e
produites
sur
un
ou
plusieurs
canaux
de
sor8es

•  Fonc8onnent
en
concurrence.
Chacun
traite
les
données
au
fur
et
mesure
qu’il
les
reçoit

–  Canal



•  Unidirec8onnel
au
travers
duquel
circulent
un
flot
de
données
(stream).


•  Synchronisa8on
et
u8lisa8on
d’un
tampon
parfois
nécessaire
pour
assurer
la
bon

fonc8onnement
entre
filtre
producteur
et
filtre
consommateur

–  Exemples
:
applica8on
de
traitement
de
texte,
de
traitement
de
signaux.
Compilateur

(analyse
lexicale,
syntaxique,
séman8que)


Filtre

canal de synchro
1/20/10 31
communication
 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
1/20/10 32
 Architecture
pipeline

•  Avantages
 •  D’un
point
de
vue
concep8on

–  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

synchronisa8on,
goulot
 cohésion
fonc8onnelle

d’étranglement,
etc.
 –  Couplage
:
les
filtres
n’ont
qu’une

–  Se
prête
bien
à
la
décomposi8on
 entrée
et
une
sor8e
en
général

fonc8onnelle
d’un
système
 –  Abstrac8on
:
les
filtres
cachent

•  Inconvénients
 généralement
bien
leurs
détails

internes

–  Mauvais
pour
le
traitement
interac8f

–  Réu8lisabilité
:
les
filtres
peuvent
très

souvent
être
réu8lisés
dans
d’autres

contextes

–  Réu8lisa8on
:
il
est
souvent
possible

d’u8liser
des
filtres
déjà
existants

pour
les
insérer
dans
le
pipeline


1/20/10 33
 Architecture
avec
référen8el
de

données
(shared
data)

•  U8lisé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éren8el
de
données
et
accesseur
de

données

•  Les
référen8els
cons8tuent
le
medium
de
communica8on
entre
les

accesseurs

–  Connecteur
:
relie
un
accesseur
à
un
référen8el

•  Rôle
de
communica8on,
mais
aussi
possiblement
de
coordina8on,
de

conversion
et
de
facilita8on


Référentiel1 Référentiel2

1/20/10 A A A A A 34
 Architecture
avec
référen8el

•  Variantes

–  Style
tableau
noir
:
les
référen8els
sont
des
agents
ac8fs.

Lorsqu’ils
reçoivent
une
données,
ils
informent
tous
les

accesseurs
concernés

–  Style
référen8el
:
les
référen8els
sont
passifs.
Simple

voca8on
de
stockage.
Les
composants
accèdent
aux

référen8els
comme
ils
le
désirent

–  Exemples
:
applica8on
de
bases
de
données,
systèmes

Web,
systèmes
centrés
sur
les
données
(e.g.
système

bancaire,
système
de
factura8on
,etc.),
environnement
de

programma8on


1/20/10 35
 Architecture
avec
référen8el

•  Environnement
de
programma8on

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
1/20/10 36
 Architecture
avec
référen8el

•  Avantages

–  Avantageux
pour
les
applica8ons
impliquant
des

tâches
complexes
sur
les
données,
nombreuses
et

changeant
souvent.
Une
fois
le
référen8el
bien

défini,
de
nouveaux
services
peuvent
facilement

être
ajoutés

•  Inconvénients

–  Le
référen8el
peut
facilement
cons8tuer
un
goulot

d’étranglement,
tant
du
point
de
vue
de
sa

performance
que
du
changement


1/20/10 37
 Architecture
Modèle‐Vue‐Contrôleur

(MVC)

•  Séparer
la
couche
interface
u8lisateur
des
autres
par8es
du

système
(car
les
interfaces
u8lisateurs
sont
beaucoup
plus

suscep8bles
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.
Con8ent
les
classes
dont
les
instances
doivent
être
vues
et

manipulées

–  Vue
:
u8lisé
pour
présenter/afficher
les
données
du
modèle
dans

l’interface
u8lisateur

–  Contrôleur
:
con8ent
les
fonc8onnalités
nécessaires
pour
gérer
et

contrôler
les
interac8ons
de
l’u8lisateur
avec
la
vue
et
le
modèle


1/20/10 38
 Architecture
Modèle‐Vue‐Contrôleur

E.g. Génère le E.g. Interprète les
Vus par code html pour le transmissions http
les acteurs browser « post » du
browser Reçoit les
événements
créer et
View des acteurs
mettre à jour

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

Modèle modifier

Le sous-système
gérant l’information.

1/20/10 39
 Architecture
Modèle‐Vue‐Contrôleur

•  Modèle
:
noyau
de
l’applica8on

–  Enregistre
les
vues
et
les
contrôleurs
qui
en
dépendent

–  No8fie
les
composants
dépendants
des
modifica8ons
aux
données

•  Vue
:
interface
(graphique)
de
l’applica8on

–  Crée
et
ini8alise
ses
contrôleurs

–  Affiche
les
informa8ons
des8nées
aux
u8lisateurs

–  Implante
les
procédure
de
mise
à
jour
nécessaires
pour
demeurer
cohérente

–  Consulte
les
données
du
modèle

•  Contrôleur
:
par8e
de
l’applica8on
qui
prend
les
décisions

–  Accepte
les
événement
correspondant
aux
entrées
de
l’u8lisateur

–  Traduit
un
événements
(1)
en
demande
de
service
adressée
au
modèle
ou

bien
(2)
en
demande
d’affichage
adressée
à
la
vue

–  Implémente
les
procédures
indirectes
de
mise
à
jour
des
vues
si
nécessaire


1/20/10 40
 Architecture
Modèle‐Vue‐Contrôleur

•  Avantages
:
approprié
pour
 •  D’un
point
de
vue
concep8on

–  Diviser
pour
régner
:
les
composants

les
systèmes
interac8fs,
 peuvent
être
conçus

par8culièrement
ceux
 indépendamment

impliquant
plusieurs
vues
 –  Cohésion
:
meilleure
cohésion
que
si

les
couches
vue
et
contrôle
étaient

du
même
modèle
de
 dans
l’interface
u8lisateur.

données.
Peut
être
u8lisé
 –  Couplage
:
le
nombre
de
canaux
de

communica8on
entre
les
3

pour
faciliter
la
 composants
est
minimal

maintenance
de
la
 –  Réu8lisabilité
:
la
vue
et
le
contrôle

cohérence
entre
les
 peuvent
être
conçus
à
par8r
de

composants
déjà
existants

données
distribuées
 –  Flexibilité
:
il
est
facile
de
changer

l’interface
u8lisateur

•  Inconvénient
:
goulot

–  Testabilité
:
il
est
possible
de
tester

d’étranglement
possible
 l’applica8on
indépendamment
de

l’interface


1/20/10 41
 Architecture
mul8‐couches

•  Composants
:
chaque
composant
réalise
un
service

–  Une
couche
offre
un
service
(serveur)
aux
couches
externes
(client)

–  Service
créé
indépendamment
du
logiciel
ou
spécifiquement

–  Met
à
profit
la
no8on
d’abstrac8on,
les
couches
externes
sont
plus

abstraites
(haut
niveau)
que
les
couches
internes

•  Connecteurs
:
dépendent
du
protocole
d’interac8on
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
u8lisé
pour
les
systèmes
implémentant

des
protocoles
de
communica8on
(TCP/IP)


1/20/10 42
 Architecture
mul8‐couches

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

•  Chaque
couche
est
un
composant
avec
une
interface
bien
définie
u8lisée
par
la
couche
juste

au
dessus
(i.e.,
externe)

•  La
couche
supérieure
(externe)
voit
la
couche
inférieur
(interne)
comme
un
ensemble
de

services
offerts

•  Un
système
complexe
peut
être
construit
en
superposant
les
couches
de
niveau
d’abstrac8on

croissant

•  Il
est
important
d’avoir
une
couche
séparée
pour
l’IU

•  Les
couches
juste
au
dessous
de
l’IU
offrent
les
fonc8ons
applica8ves
définies
par
les
cas

d’u8lisa8on

•  Les
couches
les
plus
basses
offrent
les
services
généraux

•  E.g.,
communica8on
réseau,
accès
à
la
base
de
données


1/20/10 43
 Architecture
mul8‐couches

•  Système
fermé

–  Reference
Model
of
Open
Systems
Interconnec8on

(OSI
model)

Application
Transformation des données
Présentation (encryption,etc.)

Identifier et authentifier
Session une connexion
Transmission (point à point)
Transport fiable des données

Transmission des
Réseau
routing packets

Transmission des Ligne de données

data frames sans erreurs

Interface matérielle Physique

du réseau
1/20/10 44
 Architecture
mul8‐couches


Application

Swing

AWT

X11

1/20/10 45
 Architecture
mul8‐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
1/20/10 46
 Architecture
mul8‐couches

•  D’un
point
de
vue
concep8on
 –  Réu8lisa8on
:
on
peut
souvent

–  Diviser
pour
régner
:
les
couches
 réu8liser
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ésenter
une
cohésion
 –  Flexibilité
:
il
est
facile
d’ajouter
de

par
couche
 nouveaux
services
construits
sur
les

services
de
plus
bas
niveau

–  Couplage
:
des
couches
inférieures

bien
conçues
ne
devraient
rien
savoir
 –  An8cipa8on
du
changement
:
en

à
propos
des
couches
supérieures
et
 isolant
les
composants
dans
des

les
seules
connexions
autorisées
 couches
dis8nctes,
le
système

entre
couches
se
font
via
les
API
 devient
résistant

–  Abstrac8on
:
on
n’a
pas
à
connaître
 –  Portabilité
:
tous
les
services
rela8fs
à

les
détails
d’implémenta8on
des
 la
portabilité
peuvent
être
isolés

couches
inférieures
 –  Testabilité
:
les
couches
peuvent
être

–  Réu8lisabilité
:
les
couches
 testées
indépendamment

inférieures
peuvent
être
conçues
de
 –  Concep8on
défensive
:
les
API
des

façon
à
offrir
des
solu8ons
 couches
cons8tuent
des
endroits

génériques
réu8lisables
 stratégiques
pour
insérer
des

asser8ons
de
vérifica8on


1/20/10 47
 Architecture
n‐niveaux

•  Pour
les
systèmes
distribués

–  Comparable
à
une
architecture
par
couches…
dont
les
couches
seraient

distribuées
!

•  N.b.
L’architecture
mul8‐couche
est
généralement
u8lisée
pour
décrire
la

structure
interne
(non
distribuée)
d’un
composant
qui
peut
lui‐même

appartenir
à
une
architecture
(distribuée)
n‐par8e

–  Par
abus
de
langage,
la
no8on
de
8er
a
pris
le
sens
de
couche
distribuée

–  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
communica8on
distantes
(e.g.,
requêtes
RPC,
HTTP,
TCP/IP)

–  Exemples

•  Client‐serveur,
Trois
niveaux,
Quatre
niveaux


1/20/10 48
 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


Présentation Logique Bases de

Client Applicative
(partie web) données
(calculs,
1/20/10 business) 49
 Architecture
n‐niveaux

•  Architecture
client‐serveur

–  Exemple
typique
:
un
système
d’informa8ons
u8lisant
une

base
de
données
centrale.
(cas
spécial
de
l’architecture

avec
référen8el)

•  Clients
:
reçoivent
les
données
de
l’u8lisateur,
ini8ent
les

transac8ons,
etc.

•  Serveur
:
exécute
les
transac8ons,
assure
l’intégrité
des
données

–  Architecture
pair‐à‐pair
=
une
généralisa8on
de

l’architecture
client‐serveur


•  Les
composants
peuvent
tous
à
la
fois
être
client
et
serveur

•  Concep8on
plus
difficile:
flot
de
contrôle
plus
complexe
dû
à
la

possibilité
de
deadlocks…


1/20/10 50
 Architecture
n‐niveaux

•  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
1/20/10 51
 Architecture
n‐niveaux

•  Architecture
3‐niveaux

–  Organisa8on
en
trois
couches

•  Couche
interface:
Composé
d’objets
interfaces
(boundary
objects)

pour
interagir
avec
l’u8lisateur
(fenêtres,
formulaires,
pages
Web,

etc.)

•  Couche
logique
applica8ve
:
Comporte
tous
les
objets
de
contrôle

et
d’en8tés
nécessaires
pour
faire
les
traitements,
la
vérifica8on

des
règles
et
les
no8fica8ons
requises
par
l’applica8on

•  Couche
de
stockage
:
réalise
le
stockage,
la
récupéra8on
et
la

recherche
des
objets
persistants

–  Avantage
sur
l’architecture
client‐serveur

•  Permet
le
développement
et
la
modifica8on
de
différentes

interfaces
u8lisateurs
pour
la
même
logique
applica8ve


1/20/10 52
 Architecture
n‐niveaux

•  Architecture
3‐par8es


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
1/20/10
Logique 53
applicative
 Architecture
n‐niveaux

•  Architecture
3‐niveaux
 •  À
noter
que
la
tendance
veut

que
la
par8e
cliente
soit


–  De
plus
en
plus
mince,
i.e.,
le

Interface client
ne
fait
qu’afficher
un

gestionnaire
contenu
HTML


–  La
logique
applica8ve
est
alors

responsable
de
créer
les
pages

Gestion Web
à
afficher
par
le
client

des dossiers –  Il
faut
dissocier
logique
applica8ve

et
présenta8on
des
données


Base de
données clients
1/20/10 54
 Architecture
n‐niveaux

•  Architecture
4‐niveaux

–  Architecture
dont
la
couche
logique
applica8ve
est
décomposée
en


•  Couche
Présenta8on
(JSP,
servlets)

–  Présenta8on
du
contenu
sta8que:
Contenu
HTML
ou
XML
affiché
par
le
client

–  Présenta8on
du
contenu
dynamique
:
contenu
organisé
et
créé

dynamiquement
par
le
serveur
web
(pour
ensuite
être
affiché
en
HTML/XML

par
le
client)

•  Couche
Logique
applica8ve
(calculs
purs)
:
réalise
le
cœur
des
traitements

de
l’applica8on

–  Avantage
sur
l’architecture
3‐niveaux

•  Permet
de
supporter
un
grand
nombre
de
formats
de
présenta8on

différents
(propres
à
chaque
client),
tout
en
réu8lisant
certains
des
objets

de
présenta8on
entre
les
clients.
Réduc8on
des
redondances…

•  Bien
adaptée
pour
les
applica8ons
Web
devant
supporter
plusieurs
types

de
clients


1/20/10 55
 Architecture
n‐niveaux

•  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
employé <<build>> Java Server Pages
de la banque <<submit>> -  Partie cliente
1/20/10 -  Partie serveur56
 Architecture
n‐niveaux

•  D’un
point
de
vue
concep8on
 •  Flexibilité
:
il
est
assez
facile
d’ajouter

–  Diviser
pour
régner
:
de
façon
 de
nouveaux
clients
et
serveurs

évidente,
client
et
serveur
peuvent
 •  Portabilité
:
on
peut
développer
de

être
développées
séparément
 nouveaux
clients
pour
de
nouvelles

–  Cohésion
:
le
serveur
peut
offrir
des
 plateformes
sans
devoir
porter
le

services
cohésifs
au
client
 serveur

–  Couplage
:
un
seul
canal
de

communica8on
existe
souvent
entre
 •  Testabilité
:
on
peut
tester
le
client
et

client
et
serveur
 le
serveur
indépendamment

–  Réu8lisa8on
:
il
est
possible
de
 •  Concep8on
défensive
:
on
peut

trouver
une
bibliothèque
de
 introduire
des
opéra8ons
de

composants,
interfaces,
etc.
pour
 vérifica8on
dans
le
code
traitant
les

construire
les
systèmes
 messages
reçus
de
part
et
d’autre

•  Toutefois,
les
systèmes
client‐serveur

dépendent
très
souvent
de

nombreuses
considéra8ons
liées

in8mement
à
l’applica8on


1/20/10 57
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’u8lisa8on
;
décomposi8on
en

sous‐systèmes

–  Déterminer
les
principaux
composants
requis

–  Sélec8onner
un
style
architectural

•  Raffiner
l’architecture

–  Iden8fier
les
principales
interac8ons
entre
les
composants
et
les
interfaces

requises

–  Décider
comment
chaque
donnée
et
chaque
fonc8onnalité
sera
distribuée

parmi
les
différents
composants

–  Déterminer
si
on
peut
réu8liser
un
cadriciel
existant
(réu8lisa8on)
ou
si
on

peut
en
construire
un
(réu8lisabilité)

•  Considérer
chacun
des
cas
d’u8lisa8on
et
ajuster
l’architecture
pour
qu’il

soit
réalisable

•  Détailler
l’architecture
et
la
faire
évoluer


1/20/10 58
 Développer
un
modèle
architectural

•  Décrire
l’architecture
avec
UML

–  Tous
les
diagrammes
UML
peuvent
être
u8les

pour
décrire
les
différents
aspects
du
modèle

architectural

–  Trois
des
diagrammes
UML
sont
par8culièrement

u8le
pour
décrire
une
architecture
logicielle

•  Diagramme
de
paquetages

•  Diagramme
de
composants

•  Diagramme
de
déploiement


1/20/10 59
 Développer
un
modèle
architectural

•  Diagramme
de
paquetages

–  Paquetage
=
Collec8on
d’éléments
de
modélisa8on
UML
(e.g.,
classes,

use
cases,
etc.)
groupés
ensemble
car
liés
logiquement

–  Il
faut
essayer
de
maximiser
la
cohésion
au
sein
des
paquetages

(éléments
liés)
et
minimiser
le
couplage
entre
eux

•  Dépendance
:
un
paquetage
est
dépendant
d’un
autre
s’il

l’u8lise…

SimpleChat OCSF

Client Client
Common <<import>> Server

1/20/10 60
 Développer
un
modèle
architectural

•  Diagramme
de
composants

–  Offre
une
vue
de
haut
niveau
de
l’architecture
du
système

–  U8lisé
pour
décrire
le
système
d’un
point
de
vue

implémenta8on

–  Permet
de
décrire
les
composants
d’un
système
et
les

interac8ons
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


1/20/10 61
 Développer
un
modèle
architectural

Composant
•  Qu’est‐ce
qu’un
composant?

–  Unité
autonome
faisant
par8e
d’un
 –  Granularité
?
Un
composant
peut

système
ou
d’un
sous‐système
qui
 représenter
quelque
chose
d’aussi
fin

encapsule
un
comportement
(i.e.,
 qu’un
objet,
comme
il
peut

implémenta8on)
et
qui
offre
une
ou
 représenter
un
sous‐système

plusieurs
interfaces
publiques
 complexe

–  Par8e
cons8tuante
d’un
système
qui
 –  Différence
entre
composant
et

peut
être
remplacée
ou/et
réu8lisée
 instance
de
composant

–  Élément
d’implémenta8on
(un
sous‐ –  Composant
:
vue
de
haut
niveau
d’un

système,
un
fichier
exécutable,
une
 élément
logiciel
qui
compose
le

classe
d’implémenta8on
(i.e.,
non
 système
(~classe)

abstraite,
etc.)
muni
d’interface(s)
 –  Instance
de
composant 
:
le

–  Chaque
composant
est
le
 composant
effec8vement
u8lisé

représentant
d’une
ou
plusieurs
 (~objet)

classes
qui
implémentent
un
service
 –  Exemples
de
composants:

à
l’intérieur
du
système
 •  Binaire
exécutable
(<<executable>>),

bibliotheque
dynamique/sta8que

(<<librairy>>),
un
fichier
à
interpréter

(<<file>>)…


1/20/10 62
 Développer
un
modèle
architectural

•  Les
composants
et
le
principe
de
sépara8on
des

préoccupa8ons

–  La
sépara8on
des
préoccupa8on
est
le
principe
qui
assure
l’intégrité

fonc8onnelle
d’un
composant

•  Chaque
composant
réalise
une,
et
seulement
une
fonc8on
au
sein
du

système,
mais
peut
néanmoins
exposer
plusieurs
méthodes.
Typiquement,

chaque
composant
est
défini
par
une
interface
qui
cons8tue
son
seul

moyen
d’interagir
avec
les
autres
composants

•  L’u8lisa8on
d’une
interface
pour
communiquer
avec
les
autres

composants
du
système
facilite
la
maintenance
puisqu’on
peut
alors
en

changer
l’implémenta8on
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
fonc8onnalité
du
composant


1/20/10 63
 Développer
un
modèle
architectural

•  Composants
et
interfaces
‐
Nota8on

EntréeCmdes
Personne
Commande PaiementComptes

interface requise composant interfaces offertes

Commande
<<provided interfaces>>
EntréeCmdes
PaiementComptes
<<required interface>>
Person
1/20/10 64
 Développer
un
modèle
architectural

•  Composants
et
rela8ons
–
nota8on

–  Une
flèche
de
dépendance
permet
de
me`re
en
rela8on

des
composant
via
les
interfaces
requises
et
fournies


RechercheClient
Système de Repositoire
commande Clients
RechercheClient

(3) dépendance
AccèsProduit (1) composant

AccèsProduit
Système
d’inventaire
(2) interface
1/20/10 65
 Développer
un
modèle
architectural

•  Composants
et
rela8ons
–
nota8on

réservations
Gestionnaire
Planificateur d’horaires
réservations

accèsBD
mise à jour

accèsBD
GUI
mise à jour

Réunions_BD

1/20/10 66
 Développer
un
modèle
architectural

•  Composants
–
Vue
de
la
structure
interne

–  Pour
montrer
la
structure
interne
d’un
composant


Magasin
EntréeCmdes
<<delegate>>
:Commande
Personne
Entête :Client
port
EntréeCmdes
LigneCmde
*
Compte

ItemCommandable
<<delegate>>
Assembly :Produit
Compte
1/20/10 connector 67
Développer
un
modèle
architectural

•  Diagramme
de
composants
MVC


1/20/10 68
 Développer
un
modèle
architectural

•  Construc8on
d’un
diagramme
de
composants

–  Diviser
pour
régner

–  Cohésion
forte

–  Faible
couplage

–  Abstrac8on

–  Réu8lisabilité

–  Réu8lisa8on

–  Etc.


1/20/10 69
 Développer
un
modèle
architectural

•  Diagramme
de
déploiement

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

M1:MachineX
C1:Client TCP/IP lien

C2:Client

1/20/10 70
 Développer
un
modèle
architectural

•  Diagramme
de
déploiement
–
exemple
1


internet

Machine de Joe:PC

:Planificateur
Admin:MachineHote
mise à jour
:Gestionnaire
GUI Horaires
réservations

Accès_bd

:Réunions_BD
1/20/10 71
 Développer
un
modèle
architectural

•  Diagramme
de
déploiement
–
exemple
2


1/20/10 72
 Parmi
les
objec8fs
d’appren8ssage

•  Expliquer
les
objec8fs
visés
par
la
concep8on

architecturale

–  Décrire
le
fonc8onnement
et
les
caractéris8ques
de

chacun
des
styles
architecturaux

–  Jus8fier
le
choix
d’une
architecture
pour
la
réalisa8on
d’un

logiciel,
en
tenant
compte
de
ses
exigences
fonc8onnelles

et
non
fonc8onnelles

–  Définir
ce
qu’est
un
composant

–  Expliquer
le
contenu
décrit
par
un
diagramme
de

paquetages,
de
composants
et
de
déploiement
(UML)

–  Décrire
le
modèle
d’une
architecture
avec
la
nota8on
UML


1/20/10 73
 Bonne
architecture

•  Donner
des
priorités
au
a`ributs
de
qualité

•  Bien
documenter

•  Impliquer
les
par8es
prenantes

•  Approche
itéra8ve

•  Composants
modulaires
et
bien
définis

•  Independent
des
versions
des
technologies


1/20/10 74
 Références

•  Transparents
empruntés
à
Dr.
Yann‐Gaël

Guéhéneuc.

•  Len
Bass,
Paul
Clements,
and
Rick
Kazman

(2003).
So‡ware
architecture
in
prac8ce,
2nd

edi8on,
Addison‐Wesley.


1/20/10 75