Vous êtes sur la page 1sur 48

Conception

1. Nature de la conception

2. Conception architecturale

3. Conception dtaille
Hafedh Mili Copyright 1999-2007

Conception architecturale
Introduction
Dfinitions
Architectures et critres de qualit de
systmes,
Tactiques pour atteindre les qualits
architecturales
Styles/patrons architecturaux
Hafedh Mili Copyright 1999-2007

Introduction
Client: Jai besoin dun systme de
commerce lectronique pour la vente de
mes produits
Ingnieur: Hum je peux assembler des
composantes qui trient, qui grent des files,
des listes, etc.
Client: Comment ces composantes l vont
rpondre mes besoins
Ingnieur: un trs bas niveau. Il faudra voir
comment on va les utiliser
Hafedh Mili Copyright 1999-2007

Architecture (introduction)
Le gnie logiciel souffre dun manque de
concepts intermdiaires entre objectifs
stratgiques et structures de donnes
Larchitecture intgre les exigences
fonctionnelles avec les exigences daffaire
dune organisation

Hafedh Mili Copyright 1999-2007

Architectures: une 1re dfinition


Une architecture est lexpression des
premires dcisions de conception
concernant la dcomposition dun systme
en parties [Bass, Clements & Kazman,03]
Larchitecture dun logiciel dfinit le
logiciel en terme de composantes et
dintractions entre composantes [Shaw &
Garlan, 96]
Hafedh Mili Copyright 1999-2007

Architecture: une confluence


dinfluences

Dveloppement et
maintenance:
faible cot,
prserver
les emploies

Usager final:
fonctionnalits,
performance,
scurit, fiabilit

Client: faible cot


Marketing:
dacquisition,
fonctionnalit,
dopration, et
faible prix de vente, dvolutrion
time-to-market,
diffrentiation

Hafedh Miliarchitecte
Copyright 1999-2007

ABC: Architecture Business


Cycle [Bass et al., 2003]

Client et usager final


Organization

Exigences
(proprits)

Environnement technique
Exprience de larchitecte

Architecture

Systeme

Hafedh Mili Copyright 1999-2007

Les influences
Larchitecture influence la structure
organisationnelle de dveloppement et
rciproquement
Peut influencer le client (sacrifier quelques
fonctionnalits pour dautres qualits)
Fait voluer lexprience de larchitecte
Peut faire voluer les objectifs stratgiques
Hafedh Mili Copyright 1999-2007

Cycle de dveloppement

Business case
Exigences
Concevoir/slectionner larchitecture
Dcrire et communiquer larchitecture aux
stakeholders (joueurs)
Analyser/valuer larchitecture
Implanter le systme en se basant sur
larchitecture
Vrifier que limplantation est conforme
larchitecture Hafedh Mili Copyright 1999-2007

Comment faire une bonne


architecture (processus)?
Vision (une personne ou un petit groupe)
Exigences techniques claires, et une
priorization des proprits dsires,
Bien documente et bien circule /
communique / explique
Architecture doit tre analyse et value
pour proprits quantitatives (e.g.
throughput) et qualitatives (ouverture,
volutivit)
Doit supporter le dveloppement
Mili Copyright 1999-2007
incrmental Hafedh
partir
dune skelette

10

Quest ce quune bonne


architecture? (produit)
Fonctionnalit distribue selon les principes de la
sparation of concerns et dissimulation de linformation,
Doit supporter le dveloppement en parallle
Doit isoler les spcificits de la plateforme ou de produits
commerciaux,
Doit tre simple et uniforme,
Doit sparer les modules qui produisent des donnes de
ceux qui les consomment,
Doit sparer la structure de modules (statique) de la
structure de tches (dynamique)
Doit affecter les tches aux processeurs de faon flexible
(voire dynamique)
Hafedh Mili Copyright 1999-2007

11

Conception architecturale
Introduction
Dfinitions
Architectures et critres de qualit de systmes
Tactiques pour atteindre les qualits
architecturales
Styles architecturaux

Hafedh Mili Copyright 1999-2007

12

Dfinitions
Larchitecture dun programme ou systme
informatique est:
la structure ou lensemble des structures du
systme, qui est (sont) compose(s) de
composantes logicielles
Les proprits visibles de ces composantes,
Les relations entre ces composantes l.
Hafedh Mili Copyright 1999-2007

13

Une architecture dun logiciel de


simulation
Control
Process
(CP

Prop Loss

Model
(PLM)

Reverb
Model
(MODR)

Hafedh Mili Copyright 1999-2007

Noise
Model
(MODN)

14

Ce que le dessin ne disait pas:


De quel type de composantes (modules?
Processus, tches), il sagit?
Quelle est la nature des liens
(communication, contrle, change de
donnes, appel),
Plus dautres questions , une fois quon aura
rpondu ces deux l.
Hafedh Mili Copyright 1999-2007

15

Styles, modles de rfrences, et


architectures de rfrences
Un style ou patron architectural est une
description dun type de composantes et
dun patron de contrle et de
communication entre composantes
Un modle de rfrence est une
dcomposition fonctionnelle dun
systme (e.g., dune analyse du domaine)
Une architecture de rfrence est la
correspondence dun modle de rfrence
Hafedh Mili Copyright 1999-2007
16
un style architectural

Style, modle de rfrences, et


architectures
Modle de
rfrence

Architecture de
rfrence

Architecture de
systme

Style
architectural

Hafedh Mili Copyright 1999-2007

17

Structures architecturales
Structure de modules: un module est une
unit de travail avec livrables (interface,
code, plan de test). La relation est
laggrgation/dpendance
Structure logique/conceptuelle: les lments
sont des composantes fonctionnelles. La
relation est partage/change de donnes. Le
modle de rfrence en est un exemple.
Hafedh Mili Copyright 1999-2007

18

Structures architecturales (suite)


Structure de processus/coordination: vue
run-time, orthogonale aux deux
prcdentes. Relation: synchronisation,
peut-pas-rouler-sans, peut-pas-avec,
etc.
Structure physique: lallocation du logiciel
au matriel (systmes distribus).
Composantes: hardware, liens:
communication (sert valider perf., etc.)
Hafedh Mili Copyright 1999-2007

19

Structures architecturales (suite)


Structure uses: les units = procdures ou
modules, liens = dpendences
fonctionnelles/de service.
Structure dappel: appel entre procdures
Flux de donnes: les units sont des
modules, le lien est dchange de donnes
Flux de contrle: units = programmes,
modules, ou tats. Liens: devient-actifaprs. Pour validation comportementale,
timing, etc.
Structure de classes: classes et hritage.
Hafedh Mili Copyright 1999-2007

20

10

Structures architecturales (suite)


S tru ctu re
M o d u le

U n its
T ch es d e
trav ail

C o n cep tu e F o n ctio n s
lle

R ela tio n s
S o u s-m o d u le d e

P artag e d es
d o n n es av e c

U tilit
A llo catio n d e resso u rces ,
stru ctu ration et p lan ificatio n
d e p ro jets, co n t le d e
co n figu ratio n
C o m p ren d re le d o m ain e
d ap p licatio n

P ro cessu s

P ro gram m e R o u le-en -//s


av ec, ex clu e,
p rcd e, etc.

A n alyse d e la gen cem en t d es


tch es, an alyse d e
p erfo rm an ce

P h ysiq u e

H ard w are

P erfo rm an c e, s cu rit,
fiab ilit

C o m m u n iq ueav ec

Hafedh Mili Copyright 1999-2007

21

Structures architecturales (suite)


Structure Units
Relations
Uses
Programme Exigence les
s
services de
/dpend de

Utilit
Concevoir des sous-produits,
des extensions

Appel

Programme Appelle
s

Analyse de performance

Flux
donnes

Fonctions

Trace dexigences
fonctionnelles

Flux de
contrle

tats du
Dclenche,
systme ou transite-, etc.
modules
Objets
Is-a, partage

Classes

Envoie des
donnes

Simulation, vrification de
proprits dynamiques, etc.
Dans les systmes OO, c st
aussi la conception dtaille

Hafedh Mili Copyright 1999-2007

22

11

Structures architecturales (fin)


Diffrents systmes requirent diffrentes
combinaisons de structures de
reprsentation
Certaines structures peuvent coincider pour
le cas de systmes de petite taille
Il faut assurer le lien entre ces structures l.

Hafedh Mili Copyright 1999-2007

23

Conception architecturale
Introduction
Dfinitions
Architectures et critres de qualit de systmes
Tactiques pour atteindre les qualits
architecturales
Styles architecturaux

Hafedh Mili Copyright 1999-2007

24

12

Les attributs de qualit


Il faut distinguer entre:
Attributs/proprits du systme, qui sont
dues larchitectures, et attributs
intrinsques de larchitecture elle-mme,
Qualits observables lxcution de celles
qui ne le sont pas,
Qualit technique versus qualit daffaires
(business quality).
Hafedh Mili Copyright 1999-2007

25

Attributs de qualit visible


lexcution
Performance: temps de rponse un
stimulus, ou taux de traitement
Scurit: capacit du systme rsister
lattaque, et continuer offrir un service
normal aux usagers lgitimes
Disponibilit: elle est dfinie comme:
(temps moyen entre pannes)/(temps moyen
entre pannes + temps rparation)
Hafedh Mili Copyright 1999-2007

26

13

Attributes de qualit visibles


lxcution
Fonctionnalit: capacit du systme faire
ce qui etait demand
Utilisabilit:

Facilit dapprentissage
Efficacit
Facilit de mmoriser les commandes
Prvention derreurs
Traitement derreur (recoverability)
Satisfaction de lusager
Hafedh Mili Copyright 1999-2007

27

Attributs de qualit non-visibles


lexcution
Modifiabilit: Cest la pt qui dpend le +
de larchitecture (localit de changements):
Quatre scnarios dvolution:
Extension ou changement de fonctionnalits,
liminer certaines fonctionnalits (version light)
Adaptation un nouvel environnement (portabilit,
voir plus bas)
Restructuration (e.g. pour la performance, la
rutilisation, etc.)
Hafedh Mili Copyright 1999-2007

28

14

Attributs de qualit non-visibles


lexcution (suite)
Modifiabilit: (suite)
Quatre envergures de changements:

Changement dans une composante,


Changement dans plusieurs composantes,
Changement dans linfrastructure,
Changement de style.

Portabilit: adaptabilit diffrents


environnements dopration/excution
Hafedh Mili Copyright 1999-2007

29

Attributs de qualit non-visibles


lexcution (suite)
Rutilisabilit: on parle de rutilisabilit de
composantes (qui dpend de larchitecture),
et de rutilisabilit de larchitecture-mme,
Intgrabilit: permettre des composantes
dveloppes sparment dinter-oprer
(dpend des interfaces des composantes)
Testabilit: relie la controllabilit et
observabilit du comportement des
composantes.
Hafedh Mili Copyright 1999-2007

30

15

Attributs de qualit: rsum


Attribut

Architect Considrations architecturales


ural?
Proprits observables lxcution
Performance

Oui

Communication entre composantes, sparation


fonctionnelle pour paralllisme

Scurit

Oui

Disponibilit

Oui

Composantes spcialises, e.g. serveurs


dauthentification
Tolrance aux fautes, redondance, contrle
dintraction de composantes

Fonctionnalit Non

Intraction avec les autres attributs de qualit

Utilisabilit

Modifiabilit facilite latteinte de lutilisabilit;


assurer le bon transfert dinformation

Oui

Hafedh Mili Copyright 1999-2007

31

Attributs de qualit: rsum


Attribut

Architect Considrations architecturales


ural?
Proprits non-observables lxcution
Modifiabilit

Oui

Modulariser/encapsuler les composantes

Portabilit

Oui

Couche de portabilit

Rutilisabilit

Oui

Faible couplage entre composantes

Intgrabilit

Oui

Mcanismes dinterconnection simples et


uniformes, dpendences non-circulaires,

Testabilit

Oui

Modulariser/encapsuler les composantes,


dpendences non-circulaires.
Hafedh Mili Copyright 1999-2007

32

16

Attributs de qualit orientsaffaires


Temps de mise en march: pression =>
construction partir de composantes =>
architectures ouverte, mme si non idale,
Cot: (de dveloppement)
Dure de vie projete du systme
March cible (e.g. march Microsoft, march
open-source)
Stratgie de commercialisation: (e.g. version
vanille + saveurs => modifiabilit)
Intgration avec systmes lgataires
Hafedh Mili Copyright 1999-2007

33

Qualits de larchitecture
Les (attributs de) qualits vues date
concernent le produit final; diffrents choix
vont permettre datteindre ces qualits l
plus ou moins bien
Les qualits de larchitecture sont
intrinsques, indpendamment de toute
qualit quelle pourra inculquer un produit
donn
Hafedh Mili Copyright 1999-2007

34

17

Qualits de larchitecture
Intgrit conceptuelle: cohrence, thme
dominant, quitte abandonner certaines
features,
Compltude et correctness: rpond
toutes les exigences, et efficacement,
Faisabilit: en tenant compte des
ressources, et autres contraintes.
Hafedh Mili Copyright 1999-2007

35

Atteindre les qualits architecturale


Les qualits architecturales prsentes
prcdemment sont trop vagues pour tre
oprationnelles.
Exemple: Modifiabilit
On ne peut tre contre la vertu
La modifiabilit a un cot sur les autres qualits
(e.g. performance)
Hafedh Mili Copyright 1999-2007

36

18

Atteindre les qualits architecturales


Modifiabilit (suite)
Un systme peut tre assujetti plusieurs types
de changements
Lesquels parmi ces changements doit-on
pouvoir raliser facilement
Diffrentes tactiques peuvent tre utilises pour
accommoder diffrents types de changements

Comment quantifier ce facilement ?


Hafedh Mili Copyright 1999-2007

37

Scnario attribut qualit (1/)


Une faon prcise de dcrire une exigence
architecturale en terme dattribut qualit:
Globalement, un scnario consiste imaginer un
vnement (stimulus) qui affecte le systme (e.g.
une nouvelle exigence fonctionnelle), la partie du
systme qui en sera affecte (artfact), le travail
faire pour accommoder lvnement (e.g. une
tche de maintenance), et la mesure souhaite
(exige) de ce travail (e.g. 1 personne/semaine)
Hafedh Mili Copyright 1999-2007

38

19

Scnario dattribut qualit (2/)


Prcisment, un scnario dattribut qualit est dfini par:
Source de stimulus: entit (personne, un autre systme) (e.g. le
client)
Stimulus: lvnement/situation qui doit tre considre quand elle
atteint le systme (e.g. une nouvelle exigence fonctionnelle)
Environnement: contexte dans lequel le stimulus peut se produire
(e.g. systme en production)
Artfact: la partie du systme qui est touche par le stimulus
Rponse: ce que lon/le systme doit faire pour ragir au stimulus
Mesure de la rponse: une faon de mesurer la rponse (e.g., en
jours-personne de travail) pour vrifier si lexigence (de lattribut
qualit) est respecte
Hafedh Mili Copyright 1999-2007

39

Scnario dattributs qualit (3/)


Deux types de scnarios:
Scnarios gnriques: prcise les valeurs
possibles pour chaque aspect (source stimulus,
stimulus, environnement, artfact, rponse, et
mesure).
Scnario concret: une instanciation du scnario
gnrique pour le systme sous considration

Hafedh Mili Copyright 1999-2007

40

20

Exemple: disponibilit (4/)


Scnario gnrique
Aspect

Valeurs possibles

Source

Externe, interne

Stimulus

Omission, crash, timeout, rsultat incorrect

Environnement

Normal, dgrad

Artfact

Processus, mmoire, processeur, lien de communication

Rponse

record, notification, dsactiver, continuer (normal/dgrad), devenir non disponible

Mesure

Temps de rparation, disponibilit, temps pass en mode dgrad

Scnario concret:
Source

Stimulus

Environnement

Artfact

Rponse

Externe

Message
inattendu

Mode dopration
normal

processus Informer oprateur et


continuer normal

Mesure
Pas de temps
darrt

Hafedh Mili Copyright 1999-2007

41

Modifiabilit
Aspect

Valeurs possibles

Source

Usager final, dveloppeur, administrateur systme

Stimulus

Ajouter/retirer/modifier une fonctionnalit, modifier attribut de qualit,


modifier capacit (e.g., augmenter nombre dusagers)

Environnement lexcution, durant le build , la compilation (compile-time), durant


/contexte
la conception
Artfact

Interface usager, plateforme, environnement, un systme qui interagit avec


notre systme

Rponse

Localiser les lments dans larchitecture qui doivent tre modifis, faire
modification sans affecter les autres fonctions, tester les modifications,
dployer la version modifie

Mesure

Cot en terme de, i) nombre dlments affects, ii) effort, iii) argent; la
mesure dans laquelle cela affecte dautres fonctions ou qualits
Hafedh Mili Copyright 1999-2007

42

21

Performance
Aspect

Valeurs possibles

Source

Sources indpendantes, possiblement internes au systme

Stimulus

vnements priodiques; vnements sporadiques; vnements


stochastiques

Environnement Mode normal; mode en surcharge


/contexte
Artfact

Systme

Rponse

Traiter lvnement; changer le niveau/mode de service

Mesure

Temps de rponse, temps maximal de rponse, dbit, jitter , taux


dchec ( miss rate ), perte de donnes

Hafedh Mili Copyright 1999-2007

43

Scurit
Aspect

Valeurs possibles

Source

Personne ou systme qui est, 1) identifi correctement, incorrectement, ou inconnu, 2)


interne/externe, autoris/non-autoris, 3) avec accs des ressources limits ou non

Stimulus

Tentative de, 1) afficher des donnes, 2) modifier/effacer des donnes, 3) accder


des services/fonctionnalits du systme, 4) rduire la disponibilit du systme

Env/contexte

On-line/off-line, connect ou dconnect, ouvert ou derrire un pare-feu

Artfact

Fonctionnalits/services du systme; donnes du systme

Rponse

Authentifier usager; masquer lidentit de lusager; bloquer/permettre laccs aux


services/donnes; autoriser/retirer accs aux services/donnes; enregistre
accs/modifications ou tentatives daccs/modification de donnes/services avec
identit de lusager; dtecte une demande inhabituelle de services, informe oprateur
et rduit laccs au systme, etc.

Mesure

Temps/effort/ressources requises pour djouer le systme de scurit avec probabilit


de succs, probabilit de dtection dattaque; probabilit didentifier la personne
responsable dune attaque; pourcentage de services demeurant disponible dans le cas
dattaques denial-of-service , dommages causs aux donnes/services attaqus.
Hafedh Mili Copyright 1999-2007

44

22

Testabilit
Aspect

Valeurs possibles

Source

Dveloppeur, intgrateur, vrificateur systme, testeur acceptation client, utilisateur


du systme

Stimulus

Compltion de lanalyse, architecture, conception, dune classe, ou de lintgration de


sous-systme; livraison du systme

Env/contexte

Durant la conception; durant le codage; durant la compilation; durant le dploiement

Artfact

Un bout/fragment de conception, de code, ou application complte

Rponse

Donner accs aux valeurs dtats; fournir valeurs calcules; prparer environnement
de test

Mesure

Pourcentage dinstructions excutables qui sont effectivement excutes; probabilit


dchec si une faute est prsente; temps pour effectuer les tests; dure de temps pour
prparer lenvironnement de test

Hafedh Mili Copyright 1999-2007

45

Utilisabilit
Aspect

Valeurs possibles

Source

Usager final

Stimulus

Dsir de: 1) apprendre fonctionnalits du systme, 2) utiliser le systme efficacement,


3) minimiser limpact des erreurs, 4) adapter le systme, 5) se sentir confortable

Env/contexte

Durant lexcution ou la configuration

Artfact

Le systme

Rponse

Pour: 1) apprendre fonctionnalit: i) context-sensitive help, ii) familiarit de


linterface lusager, iii) etc., 2) utiliser le systme efficacement: i) agrgation de
donnes ou commandes; ii) rutilisation/rappel de donnes/commandes dj saisies,
iii) support pour la navigation efficace dans un systme, iv) fonctionnalits de fouille,
3) minimiser impact derreurs: i) offrir undo/annuler, ii) reconnatre et corriger
erreurs de lusager, iii) vrifier ressources systmes, iv) etc.; 4) adapter le systme: i)
configurabilit, internationalisation,

Mesure

Dure pour accomplir une tche, nombre derreurs, nombre de problmes rsolus,
satisfaction de lusager, ratio de manipulation russies/nombre total de manipulation,
quantit de temps/donnes perdues, etc.
Hafedh Mili Copyright 1999-2007

46

23

Remarques
Nous devons faire la mme chose avec les
qualits daffaire
Bien que les exigences non-fonctionnelles
sont supposes tre dtermines en amont,
elles doivent tre raffines une fois que
nous sommes au stade analyse de
larchitecture
Hafedh Mili Copyright 1999-2007

47

Plan
Introduction
Dfinitions
Architectures et critres de qualit de systmes
Tactiques pour atteindre les qualits
architecturales
Styles architecturaux

Hafedh Mili Copyright 1999-2007

48

24

Tactiques
On a identifi un certain nombre de
tactiques de conception pour rpondre
plusieurs scnarios
Les tactiques contrlent la rponse du
systme un stimulus pour atteindre le
rsultat (mesure) souhaite
Les tactiques peuvent tre raffines
Hafedh Mili Copyright 1999-2007

49

Tactiques
Chaque style/patron architectural incorpore
un sous-ensemble de tactiques
Ceci nous permet de slectionner des
patrons architecturaux par rapport aux
scnarios

Hafedh Mili Copyright 1999-2007

50

25

Lien entre exigences architecturales,


tactiques, et patrons/styles
architecturaux
ScnarioGnriqueAttributQualit
AttributQualit

comporte
1

0..1

-source : sequence(idl)
-stimulus : sequence(idl)
-environnement : sequence(idl)
-artfact : sequence(idl)
-rponse : sequence(idl)
-mesure : sequence(idl)

-class
*
instance de

-instance

ScnarioConcretAttributQualit
Systme

-systme

-scnario

0..*

0..*

-source : sequence(idl)
-stimulus : sequence(idl)
-environnement : sequence(idl)
-artfact : sequence(idl)
-rponse : sequence(idl)
-mesure : sequence(idl)

rpond
0..*

0..*

Tactique

implante
0..*

StyleArchitectural

0..*

Exigence
-priorit : unsigned short(idl)

Hafedh Mili Copyright 1999-2007

51

Tactiques pour la disponibilit


Les tactiques visent trois aspects: dtection
de fautes, recouvrement derreur, et
prvention
Dtection de fautes:
Ping/cho: les composantes sinterrogent sur leur
tat de fonctionnement
Pouls ( heartbeat ): un composant A met un
message priodiquement, et composant B coute
Exceptions
Hafedh Mili Copyright 1999-2007

52

26

Tactiques de disponibilit (suite)


Recouvrement ( fault recovery )
Vote: une entre est envoye plusieurs processus ou
processeurs redondants, et le rsultat soumis un votant
Redondance active: une entre est envoy plusieurs
processeurs qui le traitent en //. Le premier qui rpond
fournit le rsultat.
Redondance passive: seul un composant fait le calcul.
Quand il finit, il informe les autres pour se synchroniser
avec son nouvel tat.
Systme de rechange: en mode standby, synchronis
priodiquement aux checkpoints produits par le
composant principal
Hafedh Mili Copyright 1999-2007

53

Tactiques de disponibilit (suite)


Prvention derreur:
Retrait de service: lorsquun composant est sur
le point dchouer, on le retire pour le
rinitialiser (e.g., garbage collector)
Transactions: regrouper plusieurs changements
cohsifs dans une mme transaction
Process monitor: surveiller les processus pour
les redmarrer en cas de bizarrets
Hafedh Mili Copyright 1999-2007

54

27

Tactiques de modifiabilit
Localiser les changements
Maintenir la cohrence/cohsion smantique
Prvoir/anticiper les changements attendus pour les isoler
Gnraliser le module

Empcher leffet de cascade (B change parce A vient de


changer: couplage):

Dissimulation de linformation
Abstraire les diffrences non-essentielles dans des interfaces
Restreindre les liens de communication
Utilisation dintermdiaires/mdiateurs (brokers)

Hafedh Mili Copyright 1999-2007

55

Tactiques de modifiabilit (suite)


Retarder le temps de liaison (binding time)

Run-time registration
Fichiers de configuration
Polymorphisme
Adhsion des protocoles dfinis/standards

Hafedh Mili Copyright 1999-2007

56

28

Tactiques de performance
Grer la demande
Augmenter efficacit de calcul (e.g. choix
dalgorithmes)
Rduire le overhead de calcul (e.g. latence
rseau, appel local versus RPC)
Grer le taux dvnement (chantillonnage)
Mettre des limites sur le temps de traitement
dun vnement /longueur dune file dattente,
si on peut se permettre de perdre des donnes
Hafedh Mili Copyright 1999-2007

57

Tactiques de performance (suite)


Meilleure gestion des ressources
Introduire le paralllisme (multi-threading,
multi-processing)
Maintenir des copies multiples des donnes
(pour rduire la contention)
Augmenter les ressources!

Arbitrage:
Utilisation de stratgie judicieuse de
planification de tches (scheduling policies)
Hafedh Mili Copyright 1999-2007

58

29

Tactiques de scurit
Rsister aux attaques:

Authentification des usagers


Gestion de droits daccs
Confidentialit des donnes (encryption)
Limit exposure
Limiter laccs (pare-feu, filtrage sur source, destination, etc.)

Dtection dattaques
Utilise les logs, des algorithmes de filtrage, etc.

Recouvrement dattaques:
Restaurer ltat du systme: similaire aux tactiques de disponibilit
Identifier lattaquant: audit trail
Hafedh Mili Copyright 1999-2007

59

Tactiques de testabilit
Testabilit = observabilit + contrlabilit
Input/output:
Enregistre/playback: on enregistre les donnes passant travers un
module pour pouvoir les utiliser plus tard pour des tests
Sparer linterface de limplantation: permet de mettre des stubs
pour tester certaines fonctionnalits de faon isole sans effets de
bord irrversibles
Prvoir des interfaces spares pour le test

Monitoring interne:
Prvoir des moniteurs qui enregistrent certaines informations
durant lexcution

Hafedh Mili Copyright 1999-2007

60

30

Tactiques dutilisabilit
Tactiques lexcution:
Grer un modle de la tche en cours
dexcution pour savoir o on est
Grer un modle de lusager
Grer un tat du systme

Tactiques la conception
Sparer linterface usager du reste de
lapplication (MVC, Seeheim, Slinky, etc.)
Hafedh Mili Copyright 1999-2007

61

Plan
Introduction
Dfinitions
Architectures et critres de qualit de systmes
Tactiques pour atteindre les qualits
architecturales
Styles architecturaux
Techniques de slection de styles architecturaux
Hafedh Mili Copyright 1999-2007

62

31

Styles architecturaux
Camelot is based on the client-server model and uses
remote procedure calls both locally and remotely to
provide communication among applications and
servers[S+87]
Abstraction layering and system decomposition provide
the appearance of system uniformity to clients, yet allow
Helix to accommodate a diversity of autonomous devices.
The architecture encourages a client-server model for the
structuring of applications[FO85]
We have chosen a distributed object-oriented approach to
managing information[Lin87]
Hafedh Mili Copyright 1999-2007

63

Styles architecturaux
Un style architectural est un patron
rcurrent (commun) dorganisation /
architecture de systme,
Les styles sont gnralement dcrits par des
noms/phrases simples, mais voquent toute
une architecture!
Un style architectural est gnralement
uniformment appliqu larchitecture dun
systme.
Hafedh Mili Copyright 1999-2007

64

32

Styles architecturaux
Un style architectural est dtermin par:
Un ensemble de types de composantes (e.g. dpt de
donnes, processus, procdure),
Une structuration topologique des composantes indiquant
leur relations durant lexcution
Un ensemble de contraintes smantiques sur les
composantes et leur interrelations, et
Un ensemble de connecteurs (e.g. appel de procdures,
interruptions, etc.) pour mdier la communication et
coordination entre les composantes.
Hafedh Mili Copyright 1999-2007

65

Styles architecturaux
5 classes de styles:
Composantes indpendantes,
Flux de donnes
Orient-donnes,
Machine virtuelle
Call-and-return
Hafedh Mili Copyright 1999-2007

66

33

Composantes indpendantes

Systmes base
dvnements

Processus
Communiquants

Invocation
explicite

Invocation implicite
Hafedh Mili Copyright 1999-2007

67

Architectures en flux de donnes

Squentiel batch

Pipes and filters

Hafedh Mili Copyright 1999-2007

68

34

Architectures orientes-donnes

Approche
blackboard

Approche
repository

Hafedh Mili Copyright 1999-2007

69

Architectures machine virtuelle

Interprte

base de rgles

Hafedh Mili Copyright 1999-2007

70

35

Architectures call and return

Programme
principal et
sous-routines

Orientsobjet

Par couches

Hafedh Mili Copyright 1999-2007

71

Architectures orientes-donnes
Principe:
Diffrents clients accdent les mmes
donnes partages:
Reposoir passifde donnes: style reposoir
Reposoir actif: style blackboard

Objectif principal:
Assurer la qualit intgrabilit des
donnes
Hafedh Mili Copyright 1999-2007

72

36

Architectures orientes-donnes
Client 3
Client 4
Client 1
Donnes
partages
Client 5

Client 2
Hafedh Mili Copyright 1999-2007

73

Architectures orientes-donnes
Les clients sont des modules relativement
indpendants (vue structurelle)
Les clients ne doivent pas ragir instantanment
aux changements de donnes => reposoir
Les clients doivent ragir aux changements de
donnes => blackboard

Les clients roulent dans des processus


spars (vue processus)
Hafedh Mili Copyright 1999-2007

74

37

Architecture blackboard
contrle
donne

Client 3
Client 4

Client 1
Donnes
partages
Client 2

Client 5
Module de
contrle
Hafedh Mili Copyright 1999-2007

75

Architectures flux de donnes


Principe:
Les donnes coulent entre processus,
allant de input versus rept ultime:
Un lment la fois: pipes and filters
Par lots: batch sequential

Objectif principal:
Assurer la qualit rutilisation et
modifiabilit.
Hafedh Mili Copyright 1999-2007

76

38

Style batch sequential

input

Traitement
1

Traitement
2

Traitement
3

Hafedh Mili Copyright 1999-2007

77

Style pipe & filters

Filtre 1
input

Pipe
tuyau

Filtre 2

Filtre 4

Filtre 3

Filtre 4

Hafedh Mili Copyright 1999-2007

78

39

Pipe & Filters


Pros:
Simplicit de conception et de fonctionnement
Les filtres sont rutilisables, facilement
modifiables, et paralllisables
Cons:
Forcent une reprsentation de donnes plate
Pas adapt aux applications intractives
Recouvrement derreur hum
Si filtre dpend du contexte => buffer (illimit?)
Hafedh Mili Copyright 1999-2007

79

Batch sequential
Pros:
Plus flexibles dans la composition,
Meilleur recouvrement derreurs
Cons:
Pas adapt aux applications intractives

Hafedh Mili Copyright 1999-2007

80

40

Architectures machine virtuelle


Principe:
Le programme excuter est trait comme
un donne pour un autre programme visible
Objectif principal:
Assurer la qualit portabilit
Assurer la qualit modifiabilit
Hafedh Mili Copyright 1999-2007

81

Architectures machine virtuelle


entres

Donnes du
programme

Programme
interprter
tat du
programme

Sorties

Interprte

Instruction et
donne choisies

Hafedh Mili Copyright 1999-2007

Prochaine
instruction
tat de
linterprte

82

41

Architectures machine virtuelle


Exemples:
Systmes base de rgles,
mulateurs de <ce que vous voulez>
Java
Shells
Etc.
Hafedh Mili Copyright 1999-2007

83

Architectures machine virtuelle


Pros:
TRS flexible
Peu de programmation,
Modifiabilit dynamique de fonctionnalit
et de modalit dexcution.
Cons:
Performance
Difficult conceptuelle, dboggage, etc.
Hafedh Mili Copyright 1999-2007

84

42

Architecture par composantes


indpendantes
Principe:
Lapplication consiste en plusieurs objets ou
processus indpendants qui communiquent.
Objectif principal:
Modifiabilit,
Intgrabilit,
Scalability
Hafedh Mili Copyright 1999-2007

85

Architectures par composantes


indpendantes
Architectures orientes vnements:
Invocation implicite: publish and subscribe
Invocation explicite: les messages sont envoys
nominativement (mais les composantes ne se
contrlent pas)

Architectures par processus communiquants


Communication gnralement bi-directionnelle,
synchrone ou asynchrone
Exemple: client-serveur
Hafedh Mili Copyright 1999-2007

86

43

Architectures orientes
vnements: publish & subscribe
Comp 1
Gestionnaire
dvnements

Comp 2
Comp 3
Comp 4
Hafedh Mili Copyright 1999-2007

87

Architecture orientes
vnements
Pros:
Indpendance des composantes,
Scalabilit
Configurabilit dynamique
Cons:
Performance,
Difficult conceptuelle pour grer des
intractions compliques
Hafedh Mili Copyright 1999-2007

88

44

Architectures call-and-return
Principe:
Le contrle est centralis, et dtenu par une
composante la fois
Les composantes sont synchrones
Objectif principal:
Rutilisation fonctionnelle
Scalabilit
Hafedh Mili Copyright 1999-2007

89

Architectures call-and-return
Trois Souches:
Programme principal et sous-programme:
style dominant pendant 30 ans (structure
statique = structure dynamique)
Remote procedure call: idem, avec distribution
physique

Oriente objets: idem, structure statique


regroupe donnes et fonctions.
En couches: composantes distribues en
couches.
Hafedh Mili Copyright 1999-2007

90

45

Analyse des styles architecturaux


Pour chaque style, nous devons rpondre :
Quel type de composantes et connecteurs
Comment le contrle est gr et pass entre
composantes,
Comment les donnes sont changes
Comment le contrle et les donnes
intragissent,
Quel type de raisonnement est possible
Hafedh Mili Copyright 1999-2007

91

Composantes et connecteurs
Composante: un bout de logiciel qui fait de
quoi durant lexcution
Connecteur: un mchanisme pour grer la
communication et coordination entre
composantes.
La relation entre styles et (types de
composantes, connecteurs) est dgnre,
Hafedh Mili Copyright 1999-2007

92

46

La gestion du contrle
Les questions adresser:
Topologie (linaire pour P&F, hirarchique,
pour C&R, etc.)
Synchronisation (ou manque de): en unison,
parrallle, rendez-vous, etc.
Temps de rsolution: codage (C&R nonOO), compilation, chargement, excution
(event-based).
Hafedh Mili Copyright 1999-2007

93

Les donnes
Topologie: do o les donnes cheminent
elles
Continuit: (continu for P&F, rgulier vs.
sporadique, etc.)
Mode: passes entre composantes vs.
partages, unicast vs broadcast,
Temps de rsolution: quand est ce que le
vis-a-vis dans un change de donnes est
dtermin?
Hafedh Mili Copyright 1999-2007

94

47

Intractions donnes/contrle
Forme: sont ils isomorphes (si OO, oui!)
Directionalit: si isomorphes, est ce
donnes et contrle vont dans le mme sens
(P&F, oui, client-serveur, oppos)

Hafedh Mili Copyright 1999-2007

95

48