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 2007 2 1
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 2007 3 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 2007 4 2
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 2007 5 1. Architecture fonctionnelle A. Paquetages dans UML B. Relations entre paquetages C. éfinir l architecture fonctionnelle Hafedh Mili Copyright 2007 6 3
Paquetages («Package») Un «package»: un groupement logique d éléments de modèles UML, constituant un espace de nommage Hafedh Mili Copyright 2007 7 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 2007 8 4
1. Architecture fonctionnelle A. Paquetages dans UML B. Relations entre paquetages C. éfinir l architecture fonctionnelle Hafedh Mili Copyright 2007 9 Relations entre paquetages (1/4) Inclusion Pack A Pack A Pack B Pack C Pack B Pack C Hafedh Mili Copyright 2007 10 5
Relations entre packages (2/4) Hafedh Mili Copyright 2007 11 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 2007 12 6
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 2007 13 1. Architecture fonctionnelle A. Paquetages dans UML B. Relations entre paquetages C. éfinir l architecture fonctionnelle Hafedh Mili Copyright 2007 14 7
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 2007 15 Exemple Partitions Couches Hafedh Mili Copyright 2007 16 8
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 2007 17 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 2007 18 9
Enlever les dépendances cycliques (3/3) Hafedh Mili Copyright 2007 19 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 2007 20 10
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 2007 21 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 2007 22 11
Une étape de A cénario(s) de qualité Composant fonctionnel élection du patron architectural écomposition fonctionnelle Instanciation du patron Hafedh Mili Copyright 2007 23 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 2007 24 12
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 2007 25 2.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 2007 26 13
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 2007 27 2.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 2007 28 14
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 2007 29 2.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 2007 30 15
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 2007 31 2.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 2007 32 16
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 2007 33 2.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 2007 34 17
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 2007 35 2.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 2007 36 18
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 2007 37 2.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 2007 38 19
Et Après? Constituer les équipes de réalisation Réaliser un squelette de l architecture Hafedh Mili Copyright 2007 39 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 2007 40 20
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 2007 41 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 2007 42 21
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 2007 43 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 2007 44 22
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 2007 45 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 2007 46 23
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 2007 47 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 2007 48 24
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 2007 49 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 2007 50 25
Composantes Hafedh Mili Copyright 2007 51 éploiement Hafedh Mili Copyright 2007 52 26