06/01/2021

Introduction
 L'activité d'architecture, une phase consacrer pour les
ARCHITECTURE LOGICIELLE grands choix de la structuration de l’application :
langages , technologies utilisés et découpage en sous-
« l'art de construire les logiciels »
parties, méthodologies mises en œuvre...
 Le résultat de cette activité, donne la structure de
l'application, 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.

156 157

Répartition des problématiques Principes de conception

 Cette partie présente les grands principes qui doivent guider la
Un logiciel sert à automatiser des traitements sur des données. création d'un logiciel, et plus généralement le travail du développeur
Donc confrontée à trois problématiques au quotidien
 la problématique de présentation : consiste à gérer les
interactions avec l'extérieur, en particulier l'utilisateur : saisie et
contrôle de données, affichage.
 la problématique des traitements : consiste à effectuer
sur les données des opérations (calculs) en rapport avec les
règles métier (« business logic »).
 la problématique des données : consiste à accéder et
stocker les informations qu'il manipule, notamment entre deux
utilisations.

158 159

1

Séparation des responsabilités
 Le principe de séparation des responsabilités (separation
of concerns):vise à organiser un logiciel en plusieurs sous-parties,
chacune ayant une responsabilité bien définie.
Le principe de la responsabilité unique (single
responsibility principle): chaque sous-partie atomique d'un
logiciel (exemple : une classe) doit avoir une unique
responsabilité (une raison de changer) ou bien être elle-
même décomposée en sous-parties.
160
Réutilisation
 la réutilisation de briques logicielles de base appelées
librairies, modules ou plus généralement composants.
En particulier, la mise à disposition de milliers de projets
open source via des plates-formes comme « GitHub » ou
des outils comme « NuGet, Composer ou npm » ont
permis aux équipes de développement de faire des gains de
productivité remarquables en intégrant ces composants lors de
la conception de leurs applications.
 un composant logiciel fait simultanément baisser le temps et
augmenter la qualité du développement.
 Il permet de limiter les efforts nécessaires pour traiter les
problématiques techniques afin de se concentrer sur les
problématiques métier
162
06/01/2021
Séparation des responsabilités (suite)
 Une sous-partie qui s'occupe des affichages à l'écran ne devrait
pas comporter de traitements métier, ni de code en rapport avec
l'accès aux données.
 Un composant de traitements métier (calcul scientifique ou
financier, etc.) ne doit pas s'intéresser ni à l'affichage des données
qu'il manipule, ni à leur stockage.
 Une classe d'accès à une base de données (connexion, exécution
de requêtes) ne devrait faire ni traitements métier, ni affichage des
informations.
161
Réutilisation (suite)
exemples de problématiques techniques adressables par des
composants logiciels :
 Accès à une base de données (connexion, exécution de
requêtes).
 Calculs scientifiques.
 Gestion de l'affichage (moteur 3D).
 Journalisation des évènements dans des fichiers.
163
2

Encapsulation maximale
 Ce principe de conception recommande de n'exposer au
reste de l'application que le strict nécessaire pour que la sous-
partie joue son rôle.
 Au niveau d'une classe, cela consiste à ne donner le niveau
d'accessibilité publique qu'à un nombre minimal de membres, qui
seront le plus souvent des méthodes.
 Au niveau d'une sous-partie d'application composée de
plusieurs classes, cela consiste à rendre certaines classes
privées afin d'interdire leur utilisation par le reste de l'application.
164
Cohésion forte
 Ce principe recommande de placer ensemble des éléments
(composants, classes, méthodes) ayant des rôles similaires ou
dédiés à une même problématique.
Inversement,
 il déconseille de rassembler des éléments ayant des rôles
différents. Exemple : ajouter une méthode de calcul métier
au sein d'un composant lié aux données (ou à la présentation)
est contraire au principe de cohésion forte.
166
06/01/2021
Couplage faible
« une entité (sous-partie, composant, classe, méthode) est couplée
à une autre si elle dépend d'elle »
 un couplage fort tisse entre ses éléments des liens puissants qui
la rend plus rigide à toute modification
 un couplage faible permet une grande souplesse de mise à
jour.
 Le couplage peut également désigner une dépendance envers
une technologie ou un élément extérieur spécifique : un SGBD,
un composant logiciel, etc.
 Le principe de responsabilité unique permet de limiter le
couplage au sein de l'application
165
DRY (Don’t Repeat Yourself)
C’est le faite d’éviter la redondance à travers l'ensemble de l'application.
Cette redondance est en effet l'un des principaux ennemis du
développeur. Elle a les conséquences néfastes suivantes :
 Augmentation du volume de code ;
 Diminution de sa lisibilité ;
 Risque d'apparition de bogues dû à des modifications
incomplètes.
La redondance peut se présenter à plusieurs endroits d'une application,
parfois de manière inévitable (réutilisation d'un existant). Elle prend
souvent la forme d'un ensemble de lignes de code dupliquées à
plusieurs endroits pour répondre au même besoin, comme dans
l'exemple suivant:
167
3
 06/01/2021

DRY (Don’t Repeat Yourself) KISS (KEEP IT SIMPLE, STUPID)

« Ne complique pas les choses »
vise à privilégier autant que possible la simplicité lors de la
construction d'une application.
La complexité peut prendre la forme d'une architecture
surdimensionnée par rapports aux besoins (over engineering),
Une autre manière d'exprimer ce principe consiste à affirmer
qu'une application doit être créée selon l'ordre de priorité
suivant:
 Make it work.
 Make it right.
 Make it fast.

168 169

YAGNI (YOU AIN'TGONNA NEED IT) La structure d’un logiciel

« vous n'en aurez pas besoin »
est un principe d'extreme programming qui déclare que
les programmeurs ne devraient pas ajouter de fonctionnalité
à un logiciel tant que celle-ci n'est pas absolument nécessaire
« mettez toujours en œuvre les choses quand vous en avez
effectivement besoin, pas lorsque vous prévoyez simplement
que vous en aurez besoin »
 l'architecture d'un logiciel décrit sa structure
globale, son squelette. Elle décrit les principales
composantes du logiciel, ainsi que les flux d'échanges
entre ces éléments.
 Elle permet à l'équipe de développement d'avoir une vue
d'ensemble de l'organisation du logiciel, et constitue donc en
elle-même une forme de documentation. On peut décrire la
structure d'un logiciel selon différents points de vue. Entre autres,
 Une vue logique
 Une vue physique

170 171

4
 06/01/2021

Vue d’une architecture Spécification VS Architecture

 La vue logique d’une architecture logicielle définit les
principaux composants d’une architecture sans se soucier  Contrairement aux spécifications produites par l’analyse
des détails physiques (équipements, machines, …etc.) fonctionnelle
 Elle met l'accent sur le rôle et les responsabilités de chaque  le modèle d'architecture ne décrit pas ce que doit réaliser
partie du logiciel. un système informatique mais plutôt comment il doit être
 La vue physique présente les processus, les machines et les conçu de manière à répondre aux spécifications.
liens réseau nécessaires.
 L’analyse fonctionnelle décrit le « quoi faire » alors que
 s’intéresse au déploiement physique des différents
l’architecture décrit le « comment faire »
services
 La vue physique est peu précise lors de la conception. Elle
devient concrète lors de la phase de déploiement.

172 173

Architecture logicielle (c’est quoi?) Architecture logicielle (pourquoi?)

 Consiste à quoi la description d’une architecture logicielle ?
 Pourquoi développer une architecture logicielle ?
 La définition de l’architecture logicielle consiste à:
 Décrire l’organisation générale d’un système et sa  Pour permettre à tous de mieux comprendre le système
décomposition en sous-systèmes ou composants  Pour permettre aux développeurs de travailler sur des
 Déterminer les interfaces entre les sous-systèmes parties individuelles du système en isolation
 Décrire les interactions et le flot de contrôle entre les sous-
systèmes  Pour préparer les extensions du système
 Décrire également les composants utilisés pour implanter les  Pour faciliter la réutilisation et la réutilisabilité
fonctionnalités des sous-systèmes
 Les propriétés de ces composants
 Leur contenu (e.g., classes, autres composants)
 Les machines ou dispositifs matériels sur lesquels ces
modules seront déployés

174 175

5

Architecture logicielle (Utilité)
 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 motivation des choix de conception sont
ainsi mis 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
176
Architecture logicielle VS Conception logicielle
 L'architecture logicielle (software architecture) considère le
logiciel de manière globale. Il s'agit d'une vue de haut niveau qui
définit le logiciel dans ses grandes lignes : que fait-il ? Quelles
sont les sous-parties qui le composent ? Interagissent-elles ? Sous
quelle forme sont stockées ses données ? etc.
 La conception logicielle (software design) intervient à un
niveau de granularité plus fin et permet de préciser comment
fonctionne chaque sous-partie de l'application. Quel logiciel
est utilisé pour stocker les données ? Comment est organisé
le code ? Comment une sous-partie expose-t-elle ses
fonctionnalités au reste du système ? Etc.
178
06/01/2021
Architecture logicielle (Utilité)
 É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épendance entre composants permet d’identifier où les délais
peuvent survenir et leur impact sur la planification générale
177
Place dans le processus de création
 L'activité d'architecture intervient traditionnellement
vers le début d'un projet logiciel, dès que les besoins
auxquels le logiciel doit répondre sont suffisamment
identifiés. Elle est presque toujours suivie par une phase de
conception.
 Les évolutions d'un projet logiciel peuvent nécessiter de
nouvelles phases d'architecture tout au long de sa vie.
C'est le cas avec certaines méthodologies de
développement itératif ou agile, où des phases
d'architecture souvent brèves alternent avec des phases de
production, de test et de livraison.
179
6
 06/01/2021

Architecture logicielle Comment choisir l’architecture ?

 L’architecture implique plusieurs choix dont les L’architecte logiciel doit se poser les questions suivantes :
technologies, les produits et les serveurs à utiliser  Le système est-il interactif ?

 Il n’y a pas une architecture unique permettant de  Nécessite-t-il de fréquent changements ?

réaliser le système, il y en a plusieurs.
 Le système est-il réparti sur le réseau ?

 Le concepteur ou l’architecte choisit la meilleure

 Comment les fonctionnalités sont-elles décomposées entre les
architecture possible selon plusieurs critères dont la composants ?
nature du projet, les compétences de l’équipe, les
budgets et outils disponibles, …etc.  Y a-t-il une architecture générale à utiliser ?

180 181

Comment choisir l’architecture? Architecture logicielle

 Quelles exigences non fonctionnelles sont importantes ?  L’architecture logicielle fournit une description de haut
niveau de la structure d’un système.
 La limitation des performances du matériel.  Elle est définie par des composants, des connecteurs et des
 La haute disponibilité : les composants critiques doivent être configurations.
tolérants aux pannes ou redondants. Connecteur
 La minimisation des risques d'entreprise. Composant Composant
 Sécurité : des fonctionnalités privées doivent être cachés, par
exemple dans des couches internes. Propriétés d’un composant : description du comportement attendu
 Services fournis ou requis
 Performance
 Protocole de communication

182 183

7
 06/01/2021

Représentations des architectures Représentation C&C : Composants et Connecteurs

 Il existe plusieurs représentations graphiques des
architectures. composant
port

connecteur
 Une des représentations les plus utilisées est la
Comp_A Comp_B
interface interface
représentation C&C : Composants et Connecteurs requise fournie
«realisation»
dépendance

 La représentation C&C est un graphe contenant des Classe_C

composants et des connecteurs

 Deux ou plusieurs composants interagissent via un connecteur
 Chaque élément architectural possède une structure et/ou
comportement pouvant être décrit par un modèle UML approprié

184 185

Éléments architecturaux Éléments architecturaux

 Interface de composant
 Permet à un composant d’exposer les moyens à utiliser pour
communiquer avec lui
 Types d’interfaces
 Interface fournie : 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
Composant
compA
 Encapsule un traitement et/ou des données
 Encapsule un sous-ensemble de fonctionnalités et/ou de données
du système
 Restreint l’accès à ce sous-ensemble au moyen d’une interface
définie explicitement
 Possède des dépendances explicitement définies pour exprimer les
contraintes requises par son contexte d’exécution ou sa réalisation

186 187

8
 06/01/2021

Éléments architecturaux PATRONS LOGICIELS

 Dépendances entre composants Un patron de conception (design pattern) aussi appelé «
Dépendance = relation entre deux composants Motif de Conception » est une solution standard à un problème
de conception.
 Types de dépendances Au fil du temps et des projets, plusieurs architectures-types se
 Un composant peut dépendre d’un autre composant qui lui sont dégagées. Elles constituent des patrons
fournit un service ou une information d'architecture (architecture patterns) qui ont fait leurs
 Un composant peut dépendre d’une classe qui implémente preuves et peuvent servir d'inspiration pour un nouveau
une partie de son comportement. Dépendance de projet.
réalisation Cette partie du cours présente les patrons logiciels (software
 Un composant peut dépendre d’un artefact (code source, patterns), qui sont des modèles de solutions à des
fichier .jar, etc.) qui l’implante concrètement. Dépendance problématiques fréquentes d'architecture ou de
de manifestation conception.

188 189

PATRONS LOGICIELS Exemple de JSP

 Les architectures utilisent des composants standards : JDBC
serveurs, bases de données, application, clients, …etc. Serveur web SGBD MySQL
 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)
Navigateur

 Par exemple, le service http répond aux requêtes des clients JSP: JavaServer Pages
JDBC: Java DataBase Connectivity)
qui sont les navigateurs web HTTP: HyperText Transfer Protocol

190 191

9
 06/01/2021

Architecture client/serveur Architecture client/serveur

L'architecture client/serveur caractérise un système basé sur
des échanges réseau entre des clients et un serveur centralisé,  Avantages:
lieu de stockage des données de l'application.  Données centralisées.
 Données faciles à sauvegarder et à sécuriser.
 Serveur peut être dimensionné pour pouvoir héberger le volume
de données nécessaire.

 Inconvénients
 Le serveur constitue le nœud central du système et représente son
maillon faible

192 193

Architecture client/serveur Services déployés dans le même serveur

On peut classer les clients d'une architecture client/serveur en
plusieurs types : Serveur 1

 Client léger : destiné uniquement à l'affichage (exemple :

navigateur web) ;
Serveur web SGBD MySQL
 Client lourd : application native spécialement conçue pour JDBC

communiquer avec le serveur (exemple : application mobile) ;

 Client riche : combinant les avantages des clients légers et
lourds (exemple : navigateur web utilisant des technologies
évoluées pour offrir une expérience utilisateur proche de celle
d'une application native) ;
Navigateur

194 195

10
 06/01/2021

Services déployés dans des serveurs différents Architecture en couches

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

Serveur web SGBD MySQL

JDBC

Navigateur

196 197

Architecture en couches Architecture orientée services

Cette architecture respecte le principe de séparation des Une architecture orientée services (SOA : Service-Oriented
responsabilités et facilite la compréhension des échanges au Architecture) décompose un logiciel sous la forme d'un
sein de l'application. Lorsque chaque couche correspond à un ensemble de services métier utilisant un format d'échange
processus distinct sur une machine, on parle d'architecture commun, généralement XML ou JSON.
« n-tiers », n désignant le nombre de couches.
Un navigateur web accédant à des pages dynamiques intégrant
des informations stockées dans une base de données constitue un
exemple classique d'architecture 3-tiers.

198 199

11