Architecture Logicielle

Architecture Logicielle
Objectif de ce cours :
Permet de donner les outils logiciels et
architecturaux pour la fabrication
professionnelle de logiciels,
A travers lexploration : A travers lexploration :
des Ateliers Gnie Logiciel
& des design Patterns
& rame!or"s#
Objectif de ce cours : $ %uite
Apprendre galement les divers solutions
conceptuelles et logi&ues fournies par les
leaders du march :
'() *'od+le$(ue$)ontr,leur- '() *'od+le$(ue$)ontr,leur-
.$/iers *. couches-,
%/01/%
2
3#4# : %eront tudies Les solutions open sources et
gratuites
Les solutions conceptuelles et logi&ues :
'() *'od+le$(ue$)ontr,leur-
un mod+le *mod+le de donnes-,
une vue *prsentation, interface une vue *prsentation, interface
utilisateur-
un contr,leur *logi&ue de contr,le,
gestion des vnements,
s5nchronisation-
.$/iers *. couches- : modliser une application comme un
empilement de trois couches logicielles *tages, niveaux,
tiers ou strates- dont le r,le est clairement dfini :
6# la prsentation des donnes : correspondant 7
l8affichage, la restitution sur le poste de travail, le
dialogue avec l8utilisateur 9
l8affichage, la restitution sur le poste de travail, le
dialogue avec l8utilisateur 9
:# le traitement mtier des donnes : correspondant 7
la mise en ;uvre de l8ensemble des r+gles de gestion
et de la logi&ue applicative 9
.# et enfin l8accs aux donnes : correspondant aux
donnes &ui sont destines 7 <tre conserves sur la
dure, voire de mani+re dfinitive#
%/01/% : est un frame!or" libre servant au
dveloppement d8applications !eb =ava >>
Java Enterprise Edition, ou Java EE *anciennement Java Enterprise Edition, ou Java EE *anciennement
J2EE-
%O''A?0> :
6# ?ntroduction aux Architectures logicielles
:# Langages de description dArchitectures
logicielles
.# )onception d1ne Architecture Logicielle .# )onception d1ne Architecture Logicielle
A# Architectures Orientes %ervices *%OA-
logicielles
.# )onception d1ne Architecture Logicielle
A# Architectures Orientes %ervices *%OA- A# Architectures Orientes %ervices *%OA-
6 $ ?ntroduction aux Architectures
logicielles :
Bfinition,
%tatut de larchitecture au sein dun projet
(ues de lArchitecture (ues de lArchitecture
%t5les dArchitectures
'od+les dArchitectures *)ouches, 'ulti$/iers,
2-,
Proprits et /echni&ues de vrification#
6#6 C Bfinition :
Larchitecture logicielle dcrit dune
mani+re s5mboli&ue et
schmati&ue les diffrents schmati&ue les diffrents
lments dun ou de plusieurs
s5st+mes informati&ues, leurs
interrelations et leurs interactions#
6#6 C Bfinition : *)omparaison-
Les spcifications produites par
lanal5se fonctionnelle dcrit ce &ue doit
raliser un s5st+me informati&ue ,
'ais le modle d'architecture, produit 'ais le modle d'architecture, produit
lors de la phase de conception, dcrit
comment un s5st+me informati&ue doit
<tre conDu de mani+re 7 rpondre aux
spcifications#
6#6 C Bfinition :
Lanal5se dcrit le :
E &uoi faire F
alors &ue larchitecture dcrit le : alors &ue larchitecture dcrit le :
E comment le faire F
6#6 C Bfinition : )ontexte & 'otivation
La phase de conception logicielle est
l8&uivalent, en informati&ue, 7 la phase
de conception en ingnierie traditionnelle
*mcani&ue, civile ou lectri&ue-9 *mcani&ue, civile ou lectri&ue-9
)ette phase consiste 7 raliser
enti+rement le produit sous une forme
abstraite avant la production effective#
la nature immatrielle du logiciel rend la
fronti+re entre l8architecture et le produit
beaucoup plus floue &ue dans l8ingnierie
traditionnelle#
Remarque : Le logiciel est model dans
l8information et non dans la mati+re#
L8utilisation d8outils oG la production de
l8architecture 7 partir du code lui$m<me et
de la documentation s5st+me permettent
de mettre en vidence le lien troit entre de mettre en vidence le lien troit entre
l8architecture et le produit#
)A%> H )omputer$aided soft!are
engineering#
L8architecture logicielle constitue le plus
gros livrable d8un processus logiciel apr+s
le produit *le logiciel lui$m<me-#
La phase de conception devrait
consommer autour de AI J de l8effort
total de dveloppement et devrait <tre
suprieure ou gale, en effort, 7 la phase suprieure ou gale, en effort, 7 la phase
de codage mais il peut <tre moindre#
L8effort dpend grandement de :
Le t5pe de logiciel dvelopp,
Lexpertise de l8&uipe de Lexpertise de l8&uipe de
dveloppement,
Le taux de rutilisation
>t du processus logiciel#
Les deux objectifs principaux de toute
architecture logicielle sont :
La rduction des coKts La rduction des coKts
>t l8augmentation de la &ualit du
logiciel9
La rduction des coKts est
principalement ralise par la rutilisation
de composants logiciels et par la
diminution du temps de maintenance diminution du temps de maintenance
*correction d8erreurs et adaptation du
logiciel-#
La &ualit, par contre, se trouve
distribue 7 travers plusieurs crit+res9 la
norme ?%O L6:M est un exemple d8un tel
ensemble de crit+res# ensemble de crit+res#
(oir paragraphe suivant2
6#6 C Bfinition : Critres de qualit logicielle
L'interoprabilit extrinsque exprime la
capacit du logiciel 7 communi&uer et 7
utiliser les ressources d8autres logiciels
comme, par exemple, les documents crs comme, par exemple, les documents crs
par une certaine application#
L'interoprabilit intrinsque exprime le
degr de cohrence entre le fonctionnement
des commandes et des modules 7 l8intrieur
d8un s5st+me ou d8un logiciel#
La portabilit exprime la possibilit de
compiler le code source etNou d8excuter le
logiciel sur des plates$formes *machines,
s5st+mes d8exploitation, environnements-
diffrentes# diffrentes#
La compatibilit exprime la possibilit, pour
un logiciel, de fonctionner correctement dans
un environnement ancien *compatibilit
descendante- ou plus rcent *compatibilit
ascendante-#
La validit exprime la conformit des
fonctionnalits du logiciel avec celles
dcrites dans le cahier des charges#
La vrifiabilit exprime la simplicit de La vrifiabilit exprime la simplicit de
vrification de la validit#
L'intgrit exprime la facult du logiciel
7 protger ses fonctions et ses donnes
d8acc+s non autoriss#
La fiabilit exprime la facult du logiciel 7 La fiabilit exprime la facult du logiciel 7
grer correctement ses propres erreurs de
fonctionnement en cours d8excution#
La maintenabilit exprime la simplicit de
correction et de modification du logiciel, et
m<me, parfois, la possibilit de modification
du logiciel en cours d8excution# du logiciel en cours d8excution#
La rutilisabilit exprime la capacit de
concevoir le logiciel avec des composants dj7
conDus tout en permettant la rutilisation
simple de ses propres composants pour le
dveloppement d8autres logiciels#
L'extensibilit exprime la possibilit
d8tendre simplement les fonctionnalits
d8un logiciel sans compromettre son
intgrit et sa fiabilit# intgrit et sa fiabilit#
L'efficacit exprime la capacit du
logiciel 7 exploiter au mieux les ressources
offertes par la ou les machines oG le
logiciel sera implant#
L'extensibilit exprime la possibilit
d8tendre simplement les fonctionnalits
d8un logiciel sans compromettre son
intgrit et sa fiabilit# intgrit et sa fiabilit#
L'efficacit exprime la capacit du
logiciel 7 exploiter au mieux les ressources
offertes par la ou les machines oG le
logiciel sera implant#
L'autonomie exprime la capacit de
contr,le de son excution, de ses donnes
et de ses communications#
La transparence exprime la capacit La transparence exprime la capacit
pour un logiciel de mas&uer 7 l8utilisateur
*humain ou machine- les dtails inutiles 7
l8utilisation de ses fonctionnalits#
La composabilit exprime la capacit
pour un logiciel de combiner des
informations provenant de sources
diffrentes# diffrentes#
La convivialit dcrit la facilit
d8apprentissage et d8utilisation du logiciel
par les usagers#
6#6 C Bfinition : iminution de la dgradation
du logiciel
1ne architecture faible ou absente peut
entraOner de graves probl+mes lors de
la maintenance du logiciel#
du logiciel
/oute modification d8un logiciel mal
architectur peut dstabiliser la structure
de celui$ci et entraOner, 7 la longue, une de celui$ci et entraOner, 7 la longue, une
dgradation#
du logiciel
L8architecte devrait donc concevoir,
s5stmati&uement, une architecture
maintenable et extensible# maintenable et extensible#
du logiciel
Bans les processus itratifs comme 1P
*1nified Process-, la gestion des
changements est primordiale# changements est primordiale#
du logiciel
>n effet, il est implicitement considr
&ue les besoins des utilisateurs du
s5st+me peuvent changer et &ue s5st+me peuvent changer et &ue
l8environnement du s5st+me peut changer#
du logiciel
L8architecte a donc la responsabilit de
prvoir le pire et de concevoir
l8architecture en cons&uence9 la plus l8architecture en cons&uence9 la plus
maintenable possible et la plus extensible
possible#
du logiciel
4ien des logiciels ont t crs sans
architecture par plusieurs gnrations de
dveloppeurs a5ant chacune us d8une dveloppeurs a5ant chacune us d8une
imagination dbordante pour russir 7
maintenir l8intgrit du s5st+me#
du logiciel
1ne telle absence d8architecture peut
<tre &ualifie d'architecture organique.
En effet, un dveloppeur confront une En effet, un dveloppeur confront une
telle architecture a plus l'impression de
travailler avec un organisme vivant
&u8avec un produit industriel#
du logiciel
?l en rsulte &ue la complexit du logiciel
fait en sorte &ue celui$ci est extr<mement
difficile 7 comprendre et 7 modifier# difficile 7 comprendre et 7 modifier#
P la limite, modifier une partie du
s5st+me est plus proche, en complexit,
de la transplantation cardia&ue &ue du
changement de carburateur#
6#6 C Bfinition : La rutilisation
La rutilisation de composants logiciels
est l8activit permettant de raliser les
conomies les plus substantielles, encore
faut$il possder des composants 7 faut$il possder des composants 7
rutiliser#
Be plus, la rutilisation de composants
ncessite de crer une architecture
logicielle permettant une intgration
harmonieuse de ces composants harmonieuse de ces composants
Le dveloppement par la rutilisation
logicielle impose donc un c5cle de
production$rutilisation perptuel et une
architecture logicielle normalise# architecture logicielle normalise#
un c5cle
de production$rutilisation perptuel
1ne rutilisation bien orchestre
ncessite la cration et le maintien d8une
biblioth+&ue logicielle et un changement
de focus9 crer une application revient 7 de focus9 crer une application revient 7
crer les composants de biblioth+&ue
ncessaires puis 7 construire l8application
7 l8aide de ces composants#
1ne telle biblioth+&ue, facilitant le
dveloppement d8application est un
frame!or" *cadriciel- d8entreprise et son
architecture, ainsi &ue sa documentation architecture, ainsi &ue sa documentation
sont les pierres angulaires de la
rutilisation logicielle en entreprise#
Le r,le de l8architecte se dplace donc
vers celui de bibliothcaire#
L8architecte doit explorer la biblioth+&ue
pour trouver les composants logiciels pour trouver les composants logiciels
appropris puis crer les composants
man&uants, les documenter et les intgrer
7 la biblioth+&ue#
Bans une grande entreprise, ce r,le de
bibliothcaire est rempli par l8architecte
en chef &ui est responsable du
dveloppement harmonieux de la dveloppement harmonieux de la
biblioth+&ue et de la conservation de
l8intgrit de son architecture#
6#6 C Bfinition : L'architecture une question
de point de vue
La description d8un s5st+me complexe
comme un logiciel informati&ue peut <tre
faite selon plusieurs points de vue faite selon plusieurs points de vue
diffrents mais chacun obit 7 la formule
de Perr5 et Qolf : !rchitecture "
Elements # $ormes # %otivations&
de point de vue
%elon le niveau de granularit, les
lments peuvent :
varier en tailles varier en tailles
varier en raffinement
varier en abstraction
de point de vue
%elon le niveau de granularit les lments
peuvent varier en tailles :
lignes de code, lignes de code,
procdures ou fonctions,
modules ou classes,
pa&uetages ou couches,
applications ou s5st+mes informati&ues
de point de vue
%elon le niveau de granularit les
lments peuvent varier en raffinement :
bauche, bauche,
solution 7 amliorer
ou solution finale
de point de vue
lments peuvent varier en abstraction :
ides ou concepts, ides ou concepts,
classes ou objets,
composants logiciels
de point de vue
lments peuvent galement possder :
une temporalit (une existence une temporalit (une existence
limite dans le temps-,
et une localisation (une existence
limite dans l'espace).
de point de vue
Les lments sont, en gnral, reprsents
par des rectangles ou des ovales,
Les formes sont &uant 7 elles constitues, la Les formes sont &uant 7 elles constitues, la
plupart du temps, d8lments relis par des
droites ou des fl+ches# La smanti&ue des liens
dtermine la majeure partie de la smanti&ue
du diagramme et l8aspect du s5st+me &ui 5 est
dcrit#
6#6 C Bfinition : 'rincipaux t(pes de liens
La dpendance fonctionnelle) signifie
&ue l8lment source ncessite l8lment
de destination pour raliser ses
fonctionnalits# fonctionnalits#
Le flot de contr*le) signifie &ue l8lment
de destination prendra le contr,le de
l8excution apr+s la terminaison de
l8lment source#
La transition d'tat) signifie &ue le s5st+me
passera de l8tat source 7 l8tat de
destination#
Le changement d'activit) signifie &ue le
s5st+me ralisera l8activit de destination
Le changement d'activit) signifie &ue le
s5st+me ralisera l8activit de destination
apr+s l8activit source#
Le flot de donnes) signifie &ue l8information
s8coule de l8lment source vers l8lment de
destination#
Le lien de communication) signifie &ue
deux lments changent de
l8information#
La composition) signifie &ue l8lment La composition) signifie &ue l8lment
source est compos d8une ou de plusieurs
donnes du t5pe de l8lment de
destination#
L'hritage +gnralisation,) signifie &ue
l8lment source poss+de l8ensemble des
donnes et des comportements de
l8lment de destination# l8lment de destination#
L'envoi de message) signifie &ue
l8lment source envoie un message 7
l8lment de destination#
6#x C Les mod+les darchitectures :
?ndpendamment de la forme &ue prend
un diagramme d8architecture, celui$ci ne
reprsente toujours &u8un point de
vue sur le s5st+me considr, vue sur le s5st+me considr,
Le plus important tant les motivations#
>n effet, 7 &uoi sert de produire un
diagramme s8il est inutile *pas utilis- ou si
les raisons des choix architecturaux sont
vagues et non$explicits# vagues et non$explicits#
Pour viter de formuler les motivations
pour cha&ue diagramme, l8architecte
produira les diffrents diagrammes en
fonction d8un modle de conception et fonction d8un modle de conception et
rutilisera des patrons de conception
prouvs.
1n mod+le de conception *ou
d8architecture- est compos d8un
ensemble de points de vue, chacun tant
compos d8un ensemble de diffrentes compos d8un ensemble de diffrentes
sortes de diagrammes#
?l propose galement des mo5ens pour
lier les diffrentes vues et diagrammes les
uns aux autres de mani+re 7 naviguer
aisment, il s8agit des mcanismes de aisment, il s8agit des mcanismes de
traDabilit architecturale#
La traDabilit doit galement s8tendre
aux spcifications s5st+mes et m<me
jus&u8aux besoins &ue ces spcifications
comblent#
La devise des trois p+res fondateurs
d81'L est :
- Centr sur l'architecture, pilot par les
cas d'utilisation et au dveloppement cas d'utilisation et au dveloppement
itratif et incrmentiel .
)ette devise indi&ue clairement
&u8aucune dcision architecturale ne doit
<tre prise sans &ue celle$ci ne soit dirige
*pilote- par la satisfaction des *pilote- par la satisfaction des
spcifications s5st+mes *cas d8utilisation-#
Le modle conventionnel
Le modle d.!nal(se
Le modle des / # 0 vues Le modle des / # 0 vues
Le modle conventionnel 1 %odles d'anal(se et
d'architecture centres sur les donnes avec tra2abilit
Le modle conventionnel 1 3 gauche
les spcifications s5st+mes &ui sont
galement reprsentes par des
diagrammes *>ntits$0elations, lux de diagrammes *>ntits$0elations, lux de
donnes, Rtats$/ransitions-#
Le modle conventionnel 1 3 droite
les diffrentes activits de conception
prenant comme intrants les livrables de la prenant comme intrants les livrables de la
phase d8anal5se#
Le modle conventionnel 1 3ous vo5ons &ue
l8architecture logicielle traditionnelle ncessiterait de
produire au moins A vues distinctes :
une architecture des donnes *conception des
donnes-,
une architecture fonctionnelle etNou modulaire une architecture fonctionnelle etNou modulaire
*conception architecturale-,
une autre architecture fonctionnelle etNou modulaire
pour les interfaces utilisateurs *conception des
interfaces-
et une architecture dtaille *ordinogrammes, tats$
transitions- des diffrents modules *conception des
composants-#
Le modle conventionnel 1
La p5ramide exprime &ue cha&ue couche est
bStie sur la prcdente# >n effet, les
composants ralisant les fonctionnalits du composants ralisant les fonctionnalits du
logiciel doivent manipuler des lments de
donnes &ui doivent donc <tre pralablement
dcrits#
Be m<me, les composants ralisant les
interfaces utilisateurs doivent utiliser les
fonctionnalits du logiciel pralablement fonctionnalits du logiciel pralablement
dcrites# >t finalement, la cration de
l8architecture dtaille de chacun des
composants du logiciel ncessite, videmment,
&ue ceux$ci soient pralablement invents#
)e mod+le d8architecture impose une
sparation claire entre
les donnes, les donnes,
les traitements
et la prsentation#
Le modle d'anal(se ou modle
d'architecture 4
Puis&ue l8anal5se produit galement des
diagrammes, il est naturel de se &uestionner, diagrammes, il est naturel de se &uestionner,
en effet, &uand se termine l8anal5se et &uand
commence l8architecture T
Le modle d'anal(se ou modle
d'architecture 4 La rponse est fort simple :
Les lments des diagrammes d8anal5se
correspondent 7 des lments visibles et correspondent 7 des lments visibles et
comprhensibles par les utilisateurs du
s5st+me,
Alors &ue les lments des diagrammes
d8architectures ne correspondent 7 aucune
ralit tangible pour ceux$ci#
Le modle des / # 0 vues
Le modle des / # 0 vues +%odle de
5ruchten, 1
?ci encore, le mod+le d8anal5se,
baptis vue des cas d8utilisation, baptis vue des cas d8utilisation,
constitue le lien et motive la cration
de tous les diagrammes
d8architecture#
La vue des cas d.utilisation 1
La vue des cas d8utilisation est un mod+le
d8anal5se formalis par ?var =acobson#
1n cas d8utilisation est dfini comme un 1n cas d8utilisation est dfini comme un
ensemble de scnarios d8utilisation, cha&ue
scnario reprsentant une s&uence
d8interaction des utilisateurs *acteurs- avec le
s5st+me#
La vue des cas d.utilisation 1 6uite
L8intr<t des cas d8utilisation est de piloter
l8anal5se par les exigences des utilisateurs#
)eux$ci se sentent concerns car ils )eux$ci se sentent concerns car ils
peuvent facilement comprendre les cas
d8utilisation &ui les concernent#
)ette mthode permet donc d8aider 7
formaliser les vritables besoins et
attentes des utilisateurs9 leurs criti&ues et attentes des utilisateurs9 leurs criti&ues et
commentaires tant les bri&ues de la
spcification du s5st+me#
)ha&ue cas d8utilisation est reprsent
par un diagramme de cas d8utilisation,
chacun des scnarios de celui$ci tant chacun des scnarios de celui$ci tant
dcrit par un ou plusieurs diagrammes
d5nami&ues : diagrammes d8activits, de
s&uence, diagrammes de
communication ou d8tats$transitions#
La vue logique 1
La vue logi&ue constitue la principale
description architecturale d8un s5st+me
informati&ue et beaucoup de petits informati&ue et beaucoup de petits
projets se contentent de cette seule vue#
)ette vue dcrit, de faDon stati&ue et
d5nami&ue, le s5st+me en termes
d8objets et de classes#
La vue logique 1
La vue logi&ue permet d8identifier
les diffrents lments et mcanismes les diffrents lments et mcanismes
du s5st+me 7 raliser#
>lle permet de dcomposer le
s5st+me en abstractions et constitue
le c;ur de la rutilisation#
La vue logique 1
>n effet, l8architecte rcuprera un
maximum de composants des
diffrentes biblioth+&ues et cadriciels diffrentes biblioth+&ues et cadriciels
*frame!or"- 7 sa disposition#
1ne recherche active de composants
libres etNou commerciaux pourra
galement <tre envisage#
La vue logique 1
La vue logi&ue est reprsente,
principalement, par des diagrammes
stati&ues de classes et d8objets enrichis
de descriptions d5nami&ues : de descriptions d5nami&ues :
Biagrammes d8activits,
Be s&uence,
Biagrammes de communication
Ou d8tats$transitions#
La vue du processus 1
La vue des processus dcrit les interactions
entre les diffrents processus, threads *fils
d8excution- ou tSches, elle permet
galement d8exprimer la s5nchronisation et galement d8exprimer la s5nchronisation et
l8allocation des objets#
)ette vue permet avant tout de vrifier le
respect des contraintes de fiabilit,
d8efficacit et de performances des s5st+mes
multitSches#
La vue du processus 1
Les diagrammes utiliss dans la vue
des processus sont exclusivement
d5nami&ues : d5nami&ues :
Biagrammes d8activits,
Biagrammes de s&uence,
Biagrammes de communication ou
d8tats$transitions#
La vue de ralisation 1
La vue de ralisation permet de visualiser
l8organisation des composants *biblioth+&ue
d5nami&ue et stati&ue, code source###- dans d5nami&ue et stati&ue, code source###- dans
l8environnement de dveloppement#
>lle permet aux dveloppeurs de se
retrouver dans la grande pagaille &ue peut
<tre un projet de dveloppement
informati&ue#
La vue de ralisation 1
)ette vue permet galement de grer la
configuration *auteurs, versions###-# configuration *auteurs, versions###-#
Les seuls diagrammes de cette vue sont
les diagrammes de composants#
La vue de dploiement 1
>lle reprsente le s5st+me dans son
environnement d8excution#
>lle traite des contraintes gographi&ues >lle traite des contraintes gographi&ues
*distribution des processeurs dans l8espace-,
des contraintes de bandes passantes, du
temps de rponse et des performances du
s5st+me ainsi &ue de la tolrance aux fautes
et aux pannes#
La vue de dploiement 1
)ette vue est fort utile pour l8installation
et la maintenance rguli+re du s5st+me# et la maintenance rguli+re du s5st+me#
Les diagrammes de cette vue sont les
diagrammes de composants et les
diagrammes de dploiement#
6#x C Les st5les architecturaux :
L8architecture logicielle, tout comme
l8architecture traditionnelle, peut se
catgoriser en st5les#
/ous les s5st+mes informati&ues /ous les s5st+mes informati&ues
dvelopps au cours des cin&uante
derni+res annes, se classent parmi
un nombre extr<mement restreint de
st5les architecturaux :
Be plus, un s5st+me informati&ue peut
utiliser plusieurs st5les selon le niveau de
granularit ou l8aspect du s5st+me dcrit#
Remarque 1 comme en architecture
traditionnelle, c8est souvent par le
mlange d8anciens st5les &ue les
nouveaux apparaissent#
!rchitecture en appels et retours)
!rchitecture en couches)
!rchitecture centre sur les donnes) !rchitecture centre sur les donnes)
!rchitecture en flot de donnes)
!rchitecture oriente ob7ets)
!rchitecture oriente agents&
$ !rchitecture en appels et retours 1
)ette architecture est base sur le
raffinement graduel propos par 3i"laus
Qirth# Qirth#
La devise : diviser pour rgner est
souvent utilise pour dcrire cette
dmarche#
)ette approche, galement appele
dcomposition fonctionnelle, consiste 7
dcouper une fonctionnalit en sous$ dcouper une fonctionnalit en sous$
fonctionnalits &ui sont galement
divises en sous sous$fonctionnalits et
ainsi de suite9
La fonctionnalit d8un module ou d8un
objet est ralise par des sous$modules
ou des sous$objets baptiss travailleurs ou des sous$objets baptiss travailleurs
*!or"er-#
1ne forme drive de cette architecture
est l8architecture distribue oG les
fonctions, modules ou classes se fonctions, modules ou classes se
retrouvent rpartis sur un rseau#
$ !rchitecture en couches 1
l8architecture en couches est la
cons&uence de lapproche suivante :
1ne biblioth+&ue gnri&ue est cre,
ensuite une biblioth+&ue gnrale est cre en
utilisant la prcdente,
enfin une autre biblioth+&ue spcialise est cre
en se basant sur la prcdente
>t ainsi de suite2
$ !rchitecture en couches 1
Autrement dit : les nouveaux composants
utilisent les anciens et ainsi de suite,
La biblioth+&ue tend donc 7 devenir une sorte
d8empilement de composants#
tous les composants des couches suprieures
dpendants fonctionnellement des composants
des couches infrieures#
$ !rchitecture en couches 1 8ibliothques
)ouche gnri&ue
)omposants gnri&ues
)ouche gnrale
)omposants gnraux
)ouche spcialise
)omposants spcialiss
$ !rchitecture centre sur les donnes 1
Bans cette architecture :
Le composant central, Le composant central,
Les composants priphri&ues
)omposant
priphri&ue
)omposant
priphri&ue
)omposant
)entral
Bonnes
)omposant
priphri&ue
)omposant
priphri&ue
)omposant
priphri&ue
)omposant
priphri&ue
)omposant
priphri&ue
priphri&ue priphri&ue
Le composant central est responsable de la
gestion des donnes :
%G4B, %G4B,
Bata!arehouse,
4lac"board#
Les oprations possibles sont :
)onservation
Ajout, Ajout,
0etrait,
'ise$7$jour,
%5nchronisation,
###,
Les composants priphri&ues, baptiss
clients, utilisent le composant central, baptis
serveur de donnes, serveur de donnes,
Le serveur se comporte, en gnral, de faDon
passive *%G4B, Bata!arehouse-#
La diffrence entre serveur passif et serveur
actif T
1n serveur passif ne fait &u8obir 1n serveur passif ne fait &u8obir
aveuglment aux ordres
1n serveur actif *4lac"board- peut notifier un
client si un changement aux donnes &ui le
concerne se produit#
$ !rchitecture en flot de donnes 1
)ette architecture est compose de plusieurs
composants logiciels relis entre eux par des
flux de donnes# flux de donnes#
L8information circule dans le rseau et est
transforme par les diffrents composants
&u8elle traverse#
Lors&ue les composants se distribuent sur une
seule ligne et &u8ils ne font &ue passer
l8information transforme 7 leur voisin, on parle
alors d'architecture par lot *batch-# alors d'architecture par lot *batch-#
%i les composants sont rpartis sur un rseau
informati&ue et &u8ils ralisent des
transformations et des s5nth+ses intelligentes de
l8information, on parle alors d'architecture de
mdiation&
Les architectures orientes vnements font
galement partie de cette catgorie#
$ !rchitecture oriente ob7ets 1
Les composants du s5st+me *objets- int+grent
des donnes et les oprations de traitement de
ces donnes# La communication et la ces donnes# La communication et la
coordination entre les objets sont ralises par
un mcanisme de passage de messages#
)ette architecture est souvent dcrite par les
trois piliers :
>ncapsulation, >ncapsulation,
Uritage
>t pol5morphisme#
L8encapsulation concerne l8architecture
dtaille de cha&ue objet, les donnes tant
protges d8acc+s direct par une couche protges d8acc+s direct par une couche
d8interface# Be plus, les sous$fonctions, inutiles
pour utiliser l8objet, sont mas&ues 7
l8utilisateur de l8objet#
L8hritage permet d8viter la redondance de
code et facilite l8extensibilit du logiciel, les
fonctionnalits communes 7 plusieurs classes fonctionnalits communes 7 plusieurs classes
d8objets tant regroupes dans un anc<tre
commun#
Le pol5morphisme permet d8utiliser des
objets diffrents *possdant des
comportements distincts- de mani+re comportements distincts- de mani+re
identi&ue, cette possibilit est ralise par la
dfinition d8interfaces 7 implmenter *classes
abstraites-#
$ !rchitecture oriente agents 1
L8architecture agent est le produit du passage
du composant objectif vers le composant
projectif# projectif#
>n effet, l8objet est essentiellement un
composant passif offrant des services et
utilisant d8autres objets pour raliser ses utilisant d8autres objets pour raliser ses
fonctionnalits9 l8architecture objet est donc
une extension de l8architecture en appels et
retours#
L8agent, par contre, utilise de mani+re
intelligente les autres agents pour raliser ses
objectifs9 il tablit des dialogues avec les autres objectifs9 il tablit des dialogues avec les autres
agents, il ngocie et change de l8information#
logicielles
Architecture Logicielle V Langages
: $ Langages de description dArchitectures
logicielles
0eprsentation dune architecture, )oncepts
fondamentaux,
%olutions apportes par les diffrents langages %olutions apportes par les diffrents langages
de description dArchitecture,
(rification de proprits
: a$ )oncepts fondamentaux :
Le composant,
Le connecteur,
>t la configuration ou la topologie# >t la configuration ou la topologie#
Le composant,
Le connecteur,
Le composant :
1n composant est une unit de calcul
ou de stoc"age 7 la&uelle est ou de stoc"age 7 la&uelle est
associe une unit dimplantation#
Le composant est un lieu de calcul et
poss+de un tat
Le composant :
1n composant peut <tre simple ou
compos 9 on parle alors dans ce compos 9 on parle alors dans ce
dernier cas de composite
Le composant :
La taille dun composant peut aller de
la fonction mathmati&ue 7 une la fonction mathmati&ue 7 une
application compl+te#
On dfinit deux parties dans un
composant :
Le composant :
1ne premi+re partie, dite extrieure,
correspond 7 son interface# >lle correspond 7 son interface# >lle
comprend la description des interfaces
fournies et re&uises par le composant#
>lle dfinit les interactions du
composant avec son environnement# :
Le composant :
1ne seconde partie, &ui correspond 7
son implantation et permet la son implantation et permet la
description du fonctionnement
interne du composant#
Le composant : Les caractristi&ues
globales dun composant dfinies par
'edvidovic et /a5lor sont les suivantes :
$ linterface,
$ le t5pe, $ le t5pe,
$ la smanti&ue,
$ les contraintes,
$ la maintenance volutive dun composant,
$ les proprits non fonctionnelles#
Le composant : Linterface dun
composant est la description de
lensemble des services offerts et
re&uis par le composant sous la re&uis par le composant sous la
forme de signature de mthodes, de
t5pe dobjets envo5s et retourns,
dexceptions et de contexte
dexcution#
Le composant : Linterface est un
mo5en dexpression des liens du
composant ainsi &ue ses contraintes composant ainsi &ue ses contraintes
avec lextrieur#
Le composant : Le type dun
composant est un concept
reprsentant limplantation des reprsentant limplantation des
fonctionnalits fournies par le
composant# ?l sapparente 7 la notion
de classe &ue lon trouve dans le
mod+le orient objet#
Le composant : Le type dun
composant : 1n t5pe de composant
permet la rutilisation dinstances permet la rutilisation dinstances
de m<me fonctionnalit soit dans un
m<me architecture, soit dans des
architectures diffrentes#
Le composant : Le type dun composant
: >n fournissant un mo5en de dcrire, de
mani+re explicite, les proprits
communes 7 un ensemble dinstances communes 7 un ensemble dinstances
dun m<me composant, la notion de t5pe
de composant introduit un classificateur
&ui favorise la comprhension dune
architecture et sa conception#
La smantique dun composant :
La smanti&ue du composant est
exprime en partie par son interface# exprime en partie par son interface#
)ependant, linterface telle &ue
dcrite ci$dessus ne permet pas de
prciser compl+tement le
comportement du composant#
La smanti&ue doit <tre enrichie par
un mod+le plus complet et plus un mod+le plus complet et plus
abstrait permettant de spcifier les
aspects d5nami&ues ainsi &ue les
contraintes lies 7 larchitecture#
)e mod+le doit garantir une
projection cohrente de la projection cohrente de la
spcification abstraite de
larchitecture vers la description de
son implantation avec diffrents
niveaux de raffinements#
La smanti&ue dun composant
sapparente 7 la notion de t5pe dans le sapparente 7 la notion de t5pe dans le
mod+le orient objet#
Les contraintes dun composant :
Les contraintes dfinissent les limites
dutilisation dun composant et ses dutilisation dun composant et ses
dpendances intra composants#
1ne contrainte est une proprit devant
<tre obligatoirement vrifie sur un <tre obligatoirement vrifie sur un
s5st+me ou une de ces parties#
%i celle$ci est viole, le s5st+me est
considr comme un s5st+me incohrent
et inacceptable#
>lles permettent ainsi de dcrire de
mani+re explicite les dpendances des
parties internes dun composant
mani+re explicite les dpendances des
parties internes dun composant
comme la spcification de la
s5nchronisation entre composants
dune m<me application *dpendance
intra composant-
Lvolution dun composant :
Les composants sont conDus pour <tre des
lments de conception &ui voluent#
1n ABL doit favoriser la modification de 1n ABL doit favoriser la modification de
ses proprits *interface, comportement,
implantation- sans perturber son
intgration dans les applications dj7
existantes#
Lvolution dun composant :
Lvolution doit donc <tre simple et
seffectuer par le biais de techni&ues seffectuer par le biais de techni&ues
comme le sous t5page ou le
raffinement
Les proprits non fonctionnelles dun
composant : *proprits lies 7 la
scurit, la performance, la portabilit- scurit, la performance, la portabilit-
composant : >lles doivent <tre exprimes
7 part, permettant ainsi une sparation
dans la spcification du composant des dans la spcification du composant des
aspects fonctionnels *aspects mtiers de
lapplication- et des aspects non
fonctionnels ou techni&ues *aspects
transactionnel, de cr5ptographie, de
&ualit de service-
composant : )ette sparation permet
la simulation du comportement dun
composant 7 lexcution d+s la phase composant 7 lexcution d+s la phase
de conception, et de la vrification de
la validit de larchitecture logicielle
par rapport 7 larchitecture matrielle
et lenvironnement dexcution
Le composant,
Le connecteur,
Le connecteur : il correspond 7 un
lment darchitecture &ui modlise
de mani+re explicite les interactions de mani+re explicite les interactions
entre un ou plusieurs composants en
dfinissant les r+gles &ui gouvernent
ces interactions#
Le connecteur : Par exemple :
un connecteur peut dcrire des
interactions simples de t5pe appel de interactions simples de t5pe appel de
procdure ou acc+s 7 une variable
partage,
Le connecteur : Par exemple :
mais aussi des interactions complexes
telles &ue des protocoles dacc+s 7
des bases de donnes avec gestion
telles &ue des protocoles dacc+s 7
des bases de donnes avec gestion
des transactions, la diffusion
dvnements as5nchrones ou encore
lchange de donnes sous forme de
flux#
Le connecteur : 1n connecteur
comprend galement deux parties:
$ La premi+re correspond 7 la partie $ La premi+re correspond 7 la partie
visible du connecteur *son interface-
$ La seconde partie correspond 7 la
description de son implantation#
Le connecteur : La seconde partie
correspond 7 la description de son
implantation# implantation#
?l sagit l7 de la dfinition du protocole
permettant la mise en ;uvre du
protocole associ 7 linteraction#
Le connecteur : Le connecteur ne
correspond pas ncessairement 7 une
seule unit dimplantation,
contrairement au composant, mais peut
<tre associ 7 plusieurs lments# <tre associ 7 plusieurs lments#
Par exemple, dans le cas dune
communication de t5pe 0P), le
connecteur correspond 7 la fois au talon
c,t client, au s&uelette c,t serveur et
au rseau de transport#
Le connecteur : A contrario, elle peut ne
pas reprsenter lunit dimplantation#
>lle peut aussi se traduire par une
re&u<te %WL entre une application et re&u<te %WL entre une application et
une base de donnes, par une variable
partage, par le partage dune file de
messages, ou toute autre forme
dimplantation#
Le connecteur : Le connecteur
permet galement de vrifier
lintgrit de la communication, cest$
7$dire de vrifier &ue les composants 7$dire de vrifier &ue les composants
peuvent <tre connects# Ainsi, il
permet la rutilisation et ladaptation
des interfaces de composants dj7
existants &ue lon cherche 7 relier#
Le connecteur : %ix caractristi&ues
importantes dfinies par 'edvidovic
et /a5lor sont 7 prendre en compte et /a5lor sont 7 prendre en compte
pour spcifier de mani+re exhaustive
un connecteur# )es caractristi&ues
sont les suivantes :
Le connecteur :
)es caractristi&ues sont les suivantes :
$ linterface,
$ le t5pe, $ le t5pe,
$ la smanti&ue,
$ les contraintes,
$ la maintenance volutive dun connecteur,
$ les proprits non fonctionnelles#
Le connecteur : L.interface
L.interface dun connecteur dfinit les points
dinteractions entre connecteurs et
composants#
Linterface ne dcrit pas des services Linterface ne dcrit pas des services
fonctionnels comme ceux du composant
mais sattache 7 dfinir des mcanismes de
connexion entre composants# )ertains ABLs
nomment ces points dinteractions comme
tant des r,les#
Le connecteur : Le 9(pe 1 Le t5pe dun
connecteur correspond 7 sa dfinition abstraction
&ui reprend les mcanismes de communication
entre composants ou les mcanismes de dcision
de coordination et de mdiation#
?l permet la description dinteractions simples ou ?l permet la description dinteractions simples ou
complexes de mani+re gnri&ue et offre ainsi
des possibilits de rutilisation de protocoles# Par
exemple, la spcification dun connecteur de t5pe
0P) &ui relie deux composants dfinit les r+gles
du protocole 0P)
Le connecteur : La smantique )omme pour les
composants, la smanti&ue des connecteurs est
dfinie par un mod+le de haut niveau spcifiant
le comportement du connecteur#
A loppos de la smanti&ue du composant &ui
doit exprimer les fonctionnalits dduites des
A loppos de la smanti&ue du composant &ui
doit exprimer les fonctionnalits dduites des
buts ou des besoins de lapplication, la
smanti&ue du connecteur doit spcifier le
protocole dinteraction# Be plus, celui$ci doit
pouvoir <tre modlis et raffin lors du passage
dun niveau de description abstraite 7 un niveau
dimplantation#
Le connecteur : Les contraintes : Les contraintes
permettent de dfinir les limites dutilisation dun
connecteur, cest$7$dire les limites dutilisation du
protocole de communication associ# 1ne
contrainte est une proprit devant <tre vrifie
sur un s5st+me ou sur lune de ses parties# %i sur un s5st+me ou sur lune de ses parties# %i
celle$ci est viole, le s5st+me est considr
comme un s5st+me incohrent et inacceptable#
Par exemple, le nombre maximum de
composants interconnects 7 travers le
connecteur peut <tre fix et correspond alors 7
une contrainte#
Le connecteur : La maintenance volutive dun
connecteur : Le changement des proprits
*interface, comportement- dun connecteur doit
pouvoir voluer sans perturber son utilisation et
son intgration dans les applications existantes# ?l
sagit de maximiser la rutilisation par sagit de maximiser la rutilisation par
modification ou raffinement des connecteurs
existants# 1n ABL donnant la possibilit de dfinir
un connecteur doit donc permettre de le faire
voluer de mani+re simple et indpendante en
utilisant le sous t5page ou des techni&ues de
raffinement#
Le connecteur : Les proprits non
fonctionnelles : Les proprits non fonctionnelles
dun connecteur concernent tout ce &ui ne
dcoule pas directement de la smanti&ue du
connecteur# >lles spcifient des besoins &ui
viennent sajouter 7 ceux dj7 existants et &ui viennent sajouter 7 ceux dj7 existants et &ui
favorisent une implantation correcte du
connecteur#
La spcification de ces proprits est importante
puis&uelle permet de simuler le comportement 7
lexcution, lanal5se, la dfinition de contraintes
et la slection des connecteurs
Le composant,
Le connecteur,
>t la configuration ou la topologie :
Les configurations darchitecture dapplication,
encore appeles topologies, dfinissent les
proprits architecturales de connectivit et proprits architecturales de connectivit et
de conformit aux heuristi&ues de conception,
ainsi &ue des proprits de concurrence et de
rpartition *dans certains ABLs-#
1ne configuration dfinit la structure et le
comportement dune application forme de
composants et de connecteurs# composants et de connecteurs#
1ne composition de composants, appele
dans certains contextes composite, est une
configuration#
La configuration structurelle de lapplication
correspond 7 un graphe connexe des
composants et des connecteurs formant composants et des connecteurs formant
lapplication# >lle dtermine les composants et
les connecteurs appropris 7 lapplication et
vrifie la correspondance entre les interfaces
des composants et des connecteurs#
La configuration comportementale, &uant 7
elle, modlise le comportement en dcrivant
lvolution des liens entre composants et lvolution des liens entre composants et
connecteurs, ainsi &ue lvolution des
proprits non fonctionnelles comme les
proprits spatio$temporelles ou la &ualit de
service#
>lle dfinit galement le schma linstanciation
des composants au moment de linitialisation
de lapplication, ainsi &ue le placement des de lapplication, ainsi &ue le placement des
composants sur les sites au moment du
dmarrage du s5st+me et leur volution
pendant la vie de lapplication
3euf caractristi&ues sont prcises par
'edvidovic et /a5lor pour valuer la 'edvidovic et /a5lor pour valuer la
configuration dun ABL#
$ un formalisme commun,
$ la composition, $ la composition,
$ le raffinement et la traDabilit,
$ lhtrognit,
$ le passage 7 lchelle,
$ lvolution de la configuration,
$ laspect d5nami&ue de lapplication,
$ les contraintes,
$ les proprits non$fonctionnelles#
Un formalisme commun :
1ne configuration doit permettre de fournir une s5ntaxe simple
et une smanti&ue permettant de
$ faciliter la communication entre les diffrents partenaires dun
projet *concepteurs, dveloppeurs, testeurs, architectes-,
$ rendre comprhensible la structure dune application 7 partir
de la configuration sans entrer dans le dtail de cha&ue
composant et de cha&ue connecteur,
$ spcifier la d5nami&ue dun s5st+me, cest$7$dire lvolution de
celui$ci au cours de son excution#
La composition : La dfinition de la configuration dune application
doit permettre la modlisation et la reprsentation de la composition
7 diffrents niveaux de dtail# La notion de configuration spcifie une
application par composition hirarchi&ue# Ainsi un composant peut
<tre compos de composants, cha&ue composant tant spcifi lui$ <tre compos de composants, cha&ue composant tant spcifi lui$
m<me de la m<me mani+re, jus&uau composant dit primitif, cest$7$
dire non dcomposable# Lintr<t de ce concept est &uil permet la
spcification de lapplication par une approche descendante par
raffinement, allant du niveau le plus gnral form par les
composants et les connecteurs principaux, dfinis eux m<mes
par des groupes de composants et de connecteurs, jus&uaux dtails
de cha&ue composant et de cha&ue connecteur primitifs#
Le raffinement et la traa!ilit : La configuration est
galement un mo5en de permettre le raffinement de
lapplication dun niveau abstrait de description gnral
vers un niveau de description de plus en plus dtaill, et, vers un niveau de description de plus en plus dtaill, et,
ceci, 7 cha&ue tape du processus de dveloppement
*conception, implantation, dploiement-# Ainsi il est
possible, par la dfinition de la configuration, de garder
trace de ce &ui a t fait en amont, et de crer des liens
entre les diffrents niveaux de description de lapplication#
)ette caractristi&ue permet le rapprochement entre les
mod+les de haut niveau et le code#
Lhtro"nit : La configuration dun ABL doit
permettre le dveloppement de grands
s5st+mes avec des lments prexistants de s5st+mes avec des lments prexistants de
caractristi&ues diffrentes#
LABL doit <tre capable de spcifier une
application indpendamment du langage de
programmation, du s5st+me dexploitation et du
langage de modlisation#
Le passa"e # lchelle :
Les ABLs se doivent de proposer une
modlisation de s5st+mes &ui peuvent grossir modlisation de s5st+mes &ui peuvent grossir
en taille#
?l sagit de prvoir le nombre dinstances et leur
placement dans un environnement ainsi &ue
la d5nami&ue de lapplication#
Lvolution de la confi"uration :La configuration
doit <tre capable dvoluer pour prendre des
nouvelles fonctionnalits impli&uant une nouvelles fonctionnalits impli&uant une
modification ou une volution de la structure
de lapplication# >lle doit permettre de faire
voluer larchitecture dune application de
mani+re incrmentale, cest$7$dire par ajout ou
retrait de composants et des connecteurs#
Laspect dynamique de lapplication : La
configuration dune application doit permettre la
modification 7 lexcution de s5st+mes demandant modification 7 lexcution de s5st+mes demandant
des temps dexcution longs ou pouvant
difficilement <tre stopps# >lle doit spcifier le
comportement d5nami&ue de lapplication, cest$7$
dire les changements de lapplication &ui peuvent
arriver pendant son excution comme la cration,
ou la suppression dinstances de composants#
Les contraintes :
Les contraintes lies 7 la configuration viennent en
complment des contraintes dfinies pour complment des contraintes dfinies pour
cha&ue composant et cha&ue connecteur#
Les contraintes :
>lles dcrivent les dpendances entre les composants
et les connecteurs et concernent des caractristi&ues et les connecteurs et concernent des caractristi&ues
lies 7 lassemblage de composants &ue lon &ualifie de
contraintes inter composants#
La spcification de ces contraintes permet de dfinir
des contraintes dites globales, sappli&uant 7 tous les
lments de lapplication#
Les proprits non fonctionnelles : )ertaines
proprits non fonctionnelles ne concernant ni
les connecteurs et ni les composants doivent les connecteurs et ni les composants doivent
<tre exprimes au niveau de la configuration#
)es contraintes sont lies 7 lenvironnement
dexcution# 1n ABL doit donc <tre capable de
spcifier ces contraintes au niveau de la
configuration#
logicielles
fondamentaux,
: $b %olutions apportes par les diffrents
langages de description dArchitecture :
Les langages de description darchitecture sont
des langages dits dclaratifs#
?ls peuvent <tre
classs en deux grandes familles :
: $b %olutions apportes par les X ABLs :
Beux grandes familles :
6# La premi+re correspond aux langages &ui
privilgient la description des lments de
larchitecture et leur assemblage structurel, larchitecture et leur assemblage structurel,
:# la seconde dfinit les langages &ui se
centrent sur la description de la
configuration dune architecture et sur la
d5nami&ue du s5st+me#
La premi+re famille de langages correspond 7
une famille de langages &ui est accompagne :
doutils de modlisation, doutils de modlisation,
danal5seur s5ntaxi&ue
et de gnrateur de code#
La deuxi+me famille de langages regroupe des
langages accompagns doutils de modlisation
et de gnration de code mais aussi dune et de gnration de code mais aussi dune
plate$forme dexcution ou de simulation dun
s5st+me, voire de modification d5nami&ue
pendant lexcution#
La particularit de ces langages :
est de dfinir un lment dune architecture
*composant ou connecteur- comme une *composant ou connecteur- comme une
instance#
?l devient alors facile et simple de spcifier
lvolution d5nami&ue dune application au
cours de son excution
3ous allons dans cette section prsenter
les !Ls les plus connus, et nous
donnerons leurs avantages et leurs donnerons leurs avantages et leurs
inconvnients :
1ni)on, Aesop, Bar!in, ):, Qright,
0apide, OLA3 et A)'>##
1ni)on : E 1niversal )onnector %upport F
>st un langage de description
darchitecture ,
)re par luniversit de )arnegie )re par luniversit de )arnegie
'ellon en Penns5lvanie, 1%A
Le concepteur principal est G# Yelesni"
1ni)on : La dclaration s5ntaxi&ue dun
composant se fait de la mani+re suivante :
C:%':;E;9 $ame
<;9ER$!CE <6
9='E Component%ype
Z Liste des proprits du composant/5pe [ Z Liste des proprits du composant/5pe [
Z Liste des Plaers du composant!
E; <;9ER$!CE
<%'LE%E;9!9<:; <6
Z Liste de Proprits [
?mplementation Primitive \ ?mplmentation )omposite
E; <%'LE%E;9!9<:;
E; $ame
1ni)on : La dclaration s5ntaxi&ue dun
connecteur se fait de la mani+re suivante :
C:;;EC9:R $ame
'R:9:C:L <6
9='E Connector%ype
Z Liste des proprits du connecteur/5pe [ Z Liste des proprits du connecteur/5pe [
Z Liste des r"les du composant! #
R:LE $om&ole '( &ole%ype
Z Liste des proprits de dfinition du r,le tel &ue le nombre
composants connects [
E; R:LE
E; 'R:9:C:LE
<%'LE%E;9!9<:; <6
41?L/?3
E; <%'LE%E;9!9<:;
E; $ame
1ni)on :Avanatages:
acilite lintgration de logiciels existants
Langage est associ 7 un environnement complet,
Avec diteur graphique permettant de dfinir des
composants et des connecteurs 1ni)on et de dcrire la composants et des connecteurs 1ni)on et de dcrire la
structure dune architecture sous forme de graphe de
connexion entre composants et connecteurs ainsi &ue
lassemblage,
un anal(seur s5ntaxi&ue,
un compilateur permettant de vrifier la bonne
utilisation des lments du mod+le,
inalement un gnrateur de code en langage )
1ni)on : ?nconvinients :
3est pas un langage homog+ne pour la description des
interfaces *Bpendance au langage de programmation-
Pas possible dajouter un nouveau t5pe de connecteur ou
de composant au mod+le de t5pe9
'od+le de t5pe : pas suffisamment abstrait et reste
dpendant de limplantation,
'od+le de t5pe : pas suffisamment abstrait et reste
dpendant de limplantation,
le schma de cration Nsuppression des composants nest
pas possible#
Les mo5ens pour spcifier des proprits non
fonctionnelles des composants ou des connecteurs ne sont
pas nombreux,
La &ualit de service, les aspects scurit et dautres
aspects sont omis
Aesop :
La particularit de Aesop est de permettre la
dfinition de plusieurs st5les darchitectures,
chacun tant propre 7 un domaine comme par chacun tant propre 7 un domaine comme par
exemple le domaine du temps rel#
Aesop :
Elments gnriques d$une description
d$architecture #
Aesop :
%lasses orientes o&'et reprsentant les tpes
des lments composant un stle
d$architecture # d$architecture #
Aesop : (escription du stle d$architecture du
filtre Pipe and )ilter
Aesop : la structure d$un environnement Aesop
Bar!in: souvent appel langage de configuration
1n langage de configuration favorise la description de la
configuration dune application, cest$7$dire la description
des interactions entre composants#
1n langage de configuration favorise la 1n langage de configuration favorise la
description de la configuration dune application,
cest$7$dire la description des interactions entre
composants#
Bar!in: souvent appel langage de configuration
La description dun composant au niveau du langage
permet de crer de multiples instances dun
composant lors de lexcution#
Ainsi, ce t5pe de langage se centre sur la description
de la configuration et sur lexpression du de la configuration et sur lexpression du
comportement dune application plut,t &ue sur la
description structurelle de larchitecture dun s5st+me
comme le font beaucoup dABLs *1ni)on, 2-#
La particularit de Bar!in est donc de permettre la
spcification dune partie de la d5nami&ue de
lapplication en terme de schma de cration de
composants logiciels avant, apr+s ou en cours
dexcution#
0apide :
est un langage de description darchitecture
dont le but est de vrifier, par la simulation, la
validit dune architecture logicielle donne# validit dune architecture logicielle donne#
0apide :
Avec le langage 0apide, une application est
construite 7 partir de modules ou de
composants communi&uant par change de composants communi&uant par change de
messages ou dvnements# 0apide fournit
galement un environnement compos dun
simulateur permettant de vrifier la validit
de larchitecture
Qright :
Qright est un langage darchitecture
logicielle &ui se centre sur la spcification de
larchitecture et de ses lments# larchitecture et de ses lments#
?l n5 a pas de gnrateur de code, ni de
plate$forme permettant de simuler
lapplication comme pour 0apide#
?l repose sur &uatre concepts &ui sont le
composant, le connecteur, la configuration
et le st5le#
): :
): est un langage de description darchitecture
conDu par luniversit 1)? en )alifornie# ?l fut
conDu, 7 lorigine pour la conception des interfaces
graphi&ues et stend aujourdhui 7 la conception graphi&ues et stend aujourdhui 7 la conception
dautres applications#
?l propose une mani+re de spcifier une
architecture similaire 7 la plupart des ABLs# >n
effet, il poss+de trois abstractions principales &ui
sont le composant, le connecteur et la
configuration dune architecture#
Olan :
est un langage de configuration labor par
l?30?A 0h,ne$Alpes dans le cadre du projet
%?0A)# %?0A)#
%on but principal est de fournir un
environnement complet pour la
construction, la configuration et le
dploiement dapplications rparties#
A)'>:
?l a pour buts principaux de fournir un langage
pivot &ui prend en compte les caractristi&ues
communes de lensemble des ABLs, &ui soit communes de lensemble des ABLs, &ui soit
compatible avec leurs terminologies et &ui
propose un langage permettant dintgrer
facilement de nouveaux ABLs#
Comparaison des diffrents !Ls prsents :
logicielles
fondamentaux,
logicielles
. $ )onception d1ne Architecture
Logicielle
Prise en compte des besoins fonctionnels et
non fonctionnels
)hoix dune solution Architecturale )hoix dune solution Architecturale
Problmati&ue de la rutilisation et de la
composition
logicielles
A $ Architectures Orientes %ervices *%OA-
%ervices , ?nterfaces,
)ontrats de service,
)omposition de services et Processus#
logicielles
?3 ?3

Architecture Logicielle - V02 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architecture Logicielle - V02 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Vous aimerez peut-être aussi