Concevoir l architecture d un système

Transcription

1 Concevoir l architecture d un système Hafedh Mili 2007 Concevoir l architecture d un système Le système doit réaliser un ensemble de fonctions ayant des dépendances logiques entre elles Architecture fonctionnelle Il faut réaliser ces fonctions de sorte à satisfaire les exigences non-fonctionnelles Les divers scénarios de qualité La façon de répondre à ces exigences (tactiques et styles architecturaux) est indépendant des fonctions Hafedh Mili Copyright

2 Concevoir l architecture d un système La conception de l architecture d un système consiste à associer («mapper») l architecture fonctionnelle du système à un (des) moule/patron(s) architectural(aux) Hafedh Mili Copyright Concevoir l architecture d un système 1. Architecture fonctionnelle 2. Attribute-riven esign (A) 3. ocumenter l architecture 4. Conception en couches Hafedh Mili Copyright

3 Architecture fonctionnelle L architecture fonctionnelle dépend de la structure des tâches et processus d affaires sous-jacents à l application Indépendante de la conception Elle est apparente aux niveaux exigences et analyse Hafedh Mili Copyright Architecture fonctionnelle A. Paquetages dans UML B. Relations entre paquetages C. éfinir l architecture fonctionnelle Hafedh Mili Copyright

4 Paquetages («Package») Un «package»: un groupement logique d éléments de modèles UML, constituant un espace de nommage Hafedh Mili Copyright Package Éléments publics (exportés) Éléments privés Nom package + classe 1 + classe 2 + classe 3 + use case 1 + règles d affaires 1 - classe 4 - classe 5 Hafedh Mili Copyright

5 1. Architecture fonctionnelle A. Paquetages dans UML B. Relations entre paquetages C. éfinir l architecture fonctionnelle Hafedh Mili Copyright Relations entre paquetages (1/4) Inclusion Pack A Pack A Pack B Pack C Pack B Pack C Hafedh Mili Copyright

6 Relations entre packages (2/4) Hafedh Mili Copyright Relations entre paquetages (3/4) «use»: un élément de A utilise («use») un élément public de B (superclasse, interface, paramètre, attribut, composant, etc.) «import»: les éléments public de B sont ajoutés comme éléments publics à A, et on y fait référence sans qualification «access»: les éléments publics de B sont ajoutés comme éléments privés de A, et on y fait référence sans qualification «trace»: montre un historique de développement (e.g. analyse conception) Hafedh Mili Copyright

7 Relations entre paquetages (4/4) Transitivité: d après les définitions La composition est transitive «use» n est pas transitive «import» est transitive «access» n est pas transitive «trace» est transitive Hafedh Mili Copyright Architecture fonctionnelle A. Paquetages dans UML B. Relations entre paquetages C. éfinir l architecture fonctionnelle Hafedh Mili Copyright

8 Architecture fonctionnelle Objectif: organiser les classes d analyse en un ensemble de paquetages (modules) cohésifs, lesquels sont organisés en partitions et couches Qu est ce qu une bonne modularisation: Une bonne cohésion des modules Un faible couplage entre modules Hafedh Mili Copyright Exemple Partitions Couches Hafedh Mili Copyright

9 Trouver les paquetages (1/3) Identifier les groupes de classes exhibant un lien sémantique assez fort eux critères: Regroupement de classes dans le modèle: beaucoup de liens / associations entre éléments du même groupe candidat, peu de liens entre éléments appartenant à deux groupes candidats différents Manipulés par les mêmes cas d utilisation Hafedh Mili Copyright Trouver les paquetages (2/3) Commencer par un premier découpage Raffiner le découpage pour maximiser la cohésion et minimiser le couplage entre paquetages: Minimiser le nombre d éléments publics Minimiser les dépendances Enlever les dépendances cycliques Hafedh Mili Copyright

10 Enlever les dépendances cycliques (3/3) Hafedh Mili Copyright Concevoir l architecture d un système 1. Architecture fonctionnelle 2. Attribute-riven esign (A) 3. ocumenter l architecture 4. Conception en couches Hafedh Mili Copyright

11 Attribute-riven esign - Conception architecturale orientée attributs (de qualité) Une approche récursive de décomposition architecturale basée sur les scénarios de qualité Les scénarios de qualité sont pris par ordre décroissant de priorité On produit les premiers niveaux de: La vue «décomposition de modules» Autres vues au besoin Hafedh Mili Copyright A (CAOAQ ) Pour chaque composant/sous-système/le système au complet: On prend le(s) prochain(s) scénario(s) de qualité dans l ordre de priorité On choisit les tactiques ou le patron architectural qui répond le mieux au scénario On distribue la fonctionnalité du composant/soussystème/système au complet entre différences instances du patron architectural patron Hafedh Mili Copyright

12 Une étape de A cénario(s) de qualité Composant fonctionnel élection du patron architectural écomposition fonctionnelle Instanciation du patron Hafedh Mili Copyright Une itération de A 1. Choisir le prochain module à décomposer; s assurer que les exigences fonctionnelles, de qualité, et les contraintes sont connues 2. Raffiner le module selon les étapes suivantes: a. Identifier les «architectural drivers» parmi les scénarios de qualité et les exigences fonctionnelles b. Choisir ou créer un patron architectural qui satisfait les «architectural drivers», et identifier les composantes du patron c. Instancier les composantes du patron et distribuer la fonctionnalité du module à décomposer et représenter avec différentes vues d. éfinir les interfaces pour les sous-modules. e. Vérifier et raffiner les cas d utilisation (fonctionnels) et les scénarios de qualité en fonction de la décomposition 3. Répéter les étapes pour chaque module qui a besoin d être décomposé davantage Hafedh Mili Copyright

13 Choisir le prochain module à décomposer Le terme «Module» fait référence à, i) système au complet, ii) sous-système, et iii) sous-module On commence avec le système au complet En plus des exigences fonctionnelles et de qualité, on peut avoir aussi des contraintes, e.g., le besoin d inter-opérer avec un système externe Hafedh Mili Copyright a) choisir les «architectural drivers» Une combinaison d exigences fonctionnelles et de qualité qui influencent l architecture ou le module sous considération Les exigences n ont pas la même priorité / importance L importance relative des exigences permet de départager des solutions partielles Hafedh Mili Copyright

14 2.a) Exemple On suppose trois exigences / qualités architecturales fortes: écurité: ifférents utilisateurs ont le droit d utiliser différentes fonctionnalités Les fonctionnalités utilisent différentes données / attributs Les données sont confidentielles, et sont accessibles selon une politique de «need-to-know» Extensibilité/disponibilité: e nouvelles fonctionnalités peuvent être ajoutées pendant que l application tourne (pas de temps d arrêt de service) istribution Hafedh Mili Copyright b) Choisir un patron architectural Chaque style/patron : Implante plusieurs tactiques répondant à des exigences de qualité A des conséquences / effets secondaires sur d autres attributs de qualité Tactique 0..* répond à 0..* AttributQualité implante tylearchitectural 0..* 0..* 0..* 0..* influence Hafedh Mili Copyright

15 2.b) exemple (1/2) Choix de tactiques: écurité: role-based access Extensibilité/disponibilité: éfinir un intermédiaire (broker) Enregistrement durant l exécution de nouvelles fonctionnalités istribution Proxy Hafedh Mili Copyright b) exemple (2/2) User input Une combinaison de publish & subscribe, proxy, et rolebased access Il y aura une copie unique du dispatcher et du bus (request broker) Plusieurs copies du gestionnaire de sécurité, une par composant fonctionnel ispatcher notification pub event Comp fonct Publier évènement notification Request broker Composant de service Composant fonctionnel requête réponse Gest. ecu annuaire Hafedh Mili Copyright

16 2.c) Instancier les composantes du patron, et distribuer la fonctionnalité Trois sous-tâches: i. Instancier les composantes du patron: approche top-down ii. Vérifier que toute la fonctionnalité du module sous considération est allouée à l une des composantes (ou à plusieurs en collaboration) iii. Représenter selon les autres vues Hafedh Mili Copyright c) Instancier les composantes du patron, et distribuer la fonctionnalité i. Instancier les composantes du patron en top-down: Une sous-composante (fonctionnelle) par groupe fonctionnel Un groupe fonctionnel peut être réalisé par une collaboration de composants fonctionnels et non-fonctionnels Hafedh Mili Copyright

17 2.c.i) exemple User input User input ispatcher notification pub event Gest. patients Publier évènement requête réponse annuaire notification Gest. ecu Gest PM Publier évènement requête réponse annuaire notification Gest. ecu Request broker Hafedh Mili Copyright c.ii) vérifier si chaque fonctionnalité du système est allouée à un ou à plusieurs composants Où est la gestion de la facturation? Gestion de la facturation ispatcher Gestion patients Gestion person. med Gestion actes médic Gestion rendez-vous Request broker Hafedh Mili Copyright

18 2.c.ii) vérifier si chaque fonctionnalité du système est allouée à un ou à plusieurs composants (suite) La distribution de fonctionnalité du module sous considération entre sous modules entraîne des interactions entre sousmodules: Prendre note de ces interactions Les représenter dans les autres vues du système / module Hafedh Mili Copyright c.iii) représenter l architecture avec des vues Représenter l architecture par au moins une vue dans chaque groupe tructures de modules: décomposition, uses, par couches, class (vues développement) tructures «component-connector»: processus communiquants, concurrence, données partagées, client-serveur (vues run-time) tructures d allocation (vues allocation): déploiement (processus processeur), implémentation (module fichier), division de travail (module équipe) Hafedh Mili Copyright

19 2.d) définir les interfaces des sousmodules identifiés Pour chaque sous-module identifié dans la décomposition, décrire les services et propriétés offertes et requises. Chacune des vues offre des éléments d information: Vue décomposition de module: montre, i) producteurs/consommateurs d information, et ii) patron d interaction entre eux Vue concurrence: interaction entre thread, statut de composante, données de synchronization, etc. Vue déploiement: exigences matériel, exigences de chronométrage (timing), exigences de communication Hafedh Mili Copyright e) vérifier et raffiner les exigences en fonction de la décomposition Exigences fonctionnelles: traduire les exigences du module par des use cases des sous-modules Contraintes: s assurer que les contraintes imposées au module sont traitées par la décomposition: La décomposition respecte la contrainte La contrainte est respecté par un sous-module La contrainte est respectée par une collaboration de sous modules cénarios de qualité: la décomposition peut atisfaire le scénario atisfaire le scénario moyennant des contraintes / les sous-modules Être neutre Faire échec au scénario: Hafedh Mili Copyright

20 Et Après? Constituer les équipes de réalisation Réaliser un squelette de l architecture Hafedh Mili Copyright Constituer les équipes Une bonne modularisation permet une division efficace du travail: Cohésion des modules responsabilités bien définies Faible couplage entre modules peu de communication / coordination / négociation sont nécessaires entres les équipes Hafedh Mili Copyright

21 Construire un squelette du système abord, implanter les parties de l application qui gèrent l exécution et l interaction entre les composantes Ensuite, ajouter les fonctionnalités une à une, en commençant par celles qui présentent le plus de risque Les relations «uses» entre modules permettent de planifier les incréments Hafedh Mili Copyright Concevoir l architecture d un système 1. Architecture fonctionnelle 2. Attribute-riven esign (A) 3. ocumenter l architecture 4. Conception en couches Hafedh Mili Copyright

22 ocumenter l architecture Choisir les vues pertinentes au système sous considération. Cela dépend de: ystème public ocumenter les vues individuellement ocumenter les liens entre vues Hafedh Mili Copyright Vues (d après [Bass et al., 2003]) Intervenant ecomp. Vues modules Uses Classes Couches C&C Any Allocation eploiemt Implément Gest. Projet éveloppeur Testeur Entretien Product Line app builder O Client O Usager Analyste upport Nouvel intervenant X X X X X X X Architecte Hafedh Mili Copyright

23 ocumenter les vues Un patron générique: Présentation globale (souvent graphique) de l essentiel Catalogue des éléments / composants: Propriétés des éléments, leur relations, leur interfaces, leur comportements iagramme de contexte Guide de variabilité: 1) points de variabilités, 2) spectres de valeurs, 3) binding time Justification de l architecture (hypothèses, design rationale, historique) Glossaire Informations supplémentaires Hafedh Mili Copyright ocumenter une interface Identité (nom) Ressources fournies (dans un IL): syntaxe, sémantique, restrictions d usage éfinitions de types éfinitions des exceptions Points de variation / configuration de l interface Attributs de qualité satisfaits par l interface Ressources exigées: syntaxe, sémantique, restrictions d usage Rationale et problèmes de conception Guide d utilisation Hafedh Mili Copyright

24 ocumentation globale Comment la documentation est organisée Liste des vues Modèle / patron des vues L architecture elle même urvol du système Correspondance entre vues Liste des éléments, et dans quelle(s) vues ils apparaissent Glossaire Pourquoi elle est telle quelle Justification («design rationale») Hafedh Mili Copyright Utiliser UML pour documenter l architecture Architecturale fonctionnelle / vues modules: les paquetages («package») Autres variantes de paquetages: stéréotypes «couche», «framework», Hafedh Mili Copyright

25 Interface Une façon de distinguer la spécification d un élément de son implantation Un mécanisme utile dans plusieurs tactiques: issimulation de l information Abstraire les différences non-essentielles entre implantation Capturer / planifier les points de variations Polymorphisme Etc. Hafedh Mili Copyright Notation «interface» Comparable +compare(in other : Comparable) : short(idl) Observer <<realization>> <<realization>> FicheProduit Comme un classifieur avec un stéréotype «interface» Comme une sucette Hafedh Mili Copyright

26 Composantes Hafedh Mili Copyright éploiement Hafedh Mili Copyright