ESTM 3ème année Télé-Informatique 2019-2020 1 ❑Les Vues Architecturales(1/4) ❑ Une Vue, Une vue définit un raffinement d’une architecture, d’un environnement ou d’un système en fonction d’un axe d’intérêt. ❑ L’architecture est donc étudiée selon un point de vue particulier (aussi, appelée une facette), ce qui facilite sa définition et sa mise eu point. ❑ Il est important de séparer la description de l'architecture en différents points de vue afin qu'un seul acteur puisse comprendre les différents aspects de l'architecture. ❑Philippe Krutchen de Rational software divise l’architecture en 5 vues appelé aussi le modèle de vue 4+1 ❑ Vue logique(Logical view) qui décrit les besoins fonctionnels, c’est à dire les services à rendre aux utilisateurs ❑ Vue Procedurale(Process view) qui décrit les aspects de concurrence, de synchronisation, de tolérance aux fautes et de performance. 2 ❑Les Vues Architecturales(2/4) ❑ Vue de distribution(physical view) qui décrit le placement du logiciel sur le matériel et décrit les aspects répartis. ❑ Vue développement (development view) qui décrit l’organisation statique des composants logiciels et de l’environnement de développement. ❑ Les scenarios(use case) qui sont des exemples de mise en pratique des quatre vues précédentes.
3 ❑Les Vues Architecturales(3/4)
4 ❑Les Vues Architecturales(4/4)
❑ L’utilisation de toutes les vues n’est pas obligatoire.
Chacune de ces vues utilisent ses propres notations et un ou plusieurs styles architecturaux. ❑ Chaque architecte gère donc différentes vues contenant des éléments qui sont adaptés à son métier. ❑ Il en résulte donc une simplicité de conception (chaque vue isolant une seule facette du problème) ❑ et un meilleur travail en groupe (chaque spécialiste d’une facette d’un système concevant son modèle en utilisant un style architectural adapté et pas forcément uniforme à toutes les vues). 5 ❑Styles et Patrons d’architecture
❑ Styles(Macro pattern) • Structure de haut niveau pour décrire un logiciel de point de vue global • Exemple : Modele en couches, MVC, etc. ❑ Patrons(Micro pattern) • Solutions abstraites application à différents contextes mais qui offrent les avantages à chaque utilisation • Exemple : les design patterns ❑ Idiomes : décrivent les bonnes pratiques liées à: • Un formalisme de programmation • A un langage particulier
6 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. ❑ Permettre 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 7 Avantages d’utiliser des styles architecturaux ❑ 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 8 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 • Fonctionnalites requises du système ❑ Propriétés non-fonctionnelles • Maintenabilites • Evolution, adaptation ou correction du système • Disponibilité • Performance • Interopérabilité • Robustesse • Gestion des erreurs • Tolérance aux fautes • Sécurité 9 Principaux styles architecturaux ❑ En couche • Machine virtuelle ❑ Interactif • Client-Serveur • MVC, MVVM, MVI • N-tiers ❑ Embarqué ❑ Data-flow • Sense-Compute-Control • Batch sequential ❑ Interpreteur • Pipe and filter • Interpréteur ❑ Shared memory • Code Mobile • Blackboard ❑ Invocation Implicite • Systemes à base de règles • Event-based ❑ Adaptatif • Publish-subscribe • MicroKernel ❑ Peer to peer • Reflexive • Plug-in
10 Architecture en Couche(Layers) ❑ Couches (Layers) • Organisation en couches de composantes offrant des groupes de services • Échanges limités aux composantes de la couche sous- jacente • Principe des machines virtuelles
11 Architecture en Couche(Layers) ❑ Client-Serveur • Modele à deux couches • La base des systèmes distribues • Les données sont distribuées dans un ensembles de composantes • Le traitement est reparti parmi les composantes
• Composantes • Serveurs : fournissent des services • Clients : utilisent ces services
• Connecteurs • RPC • Protocole réseau
12 Architecture en Couche(Layers) ❑ Modèle 3-tiers • Cas particulier d’un : • Modele en couche • Modele client-serveur
• Autre denomination : • State-Logic-Display
• Roles des niveaux:
• Representation • Logique d’application • Données(état du système)
13 Style d’architecture Interactif ❑ Model-Vue-Controler • Applications interactives - GUI • Modele : • 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 • Controleurs: • traitent les entrées (événements) en provenance des vues et du système et les traduit en operations effectuées sur le modele • Un contrôleur pour chacune des vues
18 Style d’architecture flow de données ❑ Batch sequential • Style de flot de données (dataflow) • Un des style le plus anciens • Repose sur la conversion d’un flux de données • Pour les applications de systèmes financiers
19 Style d’architecture flow de données ❑ Pipelines (Pipes and filters) • Inspiré de la composition de fonctions en unix • ls /dev | grep -e tty | sort • Composantes de transformation (Filtres) • Les filtres sont des unites de traitement qui sont spécifiées uniquement pas les entrees qu’elles acceptent est les sorties qu’elles produisent • Les filtres ne partage pas d’état entre eux • Les filtres n’ont pas d’interactions entre eux • Composantes de communication(Pipes) • Les pipes sont des connecteurs • Ils relient les composantes sources et composantes réceptrices • Ils propagent les données entre elles
❑ Une application peut être découpée en trois niveaux d’abstraction
❖ Niveau présentation ❖ Niveau logique applicative ❖ Niveau données
Traitements
globaux Locaux
Données Présentations
Logique applicative
22 ❑Niveaux d’abstraction ❑ La couche de présentation, ou IHM (Interface Homme Machine), permet l'interaction de l'application avec l'utilisateur. Ce sont : les saisies au clavier, avec la souris et l’affichage des informations à l'écran. ❑ La logique applicative décrit les traitements à réaliser par l'application pour répondre aux besoins des utilisateurs. ❑ Traitements locaux: les contrôles effectués au niveau du dialogue avec l'IHM (formulaires, champs, boutons radio…) ❑ Traitements globaux: les règles de l’application, appelées aussi logique métier (Business Logic).
❑ L'accès aux données permet la gestion des informations stockées par
l'application. Fonctions classiques d’un SGBD : Définition de données, Manipulation de données, Sécurité de données et Gestion de transactions. 23 ❑Architectures logicielles Le découpage et la répartition de 3 niveaux d’abstraction permettent de distinguer les architectures suivantes. ❑ Architecture 1-tiers : MainFrame ❑ Architecture 2-tiers : Client/Serveur ❑ Architecture 3-tiers et N-tiers ❑ Architecture orientée service
24 ❑Architecture 1-tier : Mainframe ❑ Les utilisateurs se connectent aux applications exécutées par le serveur central (mainframe) à l'aide de terminaux passifs. ❑ le serveur central prend en charge la gestion des données et des traitements, y compris l'affichage qui est transmis sur des terminaux passifs. ❑ Architecture adoptée durant les année 1970-1980.
Mainframe AS/400
21 ❑Architecture 2-tiers: Client/serveur ■ Architecture 2-tiers ou Client/Serveur. Les applications de cette architectures sont réparties sur deux types de machines: ❖ Machine Client: ❑ Elle Effectue une demande de service auprès du serveur (requêtes)
❑ Elle initie le contact (parle en premier), ouvre la session
❖ Machine serveur : ❑ Elle est la partie de l'application qui offre un service ❑ Elle est à l'écoute des requêtes clientes ❑ Elle répond au service demandé par le client (réponse)
26 ❑Architecture Client/serveur (2) ❑ Classes des applications Client/ serveur selon Gartner Group
❑ Avantages ❖ Utilisation d'une interface utilisateur riche, ❖ Appropriation des applications par l'utilisateur, ❖ Introduction de la notion d'interopérabilité
❑ Inconvénients ❖ Problèmes d’intégration ❖ Efforts de sécurité ❖ Problèmes d’administration réseau ❖ Coûts de déploiement et de maintenance
28 ❑Architecture 3-tiers: Web dynamique
❑ La présentation est toujours prise en charge par le poste client.
❑ La logique applicative est prise en charge par un serveur intermédiaire : c’est le serveur applicatif. ❑ Les données sont toujours gérées de façon centralisée. Elles sont gérées par un système de gestion de bases de données
29 ❑Architecture N-tiers(1) ❑ Le serveur d’application de l’architecture 3-tiers est décomposé en plusieurs serveurs d’application( par exemple un serveur par région ). ❑ L’avantage de l’architecture N-tiers par rapport à celle 3-tiers est en terme de performance. C’est-à-dire, le délai de réponse aux requêtes Clients.
30 ❑Architecture N-tiers(2)
Principales fonctionnalités d’un serveur Web :
❑ Réceptionner la requête ❑ Ré-router les requêtes dynamiques ❑ Rechercher les pages statiques ❑ Encapsuler les pages dans la réponse ❑ Émettre la réponse
31 ❑Architecture N-tiers(3)
Les principales fonctionnalités d’un serveur d’application sont :
❑ Réceptionner la requête ❑ Construire la réponse dynamique ❑ Renvoyer la réponse au serveur Web
32 ❑Architecture N-tiers (4)
■ Les fonctionnalités d’un serveur d’application :
La production de contenu dynamique Le support des plates-formes L'ouverture vers l'existant Le pooling de connexions Le respect des standards L'administration La reprise sur incident La répartition de charges La sécurité La gestion de contexte
33 ❑Architecture N-tiers(5)
❑ Avantages ❖ Le poste client ne supporte plus des traitements à réduire les coûts liés au déploiement et à la maintenance. ❖ les ressources réseau sont mieux exploitées. En effet, les traitements applicatifs sont centralisés ❖ la fiabilité et les performances de certains traitements sont améliorées par leur centralisation. ❖ Prise en charge simple d’une forte montée en charge en renforçant le service applicatif. ❑ Inconvénients ❖ Une expertise de développement, plus longue que dans le cadre d'une architecture 2-tiers, est nécessaire. ❖ Les coûts de développements sont plus élevés que pour du 2-tiers.
34 ❑Architecture orientée services (SOA)
❑ Style d’architecture distribuée qui permet de fournir ou
consommer un processus métier en tant que service. ❑ Offre des services réutilisables et interopérables via des interfaces standards (construites autour de XML). ❑ Plusieurs partenaires peuvent communiquer et échanger des données dans le contexte de SOA indépendamment des Plateformes et langages.
35 ❑Architecture orientée services (SOA) (2) ❑ Paradigme de SOA publication recherche Registre de service
Fournisseur de Consommateur service de service invoque
❑ Fournisseur de service : ❖ Fournit un service accessible via une adresse ❖ publie son contrat dans le registre de services ❖ et exécute les requêtes des consommateurs ❑ Consommateur de service : application, service… ❖ Cherche le service dans le registre (son adresse) ❖ Se lie dynamiquement au service (binding) ❖ Invoque le service via une requête conforme au contrat ❑ Registre de services : Annuaire des contrats de services ❖ un Contrat décrit le format d’échange (format des requête/réponse, les pré et post conditions du service et sa QoS, ex: temps de réponse). 32
