Vous êtes sur la page 1sur 156

Institut Africain d’Informatique

Etablissement Inter-Etats d’Enseignement Supérieur


Représentation du Togo

Architecture
multi-niveaux
Par

Koffi Sani
IT Engineer | CTO @ ISPACE Corp. |@koffisani
Comment ça se passera ?

 Architecture logicielle
 Architecture un tier
 Architecture deux-tier
 Architecture 3 tier
 Architecture n-tier
Développer un style architectural
Koffi SANI | @koffisani 2
Comment ça se passera ?

ARCHITECTURE LOGICIELLE

Koffi SANI | @koffisani 3


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


Koffi SANI | @koffisani 4
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

Koffi SANI | @koffisani 5


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.

Koffi SANI | @koffisani 6


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é

Koffi SANI | @koffisani 7


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

Koffi SANI | @koffisani 8


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.

Koffi SANI | @koffisani 9


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.

Koffi SANI | @koffisani 10


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)

Koffi SANI | @koffisani 11


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

Koffi SANI | @koffisani 12


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
Koffi SANI | @koffisani 13
Comment ça se passera ?

ARCHITECTURE UN-TIER

Koffi SANI | @koffisani 14


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.

Koffi SANI | @koffisani 15


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.

Koffi SANI | @koffisani 16


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.

Koffi SANI | @koffisani 17


Architecture logicielle : niveaux d’abstraction

Applications sur site central : (suite)

Présentation

Traitements

Terminal passif
Données

Koffi SANI | @koffisani 18


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
Koffi SANI | @koffisani 19
Architecture un-tier

Applications sur site central : inconvénients

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

Koffi SANI | @koffisani 20


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é.

Koffi SANI | @koffisani 21


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

Koffi SANI | @koffisani 22


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.

Koffi SANI | @koffisani 23


Architecture un-tier

Applications un-tier déployé

Solution réservée à des applications non critiques exploitées par de


petits groupes de travail.

Koffi SANI | @koffisani 24


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

Koffi SANI | @koffisani 25


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

Koffi SANI | @koffisani 26


Comment ça se passera ?

ARCHITECTURE 2-TIER

Koffi SANI | @koffisani 27


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.
Koffi SANI | @koffisani 28
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.

Koffi SANI | @koffisani 29


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

Koffi SANI | @koffisani 30


Architecture 2-tier

Dialogue client-serveur

Koffi SANI | @koffisani 31


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.
Koffi SANI | @koffisani 32
Architecture 2-tier

Le middleware

Koffi SANI | @koffisani 33


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.

Koffi SANI | @koffisani 34


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.

Koffi SANI | @koffisani 35


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

Koffi SANI | @koffisani 36


Schéma de Gartner Group

Schéma de Gartner Group

Koffi SANI | @koffisani 37


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

Koffi SANI | @koffisani 38


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

Koffi SANI | @koffisani 39


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.

Koffi SANI | @koffisani 40


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é.

Koffi SANI | @koffisani 41


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.

Koffi SANI | @koffisani 42


Comment ça se passera ?

LES ARCHITECTURES
DISTRIBUEES
ARCHITECTURE 3-TIER

Koffi SANI | @koffisani 43


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.
Koffi SANI | @koffisani 44
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

Koffi SANI | @koffisani 45


Architecture 3-tier

Serveur de transaction

Koffi SANI | @koffisani 46


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.
Koffi SANI | @koffisani 47
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 :

Koffi SANI | @koffisani 48


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 :

Koffi SANI | @koffisani 49


Architecture 3-tier

Répartition des traitements (suite)

Koffi SANI | @koffisani 50


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


Koffi SANI | @koffisani 51
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

Koffi SANI | @koffisani 52


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
Koffi SANI | @koffisani 53
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

Koffi SANI | @koffisani 54


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, …)

Koffi SANI | @koffisani 55


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

Koffi SANI | @koffisani 56


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.

Koffi SANI | @koffisani 57


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.

Koffi SANI | @koffisani 58


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

Koffi SANI | @koffisani 59


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

Koffi SANI | @koffisani 60


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.

Koffi SANI | @koffisani 61


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

Koffi SANI | @koffisani 62


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é.

Koffi SANI | @koffisani 63


Comment ça se passera ?

ARCHITECTURE N-TIER

Koffi SANI | @koffisani 64


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.

Koffi SANI | @koffisani 65


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

Koffi SANI | @koffisani 66


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

Koffi SANI | @koffisani 67


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.

Koffi SANI | @koffisani 68


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.

Koffi SANI | @koffisani 69


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é.

Koffi SANI | @koffisani 70


Architecture n-tier

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

Koffi SANI | @koffisani 71


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.

Koffi SANI | @koffisani 72


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.

Koffi SANI | @koffisani 73


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.

Koffi SANI | @koffisani 74


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.

Koffi SANI | @koffisani 75


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.

Koffi SANI | @koffisani 76


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

Koffi SANI | @koffisani 77


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.

Koffi SANI | @koffisani 78


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.

Koffi SANI | @koffisani 79


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.

Koffi SANI | @koffisani 80


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)

Koffi SANI | @koffisani 81


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.

Koffi SANI | @koffisani 82


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.

Koffi SANI | @koffisani 83


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.

Koffi SANI | @koffisani 84


Comment ça se passera ?

DEVELOPPER UN STYLE
ARCHITECTURAL

Koffi SANI | @koffisani 85


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

Koffi SANI | @koffisani 86


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é).

Koffi SANI | @koffisani 87


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.

Koffi SANI | @koffisani 88


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
Koffi SANI | @koffisani 89
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…

Koffi SANI | @koffisani 90


Modèle architectural

Diagramme de packages (fin)

Koffi SANI | @koffisani 91


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.
Koffi SANI | @koffisani 92
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).
Koffi SANI | @koffisani 93
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.

Koffi SANI | @koffisani 94


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.

Koffi SANI | @koffisani 95


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.

Koffi SANI | @koffisani 96


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.

Koffi SANI | @koffisani 97


Modèle architectural

Composants et interfaces - notation

Koffi SANI | @koffisani 98


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.

Koffi SANI | @koffisani 99


Modèle architectural

Composants et interfaces – notation (fin)

Koffi SANI | @koffisani 100


Modèle architectural

Composants – Vue de la structure interne


Il est parfois utile de pouvoir montrer la structure interne d’un
composant.

Koffi SANI | @koffisani 101


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.

Koffi SANI | @koffisani 102


Modèle architectural

Diagramme de déploiement

Koffi SANI | @koffisani 103


Modèle architectural

Diagramme de déploiement : exemple 1

Koffi SANI | @koffisani 104


Modèle architectural

Diagramme de déploiement : exemple

Koffi SANI | @koffisani 105


Comment ça se passera ?

ARCHITECTURE N-TIER PAR


L’EXEMPLE

Koffi SANI | @koffisani 106


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.

Koffi SANI | @koffisani 107


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.

Koffi SANI | @koffisani 108


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)


Koffi SANI | @koffisani 109
Architecture n-tier par l’exemple

Rappel sur le pattern Observer : Solution

Koffi SANI | @koffisani 110


Architecture n-tier par l’exemple

Pattern Observer en Java


Sujet abstrait : classe abstraite java.util.Observable

Sujet concret : votre classe qui hérite de


observable. C’est à vous d’appeler
notifyObservers().
Observer abstrait : interface java.util.Observer

Observer concret: implémente Observer et


doit implémenter upate () ().
Koffi SANI | @koffisani 111
Architecture n-tier par l’exemple

Pattern Observer en Java : exemple

import java.util.Observable; public void setValue(int n)


{
public class ObservableObject extends Observable this.n = n;
{ setChanged();
private int n = 0; notifyObservers();
}
public ObservableObject(int n) public int getValue()
{ {
this.n = n; return n;
}
} }

Koffi SANI | @koffisani 112


Architecture n-tier par l’exemple

Pattern Observer en Java : exemple

import java.util.Observer;
public void update (Observable
import java.util.Observable;
obs, Object obj)
public class TextObserver implements Observer
{
{
if (obs == ov){
private ObservableObject ov = null;
System.out.println(ov.getValue( ));
public TextObserver
}
(ObservableObject ov)
}
{
}
this.ov = ov;
}

Koffi SANI | @koffisani 113


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);
ov.addObserver(to);
}
public static void main(String [] args)
{
Main m = new Main();
}
}
Koffi SANI | @koffisani 114
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 »
Koffi SANI | @koffisani 115
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
Koffi SANI | @koffisani 116
Architecture n-tier par l’exemple

Pattern Observer en action : la conception


La conception vise à produire :

• L’architecture;
• Les classes;
• Les données.

Koffi SANI | @koffisani 117


Architecture n-tier par l’exemple

Pattern Observer en action : l’analyse


Choix d’architecture

Koffi SANI | @koffisani 118


Architecture n-tier par l’exemple

Pattern Observer en action : la conception (1)


Les couches logicielles :

Koffi SANI | @koffisani 119


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
Koffi SANI | @koffisani 120
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

Koffi SANI | @koffisani 121


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

Koffi SANI | @koffisani 122


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

Koffi SANI | @koffisani 123


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

Koffi SANI | @koffisani 124


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

Koffi SANI | @koffisani 125


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

Koffi SANI | @koffisani 126


Architecture n-tier par l’exemple

Exemple en Java : Modèle

Koffi SANI | @koffisani 127


Architecture n-tier par l’exemple

Exemple en Java : Modèle observable

Koffi SANI | @koffisani 128


Architecture n-tier par l’exemple

Exemple en Java : Evénements

Koffi SANI | @koffisani 129


Architecture n-tier par l’exemple

Exemple en Java : Vue abstraite à l’écoute

Koffi SANI | @koffisani 130


Architecture n-tier par l’exemple

Exemple en Java : Contrôleur

Koffi SANI | @koffisani 131


Architecture n-tier par l’exemple

Exemple en Java : Vue réactive et active

Koffi SANI | @koffisani 132


Architecture n-tier par l’exemple

Exemple en Java : Vue réactive

Koffi SANI | @koffisani 133


Architecture n-tier par l’exemple

Exemple en Java : Lanceur

http://baptiste-wicht.developpez.com/tutoriels/conception/mvc/

Koffi SANI | @koffisani 134


Architecture n-tier par l’exemple

Exemple en Java : Classes UML

Koffi SANI | @koffisani 135


Architecture n-tier par l’exemple

Exemple en Java : Reverse engineering

Koffi SANI | @koffisani 136


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 DAO Système de stockage

Koffi SANI | @koffisani 137


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

Koffi SANI | @koffisani 138


Architecture n-tier par l’exemple

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

Koffi SANI | @koffisani 139


Architecture n-tier par l’exemple

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

Koffi SANI | @koffisani 140


Architecture n-tier par l’exemple

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

Koffi SANI | @koffisani 141


Architecture n-tier par l’exemple

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

Koffi SANI | @koffisani 142


Architecture n-tier par l’exemple

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

Koffi SANI | @koffisani 143


Architecture n-tier par l’exemple

Koffi SANI | @koffisani 144


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.

Koffi SANI | @koffisani 145


Comment ça se passera ?

LES DESIGN PATTERN POUR


DECOUPLER LES COUCHES

Koffi SANI | @koffisani 146


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

Koffi SANI | @koffisani 147


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.
Koffi SANI | @koffisani 148
Quelques Design Patterns

Pattern « Delegate »

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

Koffi SANI | @koffisani 149


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).

Koffi SANI | @koffisani 150


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).

Koffi SANI | @koffisani 151


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

Koffi SANI | @koffisani 152


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, …)

Koffi SANI | @koffisani 153


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, …)

Koffi SANI | @koffisani 154


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
Koffi SANI | @koffisani 155
@koffisani
me@koffisani.ga
http://code.koffisani.ga