LOG4430 : Architecture logicielle et conception avancée

LOG4430 :Architecture logicielle et conception avancée Architectures – Partie 2/2

5. 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 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 • Détailler l’architecture et la faire évoluer

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 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 • 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 pour décrire une architecture logicielle • Diagramme de packages • Diagramme de composants • Diagramme de déploiement

OCSF SimpleChat Client Client Common Server Développer un modèle architectural • 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 • Dépendance : un paquetage est dépendant d’un autre s’il l’utilise… <<import>>

Développer un modèle architectural • 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é 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 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>>), un fichier à interpréter (<<file>>)… Composant Développer un modèle architectural

Développer un modèle architectural • 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

Commande <<provided interfaces>> EntréeCmdes PaiementComptes <<required interface>> Person Développer un modèle architectural • Composants et interfaces - Notation EntréeCmdes Commande Personne PaiementComptes interface requise composant interfaces offertes

Développer un modèle architectural • Composants et relations – notation • Une flèche de dépendance permet de mettre en relation des composant via les interfaces requises et fournies RechercheClient Repositoire Clients Système de commande RechercheClient (3) dépendance (1) composant AccèsProduit AccèsProduit Système d’inventaire (2) interface

Développer un modèle architectural • Composants et relations – notation réservations Gestionnaire d’horaires Planificateur réservations accèsBD mise à jour GUI accèsBD mise à jour Réunions_BD

Développer un modèle architectural • Composants – Vue de la structure interne • Pour montrer la structure interne d’un composant Magasin EntréeCmdes <<delegate>> :Commande Personne :Client Entête port EntréeCmdes LigneCmde * Compte ItemCommandable <<delegate>> :Produit Assembly connector Compte

Développer un modèle architectural • Diagramme de composants MVC

Développer un modèle architectural • 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

Développer un modèle architectural • Construction d’un diagramme de composants • 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 M2:MachineX noeuds GPS satellite Communication sans fil S:Serveur M1:MachineX C1:Client lien TCP/IP C2:Client

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

Développer un modèle architectural • 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é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 UML

LOG4430 : Architecture logicielle et conception avancée