LOG4430 :

Architecture logicielle et
conception avancée
Abdou Maiga
Revision

Département de génie informatique et de génie logiciel

École Polytechnique de Montréal © Guéhéneuc, 2009; Khomh, 2010; Maiga, 2010
 Conception architecturale
1. Introduction
2. Modéliser l’architecture avec UML
3. Éléments architecturaux
4. Styles architecturaux
1. Architecture pipeline
2. Architecture avec référentiel de données
3. Architecture MVC
4. Architecture multi-couches
5. Architecture n-niveaux
5. Développer un modèle architectural
 1. Architecture logicielle
Qu’est-ce qu’une architecture logicielle ?
L’architecture d’un logiciel est la structure des structures
(modules) d’un système
Elle inclut
• Les composants logiciels
• Les propriétés externes visibles de ces composants
• Les relations entre ces composants
Cf. [Bass, Clements, and Kazman (1998) ]
Contrairement aux spécifications produites par
l’analyse fonctionnelle
ne décrit pas ce que doit réaliser un système mais comment il
doit être conçu pour à répondre aux spécifications.
L’analyse fonctionnelle décrit le « quoi faire » alors que
l’architecture décrit le « comment le faire »
 Introduction
Qu’est que la description d’une architecture logicielle ?
La définition de l’architecture logicielle consiste à:
• Décrire l’organisation générale d’un système et sa
décomposition en sous-systèmes ou composants
• Déterminer les interfaces entre les sous-systèmes
• Décrire les interactions et le flot de contrôle entre les sous-
systèmes
• Décrire également les composants utilisés pour implanter les
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
 Introduction
Pourquoi développer une architecture logicielle ?
Pour permettre à tous de mieux comprendre le système
Pour permettre aux développeurs de travailler sur des parties
individuelles du système en isolation
Pour préparer les extensions du système
Pour faciliter la réutilisation et la réutilisabilité
 Introduction
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
 Introduction
Utilité d’une architecture logicielle [Garlan 2000]
É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
du casse-tête 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
 2. Modéliser avec UML (1/5)
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
Vue d’implémentation. Description de l’implémentation
(physique) du système logiciel en termes de composants et de
connecteurs
• UML : diagramme de composants
Vue de déploiement. Description de l’intégration et de la
distribution de la partie logicielle sur la partie matérielle
• UML: diagramme combiné de composants et de déploiement
 3. Éléments architecturaux (8/10)
Exemple d’un diagramme de composants
 3. Éléments architecturaux (10/10)
Choix d’une architecture
Dépend des exigences fonctionnelles et non fonctionnelles du
logiciel
Choix favorisant la stabilité : l’ajout de nouveaux éléments
sera facile et ne nécessitera en général que des ajustements
mineurs à l’architecture
Influencé par certains « modèles connus » de décomposition
en composants (styles architecturaux) et de mode
d’interactions (e.g., orienté objet)
 4. Style architecturaux
Un style architectural
Est un patron décrivant une architecture logicielle permettant
de résoudre un problème particulier
Définit
• Un ensemble de composants et de connecteurs (et leur type)
• Les règles de configuration des composants et connecteurs
(topologie)
• Une spécification du comportement du patron
• Des exemples de systèmes construits selon ce patron
Constitue un modèle éprouvé et enrichi par l’expérience de
plusieurs développeurs
• Compréhensibilité, maintenance, évolution, réutilisation,
performance, documentation, etc.
 Architecture pipeline
Convient bien aux systèmes de traitement et de transformation de données
Composants = filtre ; Connecteur = canal
Filtre
• Traite indépendamment et asynchrone
• Reçoit ses données d’un ou plusieurs canaux d’entrée, effectue la
transformation/traitement des données et envoie les données de sortie produites sur un
ou plusieurs canaux de sorties
• Fonctionnent en concurrence. Chacun traite les données au fur et mesure qu’il les reçoit
Canal
• Unidirectionnel au travers duquel circulent un flot de données (stream).
• Synchronisation et utilisation d’un tampon parfois nécessaire pour assurer la bon
fonctionnement entre filtre producteur et filtre consommateur
Exemples : application de traitement de texte, de traitement de signaux. Compilateur
(analyse lexicale, syntaxique, sémantique)

Filtre

canal de synchro
communication
 Architecture pipeline
Système de traitement du son
Encodeur pour
sortie de microphone

Égaliser les
Filtrer Filtrer Retirer les
les intervalles
l’écho le bruit fréquences non vocales
dynamiques

Encodeur de
bruit ambiant

Décompresser Recevoir Transmettre Compresser

Encoder la sortie
des haut-parleurs
 Architecture pipeline
Avantages
Bon pour traitement en lot (batch)
Très flexible
Analyse facilitée : performance,
synchronisation, goulot
d’étranglement, etc.
Se prête bien à la décomposition
fonctionnelle d’un système
Inconvénients
Mauvais pour le traitement interactif
D’un point de vue conception
Diviser pour régner : les filtres
peuvent être conçus séparément
Cohésion : les filtres sont un type de
cohésion fonctionnelle
Couplage : les filtres n’ont qu’une
entrée et une sortie en général
Abstraction : les filtres cachent
généralement bien leurs détails
internes
Réutilisabilité : les filtres peuvent
très souvent être réutilisés dans
d’autres contextes
Réutilisation : il est souvent possible
d’utiliser des filtres déjà existants
pour les insérer dans le pipeline
 Architecture avec référentiel
Architecture avec référentiel de données (shared data)
Utilisée dans le cas où des données sont partagées et
fréquemment échangées entre les composants
Deux types de composants : référentiel de données et accesseur de
données
• Les référentiels constituent le medium de communication entre les
accesseurs
Connecteur : relie un accesseur à un référentiel
• Rôle de communication, mais aussi possiblement de coordination, de
conversion et de facilitation

Référentiel1 Référentiel2

A A A A A
 Architecture avec référentiel
Variantes
Style tableau noir : les référentiels sont des agents actifs.
Lorsqu’ils reçoivent une données, ils informent tous les
accesseurs concernés
Style référentiel : les référentiels sont passifs. Simple
vocation de stockage. Les composants accède aux référentiels
comme ils le désirent
Exemples : application de bases de données, systèmes Web,
systèmes centrés sur les données (e.g. système bancaire,
système de facturation ,etc.), environnement de
programmation
 Architecture avec référentiel
Avantages
Avantageux pour les applications impliquant des tâches
complexes sur les données, nombreuses et changeant souvent.
Une fois le référentiel bien défini, de nouveaux services
peuvent facilement être ajoutés
Inconvénients
Le référentiel peut facilement constituer un goulot
d’étranglement, tant du point de vue de sa performance que
du changement
 Architecture Modèle-Vue-Contrôleur (MVC)
Séparer la couche interface utilisateur des autres parties du
système (car les interfaces utilisateurs sont beaucoup plus
susceptibles de changer que la base de connaissances du
système)
Composé de trois types de composants
Modèle : rassemble des données du domaine, des connaissances du
système. Contient les classes dont les instances doivent être vues et
manipulées
Vue : utilisé pour présenter/afficher les données du modèle dans
l’interface utilisateur
Contrôleur : contient les fonctionnalités nécessaires pour gérer et contrôler
les interactions de l’utilisateur avec la vue et le modèle
 Architecture Modèle-Vue-Contrôleur ()

E.g. Génère le E.g. Interprète les

Vus par code html pour le transmissions http
les acteurs browser « post » du
browser Reçoit les
événements
créer et
View des acteurs
mettre à jour

Consulter l’état
(i.e. les données) notifier changements Contrôleur

Modèle modifier

Le sous-système
gérant l’information.
 Architecture Modèle-Vue-Contrôleur
Modèle : noyau de l’application
Enregistre les vues et les contrôleurs qui en dépendent
Notifie les composants dépendants des modifications aux données
Vue : interface (graphique) de l’application
Crée et initialise ses contrôleurs
Affiche les informations destinées aux utilisateurs
Implante les procédure de mise à jour nécessaires pour demeurer cohérente
Consulte les données du modèle
Contrôleur : partie de l’application qui prend les décisions
Accepte les événement correspondant aux entrées de l’utilisateur
Traduit un événements (1) en demande de service adressée au modèle ou bien (2)
en demande d’affichage adressée à la vue
Implémente les procédures indirectes de mise à jour des vues si nécessaire
 Architecture Modèle-Vue-Contrôleur ()
Avantages :
D’un point de vue conception
approprié pour les systèmes
interactifs, particulièrement ceux
impliquant plusieurs vues du même
modèle de données.
Peut être utilisé pour faciliter la
maintenance de la cohérence entre
les données distribuées
Inconvénient :
goulot d’étranglement
possible
Diviser pour régner : les composants
peuvent être conçus
indépendamment
Cohésion : meilleure cohésion que si
les couches vue et contrôle étaient
dans l’interface utilisateur.
Couplage : le nombre de canaux de
communication entre les 3
composants est minimal
Réutilisabilité : la vue et le contrôle
peuvent être conçus à partir de
composants déjà existants
Flexibilité : il est facile de changer
l’interface utilisateur
Testabilité : il est possible de tester
l’application indépendamment de
l’interface
 Architecture multi-couches
Composants : chaque composant réalise un service
Une couche offre un service (serveur) aux couches externes (client)
Service créé indépendamment du logiciel ou spécifiquement
Met à profit la notion d’abstraction, les couches externes sont plus
abstraites (haut niveau) que les couches internes
Connecteurs : dépendent du protocole d’interaction souhaité
entre couches
Système fermé : une couche n’a accès qu’aux couches adjacentes. Les
connecteurs ne relient que les couches adjacentes
Système ouvert : toutes les couches ont accès à toutes les autres. Les
connecteurs peuvent relier deux couches quelconques
Exemples : souvent utilisé pour les systèmes implémentant des
protocoles de communication (TCP/IP)
 Architecture multi-couches
Système fermé
Reference Model of Open Systems Interconnection (OSI
model)
Application
Transformation des données
Présentation (encryption,etc.)

Identifier et authentifier
Session une connexion
Transmission (point à point)
Transport fiable des données

Transmission des
Réseau
routing packets

Transmission des Ligne de données

data frames sans erreurs

Interface matérielle Physique

du réseau
 Architecture multi-couches
D’un point de vue conception
Diviser pour régner : les couches
peuvent être conçues séparément
Cohésion : si elles sont bien
conçues, les couches présenter une
cohésion par couche
Couplage : des couches inférieures
bien conçues ne devraient rien
savoir à propos des couches
supérieures et les seules connexions
autorisées entre couches se font via
les API
Abstraction : on n’a pas à connaître
les détails d’implémentation des
couches inférieures
Réutilisabilité : les couches
inférieures peuvent être conçues de
façon à offrir des solutions
génériques réutilisables
Réutilisation : on peut souvent
réutiliser des couches développées
par d’autres et qui proposent le
service requis
Flexibilité : il est facile d’ajouter de
nouveaux services construits sur les
services de plus bas niveau
Anticipation du changement : en
isolant les composants dans des
couches distinctes, le système
devient résistant
Portabilité : tous les services relatifs
à la portabilité peuvent être isolés
Testabilité : les couches peuvent
être testées indépendamment
Conception défensive : les API des
couches constituent des endroits
stratégiques pour insérer des
assertions de vérification
 Architecture n-niveaux
Pour les systèmes distribués
Comparable à une architecture par couches… dont les couches seraient
distribuées !
• N.b. L’architecture multi-couche est généralement utilisée pour décrire
la structure interne (non distribuée) d’un composant qui peut lui-
même appartenir à une architecture (distribuée) n-partie
Par abus de langage, la notion de tier a pris le sens de couche distribuée
Composants : chaque niveaux est représenté par un composant qui joue le
rôle de client et/ou de serveur
Connecteurs : relient un client à un serveur. Connexion asymétrique. Doit
supporter les communication distantes (e.g., requêtes RPC, HTTP,
TCP/IP)
Exemples
• Client-serveur, Trois niveaux, Quatre niveaux
 Architecture n-niveaux

Architecture 2-niveaux (client-serveur ou client lourd)

Client Serveur
requête de service

Architecture 3-niveaux (client léger)

Navigateur Logique Serveurs

Web applicative de
requête requête base de données
de service de service
de B.D.
Architecture 4-niveaux
Logique
Présentation Applicative Bases de
Client
(partie web) (calculs, données
business)
 Architecture n-niveaux
Architecture client-serveur
Exemple typique : un système d’informations utilisant une
base de données centrale. (cas spécial de l’architecture avec
référentiel)
• Clients : reçoivent les données de l’utilisateur, initient les
transactions, etc.
• Serveur : exécute les transactions, assure l’intégrité des
données
Architecture pair-à-pair = une généralisation de l’architecture
client-serveur
• Les composants peuvent tous à la fois être client et serveur
• Conception plus difficile: flot de contrôle plus complexe dû à la
possibilité de deadlocks…
 Architecture n-niveaux
Architecture client-serveur
<<communication>>
Client2 <<communication>>
chercher adresse
Échanger msg

Serveur
Client1
<<communication>>
Échanger msg
<<communication>> <<communication>>
Échanger msg chercher adresse
Client3

netscape:WebBrowser diro:WebServer

iexplo:WebBrowser

www.cmu.edu:WebServer
lynx:WebBrowser
 Architecture n-niveaux
Architecture 3-niveaux
Organisation en trois couches
• Couche interface: Composé d’objets interfaces (boundary
objects) pour interagir avec l’utilisateur (fenêtres, formulaires,
pages Web, etc.)
• Couche logique applicative : Comporte tous les objets de
contrôle et d’entités nécessaire pour faire les traitements, la
vérification des règles et les notifications requises par
l’application
• Couche de stockage : réalise le stockage, la récupération et la
recherche des objets persistants
Avantage sur l’architecture client-serveur
• Permet le développement et la modification de différentes
interfaces utilisateurs pour la même logique applicative
 Architecture n-niveaux
Architecture 3-parties

Réseau

Client X
Base de
Serveur de données
B.D. Unix corporative

Marché de
données

Client Windows Serveur Serveur de Dépôt de

Windows NT B.D. Unix données
Logique
applicative
 Architecture n-niveaux

Architecture 3-niveaux À noter que la tendance veut

que la partie cliente soit
De plus en plus mince, i.e., le
Interface
client ne fait qu’afficher un
gestionnaire
contenu HTML
La logique applicative est alors
responsable de créer les pages
Gestion Web à afficher par le client
des dossiers Il faut dissocier logique
applicative et présentation des
données

Base de
données clients
 Architecture n-niveaux
Architecture 4-niveaux
Architecture dont la couche logique applicative est décomposée en
• Couche Présentation (JSP, servlets)
– Présentation du contenu statique: Contenu HTML ou XML affiché par le
client
– Présentation du contenu dynamique : contenu organisé et créé
dynamiquement par le serveur web (pour ensuite être affiché en
HTML/XML par le client)
• Couche Logique applicative (calculs purs) : réalise le cœur des
traitements de l’application
Avantage sur l’architecture 3-niveaux
• Permet de supporter un grand nombre de formats de présentation
différents (propres à chaque client), tout en réutilisant certains des
objets de présentation entre les clients. Réduction des redondances…
• Bien adaptée pour les applications Web devant supporter plusieurs
types de clients
 Architecture n-niveaux Java Server Pages
- Partie cliente
- Partie serveur

Architecture 4-niveaux
Serveur de base
Clients Serveur de données

Interface <<build>> Présentation

ATM Serveur

Accès base de
<<submit>>
Interface <<build>> données comptes clients
Web
Gestion
<<submit>> opérations bancaires
Interface
<<build>>
employé
de la banque <<submit>>
 Architecture n-niveaux
D’un point de vue conception
Diviser pour régner : de façon
évidente, client et serveur peuvent
être développées séparément
Cohésion : le serveur peut offrir des
services cohésifs au client
Couplage : un seul canal de
communication existe souvent entre
client et serveur
Réutilisation : il est possible de
trouver une bibliothèque de
composants, interfaces, etc. pour
construire les systèmes
• Toutefois, les systèmes client-
serveur dépendent très souvent de
nombreuses considérations liées
intimement à l’application
Flexibilité : il est assez facile
d’ajouter de nouveaux clients et
serveurs
Portabilité : on peut développer de
nouveaux clients pour de nouvelles
plateformes sans devoir porter le
serveur
Testabilité : on peut tester le client
et le serveur indépendamment
Conception défensive : on peut
introduire des opérations de
vérification dans le code traitant les
messages reçus de part et d’autre
 5. Développer un modèle architectural
Commencer par faire une esquisse de l’architecture
En se basant sur les principaux requis des cas d’utilisation ; décomposition en
sous-systèmes
Déterminer les principaux composants requis
Sélectionner un style architectural
Raffiner l’architecture
Identifier les principales interactions entre les composants et les interfaces
requises
Décider comment chaque donnée et chaque fonctionnalité sera distribuée parmi
les différents composants
Déterminer si on peut réutiliser un cadriciel existant (réutilisation) ou si on peut en
construire un (réutilisabilité).
Considérer chacun des cas d’utilisation et ajuster l’architecture pour qu’il soit
réalisable
Détailler l’architecture et la faire évoluer
Décrire l’architecture avec UML
 5. Développer un modèle architectural
Les composants et le principe de séparation des préoccupations
La séparation des préoccupation est le principe qui assure l’intégrité
fonctionnelle d’un composant
• Chaque composant réalise une, et seulement une fonction au sein du
système, mais peut néanmoins exposer plusieurs méthodes.
Typiquement, chaque composant est défini par une interface qui
constitue son seul moyen d’interagir avec les autres composants
• L’utilisation d’une interface pour communiquer avec les autres
composants du système facilite la maintenance puisqu’on peut alors
en changer l’implémentation sans affecter les autres composants
(induit un couplage plus faible du composant avec le reste du
système)
• Les classes d’un composant devrait être vues comme un patron
cohésif qui implémente la fonctionnalité du composant
2.Bibliothèques et le chargement de
composants dynamiques
 2.1. Introduction
Aucun logiciel de grande taille n’est développé depuis
zéro aujourd’hui
Sauf dans le cas de développement en « salle blanche »

Utilisation de
« Bouts de code »
Structures + fonctions / Classes + méthodes
Bibliothèques
 2.2. Bibliothèques et cadriciels
« Bibliothèque [library] logicielle est un ensemble de fonctions utilitaires,
regroupées et mises à disposition afin de pouvoir être utilisées sans avoir à les
réécrire » [Wikipedia]

Plutôt que de coder une procédure courante dans chaque programme en ayant
besoin, on rassemble ces procédures dans des bibliothèques.

Si un programme a une fonction à remplir et que celle-ci se trouve en

bibliothèque, il l'utilisera directement.

Les bibliothèques logicielles se distinguent des exécutables dans la mesure où

elles ne représentent pas une application

Exemples
La bibliothèque de classes Java (!)
La STL de C++ (!!)
 2.2. Bibliothèques et cadriciels
« Un cadriciel [framework] est un espace de travail
modulaire. C'est un ensemble de bibliothèques, d'outils
et de conventions permettant le développement de
programmes. » [Wikipedia]

Un framework fournit:
un ensemble de fonctions facilitant la création de tout ou
d'une partie d'un système logiciel
un guide architectural en divisant le domaine visé en
modules.
 2.2. Bibliothèques et cadriciels
Types d’interconnexions
Chainage des liens (linking)
Duplication de processus (fork)
Protocole de communication (IPC)
Sous-classage
Chargement dynamique
3. Cadres de référence et plugiciels
 3.1. Introduction
Aujourd’hui (et demain), les programmes
Sont de plus en plus complexes
Doivent être livrés de plus en plus rapidement
Doivent fonctionner avec un minimum d’arrêt
Les programmes nécessitent donc
Une plateforme de programmation favorisant l’indépendance
des composants
Un format de livraison « standardisé »
Une plateforme d’exécution permettant le remplacement à
chaud
Les programmes doivent donc être formés de
composants réutilisables et interchangeables en cours
d’exécution
 3.2. Definition: plugiciel
« Un [plugiciel] est un programme qui interagit avec un
logiciel principal, appelé programme hôte, pour lui
apporter de nouvelles fonctionnalités » [Wikipedia]

ils ne peuvent fonctionner seuls car ils sont uniquement

destinés à apporter une fonctionnalité à un ou plusieurs
logiciels ;

ils sont mis au point par des personnes n'ayant pas

nécessairement de relation avec les auteurs du logiciel
principal.
 3.2. Definition: plugiciel
L’ojectif derriere l’implementation des plugiciels est de
permettre:
L’ajout des fonctionnalités sans avoir à tout reprogrammer
Permettre aux utilisateurs d'ajouter leurs propres
fonctionnalités de manière indépendante

Cette indépendance inclut la possibilité pour le logiciel

principal d'évoluer tout en restant compatible avec
les plugiciels existants ; cette condition est cependant
loin d'être toujours remplie.
 3.3. OSGi
Considérons une classe java faisant partie d’une application et
implémentant une fonctionnalité.
Cette classe doit donc faire partie des .jar de l’application.
En cas de bug dans cette classe, l’application complète doit être arrêtée
afin que celui-ci soit corrigé même s’il n’affecte qu’une sous-
fonctionnalité très rarement utilisée.

La technologie OSGi permet de développer les fonctionnalités de

façon indépendantes et de les intégrées dans l’application sous
forme de services.

Ces services peuvent être reliées dynamiquement à l’application

Un service particulier pouvant être arrêté et mis à jour sans que

le reste de l’application ne soit affecté.
 3.3. OSGi
OSGi (Open Service Gateway Initiative) a été fondé par
Ericson, IBM, Oracle et Sun

Modèle à composants complet et dynamique

Complémente la machine virtuelle Java
Réduit la complexité : encapsulation, interface de
programmation
Réutilisation : composants depuis l’étagère
Déploiement simplifié : gestion du cycle de vie
Mises à jour dynamiques : voir ci-dessus
Adaptation : les services peuvent aller et venir
Transparence : composants indépendants

[http://aneeshkumarkb.blogspot.com/]
 3.3. OSGi
La spécification de OSGi définit comment les bundles
(composants) doivent être implémentés afin d’être
intégrés à la plateforme OSGi. Elle se structure de la
manière suivante:
Un ensemble de services qu’un conteneur OSGi doit
implémenter (Exple de conteneur: Equinox d’Eclipse)
Un contrat entre le conteneur et les application
 3.3. OSGi
Cycle de vie d’un bundle OSGi
4.Composition et architectures par
composants
 4.1. Introduction
Limitations des architecture à objets
Complexité du chargement dynamique
Ad hoc
Solution partielle des cadre de références et autres
plugiciels
 4.1. Introduction
Contexte : ingénierie du système/intergiciel
(middleware)
Maintenant des systèmes globaux intégrant des applications jusqu'ici
indépendantes + développements nouveaux.

Tenir compte applications patrimoniales (legacy) = developpées avant les

standards ouverts actuels
application patrimoniale ne peut être utilisée qu‘à travers une interface
specifiée, et ne peut être modifiée. La plupart du temps, l'application doit
être reprise telle quelle car le coût de sa réécriture serait prohibitif.

Solution : Adopter une norme commune, non liée a un langage

particulier, pour interconnecter différentes applications.
La norme spécifie des interfaces et des protocoles d'échange pour la
communication entre applications.
Les protocoles sont realisees par une couche logicielle qui fonctionne
comme un bus d'echanges entre applications: c’est l’intergiciel
(middleware)
Utiliser des wrapper (envellope) = couche logicielle qui fait le pont entre
l'interface originelle de l'application et une nouvelle interface conforme à la
norme choisie. [http://sardes.inrialpes.fr/ecole/2006/chapitre1.pdf]
 4.1. Introduction
Contexte : ingénierie du système/intergiciel
(middleware)

Intégration d'applications patrimoniales

[http://sardes.inrialpes.fr/ecole/2006/chapitre1.pdf]
 4.2. Introduction aux composants
logiciels
Composant vs objet
plus haut niveau abstraction
meilleure encapsulation, protection, autonomie
programmation + systématique + vérifiable
communications plus explicites
• port, interface, connecteur
connectables
• schéma de connexion (ADL) : « plan » applicatif
séparation « métier » - technique
meilleure converture du cycle de vie
• conception, implémentation, packaging, déploiement, exécution
 4.2. Introduction aux composants
logiciels
Définition composant
1ère apparition terme [McIlroy 68]
• 30 ans + tard : Sun EJB, OMG CCM, MS .NET/COM+, …
recensement [Szyperski 02] : 11 définitions +/- ≡

A component is a unit of composition with contractually

specified interfaces and context dependencies only. A software
component can be deployed independently and is subject to
composition by third parties. [Szyperski 97]
 4.3. Le modèle Fractal
FT R&D, INRIA
open source
http://fractal.ow2.org

Historique
fin 2000 : premières réflexions autour de Fractal
06/2002
1ère version stable API
implémentation de référence (Julia)
1ère version de l’ADL
01/2004
définition de l’ADL v2 (ADL extensible)
implémentation disponible 03/2004
 4.3. Le modèle Fractal
ingénierie des systèmes et du middleware
suffisamment général pour être appliqué à tout autre
domaine
grain fin (wrt EJB ou CCM) proche d’un modèle de classe
léger (surcoût faible par rapport aux objets)
indépendant des langages de programmation

vision homogène des couches (OS, middleware, services,

applications)
Fractal everywhere
dans le but de faciliter et d’unifier
conception, développement, déploiement, administration
 4.3. Le modèle Fractal
ouvert et adaptable
les services extra-fonctionnels peuvent être personnalisés
il n’y a pas une seule “forme” de composants Fractal

2 usages possibles avec Fractal

framework de composants pour construire des applications/systèmes
• on utilise la forme “standard” des composants Fractal
framework de frameworks de composants
• on construit d’autres “formes” de composants
– avec introspection minimale et aggregation simple (à la COM)
– avec contrôleurs de liaison et de cycle de vie (à la OSGi)
– avec hiérarchie à 2 niveaux et liaison (à la SCA)
– avec des liaisons multicast (à la CCA)
– avec des contrôleurs d’attribut (à la MBean)
– avec des contrôleurs de persistance et de transaction (à la EJB)
–…
• on développe des applications avec ces autres “formes”
 4.3. Le modèle Fractal
En résumé
5.Patrons de conception
 Patrons de conception
=
Outils pour développeurs
 5.1 Origines
“Each pattern describes a problem which occurs over and over
again in our environment, and then describes the core of the
solution to that problem, in such way that you can use this solution
a million times over, without ever doing it the same way twice.”

“Each pattern is a three part rule, which express a relation

between a context, a problem, and a solution.”
Christopher Alexander [Alexander, 1977]

“The strict modeling of the real world leads to reflect today’s

realities but not necessarily tomorrow’s. The abstractions that
emerge during design are key to making a design flexible.”

Erich Gamma [Gamma et al., 1994]

 5.1 Origines
Systèmes de plus en plus complexes, le nombre de
classes et d’instances est de plus en plus élevé.

Vers une plus grande réutilisation de classes: ensembles

de classes collaboratrices.

Qu’est qu’un bon design?

 5.1 Origines
Un patron de conception c’est:
Description d ’une solution classique à un problème récurent
Décrit une partie de la solution…
Avec des relations avec le système et les autres parties...
C ’est une technique d ’architecture logicielle
 5.1 Origines
Un patron de conception n’est pas:
Une brique
• Un pattern dépend de son environnement
Une règle
• Un pattern ne peut pas s ’appliquer mécaniquement
Une méthode
• Ne guide pas une prise de décision ; un pattern est la décision
prise
Nouveau
• Non, Lao-Tzu (-550) travaillait déjà sur les patterns...
 5.2. Definition
“The description of communicating objects and classes customized
to solve general design problem in a particular context.”

“Each design pattern lets some aspect of system structure vary

independently of other aspects, thereby making a system more
robust to a particular kind of change.”

[Gamma et al., 1994]

 5.2. Definition
Avantages
Un vocabulaire commun
Permettent une plus grande reutilisabilité
Capitalisation de l ’expérience
Un niveau d ’abstraction plus élevé qui permet d ’élaborer
des constructions logicielles de meilleure qualité
Réduire la complexité
Guide/catalogue de solutions
 5.2. Definition
Inconvénients
Effort de synthèse ; reconnaître, abstraire…
Apprentissage, expérience
Les patterns « se dissolvent » en étant utilisés
Nombreux…
• lesquels sont identiques ?
• De niveaux différents … des patterns s ’appuient sur d ’autres...
 Catégories de patrons de conception
Création
Fabrique abstraite (Abstract
Factory)
Monteur (Builder)
Fabrique (Factory Method)
Prototype (Prototype)
Singleton (Singleton)
Structuraux
Adaptateur (Adapter)
Pont (Bridge)
Objet composite (Composite)
Décorateur (Decorator)
Façade (Facade)
Poids-mouche ou poids-plume
(Flyweight)
Proxy (Proxy)
Comportementaux
Chaîne de responsabilité (Chain
of responsibility)
Commande (Command)
Interpréteur (Interpreter)
Itérateur (Iterator)
Médiateur (Mediator)
Mémento (Memento)
Observateur (Observer)
État (State)
Stratégie (Strategy)
Patron de méthode (Template
Method)
Visiteur (Visitor)
 Quand utiliser un patron de conception?
Lorsque le problème est complexe?
Plusieurs patrons de conception existent
Granularité
• Requis, analyses, architecture
• Conception, implémentation (idioms)
• Refactoring, testing
• …

Les connaître tous ...

 Application des patrons de conception
L’application des patrons lors de la conception permet
Trouver les bons objets
• Les patterns proposent des abstractions qui n'apparaissent pas
"naturellement" en observant le monde réel
• Composite par exemple permet de traiter uniformément une
• structure d'objets hétérogènes
Bien choisir la granularité des objets
• La taille des objets peut varier considérablement ; comment
choisir ce qui doit être décomposé ou au contraire regroupé ?
• Exple: Facade, Flyweight,…
Spécifier les interfaces des objets
• Qu’est-ce qui fait partie d’un objet ou non ?
• Exple: Memento, Decorator
 Application des patrons de conception
L’application des patrons lors de la conception permet
Spécifier l'implantation des objets
• Différence type-classe…
• Exple: Chain of Responsibility ; même interface, mais
implantations différentes
Mieux réutiliser
• Héritage vs composition; Préférez la composition à l'héritage
• Délégation; Une forme de composition...qui remplace l'héritage,
• Exple: Mediator, Visitor, Proxy
 Comment utiliser les patrons de
conception?
De façon itérative et inductive
Partir de solutions simple et progressivement factoriser le
code pour évoluer vers les patrons de conception si
nécessaire…

Choisir le bon patron dès la phase de conception