2/3/2023

Architecture logicielle
Rihab JMAL
D-PIIM
2022-2023
1

Objectifs:

• Comprendre les architectures logicielles ainsi que leurs composants.

• Comprendre l’évolution des architectures.
• Connaître les différents types d’architectures et principaux concepts.
• Analyser des outils de mise en œuvre d’ architectures logicielles

1
 2/3/2023

Plan:
1• Introduction aux architectures logicielles

2 Évolution des architectures logicielles

3 Architectures 2-tiers
4 Architectures 3-tiers
5 Architectures n-tiers

I. Introduction aux architectures

logicielles

2
 2/3/2023

1. Définitions
• Logiciel :
C’est un ensemble de séquences d’instructions interprétables par une
machine et d’un jeu de données nécessaires à ces opérations.

Processus et outils

Besoin
Produit logiciel
5

1. Définitions
• Étapes de réalisation d’un logiciel :

Conception architecturale proposer une architecture logicielle.

6

3
 2/3/2023

1. Définitions
• L’architecture logicielle = abstraction d’un logiciel
• Une architecture logicielle : la structure d’un système,
comprenant:
 les composantes logicielles,
 les propriétés exposées de ces composantes, et
 les interactions entre celles-ci.

1. Définitions
• Structurer un logiciel en termes de composants consiste à :
 définir les fonctionnalités associées aux composants
 définir les interfaces entre les composants
 déterminer les dépendances entre les composants
 décomposer les composants en sous-composants

Relation entre deux composants Décomposition d’un composant en 3

sous-composants 8

4
 2/3/2023

• Pourquoi développer une architecture logicielle ?

• Pour faciliter 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 evidence.
• Pour faciliter la réutilisabilité: favorise l’identification des éléments réutilisables,
parties de conception, composants, caractéristiques, fonctions ou données
communes.
• Pour faciliter le co-développement dans une équipe en permettant aux
développeurs de travailler sur des parties séparées du système (modulaire) en
fournissant un plan de haut-niveau du développement et de l’intégration des
modules qui met en évidence les composants, les interactions et les dépendances.

• Pourquoi développer une architecture logicielle ?

• Pour préparer les extensions du système en favorisant son é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 »

• Pour améliorer l’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.

• Pour contribuer à 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

10

5
 2/3/2023

• Qui est responsable de l’architecture logicielle ?

• L’architecte logiciel : c’est la personne qui propose des solutions qui

sont mises en œuvre par l’équipe de conception et de développement.
Il a pour rôle de:
 Recenser les besoins techniques (analyse de l’existant,
contraintes, besoins exprimés)
 Définir les principes directeurs de l’architecture
 Elaborer l’architecture applicative, logicielle et physique
 Argumenter ses choix technologiques
 Identifier les besoins en produits tiers et frameworks
techniques. 11

Une démarche en 4 étapes

De manière itérative et incrémentale l’architecte va dans la phase d’architecture
logicielle:
1. Définir le modèle d’architecture en couches et en tiers à mettre en œuvre pour
chacun des blocs applicatifs
2. Préconiser des motifs de conception à mettre en œuvre pour les couches
3. Préconiser les librairies, composants, Frameworks et outils à utiliser pour :
• L’implémentation des couches logicielles (présentation/coordination/services/ domaine /
persistance, gestion de logs, ...)

• La fabrication de l’application (conception, développement, tests unitaires, intégration,

packaging)
• La mise en production et le suivi (déploiement, configuration, surveillance, suivi de la qualité
de service, suivi des erreurs)

4. Guider les phases de conception et de développement en s’assurant que les

concepteurs et les développeurs ont bien compris l’architecture 12

6
 2/3/2023

Structuration des applications

 L’architecte structure le système selon plusieurs « vues » :
 Vue en couches (layer view) : vue « logique » montrant le découpage des fonctions
de l’application
• Chaque couche a ses propres responsabilités et utilise la couche située en dessous d’elle
• En fonction du projet, les architectes enrichissent et élaguent le modèle.
• La structuration est alors guidée par les contraintes exprimées et existantes: exemple:
Modèle OSI, modèle: Présentation Contrôleur Services Domaine Persistance
 Vue en niveaux (tier view) : vue « physique » de la structuration de l’application (n-
tiers)

13

Structuration des applications (suite)

La structuration des applications se traduit par une
décomposition logique de chaque application en 5 couches :

 Présentation
 Contrôleur
 Services
 Domaine
 Persistance

14

7
 2/3/2023

La couche Présentation
• La couche Présentation gère et assure l'affichage de l'interface graphique
utilisateur ou les Interfaces Homme-Machine (IHM : fenêtres, pages,
composants graphiques...)
• Cette couche intègre principalement :
 la gestion du domaine visuel
 l'interaction avec les utilisateurs
 l'interception des évènements utilisateurs et l'appel a la couche Contrôleur
 la gestion du multicanal (web, voix, mobile, fax)
 les services de portail (agrégation d’IHM, bouquets de services)
 les services d’impression (impressions PDF, gestion de templates...

15

La couche Contrôleur
• La couche Contrôleur gère:
 le contrôle de la cinématique des écrans
 l’invocation des appels de services
 les erreurs et les exceptions qui peuvent être levées
 les sessions / espace de travail utilisateur
 les habilitations et les droits d’accès

• Dans certains Framework, la couche Contrôleur peut prendre en

compte la langue et le type de terminal de l’utilisateur

16

8
 2/3/2023

La couche Services
• La couche Services correspond aux traitements qu’effectue l’application. Elle
représente l’implémentation de la logique des cas d’utilisation (use-case
fonctionnels).
• Cette couche doit :
 implémenter la logique métier
 gérer la sécurité applicative
 gérer les transactions étendues (processus, compensation)
 gérer l’intégrité́ transactionnelle (transactions locales et distribuées)
 gérer les appels aux objets métiers de la couche Domaine

17

La couche Domaine
La couche Domaine gère l'integrité du modèle ≪ métiers ≫. Cette couche intègre
principalement:
• la gestion des règles métiers ≪ élémentaires ≫ (sans état, sans processus)
• la fourniture des moyens d'accès a l'information (SGBDR, Mainframe...)
• le respect des propriétés transactionnelles de la couche persistance
• La couche Domaine recense les objets métiers manipulées par l’application
• La couche Domaine est concentrée sur le métier de l’entreprise, commun à toutes
les applications

18

9
 2/3/2023

La couche Persistance
La couche Persistance intègre principalement :
• La persistance complète du Système d'Informations (données structurées ou
non structurées, gérées entre autres via un SGBDR, ...)
• La fourniture des services de stockage des données, moteurs relationnels,
bases objets, bases XML...
• La création, la modification, la suppression d'occurrences des objets métiers
• Elle contient un niveau d’abstraction de données les DAO (Data Access
Object) qui prennent en charge l'accès à la source de données (SGBDR,
fichiers XML, CICS, ...). Ils offrent une vision objet des occurrences d’entités
du modèle physique de données

19

Framework de développement
• La mise en œuvre d’un framework de développement est un élément
fondamental pour la réussite du projet.
• Un framework (cadre de travail) correspond a un ensemble d’outils du
marche, de bibliothèques, de spécifiques et de méthodologies qui visent a
faciliter, cadrer et accélérer les développements du projet.
• Le framework de développement, élaboré en phase d’étude et consolide en
phase d’implémentation, est fondamental a la bonne réussite du projet :
 il définit le cadre de travail et les engagements de chacune des parties,
fonctionnelles et techniques, en spécifiant le processus de développement
 il permet de mieux écorréler les aspects techniques de l’implémentation des
fonctionnalités
 il contraint et standardise les développements
 il diminue les risques lies au projet

20

10
 2/3/2023

2. Critères de qualité logicielle

• L'interopérabilité intrinsèque exprime le degré de cohérence entre le
fonctionnement des commandes et des modules à l'intérieur d'un système ou d'un
logiciel.
• La portabilité exprime la possibilité de compiler le code source et/ou d'exécuter le
logiciel sur des plates-formes (machines, systèmes d'exploitation, environnements)
différentes.
• La compatibilité exprime la possibilité, pour un logiciel, de fonctionner correctement
dans un environnement ancien (compatibilité descendante) ou plus récent (compatibilité
ascendante).
• La validité exprime la conformité des fonctionnalités du logiciel avec celles décrites
dans le cahier des charges.
• La vérifiabilité exprime la simplicité de vérification de la validité.
21

2. Critères de qualité logicielle

• L'intégrité exprime la faculté du logiciel à protéger ses fonctions et ses données d'accès
non autorisés.
• La fiabilité exprime la faculté du logiciel à gérer correctement ses propres erreurs de
fonctionnement en cours d'exécution.
• La maintenabilité exprime la simplicité de correction et de modification du logiciel, et
même, parfois, la possibilité de modification du logiciel en cours d'exécution.
• La réutilisabilité exprime la capacité de concevoir le logiciel avec des composants déjà
conçus tout en permettant la réutilisation simple de ses propres composants pour le
développement d'autres logiciels.
• L'extensibilité exprime la possibilité d'étendre simplement les fonctionnalités d'un
logiciel sans compromettre son intégrité et sa fiabilité.

22

11
 2/3/2023

2. Critères de qualité logicielle

• L'efficacité exprime la capacité du logiciel à exploiter au mieux les ressources offertes
par la ou les machines où le logiciel sera implanté.
• L'autonomie exprime la capacité de contrôle de son exécution, de ses données et de ses
communications.
• La transparence exprime la capacité pour un logiciel de masquer à l'utilisateur
(humain ou machine) les détails inutiles à l'utilisation de ses fonctionnalités.
• La composabilité exprime la capacité pour un logiciel de combiner des informations
provenant de sources différentes.
• La convivialité décrit la facilité d'apprentissage et d'utilisation du logiciel par les
usagers.

23

3. Conception UML d’une

architecture logicielle
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 => organisation des modèles et des composants

• 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 => Composant et artefacts : modules et fichiers d’une

application

• 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

24

12
 2/3/2023

Rappel : vues d’un programme

25

Diagramme de paquetages

 Le diagramme de paquetages est un diagramme structurel utilisé

pour représenter l'organisation et la disposition de divers
éléments modélisés sous forme de paquetages.
 Les éléments du paquetage peuvent être représentés :
 À l’extérieur
 À l’intérieur
 Dépendance entre paquetages

 De type « Import » indique que la fonctionnalité a été importée d'un paquetage à un

autre
 De type « Access » indique qu'un paquetage nécessite le soutien d'un autre
paquetage.
26

13
 2/3/2023

Avantages d'un diagramme de

paquetages
 Un diagramme de package bien conçu offre de nombreux avantages aux personnes
souhaitant créer une représentation graphique de leur système ou projet UML.
 Ils fournissent une perspective précise de la structure hiérarchique des différents
éléments UML au sein d'un système donné.
 Ces diagrammes permettent de simplifier les diagrammes de classes complexes
sous une forme visuelle bien ordonnée.
 Ils offrent une vue d'ensemble précieuse pour les projets et systèmes de grande
ampleur.
 Les diagrammes de paquetages peuvent être utilisés pour clarifier visuellement de
nombreux types de projets et systèmes. 27

Diagramme de déploiement
• Les diagrammes de déploiement montrent la disposition physique des matériels
qui composent le système et la répartition des composants sur ces matériels.
• Les ressources matérielles sont représentées sous forme de nœuds qui sont connectés
entre eux, à l'aide d'un support de communication.
• La nature des lignes de communication et leurs caractéristiques peuvent être
précisées.
• L'implantation des modules principaux sur les nœuds du réseau.
• Les exigences en terme de performances: Temps de réponse, tolérance aux fautes et
pannes...

28

14
 2/3/2023

Exemple de diagramme de
déploiement

29

Diagramme de composants

• Offre une vue de haut niveau de l’architecture du système.

• Utilisé pour décrire le système du point de vue implémentation.
• Permet de décrire les composants d’un système et les interactions entre eux.
• Illustre comment grouper concrètement et physiquement les éléments (objets,
interfaces) du système au sein de modules qu’on appelle composants.

30

15
 2/3/2023

Éléments architecturaux

 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é
31

Éléments architecturaux
Composant

• 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

32

16
 2/3/2023

Éléments architecturaux
Composant

• Unité autonome servant de bloc de construction pour le système

• Les composants implémentent typiquement des services spécifiques à
l’application
• La manifestation concrète d’un composant est appelé artéfacte (instance du
composant déployée sur le matériel)
• N’importe quel type de code sur n’importe quel support numérique
• Code source, fichiers binaires, scripts, fichiers exécutables, bases de données,
applications, etc.

33

Éléments architecturaux
 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

34

17
 2/3/2023

Éléments architecturaux
 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
35

Éléments architecturaux
 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 connection 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 comportementales; E.g. sa
capacité, le temps de latence, le type d’interaction (binaire/naire,
asymétrique/symétrique, détails du protocole), etc.
36

18
 2/3/2023

Éléments architecturaux
 Connecteur :

 Un connecteur peut avoir un ou plusieurs rôles

 Communication :rôle le plus fréquent
 Coordination : contrôle du calcul, de la transmission des données, etc. Orthogonal aux
autres rôles
 Conversion : permet l’interaction entre composants développés indépendamment dans
des langages différents par exemple
 Facilitation : permet l’interaction entre composants conçus pour intéragir ensemble.
Synchronisation, accès contrôlés aux données partagées, etc.
 Selon le(s) rôles qu’il doit remplir et le type de communication souhaitée entre deux
composants:
 Procedure call (comm + coord) , Data access (comm + conv), Event, Stream, Linkage,
Distributor, Arbitrator, Adaptor (conv)
37

Exemple de diagramme de
composants: gestion de magasin

38

19
 2/3/2023

Exercice1

• Le composant image.java dépend de l'interface

ImageObserver du composant component.java.

Représentez le diagramme de composants.

39

Exercice 2
• Une architecture matérielle est constituée d'un serveur, d'un kiosques et d'une console.
Le serveur utilise une tour de disques durs montés en RAID. la kiosque communique
avec le serveur par une liaison Ethernet 100b et la console par une liaison RS232C.
• Les caractéristiques du serveur sont:
 Processeur Pentium
 Mémoire vive : 4 Go
 Ecran 17 pouces

• Question : Représentez le diagramme de déploiement correspondant.

• On peut aussi préciser les modules exécutables sur chaque nœud,
 sur le kiosque : user.exe
 sur le serveur : dbadmin.exe et tkmstr.exe
 sur la console : admin.exe et cong.exe
• Question : Représentez le diagramme correspondant.
40

20