Download pdf - Introduction aux styles architecturauxlamontagne/glo3001/07-Intro Styles...Introduction aux styles architecturaux GLO-3001 Architecture logicielle Luc Lamontagne Hiver 2010 Styles

Introduction aux styles architecturaux

GLO-3001

Architecture logicielle

Luc Lamontagne

Hiver 2010

Styles architecturaux

• Patrons de structures génériques fréquemment rencontrées dans la pratique– Ces patrons ont des propriétés biens définies qui permettent la réutilisation

• Architecture = composantes + connecteurs

• Spécification d’une décomposition en composantes qui sont en interrelation

• Permet d’atteindre des objectifs de conception

• Une compréhension de ces styles peut simplifier le choix et la conception d’une architecture logicielle– La plupart des systèmes de grande échelle sont hétérogènes – Ils ne correspondent pas à un style architectural unique

2

Bénéfices d’utiliser des styles

• Réutilisation d’un design– Des solutions bien comprises appliquées à de nouveaux

problèmes

• Réutilisation de code– Partage de l’implémentation des aspects invariants d’un

style

• Compréhension de l’organisation d’un système– Une expression comme client-serveur communique

beaucoup d’information

• Interopérabilité– Supporté par la standardisation d’un style

3

Styles architecturaux

• Ne pas confondre style architectural et modèlearchitectural (ou vue architecturale)

• Modèles (vues, visualisation)– Utilisés pour documenter une architecture

• Modèle statique qui présente les composantes

• Modèle dynamique qui décrit la structure de traitement

• Modèle d’interface qui définit les sous-systèmes

• Modèle de relation qui décrit les relations entre les composantes

• Modèle de distribution des sous-systèmes sur différents ordinateurs

4

Patrons, styles et autres

5

Propriétés des architectures

• Les objectifs de conception de l’architecture sont caractérisés par les propriétés que l’on désire obtenir pour le système

– Propriétés fonctionnelles• Fonctionnalités requises du système

– Propriétés non-fonctionnelles• Maintenabilité

– Évolution, adaptation ou correction du système

• Disponibilité• Performance• Interopérabilité• Robustesse

– Gestion des erreurs– Tolérance aux fautes

• Sécurité

6

Survol - principaux styles architecturaux

• Traditionnel influencé par un style de programmation– Main program and subroutines– Orienté object

• En couche– Machine virtuelle– Client-serveur– N-tiers

• Data-flow– Batch sequential– Pipe and filter

• Shared memory– Blackboard– Systèmes à base de règles

• Adaptatif– Microkernel– Reflexive– Plug-in

• Interactif– Model-View-Controller

• Embarqué– Sense-Compute-Control

• Interpréteur– Interpréteur– Code mobile

• Invocation implicite– Event-based– Publish-subscribe

• Peer to peer• Styles dérivés

– C2– CORBA

7


• Main program & Subroutines– Un programme principal qui appelle les composantes à

tour de rôle– Contrôle hiérarchique– Le style le plus simple

8


• Style orienté objet (…)– Topologie et structure de contrôle arbitraire.

– La durée de vie des instances peut varier

– Comprendre le système : relations statiques et dynamiques

9


• Couches (Layers)– Organisation en couches de

composantes offrant des groupes de services

– Échanges limités aux composantes de la couche sous-jacente• Les composantes d’une couche ne

font appel qu’aux composantes de la même couche ou de la couche inférieure

– Principe des machines virtuelles

10

Couche 1

Couche 2

Couche 3

Programme A

Programme B

Programme D

Programme C


• Client-serveur– Modèle à deux couches– La base des systèmes distribués– Les données sont distribuées dans un ensemble de

composantes– Le traitement est réparti parmi les composantes

– Composantes• Serveurs – fournissent des services• Clients – utilisent ces services

– Thin-client vs. Fat-client

– Connecteurs• RPC• Protocole réseau

11


• Modèle 3-tiers– Cas particulier d’un :

• Modèle en couche (3)• Modèle client-serveur (2)

– Autre dénomination : • State-logic-display

– Rôle des niveaux : • Présentation• Logique d’application• Données (état du système)

12

Survol des principaux styles architecturaux

• Model-View-Controller (MVC)– Applications interactives - GUI– L’application est divisée en 3 composantes

• Modèle– Représente les données et les fonctionnalités du domaine de l’application

• Vues– Représentations visuelles des données qui forment l’application– Il peut y avoir plus d’une vue pour un même modèle

• Contrôleurs– Composantes de contrôle qui traitent les entrées (événements) en provenance des vues et du

système et les traduit en opérations effectuées sur le modèle est les vues– Un contrôleur pour chacune des vues

13


• Batch sequential– Style de flot de données (dataflow)– Un des styles le plus anciens– Repose sur la conversion d’un flux de données– Pour les applications de systèmes financiers

14


• Pipelines (Pipes and Filters)– Inspiré de la composition de fonctions en Unix

ls invoices | grep –e August | sort

– Composantes de transformation (Filtres)• Les filtres sont des unités de traitement qui sont spécifiées uniquement pas les

entrées qu’elles acceptent et les sorties qu’elles produisent• Les filtres ne partagent pas d’état entre eux• Les filtres n’ont pas d’interaction entre eux

– Composantes de communication (Pipes)• Les pipes sont des connecteurs • Ils relient les composantes sources et les composantes réceptrices• Ils propagent les données entre elles

15

Pump SinkFilterFilterpipe pipe pipe


• Sense-Compute-Control

16Objectif : Structurer les applications embarquées (contrôle)


• Dépôts de données (Repository – shared memory)– Dépôt de données commun aux composantes du

système

– Les composantes interagissent par l’entremise du dépôt de données

– Applications traditionnelles– Base de données avec triggers

– Autres – Blackboard– Système à base de règles / système expert

17


• Dépôts de données (Repository)– Cas particulier: Blackboard

• Dépôt de données central

• Composantes de traitement sur les données (Knowledge Sources)– Pas d’interactions directes entre les KS

• Composante de gestion des traitements (Controller)

• Résolution de problème par des modifications successives des données

18


• Système à base de règles– Contient

– Un interface usager– Un moteur d’inférence– Une base de connaissance

– Le moteur d’inférence décortique les inputs de l’usager

– Il détermine si c’est un fait, une règle ou une requête.

– Un fait ou une règle – Ajouter à la base de connaissance

– Un requête– Interroger la base de connaissance pour obtenir les

règles applicables et tenter de résoudre la requête

19


• Publish-Subscribe– De type implicit invocation

– Abonnement pour recevoir des messages ou un contenu spécifique.

– Les abonnées peuvent s’enregistrer ou se désabonner.

– Les publieurs font un broadcast de leurs messages à leurs abonnés

• Soit de façon synchrone ou asynchrone

21


• Peer-to-peer– Peer : généralisation du modèle

client-serveur

– Une composante peut agir selon les deux modes

– Doit contenir des services pour localiser les peers et les ressources

22

Conclusion

• Différents styles répertoriés dans la littérature– Certains largement répandus, d’autres peu utilisés

• Chaque style a ses caractéristiques– Rôle des composantes– Connecteurs spécifiques

• La suite…– Description détaillée de quelques styles – Conception architecturale

• Comment choisir un ou plusieurs styles/patrons pour concevoir un système?

23