Architecture N-Tiers

indépendants manipulant les mêmes données peut devenir instable: • Possibilité d’avoir des conflits lors de la consultation ou de la

modification simultanée d'un même enregistrement par plusieurs utilisateurs.

• Les conflits peuvent altérer l'intégrité des données. • Il est difficile d'assurer la confidentialité des données.

19

Architecture 1 tiers

Architecture d'une application sur site central

20

Architecture 1 tiers

• Avantages:

• Grande facilité d'administration • Haute disponibilité. • La centralisation de la puissance sur une seule et même machine

permet une utilisation optimale des ressources

21

Architecture 1 tiers

• Inconvénients

• L’augmentation du nombre d’utilisateurs pose des problèmes de

gestion des conflits d'accès aux données ou la modification simultanée d'un même enregistrement par plusieurs utilisateurs. Ces conflits peuvent altérer l'intégrité des données

• L’explosion de la volumétrie des données rend leur gestion

difficile

• il est difficile d'assurer la confidentialité des données • En regroupant tous les traitements on groupe également toutes

les sources d'erreur

• Ce type de solution est donc à réserver à des applications non

critiques exploitées par de petits groupes de travail (une dizaine de personnes au maximum).

22

Architecture 1 tiers

• Solution • Trouver une solution regroupant :

• La fiabilité de l’application sur site central, qui gèrent les données

de façon centralisée,

• L'interface utilisateur moderne des applications sur différents

ordinateurs.

• Il est nécessaire de scinder l’application en plusieurs

parties distinctes et coopérantes : • Gestion centralisée des données • Gestion locale de l'interface utilisateur

Naissance du concept du client/serveur.

23

ARCHITECTURES CLIENT-SERVEUR

24

Architecture client-serveur

• Dans le cas d'un système reparti, l'application est divisée en plusieurs morceaux où chaque morceau joue un rôle différent pour les traitements du SI.

• L'environnement client-serveur désigne un mode de

communication à travers un réseau entre plusieurs programmes ou logiciels : l'un, qualifié de client, envoie des requêtes ; l'autre ou les autres, qualifiés de serveurs, attendent les requêtes des clients et y répondent.

25

Architecture client-serveur

• Le modèle client-serveur met en oeuvre 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.

• Dans une conversation client-serveur, on distingue donc les

deux parties suivantes : • Le client, c'est le programme qui provoque le dialogue, • Le serveur, c'est le programme qui se contente de répondre au

client.

26

Types de clients

• Client lourd (fat client): désigne une application cliente graphique exécutée sur le système d'exploitation de l'utilisateur. Un client lourd possède généralement des capacités de traitement évoluées et peut posséder une interface graphique sophistiquée. Néanmoins, ceci demande un effort de développement et tend à mêler la logique de présentation (l'interface graphique) avec la logique applicative (les traitements).

• Client leger (thin client): ne prend en charge que la

présentation de l'application avec, éventuellement, une partie de logique applicative permettant une vérification immédiate de la saisie et la mise en forme des données. Il est souvent constitué d'un simple navigateur web.

27

Types de clients

• Les clients lourds sont des logiciels destinés à être installés

localement sur une machine en opposition aux clients légers qui s'exécutent par exemple dans un navigateur internet, mais nécessitent un serveur.

• À titre indicatif, Google Maps constitue un client léger

puisque tout s’exécute sur un serveur et est affiché dans votre navigateur internet.

• Google Earth est pour sa part un client lourd puisqu’une

version doit être installée manuellement sur votre ordinateur.

28

Couplage

• Le couplage est une métrique indiquant le niveau d'interaction

et de dépendance entre deux ou plusieurs composants logiciels (fonctions, modules, objets ou applications). • Deux composants sont dits couplés s'ils échangent de

l'information et sont dépendants l’un de l’autre.

• Couplage fort: si les composants échangent beaucoup

d'information. • On ne peut pas déterminer le qui, le quoi et le comment d’une modification de données donc ça pose des problèmes lors du développement et la maintenance. A éviter autant que possible • Exemple: Architecture « peer-to-peer » (tous les processus ont le

même rôle)

29

Couplage

• Couplage faible: si les composants échangent peu

d'information. • Pas d’inter-dépendance entre les composants de l’application • Permet de maîtriser la complexité de l’architecture pour le

développement, le test et la maintenance

• Exemples: Architectures 3-tiers, n-tiers

• Couplage très faible: Les composants sont remplaçables, conçus en indépendance, avec des technologies diverses • Un composant est facilement remplaçable par un autre rendant

les mêmes services

• La construction par assemblage permet de faciliter la

maintenance

• Exemple: architecture orientée services

30

Architecture client-serveur

• Le modèle client-serveur mono-serveur

• les clients demandent des services en mode « message » • le serveur connecté offre le service demandé. Si le service

demandé n’est pas local, le serveur demande à son tour le service en question en mode « message ». Dans ce cas, le serveur devient un client.

31

Architecture client-serveur

• Le modèle client-serveur multi-serveur • les clients demandent un service en mode « message » • un service est assuré par un serveur ou par multi-serveurs

32

Architecture client-serveur

• Le client est le programme qui demande l’utilisation des

ressources d’un serveur

• Par extension, le client désigne également l'ordinateur sur

lequel est exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur.

• En général:

• Les serveurs sont des ordinateurs dédiés au logiciel serveur qu'ils

abritent, et dotés de capacités supérieures à celles des ordinateurs personnels en ce qui concerne la puissance de calcul, les entrées- sorties et les connexions réseau.

• Les clients sont souvent des ordinateurs personnels ou des appareils individuels (téléphone, tablette), mais pas systématiquement. Un serveur peut répondre aux requêtes d'un grand nombre de clients.

33

Architecture client-serveur

• Il existe une grande variété de logiciels serveurs et de logiciels

clients en fonction des besoins à servir : • un serveur web publie des pages web demandées par

des navigateurs web

• un serveur de messagerie électronique envoie des mails à des clients

de messagerie

• un serveur de fichiers permet de stocker et consulter des fichiers sur

le réseau

• Le client et le serveur doivent bien sûr utiliser le même protocole de communication au niveau de la couche transport du modèle OSI. Un serveur est généralement capable de servir plusieurs clients simultanément.

34

Middleware

• Définition • Le dialogue entre le client et le serveur s’effectue à l’aide d’un

ensemble de mécanismes assurant la communication

• On appelle intergiciel ou middleware, littéralement « élément

du milieu», un logiciel servant d'intermédiaire de communication entre plusieurs applications, généralement complexes ou distribuées sur un réseau informatique.

• Les composants logiciels du middleware assurent la

communication entre les applications quels que soient les ordinateurs impliqués et quelles que soient les caractéristiques matérielles et logicielles des réseaux informatiques, des protocoles réseau, des systèmes d'exploitation impliqués.

35

Middleware

• Pour former une application à part entière les tiers doivent être reliés entre eux. Les différents serveurs sont regroupés par un réseau. Afin d'effectuer la liaison entre les différentes parties du logiciel tout en rendant le réseau et les systèmes d’exploitation des différents machines transparents aux utilisateurs, on utilise un middleware.

• Le terme middleware est utilisé pour décrire des logiciels qui

servent de colle entre les deux applications.

• Il peut être ressemblé à la plomberie parce qu'il relie deux

côtés d'une application et transmet les données entre elles.

36

Middleware

• Objectif:

• Unifier, pour les applications, l'accès et la manipulation de

l'ensemble des services disponibles sur le réseau, afin de rendre l'utilisation de ces derniers transparente

• Offre des API (Application Programming Interface) de haut niveau

• Permettant de masquer la complexité des échanges inter-

applications

• Facilite le développement d'une application client-serveur

37

Middleware

Services • Un middleware rend les services suivants:

• Conversion : Service utilisé pour la communication entre machines

mettant en oeuvre 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. • 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.

• Le middleware masque la complexité des échanges inter-

applications. Sans ce mécanisme, la programmation d'une application client-serveur serait extrêmement complexe et rigide.

38

Middleware

Exemples de middleware • Les middleware qui lient un système de base de données à un

serveur Web. Cela permet aux utilisateurs de demander les données de la base de données en utilisant des formulaires affichées sur un navigateur Web.

• Le middleware permet au serveur Web de retourner des pages Web dynamiques basées sur les demandes et le profil de l'utilisateur: • SQL*Net : Interface propriétaire permettant de faire dialoguer une application cliente avec une base de données Oracle. Ce dialogue peut aussi bien être le passage de requêtes SQL que l'appel de procédures stockées.

• ODBC (Open DataBase Connectivity): Indépendant d ’un SGBD.

Interface standardisée isolant l’application informatique du serveur de données. Il est mis en œuvre par Microsoft pour les systèmes d'exploitation Windows, Unix et la plateforme Java.

• API JDBC: de Java avec des drivers écrits en Java

39

Middleware

Exemples de middleware • Le middleware joue un grand rôle dans la structuration du

système d'information.

• Les middleware proposés par les fournisseurs de SGBD sont très performants et permettent de tirer profit de l'ensemble des fonctionnalités du serveur de données pour lequel ils ont été conçus. Par contre, ils ne permettent pas, le plus souvent, l'accès à d'autres sources de données.

40

Middleware

Types de middleware • On distingue en général trois types de middleware différents:

• Les middlewares orientés message ou MOM • Les middlewares orienté transaction ou MOT • Les middlewares orientés objet ou MOO

41

Middleware

• Le MOM • Il permet d'échanger des messages entre un client et un serveur au moyen d’une file d'attente de messages. Les applications communiquent sur le réseau en disposant et en retirant des messages dans des files d'attentes.

• C'est un middleware qui fait abstraction de la couche

communication. Il autorise des exécutions désynchronisées des applications et n'impose pas de connexions instantanée entre elles. Une file d'attente reçoit le message de l'application émettrice et le stocke jusqu'à ce que l'application réceptrice vienne lire le message.

• Ce type de middleware est particulièrement adaptés aux

situations où une connexion entre client et serveur n'est pas souhaitable pour des raisons de sécurité ou d'efficacité.

42

Middleware

• Le MOM • Ils offrent deux modes de communications:

1.

2.

Le modèle point à point: une application produit des messages et une application les consomme. Les messages ne sont lus que par un seul consommateur. Une fois qu'un message est lu, il est retiré de la file d'attente. Le modèle Publish & Subscribe: un sujet est associé à chaque message. L’emetteur transmet le message à un agent intermédiaire. Les serveurs sont abonnées auprès de cet agent en fonction des sujets qui les intéresse. L'agent transmet le message à tous les serveurs "intéressés" par le sujet.

• Avec ce type de middleware les applications transmettent les

messages à des destinations, qui sont des files d'attente. Elles n'ont pas connaissance de la localisation physique de ces destinations ni des noms des applications. Un message peut être transmis à plusieurs destinataires.

• Plusieurs MOM existent sur le marché comme MQSeries d'IBM ou

MessageQ de BEA.

43

Middleware

• Le MOT • On appelle transaction ou unité de travail une suite d'actions qui changent l'état d’un système d’une manière contrôlée. • Il n'y a pas de demi-mesure, soit le travail a été effectué soit

non.

• Si pour une raison quelconque la transaction n'a pu se

terminer, on replace le système dans son état de départ.

• Une transaction a un début et une fin que l'on doit

obligatoirement atteindre pour que les modifications soient validées.

• Un MOT prend en charge l’exécution d'une application et la vérification de son bon fonctionnement en intégrant des mécanismes transactionnels.

44

Middleware

• Le MOT • Les MOT permettent au programmeur de ne pas s'occuper des

problèmes de simultanéités d'accès, de défaillance du système, de ruptures de connexions.

• Ils fournissent le moteur pour faire tourner les applications au

dessus des systèmes d’exploitation et du matériel.

• Ils assurent une cohérence transactionnelles et facilitent le

découpage des applications en services.

• Il existe différents moniteurs transactionnels comme Tuxedo

de BEA ou CIS d'IBM

45

Middleware

• Le MOO • Pour permettre à différentes applications de communiquer

entre elles, il faut des règles et des formats communs d'appels de services: ils sont assurés par les MOO.

• Les MOO permettent aux différents objets de communiquer

entre eux car les composants peuvent être de nature différentes, sur des machines différentes, ayant des systèmes d’exploitation différents.

• Ils peuvent aussi avoir été conçu dans des langages différents. • Ils existent trois modèles de composants objets qui sont

complémentaires et interopérable. Il s'agit du modèle CORBA, des composant Java EJB et enfin de DCOM de Microsoft.

46

Le modèle de Gartner Group

Fig. Les différents types de client-serveur selon la classification du Gartner Group

* Le trait horizontal représente le réseau

47

Le modèle de Gartner Group

• Présentation distribuée : Partie présentation est partagée par le client et le serveur. Tout le reste est attribué au serveur.

• La classification « client-serveur » de ce type

est souvent jugée abusive, du fait que l'intégralité des traitements originaux est conservée et que le poste client conserve une position d'esclave par rapport au serveur.

48

Le modèle de Gartner Group

• Présentation distante : Encore appelée

client-serveur de présentation. L'ensemble des traitements est exécuté par le serveur, le client ne prend en charge que l'affichage.

• Ce type d'application présentait jusqu'à présent l'inconvénient de ne permettre aucune répartition de la charge entre client et serveur.

49

Le modèle de Gartner Group

• Gestion distante des données : Correspond au client-serveur de données, sans doute le type de client-serveur le plus répandu.

• L'application fonctionne dans sa totalité sur le client, la gestion des données et le contrôle de leur intégrité sont assurés par un SGBD centralisé.

• Cette architecture, de part sa souplesse,

s'adapte très bien aux applications interrogeant souvent la base de données. Il ne soulage pas énormément le poste client, qui réalise encore la grande majorité des traitements.

50

Le modèle de Gartner Group

• Traitement distribué : Correspond au client- serveur de traitements. Les traitements sont distribués entre le client et le serveur. • Il s'appuie sur un mécanisme d'appel de

procédure distante, et la notion de procédure stockée proposée par les principaux SGBD du marché.

• Cette architecture permet d'optimiser la

répartition de la charge de traitement entre machines et limite le trafic réseau.

• Par contre il n'offre pas la même souplesse que

le client/serveur de données puisque les traitements doivent être connus du serveur à l'avance.

51

Le modèle de Gartner Group

• Bases de données distribuées : Il s'agit d'une variante du client-serveur de données dans laquelle une partie de données est prise en charge par le client.

• Ce modèle est intéressant si l'application doit gérer de gros volumes de données, si l'on souhaite disposer de temps d'accès très rapides sur certaines données ou pour répondre à de fortes contraintes de confidentialité.

• Ce modèle est aussi puissant que complexe à

mettre en œuvre.

52

Le modèle de Gartner Group

• Données et traitements distribués: répartir la charge des données et des traitements entre le client et le serveur.

• Ce modèle est très puissant et tire partie de la notion de composants réutilisables et distribuables pour répartir au mieux la charge entre client et serveur.

• C'est, bien entendu, l'architecture la plus

complexe à mettre en œuvre.

53

Le modèle de Gartner Group

• Les solutions que nous venons de détailler sont

indépendantes les unes des autres

• Prises individuellement, on peut dire que les deux premières solutions proposées ne correspondent pas à des applications client-serveur. (Les traitements et la gestion des données sont réalisées par le serveur)

• En effet, la présentation distribuée ne considère pas le client en tant que tel et ce dernier reste dans une position d'esclave par rapport au serveur.

• La première solution à mettre en œuvre une relation client- serveur se retrouve au troisième niveau et correspond au client-serveur de données.

• Ce type d'application, encore appelé client-serveur de

première génération, met en œuvre une architecture 2-tiers.

54

Architecture 2 tiers

• Dans une architecture deux tiers, encore appelée client-

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

• Le cas typique de cette architecture est l'application de

gestion fonctionnant sous Ms-Windows et exploitant un SGBD centralisé s'exécutant le plus souvent sur un serveur dédié pour la gestion des données

55

Architecture 2 tiers

56

Architecture 2 tiers

• Ce dernier est interrogé en utilisant un langage de requête qui, le plus souvent, est 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. Ce dialogue nécessite l'instauration d'une communication entre client et serveur. • Ce type d'application permet de tirer profit de la puissance

des ordinateurs déployés en réseau pour fournir à l'utilisateur une interface riche, tout en garantissant la cohérence des données, qui restent gérées de façon centralisée.

57

Architecture 2 tiers

• Le client provoque l'établissement d'une conversation afin de d'obtenir des données ou un résultat de la part du serveur.

• Cet échange de messages transite à travers le réseau reliant

les deux machines. Il met en œuvre des mécanismes relativement complexes qui sont, en général, pris en charge par un middleware.

58

Architecture 2 tiers

Avantages: • Maintenance et administration du serveur simplifiées • Souplesse : possibilité d’ajouter/suprimer dynamiquement des

clients sans perturber le fonctionnement de l’application

• Les ressources sont centralisées sur le serveur • Sécurisation simple des données : un seul point d’entrée • Pas de problème d’intégrité/cohérence des données Limitations: • On ne peut pas soulager la charge du poste client, qui

supporte la grande majorité des traitements applicatifs (client lourd)

• Coût élevé : le serveur doit être très performant pour honorer

tous les clients

59

Architecture 2 tiers

• Exemples d’ applications du système client-serveur • Opération transactionnelle par OLTP (On Line Transaction Processing): Elle permet d’effectuer une transaction, une transaction bancaire par exemple. Les principales composants sont des accès à la base de données, des traitements et des modifications et des affichages en mode graphique.

• Aide à la décision par DS (Decision Support), la gestion des lignes Air France, par exemple. Les principales composants sont des accès à BD, des traitements de synthèse et de décision et des affichages.

• ….

60

Architecture 2-tiers

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

• La solution résiderait donc dans l'utilisation d'un poste client

simple communicant avec le serveur par le biais d'un protocole standard.

• Dans ce but, l'architecture trois tiers applique les principes

suivants : • la présentation est toujours prise en charge par le poste client, • la logique applicative est prise en charge par un serveur

intermédiaire.

• les données sont toujours gérées de façon centralisée,

61

Architecture 3 tiers

L'architecture trois tiers, encore appelée client-serveur de deuxième génération ou client-serveur distribué, sépare l'application en trois niveaux de service distincts

• Présentation: chargé du traitement de l'interaction avec

l'utilisateur. C'est un rôle d'affichage et d'interaction (fenêtres, formulaires, pages Web, etc.)

• Applicative/métier: Comporte tous les objets de contrôle et

d’entités nécessaires pour faire les traitements, la vérification des règles etc. (le coeur de l’application)

• Persistance/données: réalise le stockage, la récupération et la

recherche des données de l’entreprise ou l’application.

62

Architecture 3 tiers

63

Architecture 3 tiers

• Présentation:

• De plus en plus mince, i.e., le client

ne fait qu’afficher un contenu HTML

• La logique métier

• Créer les pages Web à afficher pour

le client

• Gérer les dossiers des clients

• Persistance

• Le base de données des clients

64

Architecture 3 tiers

• Tous ces niveaux étant indépendants, ils peuvent être implantés sur des machines différentes, de ce fait : • le poste client ne supporte plus l'ensemble des traitements, il est moins sollicité et peut être moins évolué, donc moins coûteux, • le poste client est communément un client léger, par opposition

au client lourd des architectures deux tiers.

• la fiabilité et les performances de certains traitements se

trouvent améliorées par leur centralisation,

• le découplage logique applicative/interface permet de changer ou d’avoir plusieurs interfaces utilisateur sans toucher à l’application elle-même.

65

Architecture 3 tiers

• Cette séparation par couches de responsabilités sert à découpler au maximum une couche de l'autre afin d'éviter l'impact d'évolutions futures de l'application.

• Par exemple : si l’on est amené à devoir changer de base de données relationnelle, seule la couche d'accès aux données sera impactée, la couche métier et la couche de présentation ne seront pas concernées car elles auront été découplées des autres.

66

Architecture 3 tiers

67

Architecture 3 tiers: Exemple 2

PHP/MySql

68

Répartition des traitements

• L'architecture 3-tiers sépare l'application en trois niveaux de

service distincts :

• premier niveau : l'affichage et les traitements locaux

(contrôles de saisie, mise en forme de données... ) sont pris en charge par le poste client

• deuxième niveau : les traitements applicatifs globaux sont pris

en charge par le service applicatif : Serveur d’application • troisième niveau : les services de base de données sont pris

en charge par un SGBD: Serveur de données

69

Architecture 3 tiers: Exemple 2

70

Tiers Présentation

• Correspond à la partie de l’application visible et interactive avec les utilisateurs. On parle d’IHM. Elle peut être réalisée par une application graphique ou textuelle.

• La couche présentation relaie les requêtes de l'utilisateur à destination de la couche métier, et en retour présente à l’utilisateur les informations renvoyées par les traitements de cette couche

• Cette interface peut prendre de multiples facettes sans changer la finalité de l'application: Le déploiement est immédiat, les évolutions peuvent être transparentes pour l'utilisateur et les caractéristiques du poste client sont libres.

71

Tiers Présentation

• Exemples:

• Dans le cas d'un système de distributeurs de billets, l'automate

peut être différent d'une banque à l'autre, mais les fonctionnalités offertes sont similaires et les services identiques (fournir des billets, donner un extrait de compte, etc.).

• Une même fonctionnalité métier (par exemple, la commande d'un nouveau chéquier) pourra prendre différentes formes de présentation selon qu'elle se déroule sur Internet, sur un distributeur automatique de billets ou sur l'écran d'un chargé de clientèle en agence.

72

Tiers métier

• Correspond à la partie fonctionnelle de l’application, celle qui implémente la « logique », et qui décrit les opérations sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation.

• Les différentes règles de gestion et de contrôle du système

sont mises en oeuvre dans cette couche: fonctions d’administration, sécurité, gestion des composants etc. • Elle renvoie à la couche présentation les résultats qu'elle a

calculés.

73

Tiers métier

• Le serveur d'application est l'environnement d'exécution des

applications côté serveur.

• Il prend en charge l'ensemble des fonctionnalités de

l’application

• Le serveur d’application se retrouve dans la position du poste

client d'une application 2-tiers

• La communication avec le SGBD met en oeuvre les

mécanismes des applications client-serveur de données.

74

Tiers métier

Le serveur d'application assure les fonctions suivantes: • Gestion de la session utilisateur : conserver des contextes propres à chaque utilisateur (par exemple, un panier de commandes).

• Gestion des montées en charge et reprise sur incident : se

déployer sur plusieurs machines clientes et éventuellement offrir des possibilités de reprise sur incident

• Accès à des multiples sources de données : rendre accessible les données des applications du système d'information. Il doit donc pouvoir accéder à de nombreuses sources de données.

75

Tiers métier

• Le serveur d’application agit comme middleware entre les systèmes

d’information de l’entreprise et des clients qui accèdent à ces données.

• Le code métier est stocké sur le serveur d’application, et est déployé

et géré de manière centralisée.

• L’application peut être rendue accessible à un très grand nombre de

clients hétérogènes Exemples d’implantations • Apache Tomcat • Sun Java System Application Server, • GlassFish • Jboss • IBM WebSphere • JOnAS (Bull, France Télécom, Inria) • et d’autres. .

76

Tiers données

• C’est la partie gérant l'accès aux données du système. • Ces données peuvent être propres au système, ou gérées par

un autre système.

• La couche métier n'a pas à s'adapter à ces deux cas, ils sont

transparents pour elle, et elle accède aux données de manière uniforme, on dit qu’il y a un faible couplage.

Données propres au système • Ces données sont durables, car destinées à durer dans le temps, de manière plus ou moins longue, voire définitive. • Les données peuvent être stockées indifféremment dans de simples fichiers texte, fichiers XML, ou encore dans un SGBD

• Quel que soit le support de stockage choisi, l'accès aux

données doit être le même. Cette abstraction améliore la maintenance du système.

77

Tiers données

Données gérées par un autre système • Les données peuvent aussi être gérées de manière externe. • Elles ne sont pas stockées par le système considéré, il s'appuie sur la capacité d'un autre système à fournir ces informations. • Celle-ci est indépendant et pré-existant, et on ne se préoccupe

pas de savoir comment il obtient les résultats ou si il les sauvegarde. On utilise simplement sa capacité à fournir des données à jo