Architecture matériel et logiciel 2 Architectures Venera Arnaoudova
Concep8on architecturale 1. Introduc8on 2. Modéliser l architecture avec UML 3. Éléments architecturaux 4. Styles architecturaux 1. Architecture pipeline 2. Architecture avec référen8el de données 3. Architecture MVC 4. Architecture mul8 couches 5. Architecture n niveaux 5. Développer un modèle architectural 1/20/10 2
1. Introduc8on Qu est ce qu une architecture logicielle? L architecture d un logiciel est la structure des structures (modules) d un système Elle inclut Les composants logiciels Les propriétés externes visibles de ces composants Les rela8ons entre ces composants Cf. [Bass, Clements, and Kazman (1998) ] 1/20/10 3
Introduc8on Qu est que la descrip8on d une architecture logicielle? La défini8on de l architecture logicielle consiste à: Décrire l organisa8on générale d un système et sa décomposi8on en sous systèmes ou composants Déterminer les interfaces entre les sous systèmes Décrire les interac8ons et le flot de contrôle entre les sous systèmes Décrire également les composants u8lisés pour implanter les fonc8onnalités des sous systèmes Les propriétés de ces composants Leur contenu (e.g., classes, autres composants) Les machines ou disposi8fs matériels sur lesquels ces modules seront déployés 1/20/10 4
Introduc8on Pourquoi développer une architecture logicielle? Pour perme`re à tous de mieux comprendre le système Pour perme`re aux développeurs de travailler sur des par8es individuelles du système en isola8on Pour préparer les extensions du système Pour faciliter la réu8lisa8on et la réu8lisabilité 1/20/10 5
Introduc8on U8lité d une architecture logicielle [Garlan 2000] Compréhension : facilite la compréhension des grands systèmes complexes en donnant une vue de haut niveau de leur structure et de leurs contraintes. Les mo8va8ons des choix de concep8on sont ainsi mis en évidence Réu8lisa8on : favorise l iden8fica8on des éléments réu8lisables, par8es de concep8on, composants, caractéris8ques, fonc8ons ou données communes Construc8on : fournit un plan de haut niveau du développement et de l intégra8on des modules en me`ant en évidence les composants, les interac8ons et les dépendances 1/20/10 6
Introduc8on U8lité d une architecture logicielle [Garlan 2000] Évolu8on : met en évidence les points où un système peut être modifié et étendu. La sépara8on composant/connecteur facilite une implémenta8on du type «plug and play» Analyse : offre une base pour l analyse plus approfondie de la concep8on du logiciel, analyse de la cohérence, test de conformité, analyse des dépendances Ges8on : contribue à la ges8on générale du projet en perme`ant aux différentes personnes impliquées de voir comment les différents morceaux du casse tête seront agencés. L iden8fica8on des dépendances entre composants permet d iden8fier où les délais peuvent survenir et leur impact sur la planifica8on générale 1/20/10 7
Introduc8on D où vient l architecture? Décisions techniques Décision commerciaux De quoi dépendent les décisions de l architecte : Echéancier Type de système (ex. temps réel) Expérience 1/20/10 8
Introduc8on De quoi dépendent les décisions de l architecte (suite): Organisa8on (budget, forma8on des développeurs) Environnement technique Les architectures influencent les facteurs qui les influencent?! 1/20/10 9
Introduc8on Les par8es prenantes influencent l architecte : - Client (coût peu élevé, développement rapide, pas beaucoup de changements par la suite) - U8lisateur final (performance, sécurité, fiabilité, usabilité) - Développeur (facile à développer) - Chef de projet (coût peu élevé, développeurs occupés) - Développeurs qui main8ennent le logiciel (maintenance facile) 1/20/10 10
Introduc8on Propriétés prises en compte par l architecte: Performance Fiabilité Disponibilité Compa8bilité des plateformes U8lisa8on mémoire U8lisa8on réseau Sécurité Etc. 1/20/10 11
Introduc8on Ac8vités de l architecture logiciel: Créer les business cases du système évaluer le marché, es8mer un prix, temps visé, collabora8ons éventuelles avec d autre systèmes 1/20/10 12
Introduc8on Ac8vités de l architecture logiciel (suite): Comprendre les requis suivant le type du système, requis de qualité, réu8liser ou par8r de rien gamme de produits, prototypes Créer ou sélec8onner une architecture 1/20/10 13
Introduc8on Ac8vités de l architecture logiciel (suite): Communiquer l architecture aux par8e prenantes Evaluer l architecture Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Implémenter l architecture Assurer la conformité à l architecture 1/20/10 14
2. Modéliser avec UML Les vues (structurelles) d une architecture logicielle Vue logique. Descrip8on logique du système décomposé en sous systèmes (modules + interface) UML : diagramme de paquetages Vue d implémenta8on. Descrip8on de l implémenta8on (physique) du système logiciel en termes de composants et de connecteurs UML : diagramme de composants Vue de déploiement. Descrip8on de l intégra8on et de la distribu8on de la par8e logicielle sur la par8e matérielle UML: diagramme combiné de composants et de déploiement 1/20/10 15
Rappel : vues d un système Diagramme de classes Diagramme de composants Diagramme combiné de déploiement/ composants Vue structurelle (modèle statique) Vue des cas d utilisation (modèle fonctionnel des exigences) Diagramme de packetages Diagramme de séquence interaction Vue du comportement et des interactions (modèle dynamique) Diagramme de cas d utilisation comportement Diagramme d états comportement Diagramme de communication interaction Diagramme d activités comportement 1/20/10 16
Modéliser l architecture avec UML Diagramme de paquetages 1/20/10 17
Modéliser l architecture avec UML Diagramme de composants 1/20/10 18
Modéliser l architecture avec UML Diagramme combiné de déploiement/ composants 1/20/10 19
3. Éléments architecturaux composant port connecteur dépendance Comp_A «realisation» interface requise Classe_C interface fournie Comp_B configuration Deux ou plusieurs composants interagissent via un connecteur Chaque élément architectural possède une structure et/ou comportement pouvant être décrit par un modèle UML approprié 1/20/10 20
Éléments architecturaux Composant compa Encapsule un traitement et/ou des données Encapsule un sous ensemble de fonc8onnalités et/ou de données du système Restreint l accès à ce sous ensemble au moyen d une interface définie explicitement Possède des dépendances explicitement définies pour exprimer les contraintes requises par son contexte d exécu8on ou sa réalisa8on 1/20/10 21
Éléments architecturaux Composant Unité autonome servant de bloc de construc8on pour le système Les composants implémentent typiquement des services spécifiques à l applica8on La manifesta8on concrète d un composant est appelé artéfact (instance du composant déployée sur le matériel) N importe quel type de code sur n importe quel support numérique Code source, fichiers binaires, scripts, fichiers exécutables, bases de données, applica8ons, etc. Order «manifestation» Order.jar 1/20/10 22
Éléments architecturaux Interface de composant Permet à un composant d exposer les moyens à u8liser pour communiquer avec lui Types d interfaces Interface offerte : définit la façon de demander l accès à un service offert par le composant Interface requise : définit le type de services (aide) requis par le composant Une interface est a`achée à un port du composant Port = point de communica8on du composant Plusieurs interfaces peuvent être a`achées à un même port 1/20/10 23
Éléments architecturaux Dépendances entre composants Dépendance = rela8on entre deux composants Types de dépendances Un composant peut dépendre d un autre composant qui lui fournit un service ou une informa8on Un composant peut dépendre d une classe qui implémente une par8e de son comportement. Dépendance de réalisa8on Un composant peut dépendre d un artefact (code source, fichier.jar, etc.) qui l implante concrètement. Dépendance de manifesta8on 1/20/10 24
Éléments architecturaux Connecteur Dans les systèmes complexes, les interac8ons peuvent cons8tuer un enjeu encore plus important que les fonc8onnalités des composants individuels Défini8on : élément architectural qui définit le type d interac8ons entre les composants et les règles gouvernant ces interac8ons Un connecteur relie les ports de deux ou plusieurs composants Un connecteur décrit un mécanisme de connec8on indépendant de l applica8on Représente un concept abstrait, paramétrable et indépendant des composants spécifiques qu il relie Les a`ributs du connecteurs décrivent ses propriétés comportementales E.g. sa capacité, le temps de latence, le type d interac8on (binaire/n aire, asymétrique/symétrique, détails du protocole), etc. 1/20/10 25
Éléments architecturaux Connecteur Un connecteur peut avoir un ou plusieurs rôles Communica8on :rôle le plus fréquent Coordina8on : contrôle du calcul, de la transmission des données, etc. Orthogonal aux autres rôles Conversion : permet l interac8on entre composants développés indépendamment dans des langages différents par exemple Facilita8on : permet l interac8on entre composants conçus pour interragir ensemble. Synchronisa8on, accès contrôlées aux données partagées, etc. Selon le(s) rôles qu il doit remplir et le type de communica8on souhaitée entre deux composants, choix d un type Procedure call (comm + coord), Data access (comm + conv), Event, Stream, Linkage, Distributor, Arbitrator, Adaptor (conv) 1/20/10 26
Éléments architecturaux Rôle Type de connecteur Attributs Valeurs d attributs 1/20/10 27 Software Architecture: Foundations, Theory, and Practice; R. N. Taylor, N. Medvidovic, and E. M. Dashofy; 2008 John Wiley & Sons, Inc.
Exemple d un diagramme de composants 1/20/10 28
Choix d une architecture Choix d une architecture Dépend des exigences fonc8onnelles et non fonc8onnelles du logiciel 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 Influencé par certains «modèles connus» de décomposi8on en composants (styles architecturaux) et de mode d interac8ons (e.g., orienté objet) 1/20/10 29
4. Style architecturaux Un style architectural Est un patron décrivant une architecture logicielle perme`ant de résoudre un problème par8culier Définit Un ensemble de composants et de connecteurs (et leur type) Les règles de configura8on des composants et connecteurs (topologie) Une spécifica8on du comportement du patron Des exemples de systèmes construits selon ce patron Cons8tue un modèle éprouvé et enrichi par l expérience de plusieurs développeurs Compréhensibilité, maintenance, évolu8on, réu8lisa8on, performance, documenta8on, etc. 1/20/10 30
Architecture pipeline Convient bien aux systèmes de traitement et de transforma8on de données Composants = filtre ; Connecteur = canal Filtre Traite indépendamment et asynchrone Reçoit ses données d un ou plusieurs canaux d entrée, effectue la transforma8on/traitement des données et envoie les données de sor8e produites sur un ou plusieurs canaux de sor8es Fonc8onnent en concurrence. Chacun traite les données au fur et mesure qu il les reçoit Canal Unidirec8onnel au travers duquel circulent un flot de données (stream). Synchronisa8on et u8lisa8on d un tampon parfois nécessaire pour assurer la bon fonc8onnement entre filtre producteur et filtre consommateur Exemples : applica8on de traitement de texte, de traitement de signaux. Compilateur (analyse lexicale, syntaxique, séman8que) canal de communication Filtre synchro 1/20/10 31
Architecture pipeline Système de traitement du son Encodeur pour sortie de microphone Filtrer l écho Filtrer le bruit Retirer les fréquences non vocales Égaliser les les intervalles dynamiques Encodeur de bruit ambiant Décompresser Recevoir Transmettre Compresser Encoder la sortie des haut-parleurs 1/20/10 32
Architecture pipeline Avantages Bon pour traitement en lot (batch) Très flexible Analyse facilitée : performance, synchronisa8on, goulot d étranglement, etc. Se prête bien à la décomposi8on fonc8onnelle d un système Inconvénients Mauvais pour le traitement interac8f D un point de vue concep8on Diviser pour régner : les filtres peuvent être conçus séparément Cohésion : les filtres sont un type de cohésion fonc8onnelle Couplage : les filtres n ont qu une entrée et une sor8e en général Abstrac8on : les filtres cachent généralement bien leurs détails internes Réu8lisabilité : les filtres peuvent très souvent être réu8lisés dans d autres contextes Réu8lisa8on : il est souvent possible d u8liser des filtres déjà existants pour les insérer dans le pipeline 1/20/10 33
Architecture avec référen8el de données (shared data) U8lisée dans le cas où des données sont partagées et fréquemment échangées entre les composants Deux types de composants : référen8el de données et accesseur de données Les référen8els cons8tuent le medium de communica8on entre les accesseurs Connecteur : relie un accesseur à un référen8el Rôle de communica8on, mais aussi possiblement de coordina8on, de conversion et de facilita8on Référentiel1 Référentiel2 A A A A A 1/20/10 34
Architecture avec référen8el Variantes Style tableau noir : les référen8els sont des agents ac8fs. Lorsqu ils reçoivent une données, ils informent tous les accesseurs concernés Style référen8el : les référen8els sont passifs. Simple voca8on de stockage. Les composants accèdent aux référen8els comme ils le désirent Exemples : applica8on de bases de données, systèmes Web, systèmes centrés sur les données (e.g. système bancaire, système de factura8on,etc.), environnement de programma8on 1/20/10 35
Architecture avec référen8el Environnement de programma8on Analyseur syntaxique Analyseur sémantique Optimiseur Compilateur Générateur de code Analyseur lexical Référentiel Arbre syntaxique Table de symboles Débogueur Éditeur syntaxique 1/20/10 36
Architecture avec référen8el Avantages Avantageux pour les applica8ons impliquant des tâches complexes sur les données, nombreuses et changeant souvent. Une fois le référen8el bien défini, de nouveaux services peuvent facilement être ajoutés Inconvénients Le référen8el peut facilement cons8tuer un goulot d étranglement, tant du point de vue de sa performance que du changement 1/20/10 37
Architecture Modèle Vue Contrôleur (MVC) Séparer la couche interface u8lisateur des autres par8es du système (car les interfaces u8lisateurs sont beaucoup plus suscep8bles de changer que la base de connaissances du système) Composé de trois types de composants Modèle : rassemble des données du domaine, des connaissances du système. Con8ent les classes dont les instances doivent être vues et manipulées Vue : u8lisé pour présenter/afficher les données du modèle dans l interface u8lisateur Contrôleur : con8ent les fonc8onnalités nécessaires pour gérer et contrôler les interac8ons de l u8lisateur avec la vue et le modèle 1/20/10 38
Architecture Modèle Vue Contrôleur Vus par les acteurs View E.g. Génère le code html pour le browser créer et mettre à jour E.g. Interprète les transmissions http «post» du browser Reçoit les événements des acteurs Consulter l état (i.e. les données) notifier changements Contrôleur Modèle modifier Le sous-système gérant l information. 1/20/10 39
Architecture Modèle Vue Contrôleur Modèle : noyau de l applica8on Enregistre les vues et les contrôleurs qui en dépendent No8fie les composants dépendants des modifica8ons aux données Vue : interface (graphique) de l applica8on Crée et ini8alise ses contrôleurs Affiche les informa8ons des8nées aux u8lisateurs Implante les procédure de mise à jour nécessaires pour demeurer cohérente Consulte les données du modèle Contrôleur : par8e de l applica8on qui prend les décisions Accepte les événement correspondant aux entrées de l u8lisateur Traduit un événements (1) en demande de service adressée au modèle ou bien (2) en demande d affichage adressée à la vue Implémente les procédures indirectes de mise à jour des vues si nécessaire 1/20/10 40
Architecture Modèle Vue Contrôleur Avantages : approprié pour les systèmes interac8fs, par8culièrement ceux impliquant plusieurs vues du même modèle de données. Peut être u8lisé pour faciliter la maintenance de la cohérence entre les données distribuées Inconvénient : goulot d étranglement possible D un point de vue concep8on Diviser pour régner : les composants peuvent être conçus indépendamment Cohésion : meilleure cohésion que si les couches vue et contrôle étaient dans l interface u8lisateur. Couplage : le nombre de canaux de communica8on entre les 3 composants est minimal Réu8lisabilité : la vue et le contrôle peuvent être conçus à par8r de composants déjà existants Flexibilité : il est facile de changer l interface u8lisateur Testabilité : il est possible de tester l applica8on indépendamment de l interface 1/20/10 41
Architecture mul8 couches Composants : chaque composant réalise un service Une couche offre un service (serveur) aux couches externes (client) Service créé indépendamment du logiciel ou spécifiquement Met à profit la no8on d abstrac8on, les couches externes sont plus abstraites (haut niveau) que les couches internes Connecteurs : dépendent du protocole d interac8on souhaité entre couches Système fermé : une couche n a accès qu aux couches adjacentes. Les connecteurs ne relient que les couches adjacentes Système ouvert : toutes les couches ont accès à toutes les autres. Les connecteurs peuvent relier deux couches quelconques Exemples : souvent u8lisé pour les systèmes implémentant des protocoles de communica8on (TCP/IP) 1/20/10 42
Architecture mul8 couches 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 4. Cryptographie 3. Interface de fichiers 2. Gestion de clés 1. Authentification Chaque couche est un composant avec une interface bien définie u8lisée par la couche juste au dessus (i.e., externe) La couche supérieure (externe) voit la couche inférieur (interne) comme un ensemble de services offerts Un système complexe peut être construit en superposant les couches de niveau d abstrac8on croissant Il est important d avoir une couche séparée pour l IU Les couches juste au dessous de l IU offrent les fonc8ons applica8ves définies par les cas d u8lisa8on Les couches les plus basses offrent les services généraux E.g., communica8on réseau, accès à la base de données 1/20/10 43
Architecture mul8 couches Système fermé Reference Model of Open Systems Interconnec8on (OSI model) Application Présentation Transformation des données (encryption,etc.) Session Identifier et authentifier une connexion Transport Transmission (point à point) fiable des données Transmission des routing packets Réseau Transmission des data frames sans erreurs Ligne de données Interface matérielle du réseau Physique 1/20/10 44
Architecture mul8 couches Application Swing AWT X11 1/20/10 45
Architecture mul8 couches Interface utilisateur Logique applicative Accès au système d exploitation Accès à la base de données Communication réseau Application programs Screen display facilities User account management File system Kernel (handling processes and swapping 1/20/10 46
Architecture mul8 couches D un point de vue concep8on 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 Abstrac8on : on n a pas à connaître les détails d implémenta8on des couches inférieures Réu8lisabilité : les couches inférieures peuvent être conçues de façon à offrir des solu8ons génériques réu8lisables Réu8lisa8on : on peut souvent réu8liser des couches développées par d autres et qui proposent le service requis Flexibilité : il est facile d ajouter de nouveaux services construits sur les services de plus bas niveau An8cipa8on du changement : en isolant les composants dans des couches dis8nctes, le système devient résistant Portabilité : tous les services rela8fs à la portabilité peuvent être isolés Testabilité : les couches peuvent être testées indépendamment Concep8on défensive : les API des couches cons8tuent des endroits stratégiques pour insérer des asser8ons de vérifica8on 1/20/10 47
Architecture n niveaux Pour les systèmes distribués Comparable à une architecture par couches dont les couches seraient distribuées! N.b. L architecture mul8 couche est généralement u8lisée pour décrire la structure interne (non distribuée) d un composant qui peut lui même appartenir à une architecture (distribuée) n par8e Par abus de langage, la no8on de 8er a pris le sens de couche distribuée Composants : chaque niveaux est représenté par un composant qui joue le rôle de client et/ou de serveur Connecteurs : relient un client à un serveur. Connexion asymétrique. Doit supporter les communica8on distantes (e.g., requêtes RPC, HTTP, TCP/IP) Exemples Client serveur, Trois niveaux, Quatre niveaux 1/20/10 48
Architecture n niveaux Architecture 2 niveaux (client serveur ou client lourd) Client requête de service Serveur Architecture 3 niveaux (client léger) Navigateur Web requête de service Architecture 4 niveaux Logique applicative requête de service de B.D. Serveurs de base de données Client Présentation (partie web) Logique Applicative (calculs, business) Bases de données 1/20/10 49
Architecture n niveaux Architecture client serveur Exemple typique : un système d informa8ons u8lisant une base de données centrale. (cas spécial de l architecture avec référen8el) Clients : reçoivent les données de l u8lisateur, ini8ent les transac8ons, etc. Serveur : exécute les transac8ons, assure l intégrité des données Architecture pair à pair = une généralisa8on de l architecture client serveur Les composants peuvent tous à la fois être client et serveur Concep8on plus difficile: flot de contrôle plus complexe dû à la possibilité de deadlocks 1/20/10 50
Architecture n niveaux Architecture client serveur <<communication>> Échanger msg Client2 <<communication>> chercher adresse Client1 <<communication>> Échanger msg Client3 Serveur <<communication>> Échanger msg <<communication>> chercher adresse netscape:webbrowser diro:webserver iexplo:webbrowser www.cmu.edu:webserver lynx:webbrowser 1/20/10 51
Architecture n niveaux Architecture 3 niveaux Organisa8on en trois couches Couche interface: Composé d objets interfaces (boundary objects) pour interagir avec l u8lisateur (fenêtres, formulaires, pages Web, etc.) Couche logique applica8ve : Comporte tous les objets de contrôle et d en8tés nécessaires pour faire les traitements, la vérifica8on des règles et les no8fica8ons requises par l applica8on Couche de stockage : réalise le stockage, la récupéra8on et la recherche des objets persistants Avantage sur l architecture client serveur Permet le développement et la modifica8on de différentes interfaces u8lisateurs pour la même logique applica8ve 1/20/10 52
Architecture n niveaux Architecture 3 par8es Réseau Client X Serveur de B.D. Unix Base de données corporative Marché de données Client Windows Serveur Windows NT Serveur de B.D. Unix Dépôt de données Logique 1/20/10 53 applicative
Architecture n niveaux Architecture 3 niveaux Interface gestionnaire Gestion des dossiers À noter que la tendance veut que la par8e cliente soit De plus en plus mince, i.e., le client ne fait qu afficher un contenu HTML La logique applica8ve est alors responsable de créer les pages Web à afficher par le client Il faut dissocier logique applica8ve et présenta8on des données Base de données clients 1/20/10 54
Architecture n niveaux Architecture 4 niveaux Architecture dont la couche logique applica8ve est décomposée en Couche Présenta8on (JSP, servlets) Présenta8on du contenu sta8que: Contenu HTML ou XML affiché par le client Présenta8on du contenu dynamique : contenu organisé et créé dynamiquement par le serveur web (pour ensuite être affiché en HTML/XML par le client) Couche Logique applica8ve (calculs purs) : réalise le cœur des traitements de l applica8on Avantage sur l architecture 3 niveaux Permet de supporter un grand nombre de formats de présenta8on différents (propres à chaque client), tout en réu8lisant certains des objets de présenta8on entre les clients. Réduc8on des redondances Bien adaptée pour les applica8ons Web devant supporter plusieurs types de clients 1/20/10 55
Architecture n niveaux Architecture 4 niveaux Clients Serveur Serveur de base de données Interface ATM <<build>> Présentation Serveur Interface Web Interface employé de la banque <<submit>> <<build>> <<build>> <<submit>> Gestion opérations bancaires <<submit>> Accès base de données comptes clients Java Server Pages - Partie cliente - Partie serveur 1/20/10 56
Architecture n niveaux D un point de vue concep8on Diviser pour régner : de façon évidente, client et serveur peuvent être développées séparément Cohésion : le serveur peut offrir des services cohésifs au client Couplage : un seul canal de communica8on existe souvent entre client et serveur Réu8lisa8on : il est possible de trouver une bibliothèque de composants, interfaces, etc. pour construire les systèmes Toutefois, les systèmes client serveur dépendent très souvent de nombreuses considéra8ons liées in8mement à l applica8on 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 Concep8on défensive : on peut introduire des opéra8ons de vérifica8on dans le code traitant les messages reçus de part et d autre 1/20/10 57
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 u8lisa8on ; décomposi8on en sous systèmes Déterminer les principaux composants requis Sélec8onner un style architectural Raffiner l architecture Iden8fier les principales interac8ons entre les composants et les interfaces requises Décider comment chaque donnée et chaque fonc8onnalité sera distribuée parmi les différents composants Déterminer si on peut réu8liser un cadriciel existant (réu8lisa8on) ou si on peut en construire un (réu8lisabilité) Considérer chacun des cas d u8lisa8on et ajuster l architecture pour qu il soit réalisable Détailler l architecture et la faire évoluer 1/20/10 58
Développer un modèle architectural Décrire l architecture avec UML Tous les diagrammes UML peuvent être u8les pour décrire les différents aspects du modèle architectural Trois des diagrammes UML sont par8culièrement u8le pour décrire une architecture logicielle Diagramme de paquetages Diagramme de composants Diagramme de déploiement 1/20/10 59
Développer un modèle architectural Diagramme de paquetages Paquetage = Collec8on d éléments de modélisa8on 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 u8lise SimpleChat OCSF Client Common <<import>> Client Server 1/20/10 60
Développer un modèle architectural Diagramme de composants Offre une vue de haut niveau de l architecture du système U8lisé pour décrire le système d un point de vue implémenta8on Permet de décrire les composants d un système et les interac8ons 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 1/20/10 61
Développer un modèle architectural Qu est ce qu un composant? Unité autonome faisant par8e d un système ou d un sous système qui encapsule un comportement (i.e., implémenta8on) et qui offre une ou plusieurs interfaces publiques Par8e cons8tuante d un système qui peut être remplacée ou/et réu8lisée Élément d implémenta8on (un soussystème, un fichier exécutable, une classe d implémenta8on (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 Composant 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 effec8vement u8lisé (~objet) Exemples de composants: Binaire exécutable (<<executable>>), bibliotheque dynamique/sta8que (<<librairy>>), un fichier à interpréter (<<file>>) 1/20/10 62
Développer un modèle architectural Les composants et le principe de sépara8on des préoccupa8ons La sépara8on des préoccupa8on est le principe qui assure l intégrité fonc8onnelle d un composant Chaque composant réalise une, et seulement une fonc8on au sein du système, mais peut néanmoins exposer plusieurs méthodes. Typiquement, chaque composant est défini par une interface qui cons8tue son seul moyen d interagir avec les autres composants L u8lisa8on d une interface pour communiquer avec les autres composants du système facilite la maintenance puisqu on peut alors en changer l implémenta8on 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 fonc8onnalité du composant 1/20/10 63
Développer un modèle architectural Composants et interfaces Nota8on Personne Commande EntréeCmdes PaiementComptes interface requise composant interfaces offertes Commande <<provided interfaces>> EntréeCmdes PaiementComptes <<required interface>> Person 1/20/10 64
Développer un modèle architectural Composants et rela8ons nota8on Une flèche de dépendance permet de me`re en rela8on des composant via les interfaces requises et fournies Système de commande RechercheClient RechercheClient Repositoire Clients AccèsProduit (3) dépendance (1) composant AccèsProduit Système d inventaire (2) interface 1/20/10 65