Cours Architecture Logicielle

Enseignant responsable: Manel AMMAR, Maître Assistant, ISIMa

LES FONDEMENTS DES

Chapitre 1
ARCHITECTURES LOGICIELLES
PLAN DU CHAPITRE
Section 1
 Définition de l’architecture logicielle
Section 2
 Les styles architecturaux
Section 3
 Définition de l’architecte logiciel

2
SECTION 1

Définition de
l’architecture
logicielle
 SECTION 1
DÉFINITION D’UN LOGICIEL
▪Un logiciel est un ensemble de programmes conçus pour être exécutés sur un ordinateur ou
un appareil électronique afin de réaliser une fonction spécifique
▪Il peut être installé sur un support physique ou utilisé en ligne
▪Il peut être classé en deux catégories :
1.Logiciel système : Il gère les ressources matérielles et fournit des services aux autres
logiciels (exemple: systèmes d'exploitation, les pilotes, les langages de programmation,
et les utilitaires)
2.Logiciel applicatif : Il permet à l'utilisateur d'accomplir des tâches précises (exemple :
éditeur de texte, un navigateur web, un lecteur multimédia, un jeu vidéo)
SECTION 1
DÉFINITION D’UN LOGICIEL
Les systèmes d'exploitation

Les pilotes
Logiciel Système
Les logiciels Gestionnaire de fichiers, Logiciels
de compression de données,
Logiciel

utilitaires Antivirus

Les traducteurs de langage Compilateurs, Interpréteurs

de programmation

Application à usage Microsoft Word, Google Chrome

général
Logiciel Applicatif
Application à usage Logiciel de gestion de stocks,
spécifique logiciels d'imagerie médicale
 SECTION 1
LA CRISE DU LOGICIEL
La crise du logiciel : le problème
Dans les années 1960-1970, l'augmentation de la puissance matérielle a permis de réaliser
des logiciels plus complexes mais l'industrie a été confrontée à plusieurs défis :
▪Projets hors de contrôle : dépassement des délais et des budgets
▪Fiabilité médiocre : logiciels remplis de bugs, instables et difficiles à maintenir
▪Manque de méthodologie : le développement sans planification rigoureuse, sans cadre
structuré
▪Difficulté de maintenance : code spaghetti, absence de modularité, documentation
insuffisante
 SECTION 1
LA CRISE DU LOGICIEL
Exemple : le projet IBM OS/360 (les années 1960)
▪pour
Système d’exploitation multitâche (exécution simultanée de plusieurs programmes), conçu
fonctionner sur toute la gamme des ordinateurs IBM System/360
▪Problèmes rencontrés:
1.Explosion des coûts et des délais: Le projet a coûté 50 millions de dollars de plus que
prévu / Il a pris des années de retard, mettant IBM en difficulté.
2.Complexité ingérable: Des milliers de développeurs impliqués, avec un manque de
coordination / Un code source massif, difficile à maintenir et à comprendre
3.Bugs et instabilité: De nombreux bugs critiques rendant le système inutilisable au départ
/ La correction des erreurs entraînait souvent de nouveaux problèmes
4.Manque de méthodologie: Aucune approche structurée pour la gestion du projet /
Mauvaise estimation des ressources et des délais
SECTION 1
LA CRISE DU LOGICIEL
▪Cet échec a poussé Frederick Brooks, un des responsables du projet, à écrire "The
Mythical Man-Month", un livre de référence qui a influencé le génie logiciel
▪Il y a introduit la célèbre loi de Brooks : "Ajouter des développeurs à un projet en retard
ne fait que le retarder d’avantage"
 SECTION 1
LE GÉNIE LOGICIEL : LA SOLUTION
Le génie logiciel : la solution
▪desDéfinition: le génie logiciel consiste à identifier et à utiliser des méthodes, des pratiques et
outils permettant de maximiser les chances de réussite d'un projet logiciel
▪duObjectifs: structurer le processus de développement d’un logiciel afin de garantir la qualité
produit final tout en optimisant les coûts et les délais
▪Fondamentaux du génie logiciel: parmi ses éléments fondamentaux, on retrouve les
paradigmes logiciels, qui jouent un rôle crucial dans la manière dont les logiciels sont conçus et
développés
1) Paradigme de développement logiciel
2) Paradigme de conception du logiciel
3) Paradigme de programmation
SECTION 1
LE GÉNIE LOGICIEL : LA SOLUTION
Paradigme de
développement
▪Paradigme de développement logiciel : l'ensemble
logiciel
des approches utilisées pour concevoir, développer,
tester, déployer, et maintenir un logiciel
Paradigme de
conception du
logiciel
▪Paradigme de conception du logiciel: se concentre
spécifiquement sur l'architecture et la structuration du
logiciel avant sa mise en œuvre
▪Paradigme
Paradigme de
programmation
de programmation: se réfère aux
différents styles ou approches que les développeurs
adoptent pour écrire le code du logiciel (par
exemple, Programmation orientée objet,
Programmation procédurale, etc.)
 SECTION 1
DÉFINITION DE L’ARCHITECTURE LOGICIELLE
L'architecture logicielle : « l'art de construire les logiciels »
▪L'activité d'architecture : une phase au cours de laquelle on effectue les grands choix qui vont
structurer une application (langages et technologies utilisés, découpage en sous-parties)
▪Le résultat de l’activité d'architecture : la structure du logiciel, son squelette
▪Le logiciel créé doit répondre aux besoins et résister aux nombreuses modifications qu'il subira
au cours de son cycle de vie
▪Contrairement à un bâtiment, un logiciel mal pensé ne risque pas de s'effondrer : une
mauvaise architecture peut faire exploser le temps nécessaire pour réaliser les modifications, et
donc leur coût
 SECTION 1
DÉFINITION DE L’ARCHITECTURE LOGICIELLE
Exemple de projet: application web de gestion de stock
Phase 1: L’application est initialement développée pour une petite
entreprise
▪Description: l’application permet aux employés de saisir manuellement les
entrées et sorties de produits via une interface web connectée à une base de
données centrale

Phase 2: L’entreprise élargit son marché et le volume de transactions

devient important
▪Solution: L’entreprise décide d’intégrer une solution IoT avec des lecteurs RFID
pour automatiser le suivi des stocks en scannant les produits en temps réel
▪Problème architectural : L’application initiale n’a pas été conçue pour gérer des
flux de données en temps réel ni pour interagir avec des appareils IoT
 SECTION 1
DÉFINITION DE L’ARCHITECTURE LOGICIELLE

▪Le résultat de l’activité d'architecture : la structure Présentation

du logiciel, son squelette
▪L'activité d'architecture consiste aussi à choisir
comment répartir les trois composantes basiques
d’une application: la présentation, les traitements, et
les données Données Traitement
 SECTION 1
DÉFINITION DE L’ARCHITECTURE LOGICIELLE
Le résultat de l’activité d'architecture décrit les principaux éléments qui composent le
logiciel (les trois composantes basiques, etc.), ainsi que les flux d'échanges entre ces
éléments
Le résultat de l’activité d'architecture permet à l'équipe de développement d'avoir une vue
d'ensemble de l'organisation du logiciel selon différents points de vue :
▪Point de vue logicielle
▪Point de vue physique
 SECTION 1
DÉFINITION DE L’ARCHITECTURE LOGICIELLE
Le résultat de l’activité d'architecture de point de vue logicielle

La présentation
Communication La logique métier Les données

Front-end Back-end
 SECTION 1
DÉFINITION DE L’ARCHITECTURE LOGICIELLE
Le résultat de l’activité d'architecture de point de vue logicielle : MEAN Stack
Applications complexes (Exemple : ERP, Dashboards)

La présentation
Angular
Communication La logique métier Les données
Node.js + Express.js MongoDB

Front-end Back-end
 SECTION 1
DÉFINITION DE L’ARCHITECTURE LOGICIELLE
Le résultat de l’activité d'architecture de point de vue logicielle : MERN Stack
Applications interactives, légères, et évolutives (Exemple : Facebook, Instagram)

La présentation
React.js
Communication La logique métier Les données
Node.js + Express.js MongoDB

Front-end Back-end
 SECTION 1
DÉFINITION DE L’ARCHITECTURE LOGICIELLE
Le résultat de l’activité d'architecture de point de vue physique
Un client léger ou lourd
Poste client 1

Serveur(s)
Serveur(s) de gestion
Poste client 2 d’application des bases de
données

Front-end Back-end
SECTION 2

LES STYLES
ARCHITECTURAUX
SECTION 2
LES STYLES ARCHITECTURAUX
Répartition logique des Répartition physique des
composants de l’architecture composants de l’architecture
logicielle logicielle

Présentation
Machine(s) Machine(s)
client serveur

Données Traitement
SECTION 2
LES STYLES ARCHITECTURAUX
Répartition logique des composants de l’architecture logicielle
▪Architecture monolithique
▪Architecture en couches
Présentation

Données Traitement
 SECTION 2
LES STYLES ARCHITECTURAUX
L’architecture monolithique
L’architecture monolithique est un modèle d’architecture logicielle où
une application est développée comme un bloc unique et indivisible
Application
Caractéristiques de l’architecture monolithique
•Une seule base de code : Tous les composants (interface utilisateur, Présentation
logique métier, données, etc.) sont intégrés dans une seule base de
code Logique métier

•Un seul déploiement : L’application est compilée et déployée en tant Données

qu’unité unique
•Accès direct aux ressources : Les différents modules peuvent Architecture monolithique
communiquer directement
 SECTION 2
LES STYLES ARCHITECTURAUX Application

L’architecture monolithique Présentation

▪Avantages Logique métier

➢Facile à développer, tester et déployer pour de petits projets
➢Pas de latence liée aux communications réseau Données
➢Un seul fichier binaire ou package à livrer
▪Inconvénients Architecture monolithique
➢Difficile de faire évoluer certaines parties de l’application indépendamment
➢Au fur et à mesure de la croissance du projet, le code devient difficile à gérer
➢Une modification mineure peut nécessiter de redéployer toute l’application
 SECTION 2
LES STYLES ARCHITECTURAUX
L’architecture monolithique
Site Web de commerce électronique
Exemple : un Site Web de commerce Logique métier
électronique se basant sur une
Architecture Monolithique Gestion des produits
Présentation Gestion des commandes
Le site web de commerce électronique
assure les fonctionnalités suivantes: Gestion des comptes utilisateur
1) Gestion des produits ▪ Page d'accueil
2) Gestion des commandes ▪ Catalogue de produits
3) Gestion des comptes utilisateur ▪ Panier Données
Les trois composantes de l’application sont ▪ Profil utilisateur
dans le même fichier de code ▪ Table Utilisateurs
▪ Table Produits
▪ Table Commandes
▪ Table Paiements
 SECTION 2
LES STYLES ARCHITECTURAUX
L’architecture en couches
L’architecture en couches est un modèle d’architecture logicielle qui divise une application en différentes
couches Chaque couche a une responsabilité spécifique et communique avec les couches adjacentes
▪Avantages :
➢Séparation des préoccupations : Chaque couche est responsable d'une fonctionnalité spécifique, ce qui

facilite la compréhension et la maintenance

➢Réutilisabilité : Les composants de chaque couche peuvent être réutilisés dans d'autres projets

➢Testabilité : Chaque couche peut être testée indépendamment

➢Facilité d'évolution : Les modifications dans une couche peuvent être effectuées sans affecter les autres

couches
▪Inconvénients :
➢Complexité / Performances : Les appels entre les couches peuvent ajouter une latence si la communication

est basée sur un réseau

 SECTION 2
LES STYLES ARCHITECTURAUX
L’architecture en couches
Couches typiques de l'architecture en couches
1. Couche de présentation (ou front-end)
Définition : Cette couche est responsable de l'interaction avec l'utilisateur. Elle gère l'affichage des données
et les interactions de l'utilisateur avec l'application.
▪Responsabilités :
➢Afficher l'interface utilisateur (UI)
La couche présentation
➢Recevoir les entrées de l'utilisateur (clics, formulaires, etc.)

➢Communiquer avec la couche métier

▪Technologies courantes :
➢HTML, CSS, JavaScript

➢Frameworks comme React, Angular, Vue.js, Flutter

Front-end
 SECTION 2
LES STYLES ARCHITECTURAUX
L’architecture en couches
Couches typiques de l'architecture en couches
2. Couche métier (ou logique métier)
Définition : Cette couche décrit les traitements à exécuter par l’application afin de La couche
répondre aux besoins des utilisateurs présentation
▪Responsabilités :
➢On distingue deux types de traitements
1)traitements locaux : tiennent compte les contrôle effectués au niveau du dialogue avec
l’IHM (formulaires, boutons,...) La couche
2) traitements globaux : représentent les règles de l’application appelées aussi logique logique métier
métier
▪Technologies courantes :
➢Langages de programmation tels que Java (Spring), PHP (Symfony), Python (Django,
Flask).
 SECTION 2
LES STYLES ARCHITECTURAUX
L’architecture en couches
La couche
Couches typiques de l'architecture en couches présentation
3. Couche données
Définition :
Cette couche est responsable de la communication avec la base de données. Elle
gère toutes les opérations de création, lecture, mise à jour et suppression (CRUD)
La couche
▪Responsabilités :
logique métier
➢Garantie souvent les fonctions classiques d’un SGBD à savoir : Définition de
données, Manipulation de données, Sécurité de données, gestion des
transactions, etc.
▪Technologies courantes :
La couche
➢Bases de données comme MySQL, PostgreSQL, MongoDB
données
 SECTION 2
LES STYLES ARCHITECTURAUX
Critères Architecture Monolithique Architecture en Couches
Application unique avec tous les composants Plusieurs couches distinctes (présentation,
Structure
intégrés logique métier, accès aux données, etc.)
Développement intégré avec tous les modules Développement modulaire avec chaque couche
Développement
dans un seul projet séparée
Difficile : une modification dans un module Plus facile : chaque couche peut être modifiée
Maintenance
peut impacter l'ensemble de l'application indépendamment sans affecter les autres
Peut devenir complexe avec l'augmentation de Plus complexe par nature, mais la séparation
Complexité
la taille de l'application des préoccupations aide à gérer la complexité
Bonne performance pour les petites Peut introduire une latence en raison de la
Performance
applications communication entre les couches
Tests plus difficiles en raison de la dépendance Tests plus faciles grâce à la séparation des
Tests
des composants couches et à l'isolement des fonctionnalités
Moins flexible : les modifications peuvent
Plus flexible : les modifications peuvent être
Flexibilité nécessiter des changements dans tout le
limitées à une seule couche
système
 SECTION 2
LES STYLES ARCHITECTURAUX
Répartition physique des composants de l’architecture logicielle :
1) Architecture centralisée
2) Architecture répartie / distribuée
Serveur de Base de
Critère Serveur Web Serveur d'Application
Données
Gérer les requêtes HTTP Exécuter la logique
Stocker, gérer, et
Rôle principal et servir des contenus métier et traiter les
récupérer les données
statiques ou dynamiques demandes des clients
HTML, CSS, JavaScript, SQL, MongoDB Query
Langages Java, Python, etc.
PHP, etc. Language, etc.
MySQL, PostgreSQL,
Exemples de logiciels Apache Tomcat, Node.js
Oracle, MongoDB, etc.
Reçoit des requêtes du
Reçoit des requêtes des Reçoit des requêtes de
serveur web et
Interactions clients et renvoie des serveurs d'application et
communique avec la base
pages web retourne les données
de données
 SECTION 2
LES STYLES ARCHITECTURAUX
Répartition physique des composants de l’architecture logicielle : Architectures Multi-tiers
Architectures Multi-tiers: une approche de déploiement d'applications informatiques

Les couches de l’application peuvent être déployées sur des nœuds physiques différents (les Tiers)
Le découpage et la répartition des trois composantes d’une application informatique, permettent
de distinguer plusieurs types d’architecture de déploiement / Architectures Multi-tiers :
▪Architecture 1-tiers  Architecture Centralisée
▪Architecture 2-tiers  Architecture Client/serveur
▪Architecture 3-tiers  Architectures Réparties
▪Architecture n-tiers  Architectures Réparties
 SECTION 2
LES STYLES ARCHITECTURAUX
Architectures Multi-tiers: Architecture 1-tiers
▪Les trois composantes de l’application sont liées et s'exécutent sur la même machine
▪On parle donc de l’informatique centralisée

Application Déploiement sur 1 seule machine

Présentation

Logique métier

Données
 SECTION 2
LES STYLES ARCHITECTURAUX
Architectures Multi-tiers: Architecture client/serveur
L’architecture client/serveur est un modèle où les composants d'une application sont répartis
entre un client (qui demande des services) et un serveur (qui fournit ces services)
Types d’Architectures Client/Serveur:
1)Architecture 2-tiers
2)Architecture 3-tiers
3)Architecture n-tiers
 SECTION 2
LES STYLES ARCHITECTURAUX
Architecture client/serveur : Architecture 2-tiers
Architecture
▪Les trois couches de l’application sont Application
déployées sur deux machines différentes : la
machine client et la machine serveur Présentation
▪Les Données sont centralisées sur un Serveur Logique métier
de Base de Données / SGBD
▪Le dialogue client-serveur se résume à l’envoi Données
de requêtes et retour des données
correspondantes Quelles sont les différentes possibilités de
répartition des trois couches logicielles
entre les clients et le serveur ?
 SECTION 2
LES STYLES ARCHITECTURAUX
Architecture client/serveur : Architecture 2-tiers
L’architecture 2-tiers est un modèle où l’application Répartition 2
est réparties sur deux tiers (machines) principales : Présentation
Logique métier
1.Le client (Tier 1) : Couche présentation (Interface Logique de
présentation Données
utilisateur) + parfois une partie de la logique
métier
Répartition 1
2.Le tier serveur (Tier 2) : Base de données + Logique métier
éventuellement la logique métier
Présentation Données
Le client communique directement avec le serveur
via un réseau (LAN, Internet…)
 SECTION 2
LES STYLES ARCHITECTURAUX
Architecture client/serveur : Architecture 2-tiers
Composants de l'architecture 2-tiers :
1) Tier 1 : Client
• Interface utilisateur : Conçu pour faciliter l'interaction avec l'utilisateur, l'interface peut inclure des
formulaires, des boutons et d'autres éléments graphiques
• Logique de présentation : Gère la validation des données et l'interaction avec l'utilisateur avant
d'envoyer des requêtes au serveur
2) Tier 2 : Serveur
• Logique métier : Contient la logique nécessaire pour traiter les demandes des clients, effectuer des
calculs et manipuler les données
• Gestion des données : Interagit avec la base de données pour stocker, récupérer, mettre à jour et
supprimer des informations
 SECTION 2
LES STYLES ARCHITECTURAUX
Architecture client/serveur : Architecture 3-tiers (Architectures Réparties)
▪Son principe de base consiste à séparer trois couches logicielles, contenues dans une
application, sur trois niveaux ou machines
▪Avantages:
➢Faciliter la maintenance et les évolutions futures de l’application (Chaque couche est
indépendante)
➢Assurer une sécurité plus importante car l’accès à la base de données n’est autorisé que par
la couche logique métier
➢Optimiser le travail en équipe
 SECTION 2
LES STYLES ARCHITECTURAUX
Architecture client/serveur : Architecture 3-tiers (Architectures Réparties)
▪Principe de partitionnement
▪La couche présentation est toujours prise en charge par le poste client (Tier 1)
▪La couche logique métier est prise en charge par un serveur intermédiaire / souvent Serveur
d’application (Tier 2)
▪Les données sont toujours gérées par un serveur de base de données (Tier 3)

▪C'est une architecture partagée entre :

1)Un Client qui est l'ordinateur demandeur de ressources, équipée d'une interface utilisateur
2)Le serveur d'application, chargé de fournir les ressources mais faisant appel à un autre serveur
(serveur de données)
3)Le serveur de base de données qui va fournir au serveur d'application les données dont il a
besoin
 SECTION 2
LES STYLES ARCHITECTURAUX
Architecture client/serveur : Architecture 3-tiers (Architectures Réparties)
▪Fonctionnement
1. Client : envoi une requête au serveur applicatif
2. Serveur applicatif : exécute le service sollicité tout en demandant le serveur de BDD les données
nécessaires pour le service
3. Serveur de base de données : renvoi les données sollicitées en exécutant des requêtes sur les BD
4. Serveur applicatif : prépare le service puis le renvoi au client
Inconvénient : Le serveur applicatif
réalise la majorité des traitements
Solution : Afin de bien équilibrer la
charge entre les différents niveaux une
architecture dite n-tiers semble
intéressante
 SECTION 2
LES STYLES ARCHITECTURAUX
Architecture client/serveur : Architecture n-tiers (Architectures Réparties)
▪Objectif : Pallier aux limitations de l’architecture 3-tiers et concevoir des applications puissantes
et simple à maintenir
▪Solution : Distribuer la logique applicative pour une meilleurs répartition de la charge entre tous
les niveaux
 SECTION 2
LES STYLES ARCHITECTURAUX
Critères Architecture 2-tiers Architecture 3-tiers Architecture n-tiers
N tiers : Client + Logique métier
3 tiers : Client + Serveur Application +
Structure 2 tiers : Client + Serveur (plusieurs serveurs) + serveur base de
serveur BD
données
Moyenne : séparation entre client et Bonne : séparation claire entre les Excellente : chaque tier a des
Séparation des responsabilités
serveur couches responsabilités spécifiques
Limitée : le serveur doit gérer tous les Meilleure : possibilité de mettre à Excellente : chaque tier peut être mis à
Scalabilité
clients l'échelle la logique métier séparément l'échelle indépendamment
Modérée : ajout d'une couche Élevée : plus de couches à gérer et à
Complexité Simple : moins de composants à gérer
intermédiaire maintenir
Bonne pour un faible nombre Peut introduire de la latence entre les Peut introduire plus de latence en raison
Performance
d'utilisateurs couches des communications inter-tiers
Peut nécessiter des mises à jour Complexe : les mises à jour doivent être
Mise à jour Simple : mise à jour directe du serveur
synchronisées entre les couches gérées entre plusieurs couches
Meilleure : la logique métier peut gérer Excellente : chaque tier peut appliquer
Sécurité Dépend du serveur pour la sécurité
la sécurité ses propres mesures de sécurité
Limitée : modifications peuvent affecter Bonne : possibilité d'évoluer Excellente : chaque tier peut évoluer
Flexibilité
l'ensemble indépendamment des tiers indépendamment
Applications de bureau, systèmes Applications web, systèmes de gestion Applications d'entreprise complexes,
Exemples d'utilisation
simples d'entreprise (ERP) Applications web complexes
SECTION 3

Définition de
l’architecte logiciel
 SECTION 3
DÉFINITION DE L’ARCHITECTE LOGICIEL
UTILITÉS D'UNE ARCHITECTURE LOGICIELLE

Utilité Description
Permet de structurer le système en composants modulaires
Structure et organisation claires
et de faciliter la compréhension du projet.
Divise le système en modules indépendants, chacun
Séparation des préoccupations
responsable d'une fonction spécifique
Facilite la maintenance et les mises à jour avec moins
Amélioration de la maintenabilité
d'impact sur le reste du système.
Permet de gérer les extensions du système tout en
Scalabilité et performance
maintenant des performances optimales
Facilite la réutilisation des composants existants pour
Réutilisation du code
réduire les coûts et le temps de développement
 SECTION 3
DÉFINITION DE L’ARCHITECTE LOGICIEL
▪L'architecte logiciel: Un expert en informatique / un
professionnel
1.responsable de la conception et de l'organisation
globale des systèmes logiciels
2.responsable de la création et du respect du
modèle d'architecture logicielle
3.responsable de définir et communiquer une
architecture logicielle qui satisfait les contraintes
 SECTION 1
DÉFINITION DE L’ARCHITECTE LOGICIEL
RESPONSABILITÉS DE L’ARCHITECTE LOGICIEL
Responsabilités de l’architecte logiciel Description
Conception de l'architecture logicielle Définition de la structure globale du système
Prise en compte des exigences non fonctionnelles Comme la scalabilité, la sécurité, la performance, et la maintenabilité
Sélection des technologies et outils Choix des technologies en fonction des besoins du projet
Communication avec les parties prenantes Collaboration avec les équipes techniques et non techniques
Gestion des risques techniques Identification des risques et mise en place de solutions

Documentation Création de la documentation de l'architecture

Revue de code et validation de la conformité de l’implémentation
Évaluation et validation de l'implémentation
finale avec le modèle de conception de l'architecture
Suivi des évolutions technologiques et adaptation de l'architecture en
Évolution continue
conséquence
 Cours Architecture Logicielle
Enseignant responsable: Manel AMMAR, Maître Assistant, ISIMa

MODÉLISATION AVEC UML DES

Chapitre 2
ARCHITECTURES LOGICIELLES
PLAN DU CHAPITRE
Section 1
 L’architecture dans le cycle de vie d'un logiciel
Section 2
 Développer un modèle architectural : modéliser avec UML
 Partie 1 : Diagramme de paquetage
 Partie 2 : Diagramme de composants
 Partie 3 : Diagramme de déploiement

47
SECTION 1

L’ARCHITECTURE
DANS LE CYCLE DE VIE
D'UN LOGICIEL
SECTION 1
L’ARCHITECTURE DANS LE CYCLE DE VIE D'UN LOGICIEL
▪Le génie logiciel couvre l'ensemble du cycle de vie d'un logiciel
▪Le cycle de vie du logiciel fait référence aux étapes à suivre pour créer, déployer
et maintenir un logiciel.
▪Chaque phase a des objectifs spécifiques, et chacune d’elles est liée à des
pratiques et des méthodologies issues du génie logiciel
 SECTION 1
L’ARCHITECTURE DANS LE CYCLE DE VIE D'UN LOGICIEL
1. Planification Livrable: Plan de gestion de projet

2. Expression des Livrable: Cahier des charges fonctionnel

besoins

3. Analyse Livrable: Cahier des charges technique

4. Conception Livrable: Document de conception détaillée

5. Développement Livrable: Code source

6. Tests Livrable: Version stable du logiciel

7. Déploiement Livrable: Logiciel déployé en production

Livrable: Correctifs et
8. Maintenance
mises à jour du logiciel
 SECTION 1
L’ARCHITECTURE DANS LE CYCLE DE VIE D'UN LOGICIEL
Etape 1 : Planification
▪ Livrable principal : Plan de gestion de projet
▪ Objectif : Définition des grandes lignes du projet : objectifs, risques, ressources, et délais
▪ Contenu :
1. Charte de projet
1. Plan de gestion de projet: définit la méthodologie de gestion de projet
2. Plan de ressources: détailler les ressources humaines, matérielles et logicielles
3. Plan de gestion des risques identifie les risques potentiels pour le projet, leur probabilité
d’occurrence, leur impact, et les stratégies pour les atténuer ou les gérer.
4. Estimation des coûts et budget : estime le coût total du projet et fournit un budget
détaillé
SECTION 1
L’ARCHITECTURE DANS LE CYCLE DE VIE D'UN LOGICIEL
Etape 2 : Expression des besoins (Spécification des besoins)
▪ Livrable principal : Cahier des charges fonctionnel
▪ Objectif : Définir ce que doit faire le système sans entrer dans les détails techniques.
▪ Contenu :
1. Besoins fonctionnels : Décrire les actions que le logiciel doit accomplir
2. Besoins non fonctionnels : Performances, sécurité, compatibilité, contraintes
ergonomiques, etc.
3. Contraintes : Budget, délais, technologies souhaitées.
 SECTION 1
L’ARCHITECTURE DANS LE CYCLE DE VIE D'UN LOGICIEL
Etape 3 : Analyse
▪ Livrable principal : Cahier des charges techniques
▪ Objectif : Traduire les besoins en exigences précises et identifier les contraintes techniques
et les risques
▪ Contenu :
1. Modélisation des cas d’utilisation : Diagramme de cas d’utilisation, de classes, de séquence,
d’activité
2. Étude de faisabilité : Techniques, économiques, temporelles, et humaines.
3. Architecture préliminaire : Présentation des choix d'architecture (par exemple, choisir entre
architecture monolithique ou en couches)
4. Détails sur l’interopérabilité : Protocoles de communication, intégration avec des systèmes
existants
5. Plan de gestion des risques : Identification des risques techniques, humains, etc.
 SECTION 1
L’ARCHITECTURE DANS LE CYCLE DE VIE D'UN LOGICIEL
Etape 4 : Conception
▪ Livrable principal : Document de conception détaillée
▪ Objectif : Définir comment le système va être construit et structuré techniquement
▪ Contenu :
1. Architecture logicielle détaillée : Diagrammes UML (diagramme de paquetages, diagramme
de composants, diagramme de déploiement)
2. Modélisation avancée : diagramme de classes de conception, de séquence de conception,
de paquetages
3. Modèle de données : Schéma de base de données
4. Spécifications des interfaces : API, format des données échangées, etc.
5. Plan de tests : Tests unitaires, d’intégration, tests de performance et de sécurité.
6. Stratégie de développement : Découpage en modules ou sprints, choix des technologies, outils de
développement, et de gestion de version
SECTION 2
DÉVELOPPER UN
MODÈLE
ARCHITECTURAL :
MODÉLISER AVEC
UML

55
 SECTION 2
MODÉLISER AVEC UML
▪ Vue Logique : modéliser la structure statique
Vue du système
Vue Logique d'Implémentation ▪ Vue d'Implémentation : Description de
Diagramme de classes l’implémentation (physique) du système
Diagramme de composants
Diagramme de paquetage logiciel
▪ Vue Comportement : décrire le
Vue Cas comportement dynamique du système
d’Utilisation ▪ Vue Déploiement : montrer comment la
Diagramme de séquence
Diagramme d’activités
partie logicielle est déployé sur la partie
Diagramme de déploiement matérielle (des serveurs, des machines
Diagramme d’état
Vue Comportement Vue Déploiement physiques, ou des conteneurs cloud)
▪ Vue Cas d’Utilisation : Montrer les
interactions entre les utilisateurs et le système
 SECTION 2
MODÉLISER AVEC UML
Décrire l’architecture avec UML

▪ Tous les diagrammes UML peuvent être utiles pour décrire les différents aspects du
modèle architectural en fonction des aspects que l'on souhaite modéliser (structure,
comportement, interactions, etc.)
▪ Trois des diagrammes UML sont particulièrement utile pour décrire une architecture
logicielle
1) Diagramme de packages
2) Diagramme de composants
3) Diagramme de déploiement
 SECTION 2
DÉVELOPPER UN MODÈLE
ARCHITECTURAL :
MODÉLISER AVEC UML
PARTIE 1 : DIAGRAMME DE
PAQUETAGE

58
 SECTION 2
DIAGRAMME DE PAQUETAGE
Utilité du diagramme de paquetage

▪ Le diagramme de paquetage UML est utilisé pour organiser la partie logicielle d'une
application en regroupant les classes selon leurs responsabilités
▪ Rôle du Diagramme de Paquetage dans l'Architecture Logicielle
1) Organisation modulaire du système : Permet d'organiser et de structurer les grands
systèmes / Un système peut être vu comme un paquetage unique contenant des sous-
paquetages (représentant ses sous-systèmes)
2) Gestion de la dépendance : Identifie et gère les dépendances entre les modules
3) Documenter l'architecture du système : Sert à documenter et à communiquer
l'architecture du système
 SECTION 2
DIAGRAMME DE PAQUETAGE
Composants de base d'un diagramme de paquetage
1) Paquetage (Package) : Package
▪Regrouper un ensemble d'éléments liés de
manière logique au sein d'un système Dépendance
▪Contient d’autres éléments UML : classes, « stéréotype »
interfaces, sous-packages, etc. Nom
▪Peut être hiérarchique (un package peut contenir
d'autres packages) contenu
2) Dépendance (dependency) : Indique qu’un
package utilise les éléments d’un autre

Les stéréotypes permettent de qualifier les paquetages (exactement comme pour les classes) : préciser le rôle
ou la nature du paquetage dans l’architecture du système
Exemple: ajouter stéréotype « layer » pour un paquetage qui illustre une couche logicielle
 SECTION 2
DIAGRAMME DE PAQUETAGE
Utilité du diagramme de paquetage pour l’architecture logicielle
▪Le plus souvent utilisés pour donner un aperçu visuel de l'architecture en couches d’un
système logiciel : chaque paquetage présente une couche de l’architecture logicielle
▪Définir la vue statique du Modèle d’une architecture logicielle

« layer » « layer » « layer »

Présentation Métier Données
 SECTION 2
DIAGRAMME DE PAQUETAGE
Utilité du diagramme de paquetage pour l’architecture logicielle
▪Le plus souvent utilisés pour donner un aperçu visuel de l'architecture en couches d’un
système logiciel : chaque paquetage présente une couche de l’architecture logicielle
▪Définir la vue statique du Modèle d’une architecture logicielle

« layer » « layer » « layer »

Présentation Métier Données
 SECTION 2
DIAGRAMME DE PAQUETAGE
Comment structurer le système en paquetage
Trois étapes à suivre :
1) Partitionner le diagramme de classes d’analyse (représente la logique métier de
l’application) afin d’obtenir un diagramme de paquetage de la logique métier
2) Enrichir le diagramme de classes d’analyse avec les classes qui représentent les
interfaces (couche présentation) et les classes qui représentent les contrôleurs
(couche logique applicative) pour obtenir le diagramme de classes de
conception
3) Partitionner le diagramme de classes de conception afin d’obtenir un diagramme
de paquetage de l’architecture logique
 SECTION 2
MODÉLISER AVEC UML
Étude de cas : Site web de Vente de livres en ligne
 SECTION 2
MODÉLISER AVEC UML
Description du Site web de Vente de livres en ligne

▪ Le site de vente en ligne de livres permet à un client de consulter un catalogue de livres,

composer un panier, passer une commande, et recevoir les achats à une adresse donnée.
▪ Le site propose un catalogue structuré en rayons (équivalents à des catégories, ex. : "Science-
fiction", "Romans", etc). Chaque rayon contient plusieurs livres.
▪ Chaque livre est caractérisé par : un titre, un sous-titre, un ISBN (identifiant unique), une langue,
une date de parution, et un prix.
▪ Chaque livre est écrit par un ou plusieurs auteurs caractérisé(s) par un nom, et un prénom,
▪ Chaque livre est édité par un éditeur, identifié par son nom et son pays d’origine.
 SECTION 2
MODÉLISER AVEC UML
Description du Site web de Vente de livres en ligne
▪ Un client peut passer plusieurs commandes.
▪ Chaque commande comprend : une date de commande, un délai de livraison estimé, les frais de
port, le montant total.
▪ Une commande est associée à un panier, qui regroupe les livres sélectionnés, et à une adresse de
livraison spécifique (qui peut différer de l’adresse de facturation).
▪ Le panier contient une liste de livres, ainsi que deux attributs : le nombre d’articles, le total (prix
cumulé des articles). Un panier peut donc regrouper plusieurs exemplaires de différents livres.
▪ Un client est identifié par son nom, prénom et adresse email. Chaque client dispose d’une adresse
de facturation (obligatoire) et peut fournir une ou plusieurs adresses de livraison. Chaque adresse
inclut les informations classiques : nom, prénom, numéro et rue, code postal, ville, et pays.
 SECTION 2
MODÉLISER AVEC UML
Diagramme de classes d’analyse du Site web de Vente de livres en ligne
 SECTION 2
MODÉLISER AVEC UML
Etape 1 : Partitionner le diagramme de classes d’analyse
 SECTION 2
MODÉLISER AVEC UML
Etape 1 : Partitionner le diagramme de classes d’analyse
Diagramme de paquetage détaillé de la logique métier
 SECTION 2
MODÉLISER AVEC UML
Etape 1 : Partitionner le diagramme de classes d’analyse
Diagramme de paquetage simplifié de la logique métier
 SECTION 2
MODÉLISER AVEC UML
Etape 1 : Partitionner le diagramme de classes d’analyse
Diagramme de paquetage abstrait de la logique métier
 SECTION 2
MODÉLISER AVEC UML
Etape 2 : Enrichir le diagramme de classes
d’analyse pour obtenir le diagramme de
classes de conception
▪ La méthode ajouterArticleAuPanier() de la classe
ControleurPanier appelle la méthode ajouterArticle() de
la classe Panier
▪ La méthode supprimerArticleDuPanier() de la classe
ControleurPanier appelle la méthode supprimerArticle()
de la classe Panier
▪ La méthode demanderSuppressionArticle() de la classe
DialogueGestionPanier appelle la méthode
supprimerArticleDuPanier() de la classe
ControleurPanier
 SECTION 2
MODÉLISER AVEC UML
Etape 3 : Partitionner le diagramme de classes de conception afin d’obtenir un
diagramme de paquetage de l’architecture logique
Diagramme de paquetage détaillé de l’architecture logique

Diagramme de paquetage abstrait de l’architecture logique

 SECTION 2
DÉVELOPPER UN MODÈLE
ARCHITECTURAL :
MODÉLISER AVEC UML
PARTIE 2 : DIAGRAMME DE
COMPOSANTS

74
 SECTION 2
DIAGRAMME DE COMPOSANTS
Fixer une architecture Modèle détaillé de l’architecture logicielle
préliminaire : Décider le style
architectural (monolithique ,
en couches)

3. Analyse
• Diagramme de classes de
conception
• Diagramme de paquetage de
• Diagramme de • Diagramme de classes l’architecture logique
cas d’utilisation d’analyse • Diagramme de composants
• Diagramme de paquetage • Diagramme de déploiement
2. Expression des de la logique métier
besoins
4. Conception
 SECTION 2
DIAGRAMME DE COMPOSANTS
• Diagramme de classes de Modèle de l’architecture logicielle détaillé en 3 vues :
conception 1) Vue logique : Diagramme de classes de conception et
• Diagramme de paquetage de Diagramme de paquetage de l’architecture logique
l’architecture logique
• Diagramme de composants 2) Vue d’implémentation : Diagramme de composants
• Diagramme de déploiement 3) Vue de déploiement : Diagramme de déploiement

4. Conception

La vue d’implémentation
✓ Montre comment les éléments du système sont organisés concrètement dans le code
✓ Permet de passer de la modélisation abstraite à une modélisation prête à être codée
SECTION 2
DIAGRAMME DE COMPOSANTS
SECTION 2
DIAGRAMME DE COMPOSANTS
▪ Lorsqu'on passe de la modélisation des classes à leur implémentation en Java, chaque classe est
généralement convertie en un fichier .java contenant le code source
▪ Deux fichiers : Commande.java et Panier.java
 SECTION 2
DIAGRAMME DE COMPOSANTS
Commande.java
public class Commande {
private int delaisLivraison; Panier.java
private double fraisDePort; public class Panier {
private double montantTotal;
private int nombreArticles;
public Commande(Panier panier, int delaisLivraison, double fraisDePort) private double total;
{this.delaisLivraison = delaisLivraison;
this.fraisDePort = fraisDePort; public Panier(int nombreArticles, double total) {
this.montantTotal = panier.getTotal() + fraisDePort; this.nombreArticles = nombreArticles;
} this.total = total;
}
public void afficherDetails() {
System.out.println("Délai de livraison : " + delaisLivraison + " jours"); public int getNombreArticles() {
System.out.println("Frais de port : " + fraisDePort + " DT"); return nombreArticles;
System.out.println("Montant total : " + montantTotal + " DT"); }
}
} public double getTotal() {
return total;
}
}
 SECTION 2
DIAGRAMME DE COMPOSANTS
Application.java
public class Application {
public static void main(String[] args) {
// Création d’un panier avec 3 articles pour un total de 50 DT
Panier panier = new Panier(3, 50.0);
// Création d’une commande à partir du panier avec un délai de livraison de 5 jours et 7 DT de frais de port
Commande commande = new Commande(panier, 5, 7.0);
Exemple de fichier main
// Affichage des détails de la commande
commande.afficherDetails();
}}

Problèmes du fort couplage entre classes Commande et Panier

▪ Modification difficile : tout changement dans Panier impacte Commande
🚫 ▪ Tests limités : difficile de tester Commande seule sans instance de Panier
▪ Pas extensible : ajouter des variantes de panier oblige à modifier Commande
▪ Faible réutilisabilité : Commande ne peut pas fonctionner avec un autre type de panier
 SECTION 2
DIAGRAMME DE COMPOSANTS
L’architecte logiciel vise à bâtir une architecture flexible, capable de s’adapter aux évolutions
fonctionnelles et techniques
➢ Cela implique :
▪ La Réutilisation des composants
▪ L’extension du système sans modification majeure
▪ La Maintenance facile
➢ Grâce à :
▪ une séparation claire des responsabilités
▪ une faible dépendance entre les modules
🔧 Solution : Introduire une interface IPanier que Panier implémente, pour que Commande
dépende de l’interface, pas de la classe Panier
 SECTION 2 Déclarer une variable capable de
DIAGRAMME DE COMPOSANTS contenir un objet qui implémente
l’interface IPanir
Panier.java
public class Commande {
public class Panier implements IPanier {
private int nombreArticles;
private int delaisLivraison; Commande.java
private double fraisDePort;
private double total;
public Panier(int nombreArticles, double total) { private double montantTotal;
this.nombreArticles = nombreArticles; public Commande(IPanier panier, int delaisLivraison, double fraisDePort) {
this.total = total; this.delaisLivraison = delaisLivraison;
} this.fraisDePort = fraisDePort;
this.montantTotal = panier.getTotal() + fraisDePort;
@Override public int getNombreArticles() { }
return nombreArticles; public void afficherDetails() {
} System.out.println("Délai : " + delaisLivraison + " jours");
System.out.println("Frais de port : " + fraisDePort + " DT");
@Override public double getTotal() {
System.out.println("Montant total : " + montantTotal + " DT");
return total;
}
}
} }

public class Application {

public static void main(String[] args) {
Application.java Créer un objet de type 🔧 IPanier.java
IPanier panier = new Panier(3, 45.0); Panier, qu’on le manipule public interface IPanier {
Commande commande = new Commande(panier, 2, 5.0);
commande.afficherDetails();
via l’interface IPanier int getNombreArticles();
double getTotal();
}
} }
 SECTION 2
DIAGRAMME DE COMPOSANTS
Extensibilité & Réutilisabilité avec les Interfaces
1) Extensibilité : La capacité à ajouter de nouvelles fonctionnalités ou variantes (*) sans modifier le code
existant
Dans l’exemple : Grâce à l'interface IPanier, il est possible d’ajouter de nouvelles classes comme :
PanierAvecPointsFidélité
2) Réutilisabilité : La capacité à réutiliser une partie du code dans d’autres contextes, projets ou modules
Dans l’exemple : Grâce à l’interface, il est possible de réutiliser la classe Commande dans le contexte où
les données du panier viennent d’un autre système via une API par exemple sans changer la logique
(Une application IoT *)
public class PanierAvecFidelite implements IPanier {

Ajout d’une autre classe sans modifier aucune classe public double getTotal() {
existante (*) return total - calculPointsFidelite();

}}
 SECTION 2
DIAGRAMME DE COMPOSANTS
Diagramme de composants : définition et utilité
Définition : Le diagramme de composants décrit les parties logicielles (composants) et leurs
dépendances dans le cadre de l’implémentation d’un système.
Ce que montre ce diagramme :
▪ La vue statique de l'implémentation du système
▪ Les unités fonctionnelles autonome d’un programme
▪ Les relations entre ces unités
Ce type de diagramme est utilisé pour :
▪ Représenter les choix techniques et organisationnels d’un système
▪ Visualiser les liens de dépendance entre les éléments logiciels
▪ Préparer ou documenter les étapes de compilation, de packaging et de déploiement
 SECTION 2
DIAGRAMME DE COMPOSANTS
Éléments d'un Diagramme de Composant
Élément Description Présentation UML

Représente une unité fonctionnelle du système, généralement un module

Composants
logiciel qui implémente des services ou des fonctionnalités spécifiques

Définissent les services fournis ou requises par un composant. Elles

Interfaces permettent la communication entre composants sans exposer les détails
internes
Montrent les interactions entre les éléments du diagramme, indiquant
Dépendances comment un composant dépend d'un autre ou d'une interface pour
fonctionner

Représentent des éléments physiques générés ou déployés dans le système

Artefacts
(ex. fichiers exécutables, bibliothèques, scripts, fichiers de configuration)
 SECTION 2
DIAGRAMME DE COMPOSANTS
Un composant : définition et utilité
Définition : Un composant est un élément physique représentant une partie de l’implémentation
du système / Un composant représente l'implémentation d'une classe dans un système.
Ce qu’un composant peut représenter :
▪ Du code (source, binaire ou exécutable)
▪ Un script ou un fichier de commande
▪ Un fichier de données (table, XML, JSON, etc.)
Dépendance entre composants :
▪ C'est le type de dépendance de base, représentée par une flèche pointant d'un composant vers
un autre
▪ Indique qu'un composant utilise un service ou une ressource d'un autre composant, sans spécifier
un type particulier d'interaction
 SECTION 2
DIAGRAMME DE COMPOSANTS
Dépendance entre composants : Comment décider du sens de la dépendance ?
▪ Un composant client dépend d'un composant fournisseur pour utiliser ses services ou
fonctionnalités
▪ La dépendance va toujours du composant qui consomme un service vers le composant qui
fournit ce service
▪ Exemple simple pour aider à comprendre : l’application de commande en ligne avec deux
composants : Panier et Commande
➢Le composant Panier contient la liste des articles qu'un utilisateur veut acheter
➢Le composant Commande est responsable de la création de la commande et de son paiement
➢Si le composant Commande a besoin du composant Panier pour récupérer les articles avant
de passer au paiement, alors le composant Commande dépend du composant Panier
 SECTION 2
DIAGRAMME DE COMPOSANTS
Interfaces : définition et utilité
▪ Rôle du composant :
➢ Un composant implémente un ou plusieurs services

➢ Ces services sont exposés via des interfaces

➢ Ces services peuvent être utilisés par d’autres composants

▪ Interfaces = contrat d’usage

→ Elles définissent ce que le composant fournit (interface fournie) ou ce dont il a besoin
(interface requise)
➢D'autres composants peuvent se connecter à ces interfaces pour utiliser les services sans
connaître les détails internes
➢Cela permet de structurer les dépendances de manière claire, souple et contrôlée
 SECTION 2
DIAGRAMME DE COMPOSANTS
Interfaces : définition et utilité
Définition :
• Une interface dans un diagramme de composant définit un contrat d'échange entre les composants
• Elle décrit les services qu'un composant fournit ou requiert sans exposer l'implémentation détaillée.
Types d'Interfaces :
• Interface fournie (<<provided>>) : Ce que le composant offre à d'autres composants.
• Exemple : un composant Panier peut fournir une interface pour accéder à l'addition des articles
• Interface requise (<<required>>) : Ce que le composant attend d'autres composants pour fonctionner.
Exemple : un composant Commande peut nécessiter une interface PaiementService pour effectuer le
paiement.
Exemples d'Interfaces :
• IPanier : Interface qui expose des méthodes pour gérer le contenu du panier
 SECTION 2
DIAGRAMME DE COMPOSANTS
Dépendances entre Composants et Interfaces
Deux types de Dépendances entre Composants et Interfaces
1. Dépendance d'implémentation
▪ Stéréotype : <<realize>>
▪ Un composant peut réaliser une interface, c'est-à-dire qu'il implémente les services définis
par l'interface
Exemple :
▪ Le composant Panier réalise l'interface
IPanier, qui définit les opérations disponibles
pour gérer les articles dans le panier
 SECTION 2
DIAGRAMME DE COMPOSANTS
Dépendances entre Composants et Interfaces
Deux types de Dépendances entre Composants et Interfaces
1. Dépendance d'implémentation
2. Dépendance de l'interface pour le composant
▪ Stéréotype : <<use>>
▪ Un composant peut utiliser ou accéder à une interface exposée par un autre composant

Exemple :
▪ Le composant Commande dépend de
l’interface IPanier pour créer une commande
à partir des articles présents dans le panier
 SECTION 2
DIAGRAMME DE COMPOSANTS
Artefacts : définition et utilité
Définition :
▪ Les artefacts représentent des éléments physiques utilisés ou générés par les composants
▪ Ils incluent des fichiers (exécutables, bibliothèques), des scripts, des bases de données, etc
Rôle des Artefacts :
▪ Ils sont associés aux composants pour représenter les éléments physiques qu’ils utilisent ou
produisent
Exemples d'Artefacts :
▪ Fichiers exécutables (ex. application.jar, programme.exe)
▪ Bibliothèques (ex. spring-boot.jar)
▪ Bases de données (ex. utilisateurs.db)
 SECTION 2
DIAGRAMME DE COMPOSANTS
Artefacts : définition et utilité
Stéréotypes pour Artefacts : Ces stéréotypes sont utilisés pour décrire des éléments matériels ou des
fichiers spécifiques dans le système, indiquant la manière dont le système est déployé ou comment les
données sont stockées

▪ <<executable>> : Représente un fichier exécutable, comme un programme ou une application (ex.

.exe, .jar)
▪ <<file>> : Représente un fichier contenant des données ou des ressources (ex. .xml, .json, .txt
▪ <<library>> : Représente une bibliothèque logicielle (ex. .dll, .jar) contenant des fonctions réutilisables
▪ <<database>> : Représente une base de données ou une table dans une architecture relationnelle
 SECTION 2
DIAGRAMME DE COMPOSANTS
Artefacts : Dépendance d'artefact
Dépendance d'artefact :
▪ Cette dépendance est utilisée pour lier un composant à un artefact
▪ La dépendance indique que le composant dépend de la présence d'un artefact pour
fonctionner correctement
 SECTION 2
DIAGRAMME DE COMPOSANTS
Structuration des composants
Quand mettre plusieurs composants dans un seul composant ?
Quand les composants :
▪ Ne sont pas déployés indépendamment
▪ Ont une forte cohésion fonctionnelle (une seule grande fonctionnalité découpée en sous-parties)
Exemple. Un composant GestionCatalogue peut contenir :
▪ Composant Livre
▪ Composant Rayon
▪ Composant Catégorie
👉 Les 3 composants sont fortement liés et ne peuvent pas être déployés séparément et font
partie d'une seule unité métier
 SECTION 2
DIAGRAMME DE COMPOSANTS
Structuration des composants
Quand mettre plusieurs composants dans un seul composant ?
Exemple. Un composant GestionCatalogue peut contenir :
▪ Composant Livre
▪ Composant Rayon
▪ Composant Catégorie
Remarque : même si on introduit des interfaces (entre
Rayon et Catalogue / entre Catalogue et Livre) on garde
une dépendance fonctionnelle forte entre les composants
(dans le sens où un catalogue ne peut rien faire sans livres)
 SECTION 2
DIAGRAMME DE COMPOSANTS
Structuration des composants
Quand mettre plusieurs composants dans un même paquetage ?
Quand les composants :
• Partagent un domaine fonctionnel commun
• Ne sont pas toujours déployés ensemble mais doivent être regroupés sémantiquement
Quand l’objectif de l’architecte logiciel est de structurer le modèle ou le code pour plus de lisibilité
Exemple. Le paquetage Paiement contient un composant principal Commande
▪ L’Objectif de cette architecture : Permettre à Commande d’utiliser n’importe quel moyen de paiement
sans dépendre d’un code spécifique & Faciliter l’ajout futur de nouveaux moyens de paiement
 SECTION 2
DIAGRAMME DE COMPOSANTS
Structuration des composants
Quand mettre plusieurs composants dans un même paquetage ?
▪ Les composants PaiementCB, PaiementPaypal,
PaiementCrypto représentent des implémentations
différentes d’un même service abstrait (Paiement)
▪ Ils ont des codes différents, car chaque moyen de
paiement a une API externe différente (CB, PayPal,
Crypto)
▪ Mais ils partagent : la même interface (IPaiementService)
qui expose deux services : payer() et rembourser()
▪ Tous ces composants peuvent être regroupés dans un
paquetage paiement, car ils ont un objectif fonctionnel
commun, même s’ils ont des logiques internes différentes
 SECTION 2
DIAGRAMME DE COMPOSANTS
Structuration des composants
Composant optionnel dans un paquetage UML
▪ Un composant est dit optionnel lorsqu’il :
✓N’est pas toujours déployé, selon la configuration
du système
✓Correspond à une fonctionnalité additionnelle ou
alternative
▪ Un composant peut être déclaré optionnel via un
stéréotype (ex. : <<optionnel>>)
▪ Exemple : paquetage paiement (site e-commerce)
✓PaiementCB et PaiementPaypal : toujours inclus
✓PaiementCrypto : optionnel, activé par exemple
uniquement pour les clients premium
 SECTION 2
DÉVELOPPER UN MODÈLE
ARCHITECTURAL :
MODÉLISER AVEC UML
PARTIE 3 : DIAGRAMME DE
DÉPLOIEMENT

100
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
• Diagramme de classes de Modèle de l’architecture logicielle détaillé en 3 vues :
conception 1) Vue logique : Diagramme de classes de conception et
• Diagramme de paquetage de Diagramme de paquetage de l’architecture logique
l’architecture logique
• Diagramme de composants 2) Vue d’implémentation : Diagramme de composants
• Diagramme de déploiement 3) Vue de déploiement : Diagramme de déploiement

4. Conception

La vue de déploiement
✓ Montre où et comment les éléments logiciels sont exécutés dans l’infrastructure technique
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Diagramme de déploiement : définition et utilité
Définition : Le diagramme de déploiement est un diagramme structurel UML qui décrit l’organisation
physique d’un système / Offre une vue d'ensemble précise et détaillée de l'infrastructure physique
Rôle dans l’architecture logicielle
▪Représente la structure physique du système (ex. : serveurs, objets connectés, capteurs, clients, etc.)
▪Montre les connexions réseau entre les nœuds physiques
▪Complète le diagramme de composants en précisant comment les composants logiciels seront
distribués et exécutés sur le matériel, les serveurs, ou d'autres ressources de l'environnement
d'exploitation (*)
▪Permet d’anticiper les contraintes de déploiement :
✓ Réseau (latence, bande passante)
✓ Charge (répartition des traitements, scalabilité )
✓ Compatibilité entre plateformes (OS, architectures matérielles, dépendances logicielles)
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Éléments clés d'un Diagramme de Déploiement
Un diagramme de déploiement est composé de :
▪Nœud
▪Artefact
▪Connexion : Lien de communication / Dépendance
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Les nœuds : définition et utilité
Définition : Représentent des ressources matérielles ou des environnements d’exécution sur lesquels
les composants logiciels sont déployés.
En UML, on distingue deux types de nœuds :
1. Nœud physique (<<device>>) : une ressource matérielle
2. Environnement d’exécution (<<executionEnvironment>>) : un environnement virtuel qui
s’exécute dans un nœud physique
Stéréotypes pour les nœuds : Personnaliser et de spécifier le rôle ou le type d’un nœud
Stéréotype Description Exemple
<<device>> Nœud physique Serveur physique, smartphone, carte Arduino, PC
Une machine virtuelle (ex. : JVM), Un système d’exploitation, Serveur
<<executionEnvironment>> Environnement d’exécution d’applications (ex. Apache Tomcat), Serveur Cloud (ex. Azure App Services),
un système de gestion de base de données (ex. PostgreSQL, MongoDB)
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Les nœuds : définition et utilité

Le diagramme de déploiement représente une architecture 2-tiers d’une application web

▪ le client utilise un navigateur web pour accéder à l'application
▪ la machine serveur héberge à la fois le serveur web et la base de données
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Les nœuds : définition et utilité
Un nœud dans un diagramme de déploiement peut posséder des attributs qui décrivent ses
caractéristiques telles que :
• Propriétés de performance : telles que la capacité de mémoire, la vitesse du processeur
• Propriétés logicielles : version du système d'exploitation
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Structure interne des nœuds : artefacts et composants

Un nœud peut contenir deux types éléments internes qui représentent les unités déployées sur ce
matériel ou environnement virtuel
1. Artefacts (Artifacts)
•Représentent des fichiers exécutables, bibliothèques, scripts, etc.
•Exemples : app.war (application Java Web), app.py (script Python), main.exe (binaire
Windows), etc.
2. Composants (Components)
•Représentent des éléments logiciels du système
•Exemples : Composant GestionCatalogue, Composant Panier, etc.
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Structure interne des nœuds : artefacts et composants

Quand placer un Artefact dans un nœud ?

Si on veut représenter un élément physiquement déployé sur le matériel
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Structure interne des nœuds : artefacts et composants
Quand placer un Composant dans un nœud ?
Si on veut illustrer un module logique ou une fonctionnalité déployée parce ce module reflète
la manière dont le logiciel est construit et divisé en parties
 SECTION 2
DIAGRAMME DE DÉPLOIEMENT
Les Liens de communication
Définition : Représente une connexion physique entre deux nœuds matériels qui permet aux
appareils d’échanger des données / Représente souvent une connexion réseau
▪Possibilité d’ajout des Multiplicités aux extrémités
•Permet d’indiquer qu’un nœud peut communiquer avec plusieurs autres nœuds (1..*, 0..1, etc.)