1Hafedh Mili Copyright 1999-2007 1
Conception
1. Nature de la conception
2. Conception architecturale
3. Conception dtaille
Hafedh Mili Copyright 1999-2007 2
Conception architecturale
Introduction Dfinitions Architectures et critres de qualit de
systmes, Tactiques pour atteindre les qualits
architecturales Styles/patrons architecturaux
2Hafedh Mili Copyright 1999-2007 3
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 vontrpondre mes besoins
Ingnieur: un trs bas niveau. Il faudra voircomment on va les utiliser
Hafedh Mili Copyright 1999-2007 4
Architecture (introduction)
Le gnie logiciel souffre dun manque de concepts intermdiaires entre objectifsstratgiques et structures de donnes
Larchitecture intgre les exigencesfonctionnelles avec les exigences daffairedune organisation
3Hafedh Mili Copyright 1999-2007 5
Architectures: une 1re dfinition
Une architecture est lexpression des premires dcisions de conception concernant la dcomposition dun systmeen 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 6
Architecture: une confluence dinfluences
Dveloppement etmaintenance:faible cot, prserverles emploies
Usager final:fonctionnalits,performance, scurit, fiabilit
architecte
Client: faible cotdacquisition, dopration, et dvolutrion
Marketing: fonctionnalit, faible prix de vente, time-to-market, diffrentiation
4Hafedh Mili Copyright 1999-2007 7
ABC: Architecture Business Cycle [Bass et al., 2003]
Client et usager final Organization
Environnement technique Exprience de larchitecte
Exigences(proprits) Architecture
Systeme
Hafedh Mili Copyright 1999-2007 8
Les influences
Larchitecture influence la structure organisationnelle de dveloppement et rciproquement
Peut influencer le client (sacrifier quelquesfonctionnalits pour dautres qualits)
Fait voluer lexprience de larchitecte Peut faire voluer les objectifs stratgiques
5Hafedh Mili Copyright 1999-2007 9
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 10
Comment faire une bonnearchitecture (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 dveloppementincrmental partir dune skelette
6Hafedh Mili Copyright 1999-2007 11
Quest ce quune bonnearchitecture? (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 12
Conception architecturale
IntroductionDfinitions Architectures et critres de qualit de systmes Tactiques pour atteindre les qualits
architecturales Styles architecturaux
7Hafedh Mili Copyright 1999-2007 13
Dfinitions
Larchitecture dun programme ou systmeinformatique est:
la structure ou lensemble des structures dusystme, 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 14
Une architecture dun logiciel de simulation
ControlProcess
(CP
NoiseModel
(MODN)
ReverbModel(MODR)
Prop LossModel(PLM)
8Hafedh Mili Copyright 1999-2007 15
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 16
Styles, modles de rfrences, et architectures de rfrences
Un style ou patron architectural est unedescription dun type de composantes et dun patron de contrle et de communication entre composantes
Un modle de rfrence est unedcomposition fonctionnelle dun systme (e.g., dune analyse du domaine)
Une architecture de rfrence est la correspondence dun modle de rfrence un style architectural
9Hafedh Mili Copyright 1999-2007 17
Style, modle de rfrences, et architectures
Modle de rfrence
Style architectural
Architecture de rfrence
Architecture de systme
Hafedh Mili Copyright 1999-2007 18
Structures architecturales
Structure de modules: un module est uneunit de travail avec livrables (interface, code, plan de test). La relation estlaggrgation/dpendance
Structure logique/conceptuelle: les lmentssont des composantes fonctionnelles. La relation est partage/change de donnes. Le modle de rfrence en est un exemple.
10
Hafedh Mili Copyright 1999-2007 19
Structures architecturales (suite)
Structure de processus/coordination: vuerun-time, orthogonale aux deuxprcdentes. Relation: synchronisation, peut-pas-rouler-sans, peut-pas-avec, etc.
Structure physique: lallocation du logicielau matriel (systmes distribus). Composantes: hardware, liens: communication (sert valider perf., etc.)
Hafedh Mili Copyright 1999-2007 20
Structures architecturales (suite) Structure uses: les units = procdures ou
modules, liens = dpendencesfonctionnelles/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-actif-aprs. Pour validation comportementale, timing, etc.
Structure de classes: classes et hritage.
11
Hafedh Mili Copyright 1999-2007 21
Structures architecturales (suite)Structure U nits R elations U tilitM odule Tches de
travailSous-m odule de A llocation de ressources ,
structuration et p lanificationde projets, contle deconfigu ration
C onceptuelle
Fonctions Partage desdonnes avec
C om prendre le dom ainedapplication
Processus Program m es
R oule-en-//-avec, exclue,prcde, etc.
A nalyse de lagencem ent destches, analyse deperform ance
Physique H ardw are C om m unique-avec
Perform ance, scurit,fiabilit
Hafedh Mili Copyright 1999-2007 22
Structures architecturales (suite)Structure Units Relations UtilitUses Programme
sExigence lesservices de/dpend de
Concevoir des sous-produits,des extensions
Appel Programmes
Appelle Analyse de performance
Fluxdonnes
Fonctions Envoie desdonnes
Trace dexigencesfonctionnelles
Flux decontrle
tats dusystme oumodules
Dclenche,transite-, etc.
Simulation, vrification deproprits dynamiques, etc.
Classes Objets Is-a, partage Dans les systmes OO, c staussi la conception dtaille
12
Hafedh Mili Copyright 1999-2007 23
Structures architecturales (fin)
Diffrents systmes requirent diffrentescombinaisons 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 24
Conception architecturale
Introduction DfinitionsArchitectures et critres de qualit de systmes Tactiques pour atteindre les qualits
architecturales Styles architecturaux
13
Hafedh Mili Copyright 1999-2007 25
Les attributs de qualit
Il faut distinguer entre: Attributs/proprits du systme, qui sont
dues larchitectures, et attributsintrinsques de larchitecture elle-mme,
Qualits observables lxcution de cellesqui ne le sont pas,
Qualit technique versus qualit daffaires(business quality).
Hafedh Mili Copyright 1999-2007 26
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)
14
Hafedh Mili Copyright 1999-2007 27
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 28
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.)
15
Hafedh Mili Copyright 1999-2007 29
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 diffrentsenvironnements dopration/excution
Hafedh Mili Copyright 1999-2007 30
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 composantesdveloppes sparment dinter-oprer(dpend des interfaces des composantes)
Testabilit: relie la controllabilit et observabilit du comportement des composantes.
16
Hafedh Mili Copyright 1999-2007 31
Attributs de qualit: rsumAttribut Architect
ural?Considrations architecturales
Proprits observables lxcution
Performance Oui Communication entre composantes, sparationfonctionnelle pour paralllisme
Scurit Oui Composantes spcialises, e.g. serveursdauthentification
Disponibilit Oui Tolrance aux fautes, redondance, contrledintraction de composantes
Fonctionnalit Non Intraction avec les autres attributs de qualit
Utilisabilit Oui Modifiabilit facilite latteinte de lutilisabilit;assurer le bon transfert dinformation
Hafedh Mili Copyright 1999-2007 32
Attributs de qualit: rsumAttribut Architect
ural?Considrations architecturales
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 etuniformes, dpendences non-circulaires,
Testabilit Oui Modulariser/encapsuler les composantes,dpendences non-circulaires.
17
Hafedh Mili Copyright 1999-2007 33
Attributs de qualit orients-affaires
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 34
Qualits de larchitecture
Les (attributs de) qualits vues date concernent le produit final; diffrents choixvont permettre datteindre ces qualits lplus ou moins bien
Les qualits de larchitecture sontintrinsques, indpendamment de toutequalit quelle pourra inculquer un produitdonn
18
Hafedh Mili Copyright 1999-2007 35
Qualits de larchitecture
Intgrit conceptuelle: cohrence, thmedominant, quitte abandonner certainesfeatures,
Compltude et correctness: rpond toutes les exigences, et efficacement,
Faisabilit: en tenant compte des ressources, et autres contraintes.
Hafedh Mili Copyright 1999-2007 36
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)
19
Hafedh Mili Copyright 1999-2007 37
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 38
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)
20
Hafedh Mili Copyright 1999-2007 39
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 40
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
21
Hafedh Mili Copyright 1999-2007 41
Exemple: disponibilit (4/) Scnario gnrique
Scnario concret:Temps de rparation, disponibilit, temps pass en mode dgradMesure
record, notification, dsactiver, continuer (normal/dgrad), devenir non disponibleRponse
Processus, mmoire, processeur, lien de communicationArtfact
Normal, dgradEnvironnement
Omission, crash, timeout, rsultat incorrectStimulus
Externe, interneSource
Valeurs possiblesAspect
Pas de temps darrt
Informer oprateur et continuer normal
processusMode dopration normal
Message inattendu
Externe
MesureRponseArtfactEnvironnementStimulusSource
Hafedh Mili Copyright 1999-2007 42
Modifiabilit
Cot en terme de, i) nombre dlments affects, ii) effort, iii) argent; la mesure dans laquelle cela affecte dautres fonctions ou qualits
Mesure
Localiser les lments dans larchitecture qui doivent tre modifis, faire modification sans affecter les autres fonctions, tester les modifications, dployer la version modifie
Rponse
Interface usager, plateforme, environnement, un systme qui interagit avec notre systme
Artfact
lexcution, durant le build , la compilation (compile-time), durant la conception
Environnement/contexte
Ajouter/retirer/modifier une fonctionnalit, modifier attribut de qualit, modifier capacit (e.g., augmenter nombre dusagers)
Stimulus
Usager final, dveloppeur, administrateur systmeSource
Valeurs possiblesAspect
22
Hafedh Mili Copyright 1999-2007 43
Performance
Temps de rponse, temps maximal de rponse, dbit, jitter , taux dchec ( miss rate ), perte de donnes
Mesure
Traiter lvnement; changer le niveau/mode de serviceRponse
SystmeArtfact
Mode normal; mode en surchargeEnvironnement/contexte
vnements priodiques; vnements sporadiques; vnements stochastiques
Stimulus
Sources indpendantes, possiblement internes au systmeSource
Valeurs possiblesAspect
Hafedh Mili Copyright 1999-2007 44
Scurit
Temps/effort/ressources requises pour djouer le systme de scurit avec probabilitde 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.
Mesure
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.
Rponse
Fonctionnalits/services du systme; donnes du systmeArtfact
On-line/off-line, connect ou dconnect, ouvert ou derrire un pare-feuEnv/contexte
Tentative de, 1) afficher des donnes, 2) modifier/effacer des donnes, 3) accder des services/fonctionnalits du systme, 4) rduire la disponibilit du systme
Stimulus
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
Source
Valeurs possiblesAspect
23
Hafedh Mili Copyright 1999-2007 45
Testabilit
Pourcentage dinstructions excutables qui sont effectivement excutes; probabilitdchec si une faute est prsente; temps pour effectuer les tests; dure de temps pour prparer lenvironnement de test
Mesure
Donner accs aux valeurs dtats; fournir valeurs calcules; prparer environnement de test
Rponse
Un bout/fragment de conception, de code, ou application complteArtfact
Durant la conception; durant le codage; durant la compilation; durant le dploiementEnv/contexte
Compltion de lanalyse, architecture, conception, dune classe, ou de lintgration de sous-systme; livraison du systme
Stimulus
Dveloppeur, intgrateur, vrificateur systme, testeur acceptation client, utilisateur du systme
Source
Valeurs possiblesAspect
Hafedh Mili Copyright 1999-2007 46
Utilisabilit
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.
Mesure
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,
Rponse
Le systmeArtfact
Durant lexcution ou la configurationEnv/contexte
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
Stimulus
Usager finalSource
Valeurs possiblesAspect
24
Hafedh Mili Copyright 1999-2007 47
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 48
Plan
Introduction Dfinitions Architectures et critres de qualit de systmesTactiques pour atteindre les qualits
architecturales Styles architecturaux
25
Hafedh Mili Copyright 1999-2007 49
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 50
Tactiques
Chaque style/patron architectural incorpore un sous-ensemble de tactiques
Ceci nous permet de slectionner des patrons architecturaux par rapport aux scnarios
26
Hafedh Mili Copyright 1999-2007 51
Lien entre exigences architecturales, tactiques, et patrons/styles
architecturauxAttributQualit
Systme
-priorit : unsigned short(idl)Exigence
0..*
-scnario
0..*
-systme
1 0..1
comporte-source : sequence(idl)-stimulus : sequence(idl)-environnement : sequence(idl)-artfact : sequence(idl)-rponse : sequence(idl)-mesure : sequence(idl)
ScnarioGnriqueAttributQualit
-source : sequence(idl)-stimulus : sequence(idl)-environnement : sequence(idl)-artfact : sequence(idl)-rponse : sequence(idl)-mesure : sequence(idl)
ScnarioConcretAttributQualit
-class*
-instance*
instance de
Tactique StyleArchitectural
0..* 0..*
rpond
0..* 0..*
implante
Hafedh Mili Copyright 1999-2007 52
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
27
Hafedh Mili Copyright 1999-2007 53
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, synchronispriodiquement aux checkpoints produits par le composant principal
Hafedh Mili Copyright 1999-2007 54
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
28
Hafedh Mili Copyright 1999-2007 55
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 56
Tactiques de modifiabilit (suite)
Retarder le temps de liaison (binding time) Run-time registration Fichiers de configuration Polymorphisme Adhsion des protocoles dfinis/standards
29
Hafedh Mili Copyright 1999-2007 57
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 58
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)
30
Hafedh Mili Copyright 1999-2007 59
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 60
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
31
Hafedh Mili Copyright 1999-2007 61
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 62
Plan
Introduction Dfinitions Architectures et critres de qualit de systmes Tactiques pour atteindre les qualits
architecturalesStyles architecturaux Techniques de slection de styles architecturaux
32
Hafedh Mili Copyright 1999-2007 63
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 64
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 touteune architecture!
Un style architectural est gnralementuniformment appliqu larchitecture dun systme.
33
Hafedh Mili Copyright 1999-2007 65
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 66
Styles architecturaux
5 classes de styles: Composantes indpendantes, Flux de donnes Orient-donnes, Machine virtuelle Call-and-return
34
Hafedh Mili Copyright 1999-2007 67
Composantes indpendantes
ProcessusCommuniquants
Systmes basedvnements
Invocation implicite Invocationexplicite
Hafedh Mili Copyright 1999-2007 68
Architectures en flux de donnes
Squentiel batch Pipes and filters
35
Hafedh Mili Copyright 1999-2007 69
Architectures orientes-donnes
Approcherepository
Approcheblackboard
Hafedh Mili Copyright 1999-2007 70
Architectures machine virtuelle
Interprte base de rgles
36
Hafedh Mili Copyright 1999-2007 71
Architectures call and return
Programmeprincipal et
sous-routines
Par couchesOrients-objet
Hafedh Mili Copyright 1999-2007 72
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
37
Hafedh Mili Copyright 1999-2007 73
Architectures orientes-donnes
Client 1
Client 3
Client 2 Client 5
Client 4
Donnespartages
Hafedh Mili Copyright 1999-2007 74
Architectures orientes-donnes
Les clients sont des modules relativementindpendants (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)
38
Hafedh Mili Copyright 1999-2007 75
Architecture blackboard
Client 1
Client 3
Client 2 Client 5
Client 4
Donnespartages
Module decontrle
contrledonne
Hafedh Mili Copyright 1999-2007 76
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.
39
Hafedh Mili Copyright 1999-2007 77
Style batch sequential
Traitement1
Traitement2
Traitement3
input
Hafedh Mili Copyright 1999-2007 78
Style pipe & filters
Filtre 1 Filtre 2 Filtre 3input
Filtre 4 Filtre 4
Pipetuyau
40
Hafedh Mili Copyright 1999-2007 79
Pipe & Filters
Pros: Simplicit de conception et de fonctionnement Les filtres sont rutilisables, facilement
modifiables, et paralllisablesCons: 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 80
Batch sequential
Pros: Plus flexibles dans la composition, Meilleur recouvrement derreursCons: Pas adapt aux applications intractives
41
Hafedh Mili Copyright 1999-2007 81
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 82
Architectures machine virtuelle
Donnes duprogramme
Programme interprter
tat de linterprteInterprte
entres
Prochaineinstruction
tat duprogramme
Instruction etdonne choisies
Sorties
42
Hafedh Mili Copyright 1999-2007 83
Architectures machine virtuelle
Exemples: Systmes base de rgles, mulateurs de Java Shells Etc.
Hafedh Mili Copyright 1999-2007 84
Architectures machine virtuelle
Pros: TRS flexible Peu de programmation, Modifiabilit dynamique de fonctionnalit
et de modalit dexcution.Cons: Performance Difficult conceptuelle, dboggage, etc.
43
Hafedh Mili Copyright 1999-2007 85
Architecture par composantesindpendantes
Principe: Lapplication consiste en plusieurs objets ou
processus indpendants qui communiquent.Objectif principal: Modifiabilit, Intgrabilit, Scalability
Hafedh Mili Copyright 1999-2007 86
Architectures par composantesindpendantes
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
44
Hafedh Mili Copyright 1999-2007 87
Architectures orientesvnements: publish & subscribe
Comp 1
Comp 2
Comp 3
Comp 4
Gestionnairedvnements
Hafedh Mili Copyright 1999-2007 88
Architecture orientesvnements
Pros: Indpendance des composantes, Scalabilit Configurabilit dynamiqueCons: Performance, Difficult conceptuelle pour grer des
intractions compliques
45
Hafedh Mili Copyright 1999-2007 89
Architectures call-and-return
Principe: Le contrle est centralis, et dtenu par une
composante la fois Les composantes sont synchronesObjectif principal: Rutilisation fonctionnelle Scalabilit
Hafedh Mili Copyright 1999-2007 90
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.
46
Hafedh Mili Copyright 1999-2007 91
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 92
Composantes et connecteurs
Composante: un bout de logiciel qui fait de quoi durant lexcution
Connecteur: un mchanisme pour grer la communication et coordination entrecomposantes.
La relation entre styles et (types de composantes, connecteurs) est dgnre,
47
Hafedh Mili Copyright 1999-2007 93
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 non-
OO), compilation, chargement, excution(event-based).
Hafedh Mili Copyright 1999-2007 94
Les donnes
Topologie: do o les donnes cheminentelles
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 estdtermin?
48
Hafedh Mili Copyright 1999-2007 95
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)