CAGL-Cours-3 PDF

CAGL -Conception Architecturale en Génie Logiciel Chapitre 3 Les styles architecturaux Dr Boukhelfa Kamel NTIC/TLSI Kamel...

CAGL -Conception Architecturale en Génie Logiciel Chapitre 3 Les styles architecturaux Dr Boukhelfa Kamel NTIC/TLSI [email protected] Etudiants concernés Faculté/Institut Département Niveau Spécialité NTIC TLSI Master 1 Ingénierie des Logiciels et des Systèmes Intelligents Université Constantine 2 2024-2025. Semestre 1  Introdution Architecture Logicielle (AL) L'architecture logicielle est décrite comme l'organisation d'un système, où le système représente un ensemble de composants accomplissant un ensemble spécifique de fonctions. Le choix d’une architecture : dépend des exigences fonctionnelles et non fonctionnelles du logiciel Il doit favorise la stabilité : l’ajout de nouveaux éléments sera facile et ne nécessitera en général que des ajustements mineurs à l’architecture Influencé par certains « modèles connus » de décomposition en composants (styles architecturaux) et de mode d’interactions (e.g., orienté objet) Université Constantine 2 © Dr BOUKHELFA Kamel 2  Style architectural Le style architectural, également appelé patron architectural, est un ensemble de principes qui façonnent une application. Il définit un cadre abstrait pour une famille de systèmes en termes de modèle d'organisation structurelle. Le style architectural : Fournit un lexique de composants et de connecteurs avec des règles sur la manière dont ils peuvent être combinés. Améliore la partition et permet la réutilisation de la conception en apportant des solutions aux problèmes récurrents. Décrit une manière particulière de configurer un ensemble de composants (un module avec des interfaces bien définies, réutilisables, remplaçables) et des connecteurs (liens de communication entre les modules). Université Constantine 2 © Dr BOUKHELFA Kamel 3  Style architectural Le logiciel développé pour des systèmes informatiques adopte l'un des nombreux styles architecturaux. Chaque style décrit une catégorie de systèmes qui inclut : Un ensemble de types de composants réalisant les fonctions requises par le système. Un ensemble de connecteurs (appel de sous-programme, appel de procédure à distance, flux de données, socket) permettant la communication, la coordination et la coopération entre les composants. Des contraintes sémantiques définissant comment les composants peuvent être intégrés pour former le système. Une disposition topologique des composants indiquant leurs relations d'exécution. Etant un patron, un style architectural constitue un modèle éprouvé et enrichi par l’expérience de plusieurs développeurs  Compréhensibilité, maintenance, évolution, réutilisation, performance, documentation, etc. Université Constantine 2 © Dr BOUKHELFA Kamel 4  Classification des styles architecturaux Les styles architecturaux qui peuvent être organisés en fonction de leur domaine d’intérêt principal (communication, déploiement, structure, etc.) : Architecture pipeline : Convient bien aux systèmes de traitement et de transformation de données; Architecture centrée sur les données : Utilisée dans le cas où des données sont partagées et fréquemment échangées entre les composants; Architecture Modèle-Vue-Contrôleur (MVC) : Séparer la couche interface utilisateur des autres parties du système Architecture multi-couches : Diviser les préoccupations de l'application en groupes empilés (couches) Architecture distribuée (n-niveaux, client/serveur,…) : Sépare la fonctionnalité en segments distincts, chaque segment étant un niveau situé sur un ordinateur physiquement distinct. Université Constantine 2 © Dr BOUKHELFA Kamel 5  Architecture pipeline C’est un type d’ architecture de flux de données. Elle Convient bien aux systèmes de traitement et de transformation de données (traitement de texte, de traitement de signaux, compilateur (analyse lexicale, syntaxique, sémantique)) Composants = filtre ; Connecteur = canal Filtre Traite indépendamment et asynchrone Reçoit ses données d’un ou plusieurs canaux d’entrée, effectue la transformation/traitement des données et envoie les données de sortie produites sur un ou plusieurs canaux de sorties Fonctionnent en concurrence. Chacun traite les données au fur et mesure qu’il les reçoit Canal Unidirectionnel au travers duquel circulent un flot de données (stream). Synchronisation et utilisation d’un tampon parfois nécessaire pour assurer la bon fonctionnement entre filtre producteur et filtre consommateur Université Constantine 2 © Dr BOUKHELFA Kamel 6  Architecture pipeline Exemple : Système de traitement du son Université Constantine 2 © Dr BOUKHELFA Kamel 7  Architecture pipeline Avantages Bon pour traitement en lot (batch) et offre un débit élevé pour le traitement massif de données, Simple en proposant des divisions claires entre deux filtres connectés par un canal. Très flexible en supportant à la fois l'exécution séquentielle et parallèle. Analyse facilitée : performance, synchronisation, goulot d’étranglement, etc. Se prête bien à la décomposition fonctionnelle d’un système dû au faible couplage entre les filtres. Inconvénients Pas adapté pour des interactions dynamiques. Mauvais pour le traitement interactif Surcharge liée à la transformation des données entre filtres. Ne permet pas aux filtres de coopérer pour résoudre un problème. Difficile de configurer dynamiquement cette architecture. Université Constantine 2 © Dr BOUKHELFA Kamel 8  Architecture centrée sur les données Dans l'architecture centrée sur les données, les données sont centralisées et fréquemment accessibles par d'autres composants qui les modifient. L'objectif principal de ce style est d'assurer l'intégrité des données. L'architecture centrée sur les données se compose de différents composants qui communiquent via des dépôts de données partagés. Les composants accèdent à une structure de données partagée et sont relativement indépendants, n'interagissant qu'à travers le magasin de données. Les exemples les plus connus de l'architecture centrée sur les données incluent : L'architecture de base de données, où un schéma de base de données commun est créé avec un protocole de définition des données (par exemple, un ensemble de tables liées avec des champs et des types de données dans un SGBDR). L'architecture web, qui possède un schéma de données commun (c'est-à-dire une méta- structure du Web) et suit le modèle de données hypermédia, les processus communiquant via des services de données partagés basés sur le web. Université Constantine 2 © Dr BOUKHELFA Kamel 9  Architecture centrée sur les données Types de composants : Il existe deux types de composants : Une structure de données centrale, un dépôt de données ou un référentiel de données qui est responsable du stockage permanent des données. Il représente l'état actuel. Un accesseur de données ou une collection de composants indépendants qui opèrent sur le référentiel de données central, effectuent des calculs et peuvent être utilisés pour la gestion de l'information. Les interactions ou la communication entre les accesseurs de données se font uniquement par l'intermédiaire du référentiel de données. Les données sont le seul moyen de communication entre les clients. Le flux de contrôle différencie l'architecture en deux catégories : - Style d'architecture du référentiel - Style d'architecture du tableau noir Université Constantine 2 © Dr BOUKHELFA Kamel 10  Architecture avec référentiel de données L’ architecture avec référentiel de données (shared data) : Utilisée dans le cas où des données sont partagées et fréquemment échangées entre les composants - Largement utilisée dans les SGBD, les systèmes d'information de bibliothèque, le référentiel d'interface dans CORBA, les compilateurs et les environnements CASE (ingénierie logicielle assistée par ordinateur). Deux types de composants : référentiel de données et accesseur de données Les référentiels constituent le medium de communication entre les accesseurs Connecteur : relie un accesseur à un référentiel Rôle de communication, mais aussi possiblement de coordination, de conversion et de facilitation Université Constantine 2 © Dr BOUKHELFA Kamel 11  Architecture avec référentiel de données Exemple : Environnement de programmation Université Constantine 2 © Dr BOUKHELFA Kamel 12  Architecture avec référentiel de données Avantages Offre des fonctions d'intégrité, de sauvegarde et de restauration des données. Permet l'extensibilité et la réutilisation des agents car ils ne communiquent pas directement entre eux. Réduit la charge de travail liée aux données transitoires entre les composants logiciels. Inconvénients Il est plus vulnérable aux défaillances et la réplication ou la duplication des données est possible. Forte dépendance entre la structure des données du magasin de données et ses agents. Les modifications de la structure des données affectent fortement les clients. L'évolution des données est difficile et coûteuse. Université Constantine 2 © Dr BOUKHELFA Kamel 13  Style Tableau noir (Blackboard) Dans le style d'architecture Blackboard, le référentiel de données est actif et ses clients sont passifs. Par conséquent, le flux logique est déterminé par l'état actuel des données dans le référentiel. Un composant tableau noir, qui agit comme un dépôt de données central, et une représentation interne est construite et exploitée par différents éléments de calcul.  Un certain nombre de composants qui agissent indépendamment sur la structure de données commune sont stockés dans le tableau noir.  Les composants n'interagissent que par l'intermédiaire du tableau noir. Le dépôt de données alerte les clients chaque fois qu'il y a un changement de données.  Le système envoie aux clients des notifications appelées « trigger » (déclencheur) et « data » (données) lorsque des changements interviennent dans les données.  Cette approche se retrouve dans certaines applications d'intelligence artificielle et dans des applications complexes, telles que la reconnaissance vocale, la reconnaissance d'images, les systèmes de sécurité et les systèmes de gestion des ressources de l'entreprise, etc.  Une différence majeure avec les systèmes de base de données traditionnels est que l'invocation des éléments de calcul dans une architecture de tableau noir est déclenchée par l'état actuel du tableau noir, et non par des entrées externes. Université Constantine 2 © Dr BOUKHELFA Kamel 14  Style Tableau noir (Blackboard) Composants du modèle Tableau noir : Le modèle de tableau noir se présente généralement sous la forme de trois parties principales : Sources de connaissances (KS : Knowledge Sources) : également appelées auditeurs ou abonnés, sont des unités distinctes et indépendantes. L'interaction entre les sources de connaissances se fait uniquement par l'intermédiaire du tableau noir. Structure des données du tableau noir : Les données relatives à l'état de la résolution du problème sont organisées selon une hiérarchie dépendant de l'application. Les sources de connaissances apportent des modifications au tableau noir qui conduisent progressivement à une solution au problème. Contrôle : Le contrôle gère les tâches et vérifie l'état du travail. Université Constantine 2 © Dr BOUKHELFA Kamel 15  Style Tableau noir (Blackboard) Université Constantine 2 © Dr BOUKHELFA Kamel 16  Style Tableau noir (Blackboard) Avantages Offre une évolutivité qui permet d'ajouter ou de mettre à jour facilement les sources de connaissances. Assure la simultanéité qui permet à toutes les sources de connaissances de travailler en parallèle car elles sont indépendantes les unes des autres. Permet la réutilisation des sources de connaissances. Inconvénients Le changement de structure du tableau noir peut avoir un impact significatif sur tous ses agents (KS) car il existe une dépendance étroite entre le tableau noir et la source de connaissances. Problèmes de synchronisation de plusieurs agents. Défis majeurs dans la conception et le test du ce type de système. Université Constantine 2 © Dr BOUKHELFA Kamel 17  Architecture Modèle-Vue-Contrôleur (MVC) Modèle-Vue-Contrôleur (MVC) est l’un des principaux style de l'architecture orientée interaction (avec le modèle PAC : Présentation- Abstraction-Contrôle). Il est utilisé pour les applications interactives telles que les applications web avec des discussions multiples et des interactions avec l'utilisateur. Ils se distinguent par leur flux de contrôle et leur organisation. 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)  Le MVC décompose une application logicielle donnée en trois parties interconnectées : Modèle : rassemble des données du domaine, des connaissances du système. Contient les classes dont les instances doivent être vues et manipulées Vue : utilisé pour présenter/afficher les données du modèle dans l’interface utilisateur Contrôleur : contient les fonctionnalités nécessaires pour gérer et contrôler les interactions de l’utilisateur avec la vue et le modèle Université Constantine 2 © Dr BOUKHELFA Kamel 18  Architecture Modèle-Vue-Contrôleur (MVC) Université Constantine 2 © Dr BOUKHELFA Kamel 19  Architecture Modèle-Vue-Contrôleur (MVC) Le modèle est constitué de composants de données qui maintiennent les données brutes de l'application ainsi que la logique de l'application pour l'interface. Modèle : composant central du patron MVC. Noyau de l’application Gère directement les données, la logique et les contraintes d'une application. Enregistre les vues et les contrôleurs qui en dépendent Notifie les composants dépendants des modifications aux données Vue : interface (graphique) de l’application Crée et initialise ses contrôleurs Affiche les informations destinées aux utilisateurs Implante les procédure de mise à jour nécessaires pour demeurer cohérente Consulte les données du modèle Contrôleur : partie de l’application qui prend les décisions Accepte les événement correspondant aux entrées de l’utilisateur Traduit un événements (1) en demande de service adressée au modèle ou bien (2) en demande d’affichage adressée à la vue Implémente les procédures indirectes de mise à jour des vues si nécessaire Université Constantine 2 © Dr BOUKHELFA Kamel 20  Architecture Modèle-Vue-Contrôleur (MVC) Applications du modèle MVC L'adoption du modèle MVC est efficace pour les applications interactives où : plusieurs vues sont nécessaires pour un modèle de données unique il est facile d'ajouter une nouvelle vue ou de modifier l'interface. Le modèle MVC convient aux applications pour lesquelles il existe des divisions claires entre les modules, de sorte que différents professionnels peuvent être chargés de travailler simultanément sur différents aspects de ces applications. MVC est devenu une norme, ce pattern est donc utilisé partout dans le monde du développement. ASP.NET MVC, s’appuyant sur le Framework.NET ; QT, en C++ ; Backbone.js, en JavaScript ; Angular, en TypeScript ; Spring et Struts, en Java ; La plupart si ce n’est tous les frameworks PHP (Symfony, CakePHP, Laravel, etc.) ; Django, avec Python ; Ruby on Rails, en Ruby. Université Constantine 2 © Dr BOUKHELFA Kamel 21  Architecture Modèle-Vue-Contrôleur (MVC) Avantages De nombreuses boîtes à outils MVC sont disponibles pour les développeurs. Plusieurs vues peuvent être synchronisées avec un même modèle de données. Il est facile d'ajouter ou de remplacer des vues d'interface utilisateur. Adapté au développement d'applications dans lesquelles des experts en conception graphique, en programmation et en bases de données collaborent au sein d'une même équipe. Inconvénients : Inadapté aux applications orientées agents, comme les applications interactives mobiles ou robotiques. La gestion de multiples paires contrôleur-vue basées sur un même modèle de données peut rendre les modifications de ce modèle coûteuses. La séparation entre la vue et le contrôleur n’est pas toujours claire dans certaines situations. Université Constantine 2 © Dr BOUKHELFA Kamel 22  Architecture multi-couches Diviser les préoccupations de l'application en groupes superposés (couches) : Chaque couche est un composant avec une interface bien définie utilisée par la couche juste au dessus (i.e., externe) La couche supérieure (externe) voit la couche inférieur (interne) comme un ensemble de services offerts 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 les plus basses offrent les services généraux (communication réseau, accès à la base de données, …) Université Constantine 2 © Dr BOUKHELFA Kamel 23  Architecture multi-couches Exemples d’Architecture en multi-couches Université Constantine 2 © Dr BOUKHELFA Kamel 24  Architecture multi-couches Modèle de référence de l'interconnexion des systèmes ouverts (modèle OSI) Université Constantine 2 © Dr BOUKHELFA Kamel 25  Architecture multi-couches Caractéristiques D’un point de vue conception, voici quelques points caractérisant : 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 ne devraient rien savoir à propos des couches supérieures et les seules connexions autorisées entre couches se font via les API Abstraction : ne pas connaître les détails d’implémentation des couches inférieures Réutilisation : on peut souvent réutiliser des couches développées par d’autres et qui proposent le service requis Flexibilité : Ajout aisé de nouveaux services construits sur les services de plus bas niveau Portabilité : tous les services relatifs à la portabilité peuvent être isolés 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 Université Constantine 2 © Dr BOUKHELFA Kamel 26  Architecture multi-couches L'architecture en couches offre plusieurs avantages : Autonomie des couches : Les modifications apportées à une couche n'ont pas d'impact sur les autres. Cela permet d'ajouter des fonctionnalités à une couche, comme rendre une application initialement conçue pour les PC compatible avec les téléphones et les tablettes, sans devoir réécrire l'ensemble de l'application. Personnalisation améliorée : Cette architecture facilite la personnalisation du système. Cependant, elle présente aussi certains inconvénients majeurs : Complexité de maintenance : Chaque modification nécessite une analyse approfondie, ce qui complique la maintenance de l'application. Impact sur les performances : L'architecture en couches peut introduire une surcharge, car chaque couche supérieure doit se connecter aux couches inférieures lors de chaque opération, ce qui peut ralentir l'exécution du système. Université Constantine 2 © Dr BOUKHELFA Kamel 27  Architecture distribuée Dans cette architecture, les composants sont présentés sur différentes plates-formes et plusieurs composants peuvent être sur un réseau de communication afin d'atteindre un objectif ou un but spécifique. Le traitement de l'information n'est pas confiné à une seule machine, mais réparti sur plusieurs ordinateurs indépendants. Un système distribué peut être illustré par l'architecture client-serveur qui constitue la base des architectures à plusieurs niveaux ; les alternatives sont l'architecture de BROCKER (courtier) telle que CORBA, et l'architecture orientée service (SOA). Il existe plusieurs Frameworks technologiques pour soutenir les architectures distribuées, notamment.NET, J2EE, CORBA,.NET Web services, AXIS Java Web services et Globus Grid services. Le Middleware (Intergiciel) est une infrastructure qui prend en charge de manière appropriée le développement et l'exécution d'applications distribuées. Il sert de tampon entre les applications et le réseau. Les exemples sont les moniteurs de traitement des transactions, les convertisseurs de données et les contrôleurs de communication, etc. L'objectif principal d'une architecture distribuée est de fournir de la transparence, de la fiabilité et de la disponibilité. Université Constantine 2 © Dr BOUKHELFA Kamel 28  Architecture distribuée Architecture client-serveur L'architecture client-serveur est l'architecture de système distribué la plus courante. Elle décompose le système en deux sous-systèmes principaux ou processus logiques : Client : Il s'agit du premier processus qui émet une demande au second processus, c'est-à-dire au serveur. Serveur : Il s'agit du second processus qui reçoit la demande, l'exécute et envoie une réponse au client. Dans cette architecture, l'application est modélisée comme un ensemble de services fournis par des serveurs et un ensemble de clients qui utilisent ces services. Les serveurs n'ont pas besoin de connaître les clients, mais les clients doivent connaître l'identité des serveurs, et la correspondance entre les processeurs et les processus n'est pas nécessairement 1 : 1. Université Constantine 2 © Dr BOUKHELFA Kamel 29  Architecture distribuée L'architecture client-serveur peut être classée en deux modèles selon la fonctionnalité du client : Modèle « client léger » : tout le traitement de l'application et la gestion des données sont assurés par le serveur. Le client est simplement chargé d'exécuter le logiciel de présentation. Utilisé fréquemment lors de la migration des systèmes existants vers des architectures client-serveur dans lesquelles le système existant agit comme un serveur à part entière avec une interface graphique mise en œuvre sur un client. L'inconvénient majeur de ce modèle est qu'il impose une lourde charge de traitement au serveur et au réseau. Modèle de « client lourd » : le serveur n'est responsable que de la gestion des données. Le logiciel sur le client met en œuvre la logique de l'application et les interactions avec l'utilisateur du système. Plus approprié pour les nouveaux systèmes C/S où les capacités du système client sont connues à l'avance. Plus complexe qu'un modèle de client léger, en particulier pour la gestion. Les nouvelles versions de l'application doivent être installées sur tous les clients. Université Constantine 2 © Dr BOUKHELFA Kamel 30  Architecture distribuée Architecture n-niveaux (n-tier) C’est une architecture client-serveur dans laquelle les fonctions telles que la présentation, le traitement des applications et la gestion des données sont physiquement séparées. En séparant une application en plusieurs niveaux, les développeurs ont la possibilité de modifier ou d'ajouter une couche spécifique, au lieu de retravailler l'ensemble de l'application. Il s'agit d'un modèle qui permet aux développeurs de créer des applications flexibles et réutilisables, Ici les couches sont distribuées et la notion de « tier » a pris le sens de couche distribuée Composants : chaque niveaux est représenté par un composant qui joue le rôle de client et/ou de serveur Connecteurs : relient un client à un serveur. Connexion asymétrique. Doit supporter les communication distantes (requêtes RPC, HTTP, TCP/IP) Exemples : Client-serveur, Trois niveaux, Quatre niveaux Université Constantine 2 © Dr BOUKHELFA Kamel 31  Architecture distribuée Université Constantine 2 © Dr BOUKHELFA Kamel 32  Architecture distribuée Architecture 3-niveaux 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ôle 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 : Permet le développement et la modification de différentes interfaces utilisateurs pour la même logique applicative Université Constantine 2 © Dr BOUKHELFA Kamel 33  Architecture distribuée Université Constantine 2 © Dr BOUKHELFA Kamel 34  Architecture distribuée Architecture 4-niveaux Architecture dont la couche logique applicative est décomposée en Couche Présentation (JSP, servlets)  Présentation du contenu statique: Contenu HTML ou XML affiché par le client  Présentation du contenu dynamique : contenu organisé et créé dynamiquement par le serveur web (pour ensuite être affiché en HTML/XML par le client) Couche Logique applicative (calculs purs) : réalise le cœur des traitements de l’application Avantage : Toutes les parties de l'application peuvent désormais être mises à niveau de manière indépendante. Plus évolutif que le système à trois niveaux grâce à la réplication dans chaque niveau Différents types de clients peuvent partager la même logique d'application : Clients web, clients Phone/PDA, Clients Web lourds Université Constantine 2 © Dr BOUKHELFA Kamel 35  Architecture distribuée Architecture à 4 niveaux Exemple d’application à 4 niveaux Université Constantine 2 © Dr BOUKHELFA Kamel 36