Architecture logicielle
Architecture logicielle :
quelques lments
Licence professionnelle IDSE
2012-2013
http://anubis.polytech.unice.fr/iut/2012_2013/lp/idse/gl/management
Mireille Blay-Fornarino
blay@unice.fr
1 2
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
LOG4430 : ARCHITECTURE LOGICIELLE ET CONCEPTION AVANCE, FOUTSE KHOMH,
UNIVERSIT DE MONTRAL
3 4
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
5 6
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.
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 sous-
systmes
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
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
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
7 8
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
9 10
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
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
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
Critres de Qualit Logicielle
Interoprabilit
Portabilit Extensibilit
Compatibilit Efficacit
Validit Autonomie
Vrifiabilit Transparence
Intgrit Composabilit
Fiabilit 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 de composants
diagrammes d'objets

Le rle de larchitecte logiciel est: Vue utilisateur

diagrammes de cas
1) de dfinir une architecture logicielle qui satisfasse les diagrammes d'tats
diagrammes d'activits diagrammes de dploiement
contraintes du systme diagrammes de squence
diagrammes de collaboration
2) de la communiquer. 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

Modliser avec UML La vue logique

Aspects statiques et dynamiques
! Les vues (structurelles) dune architecture logicielle Les lments
Vue logique. Description logique du systme dcompos
Les objets, Les classes
en sous-systmes (modules + interface)
UML : diagramme de paquetages
Les collaborations, Les interactions
Vue dimplmentation. Description de limplmentation
Les paquetages : organisation des lments en groupes
logiques
(physique) du systme logiciel en termes de composants
et de connecteurs
Dependency relationship
UML : diagramme de composants
Client Package Supplier
Vue de dploiement. Description de lintgration et de la Package
distribution de la partie logicielle sur la partie matrielle
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

La vue de ralisation
A
A

Hierarchy
B Permet de visualiser les modules dans lenvironnement de dveloppement.
should be B
Un bon support, le diagramme de composants dUML.
acyclic
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 Pierre-Alain Muller
Copyright 2003 Rational Software, all rights reserved 17
18
 Diagramme de composants Modle composants
UML 2.0 Unit modulaire avec des interfaces bien dfinies qui est
remplaable dans son environnement
Unit autonome au sein d'un systme
Offre une vue de haut niveau de larchitecture du
systme A une ou plusieurs interfaces fournies et requises
Utilis pour dcrire le systme dun point de vue Sa partie interne est cache et inaccessible
implmentation Ses dpendances sont conues de telle sorte que le
composant peut tre traite de faon aussi autonome que
Permet de dcrire les composants dun systme et les possible
interactions entre ceux-ci
Illustre comment grouper concrtement et physiquement
les lments (objets, interfaces, etc.) du systme au sein
de modules quon appelle composants

Foutse Khomh
19 20

Modle composants : notation Modle composants : notation

! Composants et relations notation
EntreCmdes Une flche de dpendance permet de mettre en relation
Personne
des composant via les interfaces requises et fournies
Commande PaiementComptes

RechercheClient

Systme de Repositoire
commande Clients
RechercheClient
interface requise composant interfaces offertes
(3) dpendance
AccsProduit (1) composant
Commande AccsProduit
Systme
<<provided interfaces>>
EntreCmdes dinventaire
PaiementComptes (2) interface
<<required interface>>
Personne

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
 Exemple de diagramme de dploiement
La vue 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 reprsente la faon dont
dployer les diffrentes lments dun systme Un diagramme de dploiement ne montre pas les
interactions entre les noeuds
Les ressources matrielles et limplantation du logiciel dans
ces ressources
Les lments
Les noeuds
Les modules
Les programmes principaux

25 26

Diagramme de dploiement et
communication Connexion entre noeuds

Une connexion est une connexion physique reliant deux

noeuds entre-eux.
noeuds Elle indique en gnral la mthode utulise : ex TCP/IP
S:Serveur
Communication
GPS satellite sans fil M2:MachineX

Exemples de connexion :
C1:Client une connexion Ethernet,
M1:MachineX TCP/IP lien une ligne srie,
C2:Client un bus partag,

27 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 32

Exemples de proprits prendre en Exemples de proprits prendre en

compte compte
Persistance Interfaces avec dautres systmes
granularit latence
volume
dure
dure
mcanisme d'accs
mcanisme d'accs
frquence d'accs (cration / suppression, mise jour, lire) frquence d'accs
Fiabilit Scurit
Mcanisme de communication inter-processus granularit des donnes
latence granularit des utilisateurs
Synchronicit rgles de scurit
taille des messages privilges
Protocole
Mastering Object Oriented Analysis and Design with UML Mastering Object Oriented Analysis and Design with UML
Copyright 2003 Rational Software, all rights reserved 33 Copyright 2003 Rational Software, all rights reserved 34

Dvelopper un modle architectural 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
sous-systmes
Dterminer les principaux composants requis Tous les diagrammes UML peuvent tre utiles pour dcrire les
Slectionner un style architectural diffrents aspects du modle architectural
Raffiner larchitecture Trois des diagrammes UML sont particulirement utile pour
Identifier les principales interactions entre les composants et les interfaces dcrire une architecture logicielle
requises Diagramme de packages
Dcider comment chaque donne et chaque fonctionnalit sera distribue parmi Diagramme de composants
les diffrents composants
Diagramme de dploiement
Considrer chacun des cas dutilisation et ajuster larchitecture pour quil
soit ralisable
Dtailler larchitecture et la faire voluer

35 36
 Quelques styles dArchitecture
Styles dArchitecture Logicielle Logicielle
Centr sur les Donnes
Base de donnes
Blackboard
L'architecture logicielle, tout comme l'architecture Flots de Donnes
traditionnelle, peut se catgoriser en styles. Par lots Invocation implicite
Un systme informatique pourra utiliser plusieurs styles Tuyaux et Filtres Oriente vnements
selon le niveau de granularit ou l'aspect du systme Hirarchique Model-View-Controller
souhait.
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 40

Repository vs Blackboard Architecture avec rfrentiel

!Environnement de programmation
Analyseur
syntaxique Optimiseur
Analyseur
Compilateur lexical
Analyseur Gnrateur
smantique de code

Rfrentiel

Arbre Table de
syntaxique symboles

diteur
Dbogueur
syntaxique

41
 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 Objectifs : rutilisation et volutivit.
fort.
Point aborder:
2 types : squentiel ou pipeline
La cohrence des donnes - synchronisation des lectures /
critures style squentiel : chaque tape s'excute jusqu' la fin
avant la prochaine tape commence
La scurit des donnes, le contrle d'accs Par exemple Tubes UNIX en ligne de commande
Point de dfaillance unique style pipeline : certaines tapes peuvent fonctionner
Passage lchelle (rplication vs complexit) simultanment

43 44

Architecture flot de donnes Flots de donnes :

avantages et inconvnients
!Systme de traitement du son
Encodeur pour
sortie de microphone
Faible complexit des interactions entre les
composants : traitement en botes noires.

Filtrer Filtrer Retirer les

galiser les - Pas pour des applications interactives.
lcho le bruit frquences non vocales
les intervalles
dynamiques - performance et efficacit : gestion de buffers affectant
l'efficacit de la mmoire.
Encodeur de
bruit ambiant

Dcompresser Recevoir Transmettre Compresser

Base des workflows scientifiques utiliss sur les grilles
de calcul.

Encoder la sortie
des haut-parleurs
45 46

Architecture multi-couches 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
! Systme ferm
! Architecture 2-niveaux (client-serveur ou client lourd)
Reference Model of Open Systems Interconnection (OSI model)
Application
Client Serveur
requte de service Transformation des donnes
Prsentation (encryption,etc.)
! Architecture 3-niveaux (client lger)
Identifier et authentifier
Session une connexion

Navigateur Logique Serveurs Transmission (point point)

Web applicative de Transport fiable des donnes
requte requte base de donnes
de service de service
Transmission des Rseau
de B.D.
routing packets
! Architecture 4-niveaux
Transmission des Ligne de donnes
Logique data frames sans erreurs
Prsentation Applicative Bases de
Client
(partie web) (calculs, donnes Interface matrielle Physique
business) du rseau

49 50

Architecture multi-couches
Invocation implicite
Conception et testabilit spare des couches
Cohsion des couches
Leve dun vnement au lieu de linvocation explicite de
Faible couplage et abstraction :
la mthode
les couches infrieures ne devraient rien savoir des couches suprieures
connexions autorises entre couches uniquement via les API "Auditeurs" sinscrivent aux vnements qui les intressent et
les mthodes associes
Rutilisabilit des couches infrieures : des solutions
gnriques rutilisables "Les annonceurs" ne sont pas conscients des effets des
vnements produits : aucune hypothse sur le traitement en
Flexibilit : ajout de nouveaux services construits sur les rponse des vnements
service; une modification affecte au plus les couches
adjacentes. Deux types de connecteurs
- Performances L'invocation est soit explicite ou implicite, en rponse des
- Pas toujours applicables vnements
- Saut entre couches
51 52

Invocation implicite Architecture Modle-Vue-

Contrleur (MVC)
la rutilisation des composants ! Sparer la couche interface utilisateur des autres parties du
Evolution du systme systme (car les interfaces utilisateurs sont beaucoup plus
Tant au systme de construction en temps & run-time susceptibles de changer que la base de connaissances du
systme)
! Compos de trois types de composants
- Structure du systme non-intuitive :
Modle : rassemble des donnes du domaine, des connaissances du
- contrle des calculs donn aux Systme
systme. Contient les classes dont les instances doivent tre vues et
- Quelles ractions un vnement ? manipules
- Dans quel ordre, les traitements? Vue : utilis pour prsenter/afficher les donnes du modle dans
linterface utilisateur
Contrleur : contient les fonctionnalits ncessaires pour grer et
Evolution vers les bus messages et le complex event contrler les interactions de lutilisateur avec la vue et le modle
processing
53 54
Architecture Modle-Vue-Contrleur Architecture Modle-Vue-
E.g. Gnre le code
E.g. Interprte les
Contrleur
html pour le browser
Vus par transmissions http
les acteurs post du browser ! Modle : noyau de lapplication
Reoit les
Enregistre les vues et les contrleurs qui en dpendent
crer et vnements
View mettre jour des acteurs Notifie les composants dpendants des modifications aux donnes
! Vue : interface (graphique) de lapplication
Cre et initialise ses contrleurs
Consulter ltat
Affiche les informations destines aux utilisateurs
(i.e. les donnes) notifier changements Contrleur
Implante les procdure de mise jour ncessaires pour demeurer cohrente
Consulte les donnes du modle
! Contrleur : partie de lapplication qui prend les dcisions
Modle modifier
Accepte les vnement correspondant aux entres de lutilisateur
Traduit un vnements (1) en demande de service adresse au modle ou bien (2)
Le sous-systme
grant linformation. en demande daffichage adresse la vue
Implmente les procdures indirectes de mise jour des vues si ncessaire

56

Styles dArchitecture Logicielle :

Architecture Modle-Vue-Contrleur conclusion
! Avantages : appropri pour ! Dun point de vue conception Pas toujours immdiat didentifier un style darchitecture
les systmes interactifs, Diviser pour rgner : les composants
peuvent tre conus indpendamment
Ils servent comprendre et communiquer.
particulirement ceux Cohsion : meilleure cohsion que si les
Une architecture centre donne peut tre encapsule dans
impliquant plusieurs vues du couches vue et contrle taient dans
linterface utilisateur. un composant indpendant.
mme modle de donnes.
Peut tre utilis pour faciliter
Couplage : le nombre de canaux de
communication entre les 3 composants
Les couches dune architecture peuvent correspondre des
est minimal composants.
la maintenance de la
cohrence entre les
Rutilisabilit : la vue et le contrle
peuvent tre conus partir de Les composants dans une architecture pipeline peuvent eux
composants dj existants mme tre mis en oeuvre comme des composants
donnes distribues Flexibilit : il est facile de changer indpendants avec leur propre architecture
! Inconvnient : goulot linterface utilisateur

dtranglement possible Testabilit : il est possible de tester les architectures client / serveur CORBA peuvent tre dcrites
lapplication indpendamment de comme une architecture couches.
linterface

58

Biblio sur les architectures

Conclusion logicielles
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)
Il y a beaucoup de diagrammes http://www.emse.fr/~boissier/enseignement/aco/pdf/
Il est important de bien saisir leur articulation UML.Deploiement.4pp.pdf
UML se prte bien la reprsentation de larchitecture
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