3ème année licence

Option: SCI
Module: CL2

Chapitre 5:
Conception avancée /
architecture logicielle

Dr. Meriem Kermani

Année 2022/2022
1.INTRODUCTION

 L’architecture d’un programme ou d’un système

informatique est la structure (ou les structures)
du système qui comprend les éléments logiciels,
leurs propriétés visibles et leur relations

2
2.DÉFINITION
 L’architecture d’un système est sa conception
de haut niveau
 N’importe quel système complexe est composé de
sous-systèmes qui interagissent entre eux
 La conception de haut niveau est le processus qui
consiste à identifier ces sous-systèmes ainsi que
les relations qu’ils entretiennent entre eux
 L’architecture d’un système est le résultat de ce
processus

3
2.DÉFINITION

 L’architecture implique plusieurs choix dont les

technologies, les produits et les serveurs à
utiliser
 Il n’y a pas une architecture unique permettant
de réaliser le système, il y en a plusieurs.
 Le concepteur ou l’architecte tâchera de choisir la
meilleure architecture possible selon plusieurs
critères dont la nature du projet, les compétences
de l’équipe, les budgets et outils disponibles,
…etc.
4
3.REPRÉSENTATION DES ARCHITECTURES
 Il existe plusieurs représentations graphiques
des architectures
 Une des représentations les plus utilisées est la
représentation C&C: Composants et Connecteurs
 Un composant est un module logiciel (application,
bibliothèque, module, …etc.) ou un entrepôt de
données (base de données, système de fichiers,
…etc.)
 Le connecteur représente les interactions entre
les composants
 La représentation C&C est un graphe contenant
5
des composants et des connecteurs
3.REPRÉSENTATION DES ARCHITECTURES /
COMPOSANT

 Un composant est un module logiciel ou un

entrepôt de données
 Un composant est identifié par son nom qui
indique son rôle dans le système
 Les composants communique entre eux en
utilisant des ports (ou interfaces)
 Les architectures utilisent des composants
standards : serveurs, bases de données,
application, clients, …etc.
6
3.REPRÉSENTATION DES ARCHITECTURES /
CLIENTS -SERVEUR

 Un serveur est un module logiciel qui répond

aux requêtes d’autres modules appelés
clients
 Généralement, les services et les clients sont
hébergés dans des machines différentes et
communiquent via le réseau (intranet/
internet)
 Par exemple, le service http répond aux requêtes
des clients qui sont les navigateurs web

7
3.REPRÉSENTATION DES ARCHITECTURES /
CONNECTEUR

 Le connecteur modélise une interaction entre

deux composants
 Un connecteur peut modéliser une interaction
simple (appel de procédure) ou une
interaction complexe (par exemple
utilisation d’un protocole comme http)

8
4. VUE PHYSIQUE ET VUE LOGIQUE
 La vue logique d’une architecture logicielle
définit les principaux composants d’une
architecture sans se soucier des détails
physiques (équipements, machines, …etc.)
 La vue physique s’intéresse au déploiement
physique des différents services
 La vue physique est peu précise lors de la
conception. Elle devient concrète lors de la phase
de déploiement.

9
4. VUE PHYSIQUE ET VUE LOGIQUE

10
5.UTILISATION DE L’ARCHITECTURE
 Donne un aperçu de haut niveau du système qui
va faciliter la communication et la
compréhension
 Aide à comprendre des systèmes existants

 Décompose le système en sous-systèmes et sous-

modules ce qui réduit la complexité et facilite la
distribution des tâches
 Facilite l’évolution du système en remplaçant
uniquement le sous-système désiré

11
5. MODÉLISER AVEC UML LES
ARCHITECTURES LOGICIELLES
Les vues (structurelles) d’une architecture logicielle
 Vue logique. Description logique du système
décomposé en sous-systèmes (modules + interface)
❑ UML : diagramme de paquetages
o Vue d’implémentation. Description de
l’implémentation (physique) du système logiciel en
termes de composants et de connecteurs
❑ UML : 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
❑ UML: diagramme combiné de composants et de
déploiement 12
5. MODÉLISER AVEC UML LES
ARCHITECTURES LOGICIELLES

 Diagramme de composant

13
5. MODÉLISER AVEC UML LES
ARCHITECTURES LOGICIELLES

 Diagramme combiné de déploiement/composants

14
6.VUE D’IMPLÉMENTATION
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
15
6.VUE D’IMPLÉMENTATION
DIAGRAMME DE COMPOSANTS

 Unité modulaire avec des interfaces bien définies

qui est remplaçable dans son environnement
 Unité autonome au sein d'un système

❑ A une ou plusieurs interfaces fournies et requises

❑ Sa partie interne est cachée et inaccessible

❑ Ses dépendances sont conçues de telle sorte que

le composant peut être traitée de façon aussi
autonome que possible

16
6.VUE D’IMPLÉMENTATION
DIAGRAMME DE COMPOSANTS

Notation

17
6.VUE D’IMPLÉMENTATION
DIAGRAMME DE COMPOSANTS

Interface de composant
 Permet à un composant d’exposer les moyens à
utiliser 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 attachée à un port du composant

❑ Port = point de communication du composant

❑ Plusieurs interfaces peuvent être attachées à un

même port 18
6.VUE D’IMPLÉMENTATION
DIAGRAMME DE COMPOSANTS

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 19
6.VUE D’IMPLÉMENTATION
DIAGRAMME DE COMPOSANTS
Connecteur

 Dans les systèmes complexes, les interactions peuvent

constituer un enjeu encore plus important que les
fonctionnalités des composants individuels
 Définition : élément architectural qui définit le type
d’interactions entre les composants et les règles
gouvernant ces interactions
 Un connecteur relie les ports de deux ou plusieurs
composants
 Un connecteur décrit un mécanisme de connexion
indépendant de l’application
 Représente un concept abstrait, paramétrable et
indépendant des composants spécifiques qu’il relie
 Les attributs du connecteurs décrivent ses propriétés 20
comportementales
6.VUE D’IMPLÉMENTATION
DIAGRAMME DE COMPOSANTS

21
6.VUE D’IMPLÉMENTATION
DIAGRAMME DE COMPOSANTS

22
6.VUE D’IMPLÉMENTATION
DIAGRAMME DE COMPOSANTS

 Rattacher le contrat externe d'un composant

interne à la réalisation
 Représente la transmission des signaux

23
7.LA VUE DE DÉPLOIEMENT
Un diagramme de déploiement représente la façon
dont déployer les différents éléments d’un
système
 Les ressources matérielles et l’implantation du
logiciel dans ces ressources
 Les éléments

❑ Les nœuds

❑ Les modules

❑ Les programmes principaux

24
7.LA VUE DE DÉPLOIEMENT
 Un diagramme de déploiement propose une
vision statique de la topologie du matériel sur
lequel s’exécute le système
 Un diagramme de déploiement montre les
associations (connexions) existant entre les
nœuds du système
 Un diagramme de déploiement ne montre pas les
interactions entre les nœuds

25
7.LA VUE DE DÉPLOIEMENT

26
7.LA VUE DE DÉPLOIEMENT
 Une connexion est une connexion physique
reliant deux nœuds entre-eux.
 Elle indique en général la méthode utilisée : ex
TCP/IP
 Exemples de connexion :

❑ une connexion Ethernet.

❑ une ligne série.

❑ un bus partagé.

27
7.LA VUE DE DÉPLOIEMENT
EXEMPLE DE DÉPLOIEMENT

28
29
1. DEFINITION
 Un style architectural est un modèle
définissant comment sera le système
 Comme les systèmes ont des points communs, ces
systèmes auront des architectures qui se
ressemblent. Le regroupement de ces
architectures est appelé «style architectural»
 Un style architectural définit quels sont les
composants, les connecteurset les
contraintes définissant l’architecture d’un
système

30
2.QUELQUES STYLES D’ARCHITECTURE
LOGICIELLE
 Centré sur les Données
Entrepôt de données centralisée qui communique avec un
certain nombre de clients.
Utilisée dans le cas où des données sont partagées et
fréquemment échangées entre les composants
On distingue deux sous-types: référentiel et tableau noir
 Flots de Données
Succession de transformations des données d'entrée.
On distingue deux sous-types types : séquentiel ou pipeline
❑ Hiérarchique
❑ En couches
 Invocation implicite
31
❑ Model-View-Controller
3. ARCHITECTURE CENTRÉ SUR LES DONNÉES
 Référenciel
 Point fort :Indépendances des clients les uns des
autres on peut ajouter ou retirer des clients

32
4. ARCHITECTURE FLOTS DE DONNÉES
 Style séquentiel : chaque étape s'exécute jusqu'à la
fin avant que la prochaine étape commence
 Style pipeline : certaines étapes peuvent
fonctionner simultanément.
❑ Le filtre est un composant qui traite l’information

❑ La pipe est un canal par lequel transite

l’information

33
4. ARCHITECTURE FLOTS DE DONNÉES
 Pipeline (Pipe / Filtre).
Avantages
 Forte décomposition du systèmes

 Filtres faciles à réutiliser

 Facilite la maintenance

Inconvénients
 Ne convient pas aux applications à haute
interactivité
 Les performances dépendent des pipes

34
5.ARCHITECTURE HIÉRARCHIQUE
 Organisation hiérarchique du système en un
ensemble de couches
 Des interfaces bien définies entre les couches
 Chaque couche agit comme un
❑ Serveur : Fournisseur de services de couches
"supérieures":
❑ Client: consommateur de services de couche (s) »ci-
dessous"
 Les connecteurs sont des protocoles de la couche
d'interaction
 Objectifs :
❑ Réduire la complexité,
❑ Améliorer la modularité, réutilisabilité 35
5.ARCHITECTURE HIÉRARCHIQUE
 Client-serveur N-tiers
Chaque niveau dépend
uniquement du niveau qui
est au dessus

36
5.ARCHITECTURE HIÉRARCHIQUE
Client-serveur
Avantages
 Séparation des tâches
 Simple à utiliser
Inconvénients
 Souvent insuffisant pour des cas complexes
N-Tiers
Avantages
 Séparation poussée des tâches
 Haute flexibilité
Inconvénients
 Nécessite des ressources matérielles importantes 37
5.ARCHITECTURE HIÉRARCHIQUE
 SOA ou (Service-Oriented Architecture) est une
évolution du modèle client-serveur
 SOA est basée sur des services faiblement
couplés, indépendants des protocoles, basés sur
les standards et distribués
 Chaque ressource disponible sur le réseau est
utilisée comme un service

38
5.ARCHITECTURE HIÉRARCHIQUE
 Les service 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

39
 5.ARCHITECTURE HIÉRARCHIQUE
 Une architecture SOA est basé sur un consommateur de
service, un fournisseur de service et un registre de services
(Service Broker)
 Le consommateur utilise le service

 Le fournisseur assurele service

 Le registre fait le lien entre le fournisseur et le

consommateur

40
5.ARCHITECTURE HIÉRARCHIQUE
Avantages
 Indépendance et facilité de découverte

 Permettent à l’utilisation des applications depuis

n’importe quel équipement (PC, mobile, etc…)

41
6. INVOCATION IMPLICITE
Modèle : noyau de l’application
Vue : interface (graphique) de l’application
Contrôleur : partie de l’application qui prend les
décisions.

42
6. INVOCATION IMPLICITE
Avantages
 Approprié pour les systèmes interactifs,
particulièrement ceux impliquant plusieurs vues
du même modèle de données. Peut être utilisé
pour faciliter la maintenance de la cohérence
entre les données distribuées
Inconvénients
 Assez complexe.

 Plus d’efforts de développement car chaque tâche

concerne les trois couches.
43
CONCLUSION
Choix d’une architecture
 Dépend des exigences fonctionnelles et non
fonctionnelles 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écomposition en composants (styles
architecturaux) et de mode d’interactions (e.g.,
orienté objet)
44