IFT2251 : Génie logiciel

Julie Vachon, Hiver 2006 IFT2251 : Génie logiciel Chapitre 5. Conception Section 2. Conception architecturale Conception architecturale 1. Architecture logicielle 2. A. Architecture pipeline B. Architecture tableau noir C. Architecture MVC D. Architecture multi-couches E. Architecture n-tiers F. CORBA 3. UML et la modélisation des architectures Diagramme de packages Diagramme de composants Diagrammes de déploiement Chap.5, Sect.2, p.2 Copyrights Julie Vachon, 2006 5.2.1. Architecture logicielle Définition La définition de l architecture logicielle consiste à: Décrire l organisation générale d un système et sa décomposition en sous-systèmes. Déterminer les interfaces entre les sous-systèmes. Décrire les interactions et le flot de contrôle entre les soussystèmes. On décrira également les modules (classes, composants, etc.) utilisés pour implémenter les fonctionnalités des sous-système. Les propriétés des 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é. Chap.5, Sect.2, p.3 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.4 Copyrights Julie Vachon, 2006

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 Chap.5, Sect.2, p.5 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.6 Copyrights Julie Vachon, 2006 7.2.2 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. Filtrer l écho Décompresser Architecture pipeline Encodeur pour sortie de microphone Filtrer le bruit Encodeur de bruit ambiant Recevoir Retirer les fréquences non vocales Transmettre Égaliser les les intervalles dynamiques Compresser Filtre canal de communication synchro Chap.5, Sect.2, p.7 Copyrights Julie Vachon, 2006 Encoder la sortie des haut-parleurs Autre ex: Compilation d un programme : analyseur lexical, syntaxique, sémantique Chap.5, Sect.2, p.8 Copyrights Julie Vachon, 2006

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 Chap.5, Sect.2, p.9 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.10 Copyrights Julie Vachon, 2006 Le tableau noir (ou repositoire) Le tableau noir (ou repositoire) Analyseur syntaxique Analyseur sémantique Débugger Optimiseur Arbre syntaxique Compilateur Repositoire Générateur de code Table de symboles Éditeur syntaxique Analyseur lexical Flot de contrôle dirigé par le repositoire (triggers) ou par les soussystè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!) Chap.5, Sect.2, p.11 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.12 Copyrights Julie Vachon, 2006

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?? Vus par les acteurs Architecture Modèle-Vue-Contrôleur (MVC) View Modèle notifier changements créer et mettre à jour modifier Contrôleur Reçoit les événements des acteurs Chap.5, Sect.2, p.13 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.14 Copyrights Julie Vachon, 2006 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érence entre les données distribuées. Désavantage: goulot d étranglement possible. D un point de vue conception: 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 ) Chap.5, Sect.2, p.15 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.16 Copyrights Julie Vachon, 2006

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 Architecture multi-couches 4.. Cryptographie 3. Interface de fichiers 2. Gestion de clefs 1. Authentification 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. Chap.5, Sect.2, p.17 Copyrights Julie Vachon, 2006 Architecture multi-couches - fermée Reference Model of Open Systems Interconnection (OSI model) Application Présentation Transformation des données (encryption,etc.) Session Transmission des routing packets Identifier et authentifier une connexion Transport Réseau Transmission des data frames sans erreurs Transmission (point à point) fiable des données Interface matérielle du réseau Ligne de données Physique Chap.5, Sect.2, p.18 Copyrights Julie Vachon, 2006 Architecture multi-couches - ouverte Swing user interface library Application Swing AWT X11 Chap.5, Sect.2, p.19 Copyrights Julie Vachon, 2006 Interface utilisateur Logique applicative Accès au système d exploitation Architecture multi-couches Accès à la base de données Communication réseau Application programs Screen display facilities Kernel (handling processes and swapping User account management File system Chap.5, Sect.2, p.20 Copyrights Julie Vachon, 2006

D un point de vue conception: 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. Chap.5, Sect.2, p.21 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.22 Copyrights Julie Vachon, 2006 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 Architectures n-parties Architecture 2-tiers (client-serveur ou thick client) Architecture 3-tiers (thin client) Navigateur Web Architecture 4-tiers Client Client requête de service Présentation requête de service Logique applicative requête de service de B.D. Logique applicative Serveur Serveurs d application (base de données Données Chap.5, Sect.2, p.23 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.24 Copyrights Julie Vachon, 2006

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 tier a 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 Chap.5, Sect.2, p.25 Copyrights Julie Vachon, 2006 <<communication>> Échanger msg Client1 <<communication>> Échanger msg Architecture client-serveur Client2 <<communication>> chercher adresse Serveur <<communication>> Échanger msg <<communication>> chercher adresse Client3 iexplo:webbrowser netscape:webbrowser diro:webserver www.cmu.edu:webserver lynx:webbrowser Chap.5, Sect.2, p.26 Copyrights Julie Vachon, 2006 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. Chap.5, Sect.2, p.27 Copyrights Julie Vachon, 2006 Marché de données Architectures typiques Client X Architecture 3-parties Réseau Serveur de B.D. Unix Base de données corporative Client Windows Serveur Serveur de Dépôt de Windows NT B.D. Unix données Logique d affaires Copyrights Julie Vachon, Chap.5, Sect.2, p.28 2006

Interface gestionnaire Gestion des dossiers Base de données clients Architecture 3-tiers Remarque À noter que la tendance veut que la partie cliente soit de plus en plus mince i.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ésentation des données Chap.5, Sect.2, p.29 Copyrights Julie Vachon, 2006 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 Chap.5, Sect.2, p.30 Copyrights Julie Vachon, 2006 Java Server Pages -Page client -Page serveur Interface ATM Interface Web Clients <<submit>> Interface employé de la banque <<build>> <<build>> Architecture 4-tiers Serveur Présentation Serveur <<submit>> <<build>> Gestion opérations bancaires <<submit>> Serveur de base de données Accès base de données comptes clients Architecture N-tiers D un point de vue conception: 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. Chap.5, Sect.2, p.31 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.32 Copyrights Julie Vachon, 2006

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) Corba facilities Client IDL stub requête Implémentation de l objet (serveur) IDL squeleton Interfaces de domaines ORB Services CORBA (naming, persistence concurrency control, etc). Chap.5, Sect.2, p.33 Copyrights Julie Vachon, 2006 5.2.3 Développer un modèle 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. Chap.5, Sect.2, p.34 Copyrights Julie Vachon, 2006 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 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 <<import>> OCSF Client Server Chap.5, Sect.2, p.35 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.36 Copyrights Julie Vachon, 2006

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? Composant Unité autonome faisant 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. Chap.5, Sect.2, p.37 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.38 Copyrights Julie Vachon, 2006 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 faible du composant avec le reste du système). Les classes d un composant devrait être être vues comme un patron cohésif qui implément la fonctionnalité du composant. Chap.5, Sect.2, p.39 Copyrights Julie Vachon, 2006 Composants et interfaces - Notation Personne interface requise Commande composant Commande <<provided interfaces>> EntréeCmdes PaiementComptes <<required interface>> Person EntréeCmdes PaiementComptes interfaces offertes Chap.5, Sect.2, p.40 Copyrights Julie Vachon, 2006

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 (2) interface AccèsProduit AccèsProduit RechercheClient Système d inventaire RechercheClient (3) dépendance Repositoire Clients (1) composant Chap.5, Sect.2, p.41 Copyrights Julie Vachon, 2006 Planificateur Composants et relations notation mise à jour mise à jour réservations GUI réservations Gestionnaire d horaires Réunions_BD accèsbd accèsbd Chap.5, Sect.2, p.42 Copyrights Julie Vachon, 2006 Composants Vue de la structure interne Il est parfois utile de pouvoir montrer la structure interne d un composant. EntréeCmdes <<delegate>> :Commande port EntréeCmdes Entête LigneCmde * Magasin Personne :Client Compte Diagramme de composants décrivant une architecture MVC Assembly connector ItemCommandable :Produit <<delegate>> Compte Chap.5, Sect.2, p.43 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.44 Copyrights Julie Vachon, 2006

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. Chap.5, Sect.2, p.45 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.46 Copyrights Julie Vachon, 2006 Diagramme de déploiement Diagramme de déploiement exemple 1 GPS satellite Communication sans fil noeuds M2:MachineX S:Serveur Machine de Joe:PC :Planificateur internet Admin:MachineHote M1:MachineX C1:Client TCP/IP lien mise à jour GUI réservations :Gestionnaire Horaires Accès_bd C2:Client :Réunions_BD Chap.5, Sect.2, p.47 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.48 Copyrights Julie Vachon, 2006

Diagramme de déploiement exemple 2 Parmi les objectifs d apprentissage Expliquer les objectifs visés par la conception architecturale. Décrire le fonctionnement et les caractéristiques de chacun des styles architecturaux. Justifier le choix d une architecture pour la réalisation d un logiciel, en tenant compte de ses exigences fonctionnelles et non fonctionnelles. Décrire le modèle d une architecture avec la notation UML. Chap.5, Sect.2, p.49 Copyrights Julie Vachon, 2006 Chap.5, Sect.2, p.50 Copyrights Julie Vachon, 2006