LOG 4430 Architecture logicielle et conception avance Foutse

LOG 4430 : Architecture logicielle et conception avancée Foutse Khomh Architectures – Partie 2/2 Département de génie informatique et de génie logiciel École Polytechnique de Montréal © Guéhéneuc, 2009; Khomh, 2010

5. Développer un modèle architectural n 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 n 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 cadriciel 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 n Détailler l’architecture et la faire évoluer n 2/19

Développer un modèle architectural n 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 n 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 cadriciel 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 n Détailler l’architecture et la faire évoluer n 3/19

Développer un modèle architectural n 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 pour décrire une architecture logicielle • Diagramme de packages • Diagramme de composants • Diagramme de déploiement 4/19

Développer un modèle architectural n Diagramme de packages – Paquetage = 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 des paquetages (éléments liés) et minimiser le couplage entre eux n Dépendance : un paquetage est dépendant d’un autre s’il l’utilise… Simple. Chat Client Common <<import>> OCSF Client Server 5/19

Développer un modèle architectural n 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 6/19

Développer un modèle architectural Composant n Qu’est-ce qu’un 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 soussystè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 de 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>>), bibliotheque dynamique/statique (<<librairy>>), 7/19 un fichier à interpréter (<<file>>)…

Développer un modèle architectural n Les composants et le principe de séparation des préoccupations – 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 vues comme un patron cohésif qui implémente la fonctionnalité du composant 8/19

Développer un modèle architectural n Composants et interfaces - Notation Entrée. Cmdes Personne Commande interface requise composant Paiement. Comptes interfaces offertes Commande <<provided interfaces>> Entrée. Cmdes Paiement. Comptes <<required interface>> Person 9/19

Développer un modèle architectural n Composants et relations – notation – Une flèche de dépendance permet de mettre en relation des composant via les interfaces requises et fournies Recherche. Client Système de commande Recherche. Client Repositoire Clients (3) dépendance (1) composant Accès. Produit (2) interface Système d’inventaire 10/19

Développer un modèle architectural n Composants et relations – notation réservations Planificateur réservations Gestionnaire d’horaires accès. BD mise à jour GUI accès. BD mise à jour Réunions_BD 11/19

Développer un modèle architectural n Composants – Vue de la structure interne – Pour montrer la structure interne d’un composant Magasin Entrée. Cmdes <<delegate>> : Commande Personne Entête port Entrée. Cmdes * : Client Ligne. Cmde Compte Item. Commandable <<delegate>> Assembly connector : Produit Compte 12/19

Développer un modèle architectural n Diagramme de composants MVC 13/19

Développer un modèle architectural n La Bouquinerie (c. f. démo 9) – Architecture 3 -niveaux (client plus lourd que dans la version 4 -niveaux) – Architecture 4 -niveaux (version web, basée sur la technologie JSP) – Remarque : les interfaces n’apparaissent pas toutes sur les diagrammes 14/19

Développer un modèle architectural n Construction d’un diagramme de composants – Diviser pour régner – Cohésion forte – Faible couplage – Abstraction – Réutilisabilité – Réutilisation – Etc. 15/19

Développer un modèle architectural n Diagramme de déploiement noeuds GPS satellite Communication sans fil M 2: Machine. X S: Serveur M 1: Machine. X C 1: Client TCP/IP lien C 2: Client 16/19

Développer un modèle architectural n Diagramme de déploiement – exemple 1 internet Machine de Joe: PC : Planificateur Admin: Machine. Hote mise à jour GUI : Gestionnaire Horaires réservations Accès_bd : Réunions_BD 17/19

Développer un modèle architectural n Diagramme de déploiement – exemple 2 18/19

Parmi les objectifs d’apprentissage n 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éfinir ce qu’est un composant – Expliquer le contenu décrit par un diagramme de paquetages, de composants et de déploiement (UML) – Décrire le modèle d’une architecture avec la notation 19/19 UML