Institut Africain d’Informatique

Etablissement Inter-Etats d’Enseignement Supérieur

Représentation du Togo

Architecture
multi-niveaux

IT Engineer | CTO @ ISPACE Corp. |

 Comment ça se passera ?

 Architecture logicielle
 Architecture un tier
 Architecture deux-tier
 Architecture 3 tier
 Architecture n-tier
Développer un style architectural
 Comment ça se passera ?

ARCHITECTURE LOGICIELLE
 Architecture logicielle ?

L’architecture logicielle est la structure des

modules/composants d’un système, leurs interactions et
les principes et lignes directrices gouvernant leur
conception et leur évolution au fil du temps. Elle inclut :

Les composants logiciels

Les propriétés externes visibles de ces composants

Les relations entre ces composants

 Architecture logicielle : description

La description d’une architecture logicielle consiste en : (1/2)

La description de l’organisation générale du système et

sa décomposition en sous-systèmes ou composants
La détermination des interfaces entre les sous-systèmes
La description des interactions et le flot de contrôle entre
les sous-systèmes
 Architecture logicielle : description

La description d’une architecture logicielle consiste en : (2/2)

La description des composants utilisés pour implanter les

fonctionnalités des sous-systèmes: propriétés de ces
composants, leur contenu (classes, autres composants),
les machines ou dispositifs matériels ces modules seront
déployés.
 Architecture logicielle : pourquoi ?

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é

 Architecture logicielle : utilité

Utilité d’une architecture logicielle (1/3)

Compréhension : facilite la compréhension des grands
systèmes complexes en donnant une vue de haut-niveau
de leurs structure et contraintes
Réutilisation : favorise l’identification des éléments
réutilisables, parties de conception, composants,
caractéristiques, fonctions ou données communes
 Architecture logicielle : utilité

Utilité d’une architecture logicielle (2/3)

Construction : fournit un plan de haut-niveau du
développement et de l’intégration des modules en
mettant en évidence les composants et les interactions et
les dépendances
Evolution : met en évidence les points où le système peut
être modifié et étendu.
 Architecture logicielle : utilité

Utilité d’une architecture logicielle (3/3)

Analyse : offre une base pour l’analyse la 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.
 Architecture logicielle : niveaux d’abstraction

Les trois niveaux d’abstraction d’une application :

Présentation (IHM, UI) : permet l’interaction de
l’application avec l’utilisateur; gère les saisies au clavier, à
la souris et la présentation des informations à l’écran. =>
convivialité et ergonomie.
Les traitements, la logique applicative : décrivant les
travaux à réaliser par l’application: traitements locaux (au
niveau du dialogue IHM, contrôle de saisie), traitements
globaux (l’application elle-même, Business Logic ou
couche métier)
 Architecture logicielle : niveaux d’abstraction

Les trois niveaux d’abstraction d’une application : (suite)

Données : plus exactement l’accès aux données,
regroupant l’ensemble des mécanismes permettant la
gestion des informations stockées par l’application

Ces trois niveaux peuvent être imbriqués ou répartis de

différentes manières entre plusieurs machines physiques
 Architecture logicielle : niveaux d’abstraction

Les trois niveaux d’abstraction d’une application : (suite)

Gestion de la présentation
Présentation
Logique de la présentation

Noyau de l’application
Locaux
Traitements Logique des traitements
Globaux
Gestion des traitements

Logique des données

Données
Gestion des données

Ces trois niveaux peuvent imbriqués ou répartis de

différentes manières entre plusieurs machines physiques
 Comment ça se passera ?

ARCHITECTURE UN-TIER
 Architecture un-tier

Présentation
Dans ce type d’architecture, les trois couches applicatives
sont intimement liées et s’exécutent sur le même ordinateur.

On ne parle pas d’architecture client/serveur, mais

d’informatique centralisée.
 Architecture un-tier

Présentation (suite)
Dans un contexte multi-utilisateurs, on peut rencontrer deux
types d’architectures

Des applications sur site central

Des applications réparties sur des machines

indépendantes communicant par partage de fichiers.
 Architecture un-tier

Applications sur site central : description

Ce sont les premières à fournir un accès multi-utilisateurs.

Les utilisateurs se connectent aux applications exécutées

par le serveur central (le mainframe) à l'aide de terminaux
passifs se comportant en esclaves.
Le serveur central qui prend en charge l'intégralité des
traitements, y compris l'affichage qui est simplement
déporté sur des terminaux passifs.
 Architecture logicielle : niveaux d’abstraction

Applications sur site central : (suite)

Présentation

Traitements

Terminal passif
Données
 Architecture un-tier

Applications sur site central : avantages

Facilité d’administration
Haute disponibilité

Bénéficie d’une large palette d’outils de conception,

programmation et d’administration matures et fiables

Utilisation optimale des ressources due à la centralisation

de la puissance
 Architecture un-tier

Applications sur site central : inconvénients

Fortement démodé par les interfaces utilisateur Windows-

Mac
 Architecture un-tier

Applications un-tier déployé : description

Virent le jour avec l’arrivée en entreprise des PC en réseau :

déploiement d’une application un-tier sur plusieurs
ordinateurs indépendants.
Simple à concevoir et à mettre en œuvre : dBase,
Access, Paradox, …

Très satisfaisant pour répondre aux besoins d’un utilisateur

isolé.
 Architecture un-tier

Applications un-tier déployé : avantages

Mise en œuvre envisageable dans un environnement

multi-utilisateurs
Utilisateurs se partageant des fichiers de données stockés
sur un serveur commun
 Architecture un-tier

Applications un-tier déployé : inconvénients

Données transitant intégralement sur le réseau,

occasionnant une saturation rapide
Cohabitation instable de plusieurs moteurs de base de
données manipulant les mêmes données

Conflits lors de la consultation et la modification

simultanée d’un même enregistrement par plusieurs
utilisateurs.
 Architecture un-tier

Applications un-tier déployé

Solution réservée à des applications non critiques

exploitées par de petits groupes de travail.
 Architecture un-tier

Limitations

Nécessité de trouver une solution conciliant :

La fiabilité des solutions sur site central, gérant les
données de façon centralisée

L’interface utilisateur moderne des applications sur

micro-ordinateurs
 Architecture un-tier

Limitations

Pour obtenir cette synthèse, il a fallu scinder les applications

en plusieurs parties distinctes et coopérantes :

Gestion centralisées des données

Gestion locale de l’interface utilisateur

Ainsi est né le concept du client-serveur

 Schéma de Gartner Group

Schéma de Gartner Group

 Comment ça se passera ?

ARCHITECTURE 2-TIER
 Architecture 2-tier

Présentation
Encore appelé client-serveur de 1ère génération ou client-
serveur de données, le client se contente de déléguer la
gestion des données à un service spécialisé.

Ex: application de gestion sur Windows utilisant un SGBD

centralisé.
Permet de tirer le meilleur de la puissance des ordinateurs
déployés en réseau : interface riche, cohérence des
données gérées de façon centralisée.
 Architecture 2-tier

Présentation (suite)
La gestion des données est prise en charge par un SGBD
centralisé, le plus souvent hébergé sur un serveur dédié,
interrogé en utilisant un langage de requête, généralement
SQL.

Le dialogue entre client et serveur se résume donc à l'envoi

de requêtes et au retour des données correspondant aux
requêtes.
 Architecture 2-tier

Dialogue client-serveur
Le modèle client-serveur met en œuvre une conversation
entre deux programmes que l'on peut opposer à l'échange
figé ``maître-esclave'' qu'entretiennent les applications sur
site central avec leurs terminaux passifs.

On distingue deux intervenants :

Le client: le programme qui initie le dialogue
Le serveur: le programme qui se contente de répondre
 Architecture 2-tier

Dialogue client-serveur
 Architecture 2-tier

Le middleware: définition et description

Littéralement « élément du milieu », ensemble des couches
réseau et services logiciels qui permettent le dialogue entre
différents composants d’une application répartie
Dialogue défini par un protocole commun régi par l’API du
middleware. Il représente la clef de voute de toute
application client/serveur.
Objectif : unifier l’accès et la manipulation des services
disponibles sur un réseau, de manière transparente.
 Architecture 2-tier

Le middleware
 Architecture 2-tier

Le middleware : services rendus

Conversion: Service utilisé pour la communication entre
machines mettant en œuvre des formats de données
différents

Adressage : Permet d'identifier la machine serveur sur

laquelle est localisé le service demandé afin d'en déduire
le chemin d'accès. Dans la mesure du possible, cette
fonction doit faire appel aux services d'un annuaire.
 Architecture 2-tier

Le middleware : services rendus (suite)

Sécurité : Permet de garantir la confidentialité et la
sécurité des données à l'aide de mécanismes
d'authentification et de cryptage des informations.

Communication : Permet la transmission des messages

entre les deux systèmes sans altération. Ce service doit
gérer la connexion au serveur, la préparation de
l'exécution des requêtes, la récupération des résultats et
la déconnexion de l'utilisateur.
 Architecture 2-tier

Le middleware : exemples
SQL*Net : Interface propriétaire pour accéder aux bases
de données Oracle
ODBC : Interface standardisée isolant le client du serveur
de données. C'est l'implémentation par Microsoft du
standard CLI
DCE : Permet l’appel à des procédures distantes depuis
une application
 Architecture 2-tier

Limites de l’architecture 2-tier

L’expérience a montré qu’il est très coûteux de faire porter
l’ensemble des traitements applicatifs par le client.

Impossible de soulager le client qui supporte l’ensemble

des traitements
Client devenant très sollicité, devenant de plus en plus
complexe, et doit être régulièrement mis à jour pour
répondre aux besoins des utilisateurs
 Architecture 2-tier

Limites de l’architecture 2-tier (suite)

Communication client/serveur devenant trop bruyante,
et mal adaptée aux bandes passantes étroites. Pour cela,
ce type d’application ne s’utilise qu’en entreprise.

les applications se prêtent assez mal aux fortes montées

en charge car il est difficile de modifier l'architecture
initiale
 Architecture 2-tier

Limites de l’architecture 2-tier (fin)

la relation étroite qui existe entre le programme client et
l'organisation de la partie serveur complique les évolutions
de cette dernière

ce type d'architecture est grandement rigidifié par les

coûts et la complexité de sa maintenance.
 Architecture 2-tier

Avantages de l’architecture 2-tier

elle permet l'utilisation d'une interface utilisateur riche,

elle a permis l'appropriation des applications par

l'utilisateur,

elle a introduit la notion d'interopérabilité.

 Architecture 2-tier

Pour résoudre les limitations du client-serveur deux tiers tout

en conservant ses avantages, on a cherché une
architecture plus évoluée, facilitant les forts déploiements à
moindre coût. La réponse est apportée par les
architectures distribuées.
 Comment ça se passera ?

LES ARCHITECTURES DISTRIBUEES

ARCHITECTURE 3-TIER
 Architecture 3-tier

Architecture 3-tier: objectifs

Les limites de l'architecture deux tiers proviennent en
grande partie de la nature du client utilisé :
le frontal est complexe et non standard (même s'il s'agit
presque toujours d'un PC sous Windows),

le middleware entre client et serveur n'est pas standard.

D’où la nécessité d’utiliser un poste client simple
communicant avec le serveur par un protocole standard.
 Architecture 3-tier

Architecture 3-tier: objectifs (suite et fin)

L’architecture 3-tier applique les principes suivants :

Les données sont gérées de manière centralisée

La présentation est toujours prise en charge par le client

La logique applicative est prise en charge par un serveur

intermédiaire
 Architecture 3-tier

Serveur de transaction
 Architecture 3-tier

Serveur de transaction : rôle

Permet de garantir que toutes les transactions vérifient les
règles ACID:
Atomicité : La transaction ne peut être partiellement
effectuée,
Cohérence : Une transaction fait passer la base d'un état
cohérent à un autre,
Isolation : Une transaction n'est pas affectée par le
résultat des autres transactions,
Durée : Les modifications dues à une transaction sont
durablement garanties.
 Architecture 3-tier

Répartition des traitements

Encore appelé client/serveur de 2e génération ou distribué,
cette architecture sépare l’application en 3 niveaux de
services distincts :
 Architecture 3-tier

Répartition des traitements (suite)

Ce type d'architecture fait une distinction nette entre deux
tronçons de communication indépendants et
délimités par le serveur HTTP :
 Architecture 3-tier

Répartition des traitements (suite)

 Architecture 3-tier

Le client léger : présentation

Dans l’architecture 3-tier, le poste client est communément
appelé client léger ou thin client par opposition aux clients
lourd de l’architecture 2-tier.
Le client léger ne prend en charge que la présentation de
l’application et éventuellement une partie de la logique
applicative de vérification des saisies des utilisateurs et de
mise en forme des données.
Souvent constitué d’un navigateur internet
 Architecture 3-tier

Ergonomie : Utilisation du HTML

Les pages HTML, même avec JavaScript, sont loin
d’atteindre les fonctionnalités des environnement Windows
Le multi-fenêtrage n’est pas facile à mettre en œuvre

Le déroulement de l’application doit se faire de manière

séquentielle
Les pages affichées sont relativement statiques,
L'ergonomie de l'application est limitée aux possibilités du
navigateur
 Architecture 3-tier

Ergonomie : Utilisation de JAVA

Langage orienté objet, JAVA permet de créer de petites
applications, applet, pouvant être intégré dans des pages
HTML pour enrichir le contenu.
Multi-plateforme : philosophie d’internet
Large palette de composants graphiques et multimédia
permettant d’atteindre la richesse fonctionnelle des
applications Windows
Capacité d’une applet Java d’exploiter directement un
serveur de données utilisant JDBC
 Architecture 3-tier

Ergonomie : Utilisation d’ActiveX

Réponse de Microsoft à l’aspect multi-plateforme de JAVA

Peuvent être intégré à une page HTML, mais persiste sur le

poste client après utilisation

Peuvent communiquer entre eux en utilisant la

technologie des bases de données via ODBC
 Architecture 3-tier

Quelques clients légers

Un poste Windows doté d’un navigateur web

Un terminal Windows (NetPC) correspondant à un PC

minimal

Station réseau de type NC: prend en charge des

traitements locaux (affichage, contrôle de saisie, mise en
forme des données, …)
 Architecture 3-tier

Le service applicatif : Présentation

En architecture 3-tier, la logique applicative est prise en
charge par le serveur HTTP.
Les développements mis en œuvre sur ce serveur doivent
être conçus spécifiquement. Ils peuvent mettre en œuvre:
CGI: mécanisme standard, grand consommateur de
ressources
NSAPI ou ISAPI: les API de Netscape et Microsoft
permettant l’écriture d’applications multi-thread intégrées
au serveur HTTP
 Architecture 3-tier

Le service applicatif : Présentation (suite)

Les scripts serveur comme ASP, ou PHP sont interprétés
par le serveur pour générer des pages dynamiquement

Les servlets Java : qui appliquent le mécanisme des

appels aux traitements réalisés sur le serveur.
 Architecture 3-tier

Le service applicatif : Gestion des transactions

Le HTTP n’assurant pas la gestion des états, les applications
transactionnelles doivent gérer elles-mêmes le contexte
utilisateur afin de contrôler :
Le cheminement de l’utilisateur
Les actions et saisies de l’utilisateur
L’identité de l’utilisateur

La gestion des transactions.

 Architecture 3-tier

Le service applicatif : Gestion des transactions (suite)

Il existe différentes méthodes de gestion de contexte:

Attribution d’un identifiant à chaque étape de la

transaction

Stockage de l’ensemble du contexte sur le poste client

 Architecture 3-tier

Le service applicatif : Gestion des transactions (fin)

Ces méthodes nécessitent le stockage d’informations sur le
poste client:

Dans un cookie

Dans une URL longue

Dans des variables cachées au sein de la page HTML

 Architecture 3-tier

Limitations

L’architecture 3-tier a corrigé l’excès du client lourd en

centralisant une grande partie de la logique applicative sur
le serveur HTTP.

Le client ne gère que la présentation et les contrôles de

saisie s’est trouvé ainsi soulagé et plus léger à gérer.
 Architecture 3-tier

Limitations (suite)

Par contre, le serveur HTTP constitue la pierre angulaire de

cette architecture et se trouve fortement sollicité et il est
difficile de répartir la charge entre le client et le serveur.

On se retrouve confronté aux épineux problèmes de

redimensionnement serveur et de gestion de la montée en
charge rappelant l’époque des mainframes
 Architecture 3-tier

Limitations (fin)
De plus les solutions mises en œuvre sont relativement
complexes à maintenir et la gestion des sessions compliquée
Les contraintes semblent inversées par rapport à
l’architecture 2-tier: le client est soulagé, mais le serveur est
fortement sollicité.
 Comment ça se passera ?

ARCHITECTURE N-TIER
 Architecture n-tier

Présentation
Elle est pensée pour palier aux limitations des architectures 3-
tier et concevoir des applications puissantes et simples à
maintenir.

Permet de distribuer plus librement la logique applicative,

facilitant la répartition des charges à tous les niveaux.
 Architecture n-tier

Présentation (suite)
Cette approche met en œuvre une approche objet pour
offrir une plus grande souplesse d’implémentation et faciliter
la réutilisation des développements
 Architecture n-tier

Présentation (fin)
Théoriquement ce type d’architecture supprime tous les
inconvénients des architectures précédentes :
Utilisation d’interfaces-utilisateurs riches
Séparation nette de tous les niveaux de l’application
Grande capacité d’extension

Facilité de gestion des sessions

 Architecture n-tier

Les niveaux
L’appellation ‘n-tier’ pourrait faire penser que cette
architecture met en œuvre un nombre indéterminé de
niveaux de service, alors qu’il sont au maximum trois.

L’architecture ‘n-tier’ qualifie la distribution d’application

entre multiples services et non la multiplication des niveaux
de services.
 Architecture n-tier

Les niveaux (suite)

Cette distribution est facilitée par l’utilisation de composants
‘‘métier’’, spécialisés et indépendants, introduits par les
concepts orientés objets. Elle permet de tirer pleinement
profit de la notion de composants métiers réutilisables.

Ces composants rendent un service si possible générique et

clairement identifié. Ils sont capables de communiquer entre
eux et peuvent coopérer en étant implantés sur des
machines différentes.
 Architecture n-tier

Les niveaux (fin)

La distribution des services facilite aussi l’intégration des
traitements existants dans les nouvelles applications.

On peut ainsi envisager de connecter un programme de

prise de commande existant sur le site central de l’entreprise
à une application distribuée en utilisant un middleware
adapté.
 Architecture n-tier

L’approche objet
De plus en plus conceptuelle, elle permet de masquer la
complexité des mécanismes mis en œuvre
 Architecture n-tier

L’approche objet (suite)

Les protocoles réseau ont suivi le même type d'évolution. Ils
furent d'abord très proches de la couche physique, avec les
mécanismes de sockets orientés octets.
 Architecture n-tier

L’approche objet (fin)

Les méthodes de conception orientées objet (UML, OMT)
permettent une modélisation plus concrète des besoins et
facilitent le passage de la conception à la réalisation.

Aucune de ces évolutions ne constitue en soi une révolution,

mais elles rendent économiquement réalisables des
architectures qui n’étaient jusqu’à présent que
techniquement envisageables.
 Architecture n-tier

Les objets métiers : les Java Beans

Un Java Beans, d’après les spécification de Sun, est un
composant logiciel réutilisable qui peut être manipulé par un
outil d’assemblage.

Cette notion assez large englobe aussi bien un simple

bouton qu’une application complète. Concrètement, ce
sont des classes Java utilisant des interfaces particulières.
 Architecture n-tier

Les objets métiers : les Java Beans (fin)

Un Java Beans peut dévoiler son comportement à ses futurs
utilisateurs à l’aide des :
Propriétés qu’il expose et rend accessibles (accesseurs)
Méthodes qu’il permet d’invoquer
Événements qu’il peut générer pour avertir d’autres
composants.
Les Java Beans sont gérés comme tout objet Java (ex. leur
cycle de vie). Ils sont livrés sous forme de fichiers JAR.
 Architecture n-tier

Les objets métiers : les Entreprise Java Beans, EJB

Ce sont des Java Beans destinés à une utilisation côté
serveur :
Ils ne comportent pas forcement de partie visible,
Ils prennent en charge des fonctions de sécurité, de
gestion des transactions et d’état,
Ils peuvent communiquer avec des Java Beans côté client
Ils s’exécutent dans un environnement s’appuyant sur l’API
Java Server et offrant des fonctionnalités de gestion de la
charge d’exécution, de la sécurité, de communication,
d’accès aux services transactionnels.
 Architecture n-tier

Les objets métiers : Microsoft OLE-COM-ActiveX

Le modèle de communication COM (Component Object
Model) permet de mettre en place une communication
orientée objet entre des applications s'exécutant sur une
même machine.
DCOM est une extension de ce modèle pour les
architectures distribuées. Il repose sur le modèle DCE défini
par l'OSF et met en œuvre un serveur d'objets situé sur
chaque machine
 Architecture n-tier

Les objets métiers : Microsoft OLE-COM-ActiveX (fin)

Les contrôles ActiveX sont des composants logiciels basés sur

le modèle COM. Ils peuvent être intégrés à des applications
où à des documents sous Windows.
 Architecture n-tier

La communication entre objets : Principes

Pour permettre la répartition d’objets entre machines et

l’intégration des systèmes non objets, il doit être possible
d’instaurer une communication entre tous ces éléments.

D’où la naissance des middlewares objet, source de

plusieurs concepts, dont l’architecture CORBA préconisée
par l’OMG et DCOM développée par Microsoft.
 Architecture n-tier

La communication entre objets : Principes (suite)

Ces middlewares sont constitués d’une série de mécanismes

permettant à un ensemble de programmes d’inter-opérer
de façon transparente. Les services offerts par les serveurs
sont présentés sous forme d’objets.

La localisation et les mécanismes mis en œuvre sont cachés

dans le middleware.
 Architecture n-tier

La communication entre objets : Principes (suite)

La communication entre objets fait ignorer les notions de
‘local’ et ‘distant’.

Les appels de méthodes sont traités par un ORB se

chargeant d’aiguiller les messages vers les objets (locaux
ou distants)
 Architecture n-tier

L’appel de procédures distantes (RMI)

RMI permet à une application Java d’invoquer les méthodes
d’un objet hébergé par une machine distante.

Pour cela, le client utilise une représentation locale de

l’interface de l’objet serveur.

Cette représentation locale est appelée stub et représente

l’interface de l’objet serveur, appelée skeleton.
 Architecture n-tier

L’appel de procédures distantes (RMI)

Un objet distribué se caractérise par son interface et son
adresse (URL) commençant par ‘rmi://’.

La mise en relation est assurée par un serveur de noms.

 Architecture n-tier

Le modèle CORBA
Le système CORBA permet, au travers du protocole IIOP,
l’utilisation d’objets structurés dans un environnement
hétérogène.

Cette communication, orchestrée par l’ORB, est

indépendante des contraintes systèmes des différentes
plateformes matérielles.
 Comment ça se passera ?

DEVELOPPER UN STYLE ARCHITECTURAL

 Modèle architectural

Développement d’un modèle architectural

Commencer par faire une esquisse de l’architecture

En se basant sur les principaux éléments requis des CU;
décomposition en sous-systèmes
Déterminer les principaux composants requis
Sélectionner un style architectural
 Modèle architectural

Développement d’un modèle architectural (suite)

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 framework existant
(réutilisation) ou si on peut en construire un (réutilisabilité).
 Modèle architectural

Développement d’un modèle architectural (fin)

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.

 Modèle architectural

Décrire l’architecture avec UML

Tous les diagrammes UML peuvent être utiles pour décrire les
différents aspects du modèle architectural.

Trois des diagrammes UML sont particulièrement utiles pour

décrire une architecture logicielle:
Diagramme de packages
Diagramme de composants
Diagramme de déploiement
 Modèle architectural

Diagramme de packages
Package: Collection d’éléments de modélisation UML (e.g.
classes, use cases, etc.) groupés ensemble car liés
logiquement.
Il faut essayer de maximiser la cohésion au sein de
package (éléments liés) et minimiser le couplage entre
ceux-ci.
Dépendance: Un package est dépendant d’un autre s’il
l’utilise…
 Modèle architectural

Diagramme de packages (fin)

 Modèle architectural

Diagramme de composants
Offre une vue de haut niveau de l’architecture du
système.
Utilisé pour décrire le système d’un point de vue
implémentation.
Permet de décrire les composants d’un système et les
interactions entre ceux-ci.
Illustre comment grouper concrètement et physiquement
les éléments (objets, interfaces, etc.) du système au sein
de modules qu’on appelle composants.
 Modèle architectural

Qu’est-ce qu’un composant ?

Unité autonome faisant partie d’un système ou d’un sous-
système qui encapsule un comportement (i.e.
implémentation) et qui offre une ou plusieurs interfaces
publiques.
Partie constituante d’un système qui peut être remplacée
ou/et réutilisée.
Élément d’implémentation (un sous-système, un fichier
exécutable, une classe d’implémentation (i.e. non
abstraite), etc.) muni d’interface(s).
 Modèle architectural

Qu’est-ce qu’un composant ? (suite)

Chaque composant est le représentant d’une ou plusieurs
classes qui implémentent un service à l’intérieur du
système.
Granularité? Un composant peut représenter quelque
chose d’aussi fin qu’un objet, comme il peut représenter
un sous-système complexe.
 Modèle architectural

Qu’est-ce qu’un composant ? (fin)

Différence entre composant et instance de composant.
Composant: Vue haut niveau d’un élément logiciel qui
compose le système. (~classe)
Instance de composant: Le composant effectivement
utilisé. (~objet)
Exemples de composants:
Binaire exécutable (<<executable>>), librairie
dynamique/statique (<<librairy>>), un fichier à interpréter
(<<file>>), etc.
 Modèle architectural

Composant et principe de séparation des préoccupations (1)

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.
 Modèle architectural

Composant et principe de séparation des préoccupations (2)

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.
 Modèle architectural

Composants et interfaces - notation

 Modèle architectural

Composants et interfaces – notation (suite)

Une flèche de dépendance permet de mettre en relation
des composants via les interfaces requises et celles fournies.
 Modèle architectural

Composants et interfaces – notation (fin)

 Modèle architectural

Composants – Vue de la structure interne

Il est parfois utile de pouvoir montrer la structure interne
d’un composant.
 Modèle architectural

Construction d’un diagramme de composants

• Diviser pour mieux régner

• Cohésion forte
• Faible couplage
• Abstraction
• Réutilisabilité
• Réutilisation
• Etc.
 Modèle architectural

Diagramme de déploiement
 Modèle architectural

Diagramme de déploiement : exemple 1

 Modèle architectural

Diagramme de déploiement : exemple

 Comment ça se passera ?

ARCHITECTURE N-TIER PAR L’EXEMPLE

 Architecture n-tier par l’exemple

Rappel sur le pattern Observer

• Problème : Mettre en œuvre une relation de « un vers
plusieurs » objets afin que plusieurs objets puissent être
notifiés du changement d’état d’un objet et puisse
réagir.

Il est très utilisé en IHM, mais peut être appliqué dans bien
d’autres cas.
 Architecture n-tier par l’exemple

Rappel sur le pattern Observer : rôle

• Rôles : un sujet (observable) et des observers (qui
l’observent).

Responsabilités :
• Le sujet notifie les observers quand il change, et leur
permet de s’enregistrer.
• Les observers acceptent les notifications.
 Architecture n-tier par l’exemple

Rappel sur le pattern Observer : Solution

Sujet abstrait (Observable): gère les observers
(addObserver (Observer)) et notifie les observers
(notifiyObservers)
Sujet (Observable) : à chaque changement d’état, il
notifie les observers, et il peut donner son état (getState)
Observer : Se met à jour quand il est notifié (update)

Observer abstrait : peut être notifié (update)

 Architecture n-tier par l’exemple

Rappel sur le pattern Observer : Solution

 Architecture n-tier par l’exemple

Pattern Observer en Java

Sujet abstrait : classe abstraite
[Link]
Sujet concret : votre classe qui
hérite de observable. C’est à vous
d’appeler notifyObservers().
Observer abstrait : interface
[Link]
Observer concret: implémente
Observer et doit implémenter upate ()
().
 Architecture n-tier par l’exemple

Pattern Observer en Java : exemple

import [Link]; public void setValue(int n)

{
public class ObservableObject extends this.n = n;
Observable setChanged();
{ notifyObservers();
}
private int n = 0; public int getValue()
public ObservableObject(int n) {
{ return n;
}
this.n = n; }
}
 Architecture n-tier par l’exemple

Pattern Observer en Java : exemple

import [Link];
public void update
import [Link];
(Observable obs, Object
public class TextObserver implements
obj)
Observer
{
{
if (obs == ov){
private ObservableObject ov = null;
[Link]([Link](
public TextObserver
));
(ObservableObject ov)
}
{
}
[Link] = ov;
}
}
 Architecture n-tier par l’exemple

Pattern Observer en Java : exemple

public class Main
{
public Main()
{
ObservableValue ov = new ObservableValue(0);
TextObserver to = new TextObserver(ov);
[Link](to);
}
public static void main(String [] args)
{
Main m = new Main();
}
}
 Architecture n-tier par l’exemple

Pattern Observer en action : le besoin

Un forum : on peut poster des messages (avec titre) sur le
forum
Des abonnés : un abonné peut recevoir des messages
dans ses boîtes de messages

Dès qu’un message est posté, tous les abonnés sont notifiés

Certains abonnés enregistrent le message dans leur boîte

Certains abonnés n’enregistrent que les messages dont le
titre contient « IAI »
 Architecture n-tier par l’exemple

Pattern Observer en action : l’analyse

L’analyse produit :
Les use cases de plus haut niveau
Les premières procédures de tests de validation

Les diagrammes de séquence de niveau analyse

Un diagramme de classes capturant les grandes lignes du
domaine
Un glossaire
 Architecture n-tier par l’exemple

Pattern Observer en action : la conception

La conception vise à produire :

• L’architecture;
• Les classes;
• Les données.
 Architecture n-tier par l’exemple

Pattern Observer en action : l’analyse

Choix d’architecture
 Architecture n-tier par l’exemple

Pattern Observer en action : la conception (1)

Les couches logicielles :
 Architecture n-tier par l’exemple

Pattern Observer en action : la conception (2)

Les couches logicielles :
• couche ihm: c'est l'interface utilisateur encore
appelé interface homme machine
• couche métier : c'est le cœur de l'application
où réside les objets traités par l'application
• couche DAO: couche d'accès aux données (data
access object). Cette couche permet une
indépendance de la logique métier et du
stockage des données associées
 Architecture n-tier par l’exemple

Pattern Observer en action : la conception (3)

Le modèle :
• Décrit et contient les données manipulées par
l’application, ainsi que des traitements
propres à ces données
• Les résultats renvoyés par le modèle sont
dénués de toute présentation
• Le modèle contient la logique métier de
l’application
 Architecture n-tier par l’exemple

Pattern Observer en action : la conception (4)

La Vue:
• Interface avec laquelle l’utilisateur : reçoit
toutes les actions de l’utilisateur et envoie les
événements au contrôleur
• Présentation des résultats renvoyés par la couche
modèle, après le traitement du contrôleur
• La vue n’effectue aucun traitement
 Architecture n-tier par l’exemple

Pattern Observer en action : la conception (5)

Le contrôleur :
• Gestion des événements de synchronisation
entre modèle et vue
• Détermine l’action à réaliser

• Ne fait qu’appeler des méthodes

 Architecture n-tier par l’exemple

Exemple en Java
• Une vue listant les différents volumes et qui
ajoutera chaque nouveau volume dans une
liste déroulante : JFrameListVolume
 Architecture n-tier par l’exemple

Exemple en Java
• Une vue permettant de modifier le volume à l’aide
d’un spinner avec un bouton permettant de
valider le nouveau volume : JFrameSpinnerVolume
 Architecture n-tier par l’exemple

Exemple en Java
• Une vue permettant de modifier le nouveau
volume avec un champ texte avec un
bouton permettant de valider le nouveau
volume : JFrameFieldVolume
 Architecture n-tier par l’exemple

Exemple en Java : Modèle

 Architecture n-tier par l’exemple

Exemple en Java : Modèle observable

 Architecture n-tier par l’exemple

Exemple en Java : Evénements

 Architecture n-tier par l’exemple

Exemple en Java : Vue abstraite à l’écoute

 Architecture n-tier par l’exemple

Exemple en Java : Contrôleur

 Architecture n-tier par l’exemple

Exemple en Java : Vue réactive et active

 Architecture n-tier par l’exemple

Exemple en Java : Vue réactive

 Architecture n-tier par l’exemple

Exemple en Java : Lanceur

[Link]
 Architecture n-tier par l’exemple

Exemple en Java : Classes UML

 Architecture n-tier par l’exemple

Exemple en Java : Reverse engineering

 Architecture n-tier par l’exemple

Accès aux données : Le Pattern DAO

• Permet de séparer les données de la manière
dont elles sont stockées
• Create, Read, Update, Delete

Objets métier Système de

DAO
stockage
 Architecture n-tier par l’exemple

Accès aux données : Le Pattern DAO – Exemple

• Soit des étudiants qu’on veut manipuler dans
une application
 Architecture n-tier par l’exemple

Accès aux données : Le Pattern DAO – Exemple

 Architecture n-tier par l’exemple

Accès aux données : Le Pattern DAO – Exemple

 Architecture n-tier par l’exemple

Accès aux données : Le Pattern DAO – Exemple

 Architecture n-tier par l’exemple

Accès aux données : Le Pattern DAO – Exemple

 Architecture n-tier par l’exemple

Accès aux données : Le Pattern DAO – Exemple

Architecture n-tier par l’exemple
 Architecture n-tier par l’exemple

Remarques
• L’architecture doit supporter la séparation
entre métier, interfaces homme-machine et
données.

• MVC, DAO, Observer, …, sont des Design

Patterns pouvant guider la mise en œuvre.
 Comment ça se passera ?

LES DESIGN PATTERN POUR DECOUPLER

LES COUCHES
 Quelques Design Patterns

Pattern « Delegate »

Problème :

• Le tier présentation de la partie client doit

pouvoir avoir accès à des composants
métiers

• Il faut minimiser le couplage entre les couches

 Quelques Design Patterns

Pattern « Delegate »

Solution
• Réduire le couplage entre la présentation et
les composants métiers
• Masquer l’implémentation du composant
• Permettre des changements d’implémentation
dans touts les composants métier sans toucher
les couches supérieures.
 Quelques Design Patterns

Pattern « Delegate »

• Peut être utilisé en relation 1:1 avec le pattern

Facade.
 Quelques Design Patterns

Pattern « Facade »

• Pattern le plus utilisé de J2EE : créer un mur

entre le client et le reste de l’application

• Les composants métiers exposent leurs interfaces

au monde entier (serveur d’application, ou tout
autre serveur participant à la logique métier de
l’entreprise).
 Quelques Design Patterns

Pattern « Facade »

• Pattern le plus utilisé de J2EE : créer un mur

entre le client et le reste de l’application

• Les composants métiers exposent leurs interfaces

au monde entier (serveur d’application, ou tout
autre serveur participant à la logique métier de
l’entreprise).
 Quelques Design Patterns

Pattern « Facade »
But :
• Mettre à disposition de l’application au moyen
d’interfaces, les méthodes dont elle a réellement
besoin afin de faciliter son flot d’exécution
 Quelques Design Patterns

Pattern « DAO »
• L’accès aux sources de données varie selon la
source des données (base de données
relationnelles, ERP, …)

• Certaines applications peuvent nécessiter l’accès

à des données sur des systèmes distants (Oracle,
LDAP, SAP, …)
 Quelques Design Patterns

Pattern « DAO »
• L’accès aux sources de données varie selon la
source des données (base de données
relationnelles, ERP, …)

• Certaines applications peuvent nécessiter l’accès

à des données sur des systèmes distants (Oracle,
LDAP, SAP, …)
 Quelques Design Patterns

Pattern « DAO »
• Les servlets, pages JSP, …, peuvent à tout moment
voir besoin d’accéder à une source de données
• Les API de gestion de base de données ainsi que
leurs possibilités varient selon leur constructeur.
• La portabilité de l’application est grandement
affectée par les API propriétaires
• Les composants d’accès aux données doivent
être transparents pour l’application