Styles architecturaux

(1)

Julie Vachon, Hiver 2006

IFT2251 : Génie logiciel

Chapitre 5. Conception

Section 2. Conception architecturale

Chap.5, Sect.2, p.2 Copyrights Julie Vachon, 2006

Conception architecturale

1.

Architecture logicielle

2.

Styles architecturaux

A.

Architecture pipeline

B.

Architecture tableau noir

C.

Architecture MVC

D.

Architecture multi-couches

E.

Architecture n-tiers

F.

CORBA

3.

Développer un modèle architectural

UML et la modélisation des architectures

Diagramme de packages

Diagramme de composants

Diagrammes de déploiement

5.2.1. Architecture logicielle

Définition

La définition de l’architecture logicielle consiste à:

Décrire l’organisation généraled’un système et sa décomposition en sous-systèmes.

Déterminer les interfaces entre les sous-systèmes.

Décrire lesinteractionset le flot de contrôleentre les sous- systèmes.

On décrira également les modules(classes, composants, etc.) utilisés pour implémenter les fonctionnalités des sous-système.

Lespropriétésdes modules

Leur contenu(e.g. d’autres modules)

Les machines ou dispositifs sur lesquels ces modules seront déployés.

Architecture logicielle

Pourquoi développer un modèle d’architecture ?

Pour permettre à tous de mieux comprendre le système

Pour permettre aux développeurs de travailler sur des parties individuelles du système en isolation.

Pour préparer les extensions du système.

Pour faciliter la réutilisation et la réutilisabilité.

(2)

Architecture logicielle

Choix d’une architecture

Dépend des besoins fonctionnels et non fonctionnels du logiciel

Influencé par certains « modèles connus » de décomposition en composants et mode d’interactions.

Choix favorisant la stabilité: l’ajout de nouveaux éléments sera facile et ne nécessitera en général que des ajustements mineurs à l’architecture.

Utilité des styles architecturaux (aussi appelés patrons d’architecture)

Modèle éprouvé et enrichis par l’expérience de plusieurs développeurs Mode d’interaction établi entre modules via une d’interface générique Fournit une plate-forme d’intégration pour connecter les différentes

sous-parties du logiciel à développer

Meilleure qualité du logiciel : compréhensibilité, maintenance, évolubilité, réutilisation, performance, documentation, etc.

Architecture logicielle

Dimensions d’une architecture

Une architecture peut être vue sous plusieurs angles

Vue logique, organisation conceptuelle (classes, interfaces, paquetages, sous-parties, composants, etc.)

Vue de déploiement, organisation physique (allocation de processus aux unités de traitement, configuration réseau, etc.)

La décomposition proposée par la vue logique contribuera à définir la distribution de la vue de déploiement

7.2.2 Styles architecturaux

A. Architecture pipeline

Un flot de données, dans un format relativement simple, passe par une série de processus de traitement.

Sous-systèmes organisés en pipeline de filtres indépendants La sortie d’un filtre correspond à l’entrée d’un autre

Communication locale (voisins de gauche et de droite), un filtre peut souvent commencer à opérer avant même d’avoir lu tout le flux d’entrée

Utile pour les traitements en plusieurs étapes

Analyse facilitée : performance, synchronisation, goulot d’étranglement, etc.

Exécution concurrente de filtres possible, synchronisation des flux parfois nécessaire.

canal de communication

Filtre

synchro

Styles architecturaux

Architecture pipeline

Encodeur pour sortie de microphone

Filtrer

l’écho Filtrer

le bruit Retirer les fréquences non vocales

Égaliser les les intervalles dynamiques

Compresser Transmettre

Recevoir Décompresser

Encoder la sortie des haut-parleurs Encodeur de bruit ambiant

Autre ex: Compilation d’un programme : analyseur lexical, syntaxique, sémantique…

(3)

Architecture pipeline

Avantages:

bon pour traitement en lot (batch),

architecture très flexible (les composants peuvent être enlevés, remplacés ou réordonnés; de nouveaux composants peuvent être ajoutés)

Inconvénient: mauvais pour le traitement interactif.

D’un point de vue conception:

Diviser pour régner: les filtres peuvent être conçus séparément.

Cohésion: les filtres présent un type de cohésion fonctionnelle.

Couplage: les filtres n’ont qu’une entrée et une sortie en général.

Abstraction: les filtres cachent généralement bien leurs détails internes.

Réutilisabilité: les filtres peuvent très souvent être réutilisés dans d’autres contextes.

Réutilisation: il est souvent possible d’utiliser des filtres déjà existants pour les insérer dans le pipeline.

B. Le tableau noir (ou repositoire)

Tableau noir : médium de communication

Communication étendue à tous les partenaires

Un des sous-système est désigné comme le tableau noir

On ne peut recevoir et transmettre des informations que via le tableau

Tableau noir

Styles architecturaux

Le tableau noir (ou repositoire)

Débugger Éditeur

syntaxique Compilateur

Repositoire Arbre

syntaxique

Table de symboles Analyseur

syntaxique

Analyseur sémantique

Optimiseur

Analyseur lexical Générateur

de code

Styles architecturaux

Le tableau noir (ou repositoire)

Flot de contrôle dirigé par le repositoire (triggers) ou par les sous- systèmes (flots concurrents avec sync via des verrous sur les données)

Architecture utilisée par les systèmes centrés sur les données, applications de type SGBD (ex. système bancaire, système de facturation), environnement de programmation, etc.

Avantageux pour les applications impliquant des tâches complexes sur les données, nombreuses et changeant souvent. Une fois le repositoire bien défini, de nouveaux services peuvent facilement être ajoutés.

Inconvénient: le repositoire peut facilement constituer un goulot d’étranglement, tant du point de vue de sa performance que de sa modifiabilité (étant donné le fort couplage!)

(4)

C. Architecture Modèle-Vue-Contrôleur (MVC)

Séparer la couche interface utilisateur des autres parties du système

(car les interfaces utilisateurs sont beaucoup plus susceptibles de changer que la base de connaissances du système).

Composé de trois types de sous-systèmes:

Modèle: Constitue l’ensemble des données du domaine, des connaissances du système. Contient les classes dont les instances doivent être vues et manipulées.

Vue: Contient les objets utilisés pour présenter/afficher les données du modèle dans l’interface utilisateur.

Contrôleur: Contient les objets nécessaires pour gèrer et contrôler les interactions de l’utilisateur avec la vue et le modèle.

Fait appel au design pattern X??

Architecture Modèle-Vue-Contrôleur (MVC)

View

Contrôleur

Modèle

créer et mettre à jour

modifier notifier changements

Reçoit les événements

des acteurs Vus par

les acteurs

Styles architecturaux

Architecture Modèle-Vue-Contrôleur (MVC)

Approprié pour les systèmes interactifs, particulièrement ceux impliquant plusieurs vues du même modèle de données. Peut être utilisé pour faciliter la maintenance de la cohérenceentre les données distribuées.

Désavantage: goulot d’étranglement possible.

Diviser pour régner: les composants peuvent être conçus assez indépendamment.

Cohésion: Meilleure cohésion que si les couches vue et contrôle étaient englobées dans une même couche interface utilisateur.

Couplage: Le nombre de canaux de communication entre les 3 composants est minimal.

Réutilisabilité: La vue et le contrôle peuvent être conçus à partir de composants déjà existant, développés pour différents types d’interaction avec l’utilisateur.

Flexibilité: Il est facile de changer l’interface utilisateur (en changeant la vue et/ou le contrôle).

Testabilité: On peut tester l’application indépendamment de l’interface utilisateur.

D. Architecture multi-couches

Dans un système par couches (fermé), chaque couche communique uniquement avec la couche immédiatement sous elle.

Chaque couche offre un service (serveur) aux couches externes (client) Service créé indépendamment du logiciel ou spécifiquement

La conception doit préciser le protocole d’interaction entre couches Toutes les couches ont accès à toutes les autres ? (système ouvert ou fermé) Une couche n’a accès qu’aux couches adjacentes ?

Relation hiérarchique privilégiée

Met à profit la notion d’abstraction, les couches externes sont plus abstraites (haut niveau) que les couches internes

Souvent utilisé pour les systèmes implémentant des protocoles de communication (TCP/IP…)

Styles architecturaux

(5)

Architecture multi-couches

1. Authentification 2. Gestion de clefs 3. Interface de fichiers 4.. Cryptographie Encrypter/décrypter un fichier

1. Entrée d’un mot de passe 2. Obtention d’une clef d’accès 3. Encryptage/décryptage du fichier 4. Fonctions d’encryptage/décryptage

Chaque couche a une interface bien définie utilisée par la couche juste au dessus (i.e. interne).

La couche supérieure (interne) voit la couche inférieur (externe) comme un ensemble de services.

Un système complexe peut être construit en superposant les couches de niveau d’abstraction croissant.

Il est important d’avoir une couche séparée pour l’IU.

Les couches juste au dessous de l’IU offrent les fonctions applicatives définies par les cas d’utilisation.

Les couches inférieures offrent les services généraux.

E.g. communication réseau, accès à la base de données.

Architecture multi-couches - fermée

Reference Model of Open Systems Interconnection (OSI model) Application

Présentation Session

Transport

Réseau

Ligne de données Physique Identifier et authentifier

une connexion Transformation des données (encryption,etc.)

Interface matérielle du réseau Transmission des data frames sans erreurs Transmission des

routing packets

Transmission (point à point) fiable des données

Architecture multi-couches - ouverte Swing user interface library

Styles architecturaux

Application

Swing AWT

X11

Architecture multi-couches

Styles architecturaux

Interface utilisateur

Logique applicative

Accès au système

d’exploitation Accès à la base de données

Communication réseau

Application programs

Screen display facilities

User account management

File system

Kernel (handling processes

and swapping

(6)

Architecture multi-couches

Diviser pour régner: Les couches peuvent être conçues séparément.

Cohésion: Si elles sont bien conçues, les couches présenter une cohésion par couche.

Couplage: Des couches inférieures bien conçues ne devraient rien savoir à propos des couches supérieures et les seules connexions autorisées entre couches se font via les API.

Abstraction: On n’a pas à connaître les détails d’implémentation des couches inférieures.

Réutilisabilité: Les couches inférieures peuvent être conçues de façon à offrir des solutions génériques réutilisables.

Architecture multi-couches

Réutilisation: On peut souvent réutiliser des couches développées par d’autres et qui proposent le service dont on a besoin.

Flexibilité: Il est facile d’ajouter de nouveaux services construits sur les services de plus bas niveau ou bien de remplacer une couche supérieure.

Anticipation du changement: En isolant les composants dans des couches distinctes, le système devient ainsi plus résistant à la désuétude.

Portabilité: Touts les services relatifs à la portabilité peuvent être isolés dans l’une des couches inférieures.

Testabilité: Les couches peuvent être testées indépendamment.

Conception défensive: Les API des couches constituent des endroits stratégiques pour insérer des assertions de vérification.

Styles architecturaux

E. Architecture n-parties (n-étages, n-tier)

Pour les logiciels distribués

Comparable à une architecture par couches… dont les couches seraient distribuées.

Par abus de langage, la notion de tier a pris le sens de couche distribuée

Architecture n-tiers

Client-serveur Trois tiers Quatre tiers

Styles architecturaux

Architectures n-parties

Architecture 2-tiers (client-serveur ou thick client)

Architecture 3-tiers(thin client)

Architecture 4-tiers

Client Données

Navigateur Web

Serveurs d’application (base de données Logique

applicative requête

de service requête

de service de B.D.

Logique applicative Présentation

Client Serveur

requête de service

(7)

Architecture client-serveur

Exemple typique: un système d’informations utilisant une base de données centrale. (cas spécial de l’architecture du repositoire)

Clients: recoivent les données de l’utilisateur, initient les transactions, etc.

Serveur: Exécute les transaction, assure l’intégrité des données, Par abus de langage, la notion de tiera pris le sens de couche distribuée

Plusieurs clients peuvent faire affaire avec plusieurs serveurs différents (contrairement à l’architecture repositoire…)

Une généralisation de l’architecture client-serveur: l’architecture peer-to-peer.

Les sous-systèmes peuvent à la fois être client et serveur.

Conception plus difficile: flot de contrôle plus complexe dû à la possibilité de deadlocks…

Architecture client-serveur

Client1

Client2

Client3

Serveur

<<communication>>

chercher adresse

<<communication>>

Échanger msg

<<communication>>

Échanger msg

<<communication>>

Échanger msg

<<communication>>

chercher adresse

netscape:WebBrowser iexplo:WebBrowser

lynx:WebBrowser

diro:WebServer

www.cmu.edu:WebServer

Styles architecturaux

Architecture 3-tiers

Organisation en trois couches:

Couche Interface: Composé d’objets interfaces (boundary objects) pour interagir avec l’utilisateur (fenêtres, formulaires, pages web, etc.)

Couche Logique applicative: Comporte tous les objets de contrôles et d’entités nécessaire pour faire les traitements, la vérification des règles et les notifications requises par l’application.

Couche de Stockage: Réalise le stockage, la récupération et la recherche des objets persistants.

Avantage p/r à l’architecture client-serveur:

Permet le développement et la modification de différentes interfaces utilisateurs pour la même logique applicative.

Architectures typiques

Architecture 3-parties

Base de données corporative

Dépôt de données Marché de

données Client X

Client Windows

Serveur de B.D. Unix

Serveur de B.D. Unix Réseau

Serveur Windows NT

Logique d’affaires

(8)

Architecture 3-tiers

Interface gestionnaire

Base de données clients

Gestion des dossiers

Remarque

•À noter que la tendance veut que la partie cliente soit de plus en plus mincei.e. le client ne fait qu’afficher un contenu html…

• La logique applicative est alors responsable de créer les pages web à afficher par le client.

•Or il serait bon de bien dissocier logique applicative et présentationdes données…

Architecture 4-tiers

Architecture 3-tiers dont la couche interface a été décomposée en :

Couche Présentation Client: Module logé sur les

machines des utilisateurs. (Affichage)

Couche Présentation Serveur: Module logé sur un

ou plusieurs serveurs. (Création du contenu à afficher)

Avantage p/r à l’architecture trois tiers:

Permet de supporter un grand nombre de formats de présentation différents (propres à chaque client), tout en réutilisant certains des objets de présentation entre les clients. Réduction des redondances…

Styles architecturaux

Architecture 4-tiers

Interface ATM

Gestion opérations bancaires

Présentation Serveur

Interface Web

Interface employé de la banque

Accès base de données comptes clients Java Server Pages

-Page client -Page serveur

Serveur

Clients Serveur de base

de données

<<build>>

<<submit>>

<<build>>

<<submit>>

Styles architecturaux

Architecture N-tiers

Diviser pour régner: De façon évidente, les parties client et serveur peuvent être développées séparément.

Cohésion: Le serveur peut offrir des services cohésifs au client.

Couplage: On retrouve généralement un seul canal de communication entre le client et le serveur, utilisé pour échanger des messages simples.

Réutilisation: il est possible de trouver un framework (librairie de composants, interfaces, etc.) adéquat à partir duquel on peut construire de bons systèmes distribués.

Toutefois, les systèmes client-serveur dépendent très souvent de nombreuses considérations liées intimement à l’application.

Flexibilité: Il est assez facile d’ajouter de nouveaux clients et serveurs.

Portabilité: On peut développer de nouveaux clients pour de nouvelles plateformes sans devoir porter le serveur.

Testabilité: On peut tester le client et le serveur indépendamment.

Conception défensive: On peut introduire des opérations de vérification dans le code traitant les messages reçus de part et d’autre.

(9)

Styles architecturaux

F. Cadre d’application pour composants (CORBA)

Plate-forme d’intégration de composants hétérogènes

Cadre d’application pour la réalisation de logiciels distribués

ORB (Object Request Broker)

Bus qui permet à des clients et à des serveurs de se connecter Les ORB sur différents réseaux peuvent communiquer ensemble

IDL (Interface Description Language)

Client Implémentation

de l’objet (serveur)

IDL stub IDL squeleton

ORB Interfaces de

domaines

requête Services CORBA (naming, persistence concurrency control, etc).

Corba facilities

architectural

Commencer par faire une esquisse de l’architecture

En se basant sur les principaux requis des cas d’utilisation;

décomposition en sous-systèmes

Déterminer les principaux composants requis;

Sélectionner un style architectural

Raffiner l’architecture

Identifier les principales interactions entre les composants et les interfaces requises

Décider comment chaque donnée et chaque fonctionnalité sera distribuée parmi les différents composants.

Déterminer si on peut réutiliser un framework existant (réutilisation) ou si on peut en construire un (réutilisabilité).

Considérer chacun des cas d’utilisation et ajuster l’architecture pour qu’il soit réalisable.

Détailler l’architecture et la faire évoluer.

Développer un modèle architectural

Décrire l’architecture avec UML

Tous les diagrammes UML peuvent être utiles pour décrire les différents aspects du modèle architectural.

Trois des diagrammes UML sont particulièrement utile our décrire une architecture logicielle:

Diagramme de packages

Diagramme de composants

Diagramme de déploiement

Développer un modèle architectural

Diagramme de packages

Package:Collection d’éléments de modélisation UML (e.g. classes, use cases, etc.) groupés ensemble car liés logiquement.

Il faut essayer de maximiser la cohésion au sein de package (éléments liés) et minimiser le couplage entre ceux-ci.

Dépendance: Un package est dépendant d’un autre s’il l’utilise…

SimpleChat Client

Common

OCSF Client

Server

<<import>>

(10)

Diagramme de composants

Offre une vue de haut niveau de l’architecture du système.

Utilisé pour décrire le système d’un point de vue implémentation.

Permet de décrire les composants d’un système et les interactions entre ceux-ci.

Illustre comment grouper concrètement et physiquement les éléments (objets, interfaces, etc.) du système au sein de modules qu’on appelle composants.

Qu’est-ce qu’un composant?

Unité autonomefaisant partie d’un système ou d’un sous-système qui encapsule un comportement (i.e. implémentation) et qui offre une ou plusieurs interfaces publiques.

Partie constituante d’un système qui peut être remplacée ou/et réutilisée.

Élément d’implémentation (un sous-système, un fichier exécutable, une classe d’implémentation (i.e. non abstraite), etc.) muni d’interface(s).

Chaque composant est le représentant d’une ou plusieurs classes qui implémentent un service à l’intérieur du système.

Granularité? Un composant peut représenter quelque chose d’aussi fin qu’un objet, comme il peut représenter un sous-système complexe.

Différence entre composant et instance de composant.

Composant: Vue haut niveau d’un élément logiciel qui compose le système.

(~classe)

Instance de composant: Le composant effectivement utilisé. (~objet)

Exemples de composants:

Binaire exécutable (<<executable>>), librairie dynamique/statique (<<librairy>>), un fichier à interpréter (<<file>>), etc.

Composant

Développer un modèle architectural

Composant et le principe de séparation des préoccupation

La séparation des préoccupation est le principe qui assure l’intégrité fonctionnelle d’un composant.

Chaque composant réalise une, et seulement une fonction au sein du système, mais peut néanmoins exposer plusieurs méthodes. Typiquement, chaque composant est défini par une interface qui constitue son seul moyen d’interagir avec les autres composants.

L’utilisation d’une interface pour communiquer avec les autres composants du système facilite la maintenance puisqu’on peut alors en changer l’implémentation sans affecter les autres composants (induit un couplage plus faibledu composant avec le reste du système).

Les classes d’un composant devrait être être vues comme un patron cohésifqui implément la fonctionnalité du composant.

Développer un modèle architectural

Composants et interfaces - Notation

Commande

EntréeCmdes

PaiementComptes Personne

composant

interface requise interfaces offertes

Commande

<<provided interfaces>>

EntréeCmdes PaiementComptes

<<required interface>>

Person

(11)

Composants et relations – notation

Une flèche de dépendance permet de mettre en relation des composant via les interfaces requises et celles fournies.

Système de commande

AccèsProduit

RechercheClient

Système d’inventaire

Repositoire Clients

RechercheClient

AccèsProduit

(3) dépendance

(1) composant

(2) interface

Composants et relations – notation

Planificateur

réservations

GUI

Gestionnaire d’horaires

réservations

mise à jour

Réunions_BD accèsBD

accèsBD

Développer un modèle architectural

Composants – Vue de la structure interne

Il est parfois utile de pouvoir montrer la structure interne d’un composant.

:Commande

Personne

:Produit

:Client

ItemCommandable

Magasin

EntréeCmdes

<<delegate>>

Compte

Compte EntréeCmdes

<<delegate>>

port

Assembly connector

Entête LigneCmde

*

Développer un modèle architectural

Diagramme de composants décrivant une architecture MVC

(12)

La Bouquinerie

Architecture 3-tiers (client plus lourd que dans la version 4-tiers)

Architecture 4-tiers (version web, basée sur la technologie JSP)

Remarque: Les interfaces n’apparaissent pas toutes sur les diagrammes.

Construction d’un diagramme de composants

Suivre l’approche présentée à la p.34 tout en respectant les principes de conception, tel que vu jusqu’ici (cf. chap. 5.3 pour les détails):

Diviser pour régner

Cohésion forte

Faible couplage

Abstraction

Réutilisabilité

Réutilisation

Etc.

Développer un modèle architectural

Diagramme de déploiement

GPS satellite

M1:MachineX

M2:MachineX

C1:Client C2:Client

S:Serveur Communication

sans fil

TCP/IP noeuds

lien

Machine de Joe:PC

Développer un modèle architectural

Diagramme de déploiement – exemple 1

:Planificateur

GUI

mise à jour

Admin:MachineHote :Gestionnaire

Horaires

:Réunions_BD réservations

Accès_bd internet

(13)