ARCHITECTURE

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

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

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)
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
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
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.
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.
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.
Applications sur site central : (suite)
Présentation
Traitements
Terminal passif
Données
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
Applications sur site central : inconvénients
Fortement démodé par les interfaces utilisateur Windows-

Mac
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é.
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
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.
Applications un-tier déployé
Solution réservée à des applications non critiques

exploitées par de petits groupes de travail.
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
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

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

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
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…
Diagramme de packages (fin)

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.
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).
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.
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.
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.
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.
Composants et interfaces - notation

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.
Composants et interfaces – notation (fin)

Composants – Vue de la structure interne

Il est parfois utile de pouvoir montrer la structure interne
d’un composant.
Construction d’un diagramme de composants
• Diviser pour mieux régner

• Cohésion forte
• Faible couplage
• Abstraction
• Réutilisabilité
• Réutilisation
• Etc.
Diagramme de déploiement
Diagramme de déploiement : exemple 1

Diagramme de déploiement : exemple

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

Rappel sur le pattern Observer : Solution

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 ()
().
Pattern Observer en Java : exemple
import java.util.Observable; 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; }
}
import java.util.Observer;
public void update
import java.util.Observable;
(Observable obs, Object
public class TextObserver implements
obj)
Observer
{
{
if (obs == ov){
private ObservableObject ov = null;
System.out.println(ov.getValue(
public TextObserver
));
(ObservableObject ov)
}
{
}
this.ov = ov;
}
}

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();
}
}
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 »
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
Pattern Observer en action : la conception

La conception vise à produire :
• L’architecture;
• Les classes;
• Les données.
Pattern Observer en action : l’analyse

Choix d’architecture
Pattern Observer en action : la conception (1)

Les couches logicielles :

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

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

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

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

Exemple en Java
• Une vue listant les différents volumes et qui
ajoutera chaque nouveau volume dans une
liste déroulante : JFrameListVolume
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
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
Exemple en Java : Modèle

Exemple en Java : Modèle observable

Exemple en Java : Evénements

Exemple en Java : Vue abstraite à l’écoute

Exemple en Java : Contrôleur

Exemple en Java : Vue réactive et active

Exemple en Java : Vue réactive

Exemple en Java : Lanceur
http://baptiste-wicht.developpez.com/tutoriels/conception/mvc/
Exemple en Java : Classes UML

Exemple en Java : Reverse engineering

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
Accès aux données : Le Pattern DAO – Exemple

• Soit des étudiants qu’on veut manipuler dans
une application





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

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.
• Peut être utilisé en relation 1:1 avec le pattern

Facade.
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).
• 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).
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
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, …)
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, …)
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

ARCHITECTURE

Transféré par

ARCHITECTURE

Transféré par

Institut Africain d’Informatique

Etablissement Inter-Etats d’Enseignement Supérieur

IT Engineer | CTO @ ISPACE Corp. |

L’architecture logicielle est la structure des

Les composants logiciels

Les relations entre ces composants

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

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

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

La description des composants utilisés pour implanter les

Pourquoi développer une architecture logicielle ?

Pour préparer les extensions du système

Pour faciliter la réutilisation et la réutilisabilité

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

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

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

Les trois niveaux d’abstraction d’une application :

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

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

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

Logique des données

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

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

Des applications sur site central

Des applications réparties sur des machines

Applications sur site central : description

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

Applications sur site central : (suite)

Applications sur site central : avantages

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

Utilisation optimale des ressources due à la centralisation

Applications sur site central : inconvénients

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

Applications un-tier déployé : description

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

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

Applications un-tier déployé : avantages

Mise en œuvre envisageable dans un environnement

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

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

Conflits lors de la consultation et la modification

Applications un-tier déployé

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

Nécessité de trouver une solution conciliant :

L’interface utilisateur moderne des applications sur

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

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

Ex: application de gestion sur Windows utilisant un SGBD

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

On distingue deux intervenants :

Le middleware: définition et description

Le middleware : services rendus

Adressage : Permet d'identifier la machine serveur sur

Le middleware : services rendus (suite)

Communication : Permet la transmission des messages

Limites de l’architecture 2-tier

Impossible de soulager le client qui supporte l’ensemble

Limites de l’architecture 2-tier (suite)

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

Limites de l’architecture 2-tier (fin)

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

Avantages de l’architecture 2-tier

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

elle a permis l'appropriation des applications par

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

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

LES ARCHITECTURES DISTRIBUEES

Architecture 3-tier: objectifs

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

Architecture 3-tier: objectifs (suite et fin)

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