Introduction

Définition d’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 relations entre ces composants

La définition de l’architecture logicielle consiste à:

• Décrire l’organisation générale d’un système et sa décomposition en sous-
systèmes ou composants
• Déterminer les interfaces entre les sous-systèmes
• Décrire les interactions et le flot de contrôle entre les sous-systèmes
• Décrire aussi les composants utilisés pour implanter les fonctionnalités des
sous-systèmes
 Les propriétés de ces composants
 Leur contenu ( classes , autres composants)
 Les machines ou dispositifs matériels sur lesquels ces modules seront
déployés

Utilité 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 motivations des choix de conception sont ainsi
mises en évidence
 Réutilisation : favorise l’identification des éléments réutilisables, parties
de conception, composants, caractéristiques, fonctions ou données
communes
 Construction : fournit un plan de haut-niveau du développement et de
l’intégration des modules en mettant en évidence les composants, les
interactions et les dépendances
 Évolution : met en évidence les points où un système peut être modifié
et étendu. La séparation composant/connecteur facilite une
implémentation du type « Plug-and-Play »
 Analyse : offre une base pour l’analyse plus approfondie de la conception
du logiciel, analyse de la cohérence, test de conformité, analyse des
dépendances
 Gestion : contribue à la gestion générale du projet en permettant aux
différentes personnes impliquées de voir comment les différents
morceaux seront agencés. L’identification des dépendances entre
composants permet d’identifier où les délais peuvent survenir et leur
impact sur la planification générale
 L’activité de conception est une étape cruciale du développement logiciel
analyse → conception → implémentation
la conception permet la décomposition du produit en unités (ex:modules,classes)
plus simples, cette tâche exige de la créativité
 Une bonne conception contribue à la qualité du logiciel
• fiabilité
• correction
• facilité d’évolution et maintenance
Types de conception
 Conception architecturale (haut niveau)
 Définit la structure et l’organisation générale du logiciel demandé
 Décrit les principaux modules, les relations entre eux, les
contraintes à respecter
 Conception détaillée (bas niveau)
• Réalise chacun des cas d’utilisation
• Respecte le plan de la conception architecturale
• Décrit le fonctionnement interne de chacun des modules
• Permet l’implémentation dans un langage de programmation

Objectifs d’une bonne conception

• Forte cohésion : les éléments ne sont pas réunis dans un même module (ou
une même classe) par hasard, ils forment un tout pour réaliser une tâche
• Faible couplage : les modules (ou classes) sont relativement indépendants, ils
ne dépendent le moins possible des éléments d’autres modules
• Abstraction : une décomposition intuitive et qui permet de se concentrer sur
un module (ou classe) à la fois
• Encapsulation et masquage d’information : les détails d’implémentation
sujets aux changements sont cachés derrière une interface stable.

Conception et maintenance
La conception doit tenir en compte
• les besoins existants
• les besoins à venir
La conception doit faciliter l’adaptation du logiciel aux différents types
changements :
• Changement d’algorithme / de fonctionnalité
• Changement de la représentation des données
• Changement au niveau de la machine abstraite sous-jacente
• Changement au niveau des périphériques
• Changement de l’environnement
• Changements dus au processus de développement
• ...
Modularisation
Modules
Objectif : déterminer la structure modulaire du logiciel à développer
Module : unité fournissant des ressources et/ou des services
Quels sont les modules ?
• S = { M1, M2, ..., Mn }
Relations entre modules :deux types de relations sont utiles pour décrire la
structure d’un système
• Relation « contient » : regroupement en paquetages, classes internes (aussi
agrégation/composition)
• Relation « utilise » : association, agrégation/composition, généralisation, liens
de dépendance
Relation « utilise »
• Mi utilise Mj si Mi requiert la présence de Mj car Mj lui fournit des ressources
ou des services
• Idéalement une hiérarchie :
• Facilite la compréhension de la structure (par niveau d’abstraction)
• Facilite le test unitaire
• Permet de bâtir un système partiel mais fonctionnel
Définit des niveaux d’abstraction

On définit le niveau d’un module Mi dans une hiérarchie r

• niveau(Mi) = 0 s’il n’existe pas de Mk tel que Mk r Mi,
• niveau(Mi) = max({ niveau(Mk) | Mk r Mi }) + 1
Interface & implémentation
Interface : partie publique
• l’ensemble des ressources (opérations, attributs, etc.) rendues accessibles aux
modules clients
• la conception d’un module M ne nécessite que les interfaces des autres
modules que M pourra utiliser
Implémentation : partie privée
• façon dont les ressources sont concrètement représentées et réalisées dans le
module
Séparation des préoccupations
• Quoi offrir ? → Analyse et conception
• Comment le réaliser ? → Conception et implémentation

Gestion des anomalies

 État anormal : état d’un module qui ne peut offrir le service tel qu’attendu et
spécifié par son interface
Causes possibles de la défaillance d’un module
• Service invoqué avec des paramètres inadéquats
• Pré conditions non-satisfaites
• Utilisation un service défaillant exporté par un autre module
• etc.
En cas d’anomalie, un module offrant un service qui doit :
• gérer l’anomalie localement
• signaler l’anomalie en levant une exception auprès du module client, le client
se chargera de gérer correctement l’exception, ou répétera le processus
• Les exceptions qu’un module serveur peut lever doivent être indiquées dans
son interface
Tâches de la phase de conception
• Concevoir l’architecture
• « Qui » fera « quoi » et « où » ?
• Concevoir les interfaces utilisateurs du logiciel
• Concevoir les bases de données
• Concevoir les contrôles du logiciel
• Mise en œuvre de tous les aspects liés au contrôle, à la correction, à la sécurité,
à la tolérance aux fautes, à la protection des données, etc.
• Concevoir le réseau
• Communication entre les processus distribués

Architecture logicielle décrit

• L’organisation générale du logiciel
• Les modules et leurs interfaces
• L’agencement du logiciel des sous-systèmes, des modules et des
composants
• Leurs propriétés
• Leur composition («contient »)
• Leurs collaborations («utilise»)
Dépend des besoins fonctionnels et non fonctionnels du logiciel

Types d’architectures

Architecture en pipeline
Convient aux systèmes de traitement et de transformation de données
Composants = filtre ; Connecteur = pipe
Filtre est un composant qui traite l’information
• Traitement indépendamment et asynchrone
• Reçoit ses données d’un ou plusieurs canaux d’entrée, effectue la
transformation/traitement des données et envoie les données de sortie produites
sur un ou plusieurs canaux de sorties
• Fonctionnent en concurrence. Chacun traite les données au fur et mesure qu’il
les reçoit
Pipe est un canal par lequel transite l’information
• Unidirectionnel au travers duquel circulent un flot de données (stream).
• Synchronisation et utilisation d’un tampon parfois nécessaire pour assurer le
bon fonctionnement entre filtre producteur et filtre consommateur
Exemples : application de traitement de texte, de traitement de signaux.
Compilateur (analyse lexicale, syntaxique, sémantique)

Permet à l’information d’être traitée par plusieurs composants d’une manière

séquentielle

Sous-systèmes organisés en pipeline de filtres indépendants

• La sortie d’un filtre correspond à l’entrée d’un autre
• Communication locale (voisins de gauche et de droite)
• un filtre peut souvent commencer à opérer avant même d’avoir lu tout le flux
d’entrée
• Utile pour les traitements en plusieurs étapes
• Exécution concurrente de filtres possible, synchronisation des flux parfois
nécessaire
Architecture en pipeline - exemple 1

Architecture en pipeline - exemple 2

Unix Shell : cat fichier.txt | grep logiciel | wc : compte le nombre de mots
logiciel dans le fichier fichier.txt
Avantages
 Bon pour le traitement en lot (batch)
 Très flexible
 Se prête bien à la décomposition fonctionnelle d’un système
Inconvénients
 Mauvais pour le traitement interactif

Architecture avec référentiel de données (shared data)

Utilisé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érentiel de données et accesseur de données
• Les référentiels constituent le medium de communication entre les accesseurs
– Connecteur : relie un accesseur à un référentiel
• Rôle de communication, mais aussi de coordination, de conversion et de
facilitation

Variantes
Style tableau noir : les référentiels sont des agents actifs, lorsqu’ils reçoivent
une donnée, ils informent tous les accesseurs concernés
Le tableau noir est le médium de communication avec tous les partenaires, on
ne peut recevoir et transmettre des informations que via le tableau, utile
lorsqu’on ne connaît pas de solution déterministe

Style référentiel : les référentiels sont passifs. Simple vocation de stockage.

Les composants accèdent aux référentiels comme ils le désirent
Exemples : application de bases de données, systèmes Web, systèmes centrés
sur les données (système bancaire, système de facturation, etc.), environnement
de programmation
Environnement de programmation

Avantages
Avantageux pour les applications impliquant des tâches complexes sur les
données, nombreuses et changeant souvent. Une fois le référentiel bien défini,
de nouveaux services peuvent facilement être ajoutés
Inconvénients
Le référentiel peut facilement constituer un goulot d’étranglement, tant du point
de vue de sa performance que du changement

Architecture par couches

Une architecture en couches organise un logiciel sous forme de couches (layers).
Chaque couche ne peut communiquer qu'avec les couches adjacentes.

Cette architecture respecte le principe de séparation des responsabilités et

facilite la compréhension des échanges au sein de l'application.

 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 notion d’abstraction, les couches externes sont plus abstraites
(haut niveau) que les couches internes
 Connecteurs : dépendent du protocole d’interaction 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 utilisé pour les systèmes implémentant des protocoles de
communication (TCP/IP)
Reference Model of Open Systems Interconnection (OSI model)

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
Architecture par événements

• Les sous-systèmes répondent aux événements

• Appropriée pour les logiciels dont les composants doivent interagir avec
l’environnement
• Les sous-systèmes s’abonnent pour recevoir les annonces de certains types
d’événements

Modèle-vue-contrôleur (MVC)
• Inventé en 1978 par Trygve Reenskaug (U. Oslo) lors d’une visite à Xerox
PARC
• Problème: permettre à des utilisateurs de contrôler de grands et complexes
ensembles de données avec maximum de flexibilité et de réutilisation possible
Peut être vu comme
• Un patron de conception
• Un type d’architecture
• Un cadre d’applications (framework)
Modèle-vue-contrôleur (MVC)
Le patron Modèle-Vue-Contrôleur, ou MVC, décompose une application en
trois sous-parties :

 Le modèle représente les entités du système qui regroupe l’ensemble des

composants qui regroupent le logique métier («business logic ») ainsi que
l'accès aux données. Il doit mettre les résultats à la disposition de la Vue
 Le contrôleur implémente le logique métier et la logique des
interactions, il gère la synchronisation entre la Vue et le Modèle, il réagit
aux actions de l’utilisateur en effectuant les actions nécessaires sur le
Modèle, il surveille les modifications du modèle et informe la Vue des
mises à jour nécessaires.il gère la dynamique de l'application et fait le
lien entre les deux autres parties.
 La vue représente l’interface utilisateur, elle s'occupe des interactions
avec l'utilisateur : présentation, saisie et validation des données ;
Modèle-vue-contrôleur (MVC)
Architecture client-serveur
Clients
• Reçoivent des services des serveurs
• Doivent connaître comment contacter les serveurs
• Ex: adresse IP, port, etc.
Serveurs
• Fournissent des services aux clients et autres serveurs
• Extensibilité par ajout de serveurs
Client-serveur

Architecture n-parties Architecture par niveaux

• 2 niveaux (2-tier)

• 3 niveaux (3-tier)

• Multiniveau (n-tier, multitier)

Types de clients
 Clients légers
• Le client est responsable de la présentation uniquement
• Facile à déployer et à maintenir à jour
• Utilise beaucoup de ressources du (des) serveur(s)
• Ex: fureteur web (sans javascript, AJAX, etc)
 Clients lourds
• Le client est responsable de la présentation et de la logique d’application
• Utilise les ressources du client de manière plus efficace
• Complexité accrue
• Ex: Guichet bancaire
Variante - peer-to-peer
• Chaque composant joue le rôle à la fois du client et du serveur
• Aucun serveur central
• Modèle hybride : un serveur central conserve l’information au sujet des pairs
• ex: Skype
Avantages
• fiabilité (tolérance aux pannes)
• mise à l’échelle facile (grandit avec le nombre de pairs)
Inconvénients
• complexité, rôle plus lourd des pairs
Variante - Cloud computing
• Cloud computing : le serveur est géré par un fournisseur de service, et
typiquement accessible par internet, exemple : Amazon Web Services (AWS)
Avantages
• Facilité (sécurité, fiabilité, etc.)
• Mise à l’échelle facile
Inconvénient
• Contrôle réduit
Architecture par objets distribués
Elle élimine la distinction entre client et serveur
• Des objets fournissent l’interface pour les services qu’ils fournissent
• D’autres objets appellent ces objets sans distinction logique entre objets clients
et serveurs
Les intergiciels assurent le partage des objets entre les différentes machines
• « Bus » logiciel
• Gestionnaire ORB (Object Request Broker)

 Avantages
• Possibilité de retarder certaines décisions:
• Ex: client lourd / léger
• Architecture ouverte à l’ajout de nouvelles ressources
• Flexibilité et extensibilité
• Possibilité de reconfiguration dynamique
• Ex: des objets serveurs se déplacent vers la même machine que des objets
clients qui les utilisent
• Ex: conversion de 2 niveaux à 3 niveaux après déploiement
• Différents standards pour les intergiciels d’objets distribués:
• CORBA (Sun, IBM, HP, etc.), DCOM (Microsoft), Java RMI, …

Objets distribués - exemple

 Enterprise Java Beans (EJBs)
• Permettent le développement rapide d’applications transactionnelles
décentralisées
• 3 types d’objets distribués :
 Session Bean: représente une session avec un client, avec ou
sans état
 Message Bean: répond à des messages asynchrones
 Entity Bean: représente des données persistantes (ex: en
provenance d’une base de données)
UML et les architectures logicielles
Rappel :Les diagrammes UML

Les vues (structurelles) d’une architecture logicielle

– Vue logique. Description logique du système décomposé en sous-systèmes
(modules + interface) diagramme de paquetages
– Vue d’implémentation. Description de l’implémentation (physique) du
système logiciel en termes de composants et de connecteurs diagramme de
composants
– Vue de déploiement. Description de l’intégration et de la distribution de la
partie logicielle sur la partie matérielle diagramme combiné de composants
et de déploiement
 Le diagramme de composants peut servir à représenter la vue logique
d’une architecture
 Le diagramme de déploiement peut servir à représenter la vue physique
d’une architecture
Diagramme de composants
Les diagrammes de composants permettent de modéliser les composants et leurs
interactions
Un composant est une unité autonome dans un système, il définit un système ou
un sous-système de n’importe quelle taille ou complexité
Caractéristiques d’un composant
 Un composant est une unité modulaire
 Un composant a une interface qui définit comment le composant peut être
appelé ou intégré
  Le composant est autonome, il est réutilisable et remplaçable
 L’implémentation du composant est cachée (encapsulée) aux entités
externes
Représentation UML

 Un composant a un nom unique dans son contexte

 Un composant peut être étendu par un stéréotype
 Il existe des stéréotypes standards pour les composants
comme « subsytem », « database » ou « executable »
 L’utilisateur peut ajouter ses propres stéréotypes à condition que ça soit
consistant avec l’objectif du diagramme
Exemples de stéréotypes

Interfaces

Un composant définit son comportement en termes d’interfaces fournies et

interfaces requises
 Une interface est une collection d’opérations ayant un lien sémantique et
qui n’ont pas d’implémentation
 L’implémentation des interfaces se fait par une ou plusieurs classes
implémentant le composant
 Les noms d’interfaces commencent par « I » (convention)
 Un contrat entre C1 et C2 est défini quand C1 fournit une interface I qui
est requise par C2
Interfaces – Exemple
Interfaces fournie : définit les fonctions qu’un composant pourrait faire
 Exemple : un serveur web peut gérer les requêtes HTTP de type get ou post

Interfaces requise : Définit la (ou les interfaces) qu’un composant attend de son
environnement

Assemblage
Un assemblage entre deux composants est lorsqu’une même interface est requise
pour un composant et fournie par l’autre
S EC T ION 2 –

Dépendances entre composants

– Dépendance = relation entre deux composants
– Types de dépendances
• Un composant peut dépendre d’un autre composant qui lui fournit un service
ou une information
• Un composant peut dépendre d’une classe qui implémente une partie de son
comportement.
Dépendance de réalisation
• Un composant peut dépendre d’un artefact (code source, fichier .jar, etc.) qui
l’implante concrètement.
Dépendance de manifestation
Utilisation
Un composant C1 dépend d’un autre composant C2 lorsque C1 requiert C2 pour
son implémentation (C1appelle un des services de C2), l’exécution de C1
requiert la présence de C2

Composition
Un composant peut être lui -même composé d’autres composants. On parle alors
de composition.
 Par exemple, le navigateur est composé de getManager (gestionnaire des
requêtes get), postManager (gestionnaire des requêtes POST) et GUI
(interface)

Délégation
Un composant peut avoir des sous-composants qui incluent des interfaces
fournies ou des interfaces requises
 La délégation consiste à transférer les interfaces fournies / requises du
composant interne vers le composant externe

Exemple 2
Paquets
Les paquets peuvent être utilisés dans les diagrammes de composants pour
organiser les composants

Composants et classes
Les classes sont « packagées » dans des bibliothèques par exemple une
bibliothèque est un fichier jar (java) ou une assembly dll (.NET)
 Le diagramme de composants définit le packaging des classes du système
 Le connecteur liant les classes aux composants est le connecteur « realize »
Artifacts
Un artifact est une pièce physique utilisée par le système qui peut être un
document, un fichier, un code source ou n’importe quel élément ayant une
relation avec le système
 La dépendance avec le stéréotype « manifest » indique qu’un artifact est
la représentation physique d’un composant.
 Par exemple, un fichier jar est une représentation physique d’une classe
java

Composants et classes
Architecture SOA ou (Service-Oriented Architecture)
 SOA est une évolution du modèle client -serveur
 SOA est basée sur des services, chaque ressource disponible sur le réseau
est utilisée comme un service
Caractéristiques des services
Les services sont :
 faiblement couplés
 indépendants des protocoles
 basés sur les standards
 distribués
 Les services sont autonomes
 Les services sont composables : créer un service à partir d’autres services
 Les services sont réutilisables
 Les services permettent leur découverte
Composants de SOA
Une architecture SOA est basée sur un consommateur de service, un
fournisseur de service et un registre de services (Service Broker)
 Le consommateur utilise le service
 Le fournisseur assure le service
 Le registre fait le lien entre le fournisseur et le consommateur
Composants de SOA
SOA Technologies
Deux tendances permettent d’implémenter SOA : SOAP /WSDL / UDDI ou
REST
 SOAP est un protocole basé sur XML permettant de véhiculer des
données via HTTP en utilisant XML
 WSDL permet de décrire un service web
 UDDI permet de découvrir un service web
SOAP / WSDL / SOAP sont utilisées conjointement
 REST est un protocole basée sur HTTP uniquement
Dans REST, HTTP est le protocole de transmission et aussi le service
web en même temps
SOA – Avantages
Indépendance et facilité de découverte
Permettent à l’utilisation des applications depuis n’importe quel équipement
(PC, mobile, etc…)
SOA – Exemples
 Google Search Engine (web + application android + application iOs)
 Youtube (web + application android + application WP7 +application
blackberry + application iOs)
 Facebook (web + applications mobiles)

Diagramme de déploiement
Introduction
Le diagramme de composants s’intéresse à l’architecture d’un point de vue
logique tandis que le diagramme de déploiement s’y intéresse d’un point de vue
physique
  entre les relations
entre les composants et les équipements
 appelés noeuds
(nodes)
 Le diagramme de déploiement est composé de noeuds et de connecteurs
o Un noeud représente un équipement dans le système
o Un connecteur représente une communication entre les Nœuds
Dans UML 2, un noeud est illustré comme ceci :

Dans UML, un noeud peut aussi avoir un stéréotype pour préciser la nature du
nœud : «cdrom», «computer», «disk array», «pc», «pc client», «pc server»,
«secure», «server», «storage», «unix server», «user pc» sont des exemples de
stéréotypes
Deux stéréotypes très utilisés : « device » et « execution environment »
 Le stéréotype « device » représente un équipement hardware

environnement où les processus s’exécutent : par exemple un
framework ou un système d’exploitation

Les nouds peuvent être imbriqué par exemple

Noeuds, composants et artifacts

Un composant réside physiquement dans un noeud
 on physique d’un composant
où tout autre élément physique (document, exécutable, code source,…)
Les composants Listener et Diagnostic sont hébergés

dans « Serveur »

Les composants Listener et Diagnostic sont hébergés

dans « Serveur ». Les artifastc représentent les
exécutables associés

Lien de communication
Le lien de communication est une association entre les
noeuds modélisation la communication entre ces noeuds

Exemple d’architecture N/Tiers