conception-architecturale.pdf

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


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


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


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]


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


ABC: Architecture Business Cycle [Bass et al., 2003]

Client et usager final Organization

Environnement technique Exprience de larchitecte

Exigences(proprits) Architecture

Systeme


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


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


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


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)



IntroductionDfinitions Architectures et critres de qualit de systmes Tactiques pour atteindre les qualits

architecturales Styles architecturaux


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.


Une architecture dun logiciel de simulation

ControlProcess

(CP

NoiseModel

(MODN)

ReverbModel(MODR)

Prop LossModel(PLM)


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.


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


Style, modle de rfrences, et architectures

Modle de rfrence

Style architectural

Architecture de rfrence

Architecture de systme


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


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.)


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


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


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


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.



Introduction DfinitionsArchitectures et critres de qualit de systmes Tactiques pour atteindre les qualits


13


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).


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


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


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


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


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


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


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


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


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


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.


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


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 ?


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


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


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


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


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


22


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



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


23


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



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


24


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


Plan

Introduction Dfinitions Architectures et critres de qualit de systmesTactiques pour atteindre les qualits


25


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


Tactiques

Chaque style/patron architectural incorpore un sous-ensemble de tactiques

Ceci nous permet de slectionner des patrons architecturaux par rapport aux scnarios

26


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


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


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


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


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)


Tactiques de modifiabilit (suite)

Retarder le temps de liaison (binding time) Run-time registration Fichiers de configuration Polymorphisme Adhsion des protocoles dfinis/standards

29


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


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


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


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


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.)


Plan

Introduction Dfinitions Architectures et critres de qualit de systmes Tactiques pour atteindre les qualits

architecturalesStyles architecturaux Techniques de slection de styles architecturaux

32


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]



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



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.



5 classes de styles: Composantes indpendantes, Flux de donnes Orient-donnes, Machine virtuelle Call-and-return

34


Composantes indpendantes

ProcessusCommuniquants

Systmes basedvnements

Invocation implicite Invocationexplicite


Architectures en flux de donnes

Squentiel batch Pipes and filters

35


Architectures orientes-donnes

Approcherepository

Approcheblackboard


Architectures machine virtuelle

Interprte base de rgles

36


Architectures call and return

Programmeprincipal et

sous-routines

Par couchesOrients-objet



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



Client 1

Client 3

Client 2 Client 5

Client 4

Donnespartages



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


Architecture blackboard

Client 1

Client 3

Client 2 Client 5

Client 4

Donnespartages

Module decontrle

contrledonne


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


Style batch sequential

Traitement1

Traitement2

Traitement3

input


Style pipe & filters

Filtre 1 Filtre 2 Filtre 3input

Filtre 4 Filtre 4

Pipetuyau

40


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?)


Batch sequential

Pros: Plus flexibles dans la composition, Meilleur recouvrement derreursCons: Pas adapt aux applications intractives

41



Principe: Le programme excuter est trait comme

un donne pour un autre programme visible

Objectif principal: Assurer la qualit portabilit Assurer la qualit modifiabilit



Donnes duprogramme

Programme interprter

tat de linterprteInterprte

entres

Prochaineinstruction

tat duprogramme

Instruction etdonne choisies

Sorties

42



Exemples: Systmes base de rgles, mulateurs de Java Shells Etc.



Pros: TRS flexible Peu de programmation, Modifiabilit dynamique de fonctionnalit

et de modalit dexcution.Cons: Performance Difficult conceptuelle, dboggage, etc.

43


Architecture par composantesindpendantes

Principe: Lapplication consiste en plusieurs objets ou

processus indpendants qui communiquent.Objectif principal: Modifiabilit, Intgrabilit, Scalability


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


Architectures orientesvnements: publish & subscribe

Comp 1

Comp 2

Comp 3

Comp 4

Gestionnairedvnements


Architecture orientesvnements

Pros: Indpendance des composantes, Scalabilit Configurabilit dynamiqueCons: Performance, Difficult conceptuelle pour grer des

intractions compliques

45


Architectures call-and-return

Principe: Le contrle est centralis, et dtenu par une

composante la fois Les composantes sont synchronesObjectif principal: Rutilisation fonctionnelle Scalabilit


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


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


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


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).


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


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)

conception-architecturale.pdf

Documents

utiliserhafedh mili

influences larchitecture

architecture introduction

terme de composantes

conception architecturale3

jai besoin dun systme

gnie logiciel

faible cotdacquisition