Architecture Logicielle

et Design Patterns
Introduction

I. Mouakher
PRÉSENTATION DU COURS

2
Objectifs du cours
 Présenter les styles et les patrons
d’architecture et de conception logicielle
en mettant l’emphase sur les systèmes
distribués

3
Evaluation du cours
 Charge totale : 31.5
 Evaluation du cours
 Examen 60%
 Devoir 30%
 Note présentielle 10%

4
Plan du cours
 Introduction
 Concepts de base
 Patron de conception Gof
 Creational patterns
 Structural patterns
 Behavioral patterns

 Styles et Patrons d’Architectures Distribuées

 Refactoring, refactoring to patterns

5
CONCEPTS DE BASES

6
L’architecture et la conception
dans le domaine immobilier

7
L’architecture et la conception
dans le domaine immobilier

8
QU’EST-CE QUE L’ARCHITECTURE?
QU’EST-CE QUE LA CONCEPTION?

9
Architecture logicielle
(ANSI/IEEE Std 1471-2000)
 L’architecture d’un système logiciel est
définie comme l’organisation
fondamentale du système, qui s’incarne
dans ses composantes, leurs relations
entre elles et avec leur environnement, et
les principes qui guident sa conception et
son évolution.

10
Architecture logicielle (définition
SEI)
 L’architecture d’un système logiciel est
l’ensemble des structures nécessaires
pour raisonner à propos du système, qui
comprennent les éléments logiciels, les
relations entre eux et les propriétés des
chaque.

11
Architecture logicielle (définition
Sangwan, 2015)
 L’architecture d’un système logiciel se
préoccupe fondamentalement de
l’organisation d’un système en ses
constituants et leurs interrelations afin de
réaliser un objectif donné.

12
Architecture
 Elle répond à « quoi? ».
 Au niveau modèle
 Paquetages, composantes et relations
 Niveau de décision plus abstrait.
 Les décisions qui doivent être prises en avance.
 Les décisions qui sont très couteuses à changer pendant le
développement.
 Pertinente pour les objectifs opérationnels et les exigences
nonfonctionnelles.
 Elle inclut:
 Modules
 Bases/technologies de données
 Environnement d’exécution et de déploiement
13
Conception
 Elle répond à « comment? ».
 Comment on va implémenter l’architecture.
 Éléments plus concrets:
 Classes
 Méthodes/Fonctions
 Tables de données
 Pertinent pour les exigences fonctionnelles.
 Éléments qui peuvent être changés pendant le
développement (la phase de maintenance)
 Réingénierie (refactoring)
 Évolution
 Adaptation 14
Exercice
 On vous présente des exemples d’énoncé
que vous pouvez rencontrer durant les
premières phases de cycles de
développement de logiciel. Pour chacun
d’entre eux on vous demande d’identifier
si l’énoncé est pertinent à l’architecture ou
à la conception

15
Énoncé 1
 On veut une couche de GUI, une couche
d’analyse et une couche de stockage des
données

16
Énoncé 1
 On veut une couche de GUI, une couche
d’analyse et une couche de stockage des
données
 Architecture
L’énoncé réfère aux modules de haut niveau,
tels que les couches.

17
Énoncé 2
 Toutes les nouvelles applications doivent
étendre l’interface Application.

18
Énoncé 2
 Toutes les nouvelles applications doivent
étendre l’interface Application.
 Conception
L’énoncé réfère à un détail d’implémentation. Il
requiert des modifications au niveau de la
classe.

19
Énoncé 3
 L’application sera disponible comme un
service déployé en infonuagique.

20
Énoncé 3
 L’application sera disponible comme un
service déployé en infonuagique.
 Architecture
L’énoncé réfère à l’environnement
d’exécution/déploiement de l’application.

21
Énoncé 4
 On a besoin d’une base de données
NoSQL avec un taux de disponibilité
élevé.

22
Énoncé 4
 On a besoin d’une base de données
NoSQL avec un taux de disponibilité
élevé.
 Architecture
L’énoncé réfère à une couche/niveau spécifique
de l’application. Il mentionne aussi une
exigence non-fonctionnelle. NoSQL est une
technologie spécifique, mais pas une
implémentation particulière.
23
Énoncé 5
 Une méthode prend le type d’un objet
comme paramètre et retourne une
instance de ce type en appelant le
constructeur privé de la classe
correspondante.

24
Énoncé 5
 Une méthode prend le type d’un objet
comme paramètre et retourne une
instance de ce type en appelant le
constructeur privé de la classe
correspondante.
 Conception
L’énoncé réfère à un détail d’implémentation. Il
requiert des modifications au niveau de la
classe. Il mentionne aussi un patron de
conception (Singleton). 25
PATTERNS

26
Réutilisation en informatique
 Réutilisation de code métier
 Sous la forme de bibliothèques / composants
 À acheter / fabriquer

 Réutilisation de code générique

 Sous la forme de frameworks
 À utiliser en les spécialisant

 Réutilisation de principes de conception

 Dès que des principes se révèlent pertinents
 Abstraction Design patterns
 Réutilisation 27
Catégories de Patterns
 Architectural Patterns
 schémas d’organisation structurelle de logiciels (pipes, filters, brokers,
blackboard, MVC, …)
 Design Patterns
 caractéristiques clés d’une structure de conception commune à plusieurs
applications,
 Portée plus limitée que les « architectural patterns »

 Idioms ou coding patterns

 solution liée à un langage particulier
 Anti-patterns
 mauvaise solution ou comment sortir d ’une mauvaise solution

28
Patron d'architecture
 Un patron d'architecture est la meilleure solution
connue à un problème d'architecture récurrent. Il
apporte des solutions sur la manière de
concevoir l'organisation à grande échelle
(architecture) d'un logiciel en faisant abstraction
des détails. Il concerne la structure générale
d'un logiciel, sa subdivision en unités plus
petites, comporte des guides de bonnes
pratiques et des règles générales qui ne
peuvent pas être traduites directement en code
source5. 29
Patron de conception
 Un patron de conception est la meilleure
solution connue à un problème de conception
récurrent.
 Le patron de conception suggère un
arrangement, une manière d'organiser des
modules ou des classes. Il décrit une
organisation de classes fréquemment utilisée
pour résoudre un problème récurrent. Le patron
de conception parle d'instances, de rôles et de
collaboration.
30
Idiotisme de programmation
 L'idiotisme de programmation est une construction
spécifique à un langage de programmation, qui est une
manière usuelle de mettre en œuvre une solution à un
problème dans ce langage de programmation. Par
exemple pour effectuer cent fois une opération, un
programmeur en langage C utilise les instructions for (i =
0; i < 100; i++) pour sa ligne de code. L'utilisation d'un
idiotisme par le programmeur lui évite d'avoir à remettre
en question la structure détaillée du programme et
améliore la qualité du produit5.

31
Patrons architecturaux vs patrons
de conception
 Patrons architecturaux : Structuration globale en paquetages;
Couches, MVC, Client-serveur, Multi-tiers, ...
 Patrons de conception : Structuration détaillée en classes
 Attributs et opérations des classes : qui doit savoir, qui doit faire ?
 Relations entre classes : délégation, héritage, réalisation, ... ?

32