Architecture logicielle

Architecture logicielle :
quelques lments

L'architecture informatique dfinit la structuration d'un

systme informatique (i.e. matriel et logiciel) en termes
de composants et d'organisation de ses fonctions.

Licence professionnelle IDSE

2012-2013
http://anubis.polytech.unice.fr/iut/2012_2013/lp/idse/gl/management

Mireille Blay-Fornarino
blay@unice.fr
1

Quest-ce quune architecture

logicielle ?
!

Contrairement aux spcifications produites par

lanalyse fonctionnelle
le modle d'architecture ne dcrit pas ce que doit
raliser un systme informatique mais plutt
comment il doit tre conu de manire rpondre
aux spcifications.
Lanalyse fonctionnelle dcrit le quoi faire alors
que larchitecture dcrit le comment le faire

Franois Trudel, ing., M.Sc.A.

Prsident Fondateur
francois.trudel@aginex.com
universit de Sherbrook
LARCHITECTURE
LOGICIELLE EN
PRATIQUE

Description dune architecture logicielle ?

La dfinition de larchitecture logicielle consiste :
Dcrire lorganisation gnrale dun systme et sa
dcomposition en sous-systmes ou composants
Dterminer les interfaces entre les sous-systmes
Dcrire les interactions et le flot de contrle entre les soussystmes
Dcrire galement les composants utiliss pour implanter les
fonctionnalits des sous-systmes
Les proprits de ces composants
Leur contenu (e.g., classes, autres composants)
Les machines ou dispositifs matriels sur lesquels ces modules
seront dploys

LOG4430 : ARCHITECTURE LOGICIELLE ET CONCEPTION AVANCE, FOUTSE KHOMH,

UNIVERSIT DE MONTRAL
3

Pourquoi une architecture logicielle [Garlan 2000]

Pourquoi une architecture logicielle [Garlan 2000]

Comprhension : facilite la comprhension des grands systmes complexes

en donnant une vue de haut-niveau de leur structure et de leurs contraintes.
Les motivation des choix de conception sont ainsi mis en vidence

Comprhension : facilite la comprhension des grands systmes complexes

en donnant une vue de haut-niveau de leur structure et de leurs contraintes.
Les motivation des choix de conception sont ainsi mis en vidence

Rutilisation : favorise lidentification des lments rutilisables, parties de

conception, composants, caractristiques, fonctions ou donnes communes.

Rutilisation : favorise lidentification des lments rutilisables, parties de

conception, composants, caractristiques, fonctions ou donnes communes.

Construction : fournit un plan de haut-niveau du dveloppement et de

lintgration des modules en mettant en vidence les composants, les
interactions et les dpendances. Elle doit permettre aux dveloppeurs de
travailler sur des parties individuelles du systme en isolation

Construction : fournit un plan de haut-niveau du dveloppement et de

lintgration des modules en mettant en vidence les composants, les
interactions et les dpendances. Elle doit permettre aux dveloppeurs de
travailler sur des parties individuelles du systme en isolation

volution : met en vidence les points o un systme peut tre modifi et

tendu. La sparation composant/connecteur facilite une implmentation du
type plug-and-play

volution : met en vidence les points o un systme peut tre modifi et

tendu. La sparation composant/connecteur facilite une implmentation du
type plug-and-play

Analyse : offre une base pour lanalyse plus approfondie de la conception du

logiciel, analyse de la cohrence, test de conformit, analyse des dpendances

Analyse : offre une base pour lanalyse plus approfondie de la conception du

logiciel, analyse de la cohrence, test de conformit, analyse des dpendances

Gestion : contribue la gestion gnrale du projet en permettant aux

diffrentes personnes impliques de voir comment les diffrents morceaux du
casse-tte seront agencs. Lidentification des dpendance entre composants
permet didentifier o les dlais peuvent survenir et leur impact sur la
planification gnrale

Gestion : contribue la gestion gnrale du projet en permettant aux

diffrentes personnes impliques de voir comment les diffrents morceaux du
casse-tte seront agencs. Lidentification des dpendance entre composants
permet didentifier o les dlais peuvent survenir et leur impact sur la
planification gnrale

Pourquoi une architecture logicielle [Garlan 2000]

Pourquoi une architecture logicielle [Garlan 2000]

Comprhension : facilite la comprhension des grands systmes complexes

en donnant une vue de haut-niveau de leur structure et de leurs contraintes.
Les motivation des choix de conception sont ainsi mis en vidence

Comprhension : facilite la comprhension des grands systmes complexes

en donnant une vue de haut-niveau de leur structure et de leurs contraintes.
Les motivation des choix de conception sont ainsi mis en vidence

Rutilisation : favorise lidentification des lments rutilisables, parties de

conception, composants, caractristiques, fonctions ou donnes communes.

Rutilisation : favorise lidentification des lments rutilisables, parties de

conception, composants, caractristiques, fonctions ou donnes communes.

Construction : fournit un plan de haut-niveau du dveloppement et de

lintgration des modules en mettant en vidence les composants, les
interactions et les dpendances. Elle doit permettre aux dveloppeurs de
travailler sur des parties individuelles du systme en isolation

Construction : fournit un plan de haut-niveau du dveloppement et de

lintgration des modules en mettant en vidence les composants, les
interactions et les dpendances. Elle doit permettre aux dveloppeurs de
travailler sur des parties individuelles du systme en isolation

volution : met en vidence les points o un systme peut tre modifi et

tendu. La sparation composant/connecteur facilite une implmentation du
type plug-and-play

volution : met en vidence les points o un systme peut tre modifi et

tendu. La sparation composant/connecteur facilite une implmentation du
type plug-and-play

Analyse : offre une base pour lanalyse plus approfondie de la conception du

logiciel, analyse de la cohrence, test de conformit, analyse des dpendances

Analyse : offre une base pour lanalyse plus approfondie de la conception du

logiciel, analyse de la cohrence, test de conformit, analyse des dpendances

Gestion : contribue la gestion gnrale du projet en permettant aux

diffrentes personnes impliques de voir comment les diffrents morceaux du
casse-tte seront agencs. Lidentification des dpendance entre composants
permet didentifier o les dlais peuvent survenir et leur impact sur la
planification gnrale

Gestion : contribue la gestion gnrale du projet en permettant aux

diffrentes personnes impliques de voir comment les diffrents morceaux du
casse-tte seront agencs. Lidentification des dpendance entre composants
permet didentifier o les dlais peuvent survenir et leur impact sur la
planification gnrale

Pourquoi une architecture logicielle [Garlan 2000]

Pourquoi une architecture logicielle [Garlan 2000]

Comprhension : facilite la comprhension des grands systmes complexes

en donnant une vue de haut-niveau de leur structure et de leurs contraintes.
Les motivation des choix de conception sont ainsi mis en vidence

Comprhension : facilite la comprhension des grands systmes complexes en

donnant une vue de haut-niveau de leur structure et de leurs contraintes. Les
motivation des choix de conception sont ainsi mis en vidence

Rutilisation : favorise lidentification des lments rutilisables, parties de

conception, composants, caractristiques, fonctions ou donnes communes.

Rutilisation : favorise lidentification des lments rutilisables, parties de

conception, composants, caractristiques, fonctions ou donnes communes.
Construction : fournit un plan de haut-niveau du dveloppement et de
lintgration des modules en mettant en vidence les composants, les
interactions et les dpendances. Elle doit permettre aux dveloppeurs de
travailler sur des parties individuelles du systme en isolation
volution : met en vidence les points o un systme peut tre modifi et
tendu. La sparation composant/connecteur facilite une implmentation du
type plug-and-play
Analyse : offre une base pour lanalyse plus approfondie de la conception du
logiciel, analyse de la cohrence, test de conformit, analyse des
dpendances

Construction : fournit un plan de haut-niveau du dveloppement et de

lintgration des modules en mettant en vidence les composants, les
interactions et les dpendances. Elle doit permettre aux dveloppeurs de
travailler sur des parties individuelles du systme en isolation
volution : met en vidence les points o un systme peut tre modifi et
tendu. La sparation composant/connecteur facilite une implmentation du
type plug-and-play
Analyse : offre une base pour lanalyse plus approfondie de la conception du
logiciel, analyse de la cohrence, test de conformit, analyse des dpendances
Gestion : contribue la gestion gnrale du projet en permettant aux
diffrentes personnes impliques de voir comment les diffrents morceaux du
casse-tte seront agencs. Lidentification des dpendance entre composants
permet didentifier o les dlais peuvent survenir et leur impact sur la
planification gnrale

Gestion : contribue la gestion gnrale du projet en permettant aux diffrentes

personnes impliques de voir comment les diffrents morceaux du casse-tte
seront agencs. Lidentification des dpendance entre composants permet
didentifier o les dlais peuvent survenir et leur impact sur la planification
gnrale

Pourquoi une architecture logicielle [Garlan 2000]

Comprhension : facilite la comprhension des grands systmes complexes
en donnant une vue de haut-niveau de leur structure et de leurs contraintes.
Les motivation des choix de conception sont ainsi mis en vidence
Rutilisation : favorise lidentification des lments rutilisables, parties de
conception, composants, caractristiques, fonctions ou donnes communes.
Construction : fournit un plan de haut-niveau du dveloppement et de
lintgration des modules en mettant en vidence les composants, les
interactions et les dpendances. Elle doit permettre aux dveloppeurs de
travailler sur des parties individuelles du systme en isolation
volution : met en vidence les points o un systme peut tre modifi et
tendu. La sparation composant/connecteur facilite une implmentation du
type plug-and-play
Analyse : offre une base pour lanalyse plus approfondie de la conception du
logiciel, analyse de la cohrence, test de conformit, analyse des dpendances
Gestion : contribue la gestion gnrale du projet en permettant aux
diffrentes personnes impliques de voir comment les diffrents morceaux du
casse-tte seront agencs. Lidentification des dpendance entre composants
permet didentifier o les dlais peuvent survenir et leur impact sur la
planification gnrale
11

10

Critres de Qualit Logicielle

Interoprabilit
Portabilit
Compatibilit
Validit
Vrifiabilit
Intgrit
Fiabilit

Extensibilit
Efficacit
Autonomie
Transparence
Composabilit
Simplicit

Maintenabilit
Rutilisabilit

Franois Trudel, ing., M.Sc.A.

Prsident Fondateur
francois.trudel@aginex.com
universit de Sherbrook
LARCHITECTURE
LOGICIELLE EN
PRATIQUE

12

Rle dun Architecte Logiciel

Modle darchitecture
Vue Vue
logique implmentation
diagrammes de classes
diagrammes d'objets

Le rle de larchitecte logiciel est:

diagrammes de composants

Vue utilisateur

diagrammes de cas

1) de dfinir une architecture logicielle qui satisfasse les

diagrammes d'tats
diagrammes d'activits
diagrammes de squence
diagrammes de collaboration

contraintes du systme
2) de la communiquer.

diagrammes de dploiement

Vue Vue
comportement dploiement

Franois Trudel, ing., M.Sc.A.

Prsident Fondateur
francois.trudel@aginex.com
universit de Sherbrook
LARCHITECTURE
LOGICIELLE EN
PRATIQUE

13

14

La vue logique

Modliser avec UML

! Les

vues (structurelles) dune architecture logicielle

Vue logique. Description logique du systme dcompos

en sous-systmes (modules + interface)
UML : diagramme de paquetages

Vue dimplmentation. Description de limplmentation

(physique) du systme logiciel en termes de composants
et de connecteurs
UML : diagramme de composants

Vue de dploiement. Description de lintgration et de la

distribution de la partie logicielle sur la partie matrielle

Aspects statiques et dynamiques

Les lments

Les objets, Les classes

Les collaborations, Les interactions
Les paquetages : organisation des lments en groupes
logiques

Dependency relationship

Client Package

Supplier
Package

UML: diagramme combin de composants et de dploiement

Il faut essayer de maximiser la cohsion au sein des paquetages (lments
lis) et minimiser le couplage entre eux
Reprsentation des vues darchitecture avec UML
Pierre-Alain Muller

15

16

Avoiding Circular Dependencies

A

La vue de ralisation
A

Hierarchy
should be
acyclic

Permet de visualiser les modules dans lenvironnement de dveloppement.

Un bon support, le diagramme de composants dUML.

A
C
B
A'
C

Circular dependencies make it impossible

to reuse one package without the other.
Reprsentation des vues darchitecture avec UML

Mastering Object Oriented Analysis and Design with UML

Copyright 2003 Rational Software, all rights reserved

17

Pierre-Alain Muller

18

Diagramme de composants
UML 2.0
Offre une vue de haut niveau de larchitecture du
systme
Utilis pour dcrire le systme dun point de vue
implmentation
Permet de dcrire les composants dun systme et les
interactions entre ceux-ci
Illustre comment grouper concrtement et physiquement
les lments (objets, interfaces, etc.) du systme au sein
de modules quon appelle composants

Modle composants
Unit modulaire avec des interfaces bien dfinies qui est
remplaable dans son environnement
Unit autonome au sein d'un systme

A une ou plusieurs interfaces fournies et requises

Sa partie interne est cache et inaccessible
Ses dpendances sont conues de telle sorte

que le
composant peut tre traite de faon aussi autonome que
possible

Foutse Khomh
19

20

Modle composants : notation

Modle composants : notation

! Composants

Personne

Commande

et relations notation

Une flche de dpendance permet de mettre en relation

des composant via les interfaces requises et fournies

EntreCmdes

PaiementComptes
RechercheClient

interface requise

composant

interfaces offertes

Systme de
commande

Repositoire
Clients

RechercheClient

(3) dpendance
(1) composant

AccsProduit

Commande

AccsProduit

<<provided interfaces>>
EntreCmdes
PaiementComptes
<<required interface>>
Personne

(2) interface

Systme
dinventaire

Venera Arnaoudova

Venera Arnaoudova
21

22

Modle composants : vue interne

Modle composants : notation

Dlgation
Rattacher le contrat externe d'un composant interne la
ralisation
Reprsente la transmission des signaux
Il ne doit tre dfini quentre les interfaces requises ou des
ports du mme genre

Venera Arnaoudova
23

24

Venera Arnaoudova

La vue de dploiement
Un diagramme de dploiement reprsente la faon dont
dployer les diffrentes lments dun systme

Les ressources matrielles et limplantation du logiciel dans

Exemple de diagramme de dploiement

Un diagramme de dploiement propose une vision
statique de la topologie du matriel sur lequel sexcute
le systme
Un diagramme de dploiement montre les associations
(connexions) existant entre les noeuds du systme
Un diagramme de dploiement ne montre pas les
interactions entre les noeuds

ces ressources
Les lments
Les noeuds
Les modules

Les programmes principaux

25

26

Diagramme de dploiement et
communication

Une connexion est une connexion physique reliant deux

noeuds entre-eux.
Elle indique en gnral la mthode utulise : ex TCP/IP

noeuds
S:Serveur

GPS satellite

Communication
sans fil

Connexion entre noeuds

M2:MachineX

Exemples de connexion :
C1:Client
TCP/IP

M1:MachineX

lien

C2:Client

27

une connexion Ethernet,

une ligne srie,
un bus partag,

28

Exemple de dploiement et contraintes

Artefact
Un artefact est la spcification dun lment physique qui est
utilis ou produit par le processus de dveloppement du logiciel
ou par le dploiement du systme.

lment concret : fichier, excutable ou

table dune base de

donnes....

Un artefact peut tre reli dautres artefacts par notamment

des liens de dpendance.

29

30

Exemple

http://www.agilemodeling.com/artifacts/deploymentDiagram.htm

http://www.agilemodeling.com/artifacts/deploymentDiagram.htm

Dfinir un diagramme de dploiement

1. Identifier le cadre : une application ou lensemble du systme?
2. Prenez en compte les caractristiques techniques essentielles.

Quels systmes pr-existants doivent tre intgrs? Par

interaction?

Quelle qualit est attendue ? Mise en place de redondance?

Qui/quoi doit interagir avec le systme? Par quels moyens?

(Internet, exchanging data files, ...)? Comment le systme sera

monitor? Quelle scurit? (firewall, scurit hardware,...)

3. Identifier le style de larchitecture de distribution.

4. Identifier les noeuds et leurs connexions.

OS? Connexions (RMI, SOAP, ...).

5. Distribuer le logiciel sur les noeuds.
31

Exemples de proprits prendre en

compte
Persistance

granularit
volume
dure
mcanisme d'accs
frquence d'accs (cration / suppression, mise jour, lire)
Fiabilit

Mcanisme de communication inter-processus

latence
Synchronicit
taille des messages
Protocole
Mastering Object Oriented Analysis and Design with UML
Copyright 2003 Rational Software, all rights reserved

33

Dvelopper un modle architectural

32

Exemples de proprits prendre en

compte
Interfaces avec dautres systmes

latence
dure
mcanisme d'accs
frquence d'accs
Scurit

granularit des donnes

granularit des utilisateurs
rgles de scurit
privilges
Mastering Object Oriented Analysis and Design with UML
Copyright 2003 Rational Software, all rights reserved

34

Dvelopper un modle architectural

Commencer par faire une esquisse de larchitecture

En se basant sur les principaux requis des cas dutilisation ; dcomposition en

Dcrire larchitecture avec UML

Slectionner un style architectural

Tous les diagrammes UML peuvent tre utiles pour dcrire les

sous-systmes

Dterminer les principaux composants requis

Raffiner larchitecture

Identifier les principales interactions entre les composants et les interfaces

requises

Dcider comment chaque donne et chaque fonctionnalit sera distribue parmi

les diffrents composants

Considrer chacun des cas dutilisation et ajuster larchitecture pour quil

soit ralisable

diffrents aspects du modle architectural

Trois des diagrammes UML sont particulirement utile pour

dcrire une architecture logicielle
Diagramme de packages
Diagramme de composants
Diagramme de dploiement

Dtailler larchitecture et la faire voluer

35

36

Styles dArchitecture Logicielle

Quelques styles dArchitecture

Logicielle
Centr sur les Donnes

Base de donnes
Blackboard
L'architecture logicielle, tout comme l'architecture
traditionnelle, peut se catgoriser en styles.
Un systme informatique pourra utiliser plusieurs styles
selon le niveau de granularit ou l'aspect du systme
souhait.

Flots de Donnes
Invocation implicite

Par lots
Tuyaux et Filtres

Oriente vnements
Model-View-Controller

Hirarchique

En couches

37

38

Le style le plus rpandu

Architecture centre donnes

Entrept de donnes centralise qui communique avec un
certain nombre de clients.
Objectif : maintenir lintgrit des donnes
Utilise dans le cas o des donnes sont partages et
frquemment changes entre les composants
On distingue deux sous-types: rfrentiel et tableau noir

Rfrentiel: un client envoie une requte au systme en demandant

d'excuter une action ncessaire (par exemple des donnes

d'insertion)
Blackboard: le systme informe les abonns intresss par les
changements. Une Architecture de style Blackboard est similaire
l'observateur, modle de conception (Gamma et al., 1995).

39

Repository vs Blackboard

40

Architecture avec rfrentiel

!Environnement
Analyseur
syntaxique

de programmation

Optimiseur

Analyseur
lexical

Compilateur
Analyseur
smantique

Gnrateur
de code

Rfrentiel
Arbre
syntaxique

Dbogueur
41

Table de
symboles

diteur
syntaxique

Centre donnes :
avantages et difficults

Architecture flots de donnes

Indpendances des clients les uns des autres

on peut ajouter ou retirer des clients

Succession de transformations des donnes d'entre.

Mais attention aux optimisations qui crent un couplage

fort.
Point aborder:

La cohrence des donnes - synchronisation des lectures /

critures
La scurit des donnes, le contrle d'accs
Point de dfaillance unique
Passage lchelle (rplication vs complexit)

Objectifs : rutilisation et volutivit.

2 types : squentiel ou pipeline

style squentiel

: chaque tape s'excute jusqu' la fin

avant la prochaine tape commence
Par exemple Tubes UNIX en ligne de commande

style pipeline : certaines tapes peuvent fonctionner

simultanment

43

44

Flots de donnes :
avantages et inconvnients

Architecture flot de donnes

!Systme

de traitement du son

Faible complexit des interactions entre les

Encodeur pour
sortie de microphone

Filtrer
lcho

Filtrer
le bruit

composants : traitement en botes noires.

Retirer les
frquences non vocales

galiser les
les intervalles
dynamiques

- Pas pour des applications interactives.

- performance et efficacit : gestion de buffers affectant
l'efficacit de la mmoire.

Encodeur de
bruit ambiant

Dcompresser

Recevoir

Encoder la sortie
des haut-parleurs

Transmettre

Compresser

45

Architecture multi-couches

Base des workflows scientifiques utiliss sur les grilles

de calcul.

46

Style Client-Server Style

Organisation hirarchique du systme en un ensemble de

couches
Des interfaces bien dfinies entre les couches
Chaque couche agit comme un

Serveur : Fournisseur de services de couches "suprieures":

Client: consommateur de services de couche (s) ci-dessous"
Les connecteurs sont des protocoles de la couche d'interaction
Objectifs :

Rduire la complexit,
Amliorer la modularit, rutilisabilit, maintenabilit

Les composants sont les clients et les servers

Les serveurs ne connaissent pas le numro ou l'identit
des clients
Les clients connaissent l'identit du serveur
Les connecteurs sont bass sur les protocoles bass sur
RPC

Diffrents critres de stratification: notamment abstraction

47

48

Architecture multi-couches

Architecture n-niveaux
!

Client
!

! Systme

Architecture 2-niveaux (client-serveur ou client lourd)

Application

Serveur

requte de service

ferm

Reference Model of Open Systems Interconnection (OSI model)

Prsentation

Architecture 3-niveaux (client lger)

Transformation des donnes

(encryption,etc.)
Identifier et authentifier
une connexion

Session

Navigateur
Web

requte
de service

Logique
applicative

requte
de service
de B.D.

Serveurs
de
base de donnes

Transport
Transmission des
routing packets

Architecture 4-niveaux
Client

Logique
Applicative

Prsentation
(partie web)

(calculs,
business)

Transmission (point point)

fiable des donnes
Rseau

Transmission des
data frames sans erreurs

Bases de
donnes

Interface matrielle
du rseau

49

Architecture multi-couches

Ligne de donnes

Physique

50

Invocation implicite

Conception et testabilit spare des couches

Cohsion des couches
Faible couplage et abstraction :
les couches infrieures ne devraient rien savoir des couches suprieures
connexions autorises entre couches uniquement via les API
Rutilisabilit des couches infrieures : des solutions
gnriques rutilisables
Flexibilit : ajout de nouveaux services construits sur les
service; une modification affecte au plus les couches
adjacentes.
- Performances
- Pas toujours applicables
- Saut entre couches

Leve dun vnement au lieu de linvocation explicite de

la mthode

"Auditeurs" sinscrivent aux vnements qui les intressent et

les mthodes associes

"Les annonceurs" ne sont pas conscients des effets des

vnements produits : aucune hypothse sur le traitement en

rponse des vnements

Deux types de connecteurs

L'invocation est soit explicite ou implicite, en rponse des

vnements

51

Invocation implicite
la rutilisation des composants
Evolution du systme
Tant au systme de construction en temps & run-time

- Structure du systme non-intuitive :

-

contrle des calculs donn aux Systme

Quelles ractions un vnement ?
Dans quel ordre, les traitements?

Evolution vers les bus messages et le complex event

processing

53

52

Architecture Modle-VueContrleur (MVC)

! Sparer

la couche interface utilisateur des autres parties du

systme (car les interfaces utilisateurs sont beaucoup plus
susceptibles de changer que la base de connaissances du
systme)
! Compos de trois types de composants
Modle : rassemble des donnes du domaine, des connaissances du
systme. Contient les classes dont les instances doivent tre vues et
manipules
Vue : utilis pour prsenter/afficher les donnes du modle dans
linterface utilisateur
Contrleur : contient les fonctionnalits ncessaires pour grer et
contrler les interactions de lutilisateur avec la vue et le modle
54

Architecture Modle-VueContrleur

Architecture Modle-Vue-Contrleur
E.g. Gnre le code
html pour le browser

Vus par
les acteurs

View

E.g. Interprte les

transmissions http
post du browser

!
Reoit les
vnements
des acteurs

crer et
mettre jour

Modle : noyau de lapplication

Enregistre les vues et les contrleurs qui en dpendent
Notifie les composants dpendants des modifications aux donnes

Vue : interface (graphique) de lapplication

Cre et initialise ses contrleurs

Consulter ltat
(i.e. les donnes)

notifier changements

Affiche les informations destines aux utilisateurs

Contrleur

Implante les procdure de mise jour ncessaires pour demeurer cohrente

Consulte les donnes du modle
!

modifier

Modle

Le sous-systme
grant linformation.

Contrleur : partie de lapplication qui prend les dcisions

Accepte les vnement correspondant aux entres de lutilisateur
Traduit un vnements (1) en demande de service adresse au modle ou bien (2)
en demande daffichage adresse la vue
Implmente les procdures indirectes de mise jour des vues si ncessaire
56

Architecture Modle-Vue-Contrleur
! Avantages

: appropri pour
les systmes interactifs,
particulirement ceux
impliquant plusieurs vues du
mme modle de donnes.
Peut tre utilis pour faciliter
la maintenance de la
cohrence entre les
donnes distribues
! Inconvnient : goulot
dtranglement possible

Dun point de vue conception

Diviser pour rgner : les composants
peuvent tre conus indpendamment
Cohsion : meilleure cohsion que si les
couches vue et contrle taient dans
linterface utilisateur.
Couplage : le nombre de canaux de
communication entre les 3 composants
est minimal
Rutilisabilit : la vue et le contrle
peuvent tre conus partir de
composants dj existants
Flexibilit : il est facile de changer
linterface utilisateur
Testabilit : il est possible de tester
lapplication indpendamment de
linterface

Styles dArchitecture Logicielle :

conclusion
Pas toujours immdiat didentifier un style darchitecture
Ils servent comprendre et communiquer.

Une architecture centre donne peut tre encapsule dans

un composant indpendant.

Les couches dune architecture peuvent correspondre des

composants.

Les composants dans une architecture pipeline peuvent eux

mme tre mis en oeuvre comme des composants

indpendants avec leur propre architecture
les architectures client / serveur CORBA peuvent tre dcrites
comme une architecture couches.

58

Biblio sur les architectures

logicielles

Conclusion

Il y a beaucoup de diagrammes
Il est important de bien saisir leur articulation
UML se prte bien la reprsentation de larchitecture

LOG4430 :
Architecture logicielle et conception avance, Foutse Khomh
VERIFICATION AND VALIDATION FOR QUALITY OF UML 2.0
MODELS, BHUVAN UNHELKAR, PHD
UML (Diagramme de composants,Diagramme de dploiement)
http://www.emse.fr/~boissier/enseignement/aco/pdf/
UML.Deploiement.4pp.pdf
http://laurent-audibert.developpez.com/Cours-UML/html/
Cours-UML051.html
http://www.iict.ch/Tcom/Cours/OOP/Livre/UML13.pdf
Modularization and Software Architectures, http://
www.softwareresearch.net/fileadmin/src/docs/teaching/WS06/SE1/SE1_lect12.pdf

59

60

Biblio diagrammes de
composants

COMPONENT DIAGRAM in UML 2.0, Veronica Carrega

http://www.ibm.com/developerworks/rational/library/
dec04/bell/

61