Mise en place d'un systeme d'information pour la gestion des expatriés du bas Congo

CHAPITRE I : CONCEPTS THEORIQUES

Ce chapitre est consacré à la revue des principaux concepts utilisés dans ce Mémoire. Il s'agit, en effet, d'éclairer nos lecteurs sur la signification des concepts de base en vue de leur permettre une compréhension du contenu de ce dernier.

I.1. SYSTEME INFORMATIQUE

I.1.1. Système

Un système est un ensemble d'éléments en interaction dynamique, organisés en fonction d'un but^5(*) .

I.1.2. Composition d'un Système

o Système de pilotage (SP) ;

o Système d'information (SI) ;

o Système opérant (SO).

I.1.3. Structure d'un Système

Système de pilotage

Système d'information

Système Opérant

Figure 1 : structure d'un système

N.B : l'environnement d'un système est l'univers auquel il appartient.

La Direction général de Migration de Matadi représente le système et son environnement, ce sont la division de la police des Etrangers, de frontières, la division de chancellerie et la division de finances. Qui sont en interaction pour un but qui est la gestion des expatriés.

I.1.4. Information

L'information est une ressource précieuse pour l'entreprise, au même titre que le capital ou les matières premières. Rares sont les entreprises où n'importe qui peut avoir accès aux réserves de capital ou de matières premières. On aurait intérêt à en faire autant pour l'information ; elle devrait être protégée, et son accès limité aux seules personnes autorisées^6(*).

Ainsi, une bonne information est celle qui permet la prise de décision et qui accroît l'efficacité dans le travail. Dans une entreprise, les imprimés constituent le véhicule principal de l'information et l'ensemble de ces imprimés constitue, à côté des informations stockées sur des supports électroniques et magnétiques, une documentation de référence non négligeable.

I.2 .Base de Données

Une base de données, usuellement abrégée BD ou BDD, est un ensemble structuré et organisé permettant le stockage de grandes quantités d'informations afin d'en faciliter l'exploitation (ajout, mise à jour, recherche de données,...)

Une base des données permet donc de stocker, classer, retrouver des données, et de réaliser des calculs sur ces données. Généralement, une base de données est contrôlée par un système de gestion permettant d'effectuer la recherche, le tri ou la fusion de données, ainsi que toute autre requête relative à ces données.

Une base de données est un ensemble de données organisées logiquement de façon à faciliter l'analyse et produire des rapports^7(*)

Parmi les systèmes de gestion de bases de données (SGBD), les plus courants sont ceux associés aux bases de données relationnelles, où l'information est rangée dans des fichiers, sous forme de tables composées de lignes et de colonnes. Les lignes représentent les enregistrements (ensembles d'informations relatives à des rubriques séparées), tandis que les colonnes correspondent aux champs (attributs spécifiques à un enregistrement).

Alors que Oracle ou SQL Server sont destinés à de grosses entreprises gérants énormément de données et où plusieurs utilisateurs doivent accéder simultanément aux bases, Access lui, résolument plus petit et simple d'utilisation est plutôt destiné aux professionnels et petites entreprises^8(*).

Lorsque l'on décide de créer une base de données relationnelle, il faut surtout veiller à définir clairement ses caractéristiques. Les données du problème doivent être énoncées avec précision et décidées en amont selon les besoins à traiter, la réalisation et l'installation de la base de données s'avérant alors beaucoup plus souples. En effet, une erreur de conception pourrait en générer d'autres biens plus graves lors de l'installation de la base, allant parfois même jusqu'à la perte de certaines données.

C'est pourquoi des Langage et méthodes de conception de bases de données ont été mises au point afin d'éviter des fautes.

I.3. Présentation et Justification du Choix d'UML

I.3.1. Définition

Unified Modeling Language est un langage unifié de modélisation objets. Ce n'est pas une méthode, il ne donne pas de solution pour la mise en oeuvre d'un projet^9(*). C'est avant tout un formalisme graphique issu de notations employées dans différentes méthodes objets.

I.3.2. Historique

UML est le résultat de la fusion de trois de méthodes d'analyse orientées objet : OOD, OMT et OOSE. La méthode OOD, Object Oriented Design, de G.Booch a été conçue à la demande du Ministère de la Défense des USA. L'objectif était de préparer de façon rigoureuse la structuration des programmes écrits en langage ADA ou C++.

La méthode OMT, Object Modeling Technique, a été mise au point à General Electric. Ses auteurs ont puisé leur inspiration d'une part dans les langages objets pour des applications d'informatique industrielle (automates, contrôle de processus...), d'autre part dans les techniques de modélisation conceptuelle des méthodes d'analyse des années 80.

OMT représente un système comme un assemblage d'éléments auxquels on attache des comportements, c'est-à-dire des opérations pouvant être déclenchées a la réception d'un message envoyé par d'autres composants.

La méthode OOSE, Object Oriented Software Engineering, est d'origine universitaire (informatique temps réel) et industrielle (Ericsson). Son originalité consiste à faire reposer l'analyse sur une expression par l'utilisateur de la façon dont il pense utiliser le futur système. Devant l'attentisme du marché face aux méthodes et aux AGL objets, la société Rational Software a réuni les auteurs principaux de ces trois méthodes pour qu'ils se mettent d'accord sur un langage de modélisation dans l'espoir qu'il devienne une référence. Sa réussite fut d'être retenue comme norme de modélisation par l'OMG, après avoir reçu le soutien de Plusieurs grands constructeurs informatiques et éditeurs de logiciels. Ce langage est passé par différents stades et est encore en évolution.

I.3.3. A quoi Sert UML

UML donne une définition sur une approche objet plus formelle et apporte la dimension logique à l'approche objet^10(*).

Pour concevoir en UML, il faut commencer par prendre de la hauteur par rapport au problème qui est posé et utiliser des concepts abstraits complètement indépendants des langages de programmation pour modéliser. L'utilisation d'un langage de programmation comme support de conception revient à faire une analyse peu précise et réductrice par rapport à une modélisation objet.

A l'inverse de la plupart des technologies objet, UML permet de s'affranchir totalement de tout langage de programmation (permettant ainsi l'écueil de la limitation de vue du langage de programmation) pour élaborer et exprimer des modèles objet. Il a été pensé comme support d'analyse objet.

De plus, UML est un méta modèle : il décrit très précisément tous les éléments de modélisation (permettant ainsi de limiter les ambiguïtés) et normalise les concepts objet. Étant un méta modèle, UML est valable pour tous les langages de programmation.

Les critères (ou qualités) d'UML sont les suivants :

Ø langage sans ambiguïté ;

Ø langage universel ;

Ø moyen de définir les structures de programmation,

Ø représentation universelle (communication performante),

Ø Notation graphique simple (compréhensible par tous et non pas seulement les informaticiens).

UML propose aussi une notation pour représenter graphiquement les éléments de modélisation du méta modèle, cette notation graphique est le support du langage UML. Ceci lui permet donc d'être visuellement plus compréhensible (pour comparer ou évaluer) et limite ainsi les ambiguïtés. Il offre un cadre avec différentes vues complémentaires du système sur plusieurs niveaux d'abstraction, les diagrammes, et contrôle ainsi que la complexité dans l'expression des solutions objets.

I.3.4. Modélisation Objet

UML permet de représenter des modèles, mais il ne définit pas de processus d'élaboration des modèles. Les auteurs d'UML conseillent tout de même une démarche pour favoriser la réussite d'un projet :^11(*)

Ø Une démarche itérative et incrémentale : pour comprendre et représenter un système complexe, pour analyser par étapes, pour favoriser le prototypage (pour réduire et maîtriser l'inconnu),

Ø une démarche guidée par les besoins des utilisateurs : tout est basé sur les besoins des utilisateurs du système. Chaque étape sera affinée et validée en fonction des besoins des utilisateurs.

Ø Une démarche centrée sur l'architecture logicielle : c'est la clé de voûte du succès d'un développement, les choix stratégiques définiront la qualité des logiciels.

UML s'est inspiré de la vue « 4+1 » définie par Ph. Kruchten, cette vue représente différentes perspectives indépendantes et complémentaires pour définir un modèle d'architecture.^12(*)

Figure2 : Vues d'UML

Ø La vue logique décrit les éléments, mécanismes et interactions du système. Cette vue organise les éléments en « catégories », c'est une vue de haut niveau.

Ø La vue des composants alloue des éléments de modélisation dans des modules (réalisant les classes de la vue logique) et crée les dépendances de ces modules. Cette vue est une vue de bas niveau.

Ø La vue des processus décompose le système en processus, en interactions (communication) et synchronisation entre eux.

Ø La vue de déploiement décrit les ressources matérielles et la répartition du logiciel dans ces ressources (disposition, nature physique, performance, implantation des modules principaux, temps de réponse, tolérance aux fautes et aux pannes, etc.).

Ø La vue des besoins utilisateurs (ou vue des cas d'utilisation ») est un guide pour toutes les autres vues : c'est la définition des besoins des clients du système et de l'architecture sur la satisfaction de ces besoins, la colle qui unifie les autres vues, et qui motive les choix, identifie les interfaces et force à se concentrer sur les besoins des utilisateurs.

I.3.4. Présentation des Diagrammes

UML s'articule autour de neuf diagrammes, chacun d'entre eux est dédié à la représentation d'un système logiciel suivant un point de vue particulier.

1. le diagramme de cas d'utilisation : représente les relations entre les acteurs et les fonctionnalités du système. Les cas d'utilisation présentent une vue externe de la façon d'utiliser un système, que ce soit l'application, un sous-système, une fonction, un composant^13(*).

2. le diagramme de séquence : représente les messages échangés entre les objets. Il donne une notion temporelle aux messages.

3. le diagramme d'activités décrit le déroulement d'un processus formalisé éventuellement dans un cas d'utilisation, il modélise les actions effectuées sur le système (peut permettre de présenter un processus métier).

4. le diagramme de classes : est un ensemble d'éléments statiques qui montre la structure d'un modèle (les classes, leur type, leur contenu et leurs relations).

5. le diagramme d'objets (objet : instance d'une classe) représente les objets et les liens entre eux. Il permet d'affiner un aspect particulier d'un diagramme de classes pour un contexte donné.

6. le diagramme de déploiement : indique la répartition physique des matériels du système (processeurs, périphériques) et leurs connexions.

7. le diagramme d'états/transitions : décrit le cycle de vie des objets formalisés dans une classe (une classe ne se voit donc associé qu'un cycle de vie).

8. le diagramme de composants : montre les éléments logiciels (exécutables, librairies, fichiers qui constituent le système) et leurs dépendances.

9. le diagramme de collaboration : représente les messages échangés entre les objets. Il insiste plus particulièrement sur la notion organisationnelle.

Nous présentons ci-dessous les diagrammes UML, que nous avons utilisés dans le cadre de ce projet et quelques notions de base qui leurs étant associées.

1. Diagramme de cas d'Utilisation

Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans l'analyse d'un système.

Les éléments de diagramme de cas d'utilisation

Ø Acteur : Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié.

Les relations entre cas d'utilisation :

Ø Relation d'inclusion : Une relation d'inclusion d'un cas d'utilisation A par rapport à un cas d'utilisation B signifie qu'une instance de A contient le comportement décrit dans B.

Ø Relation d'extension : Une relation d'extension d'un cas d'utilisation A par un cas d'utilisation A signifie qu'une instance de A peut être étendue par le comportement décrit dans B.

Ø Relation de généralisation : Les cas d'utilisation descendants héritent de la description de leurs parents communs. Chacun d'entre eux peut néanmoins comprendre des interactions spécifiques supplémentaires.

2. Diagramme de Séquence

Ce diagramme permet de décrire les scénarios de chaque cas d'utilisation en mettant l'accent sur la chronologie des opérations en interaction avec les objets.

Ø Scénario: Représente une succession particulière d'enchaînements, s'exécutant du début à la fin du cas d'utilisation, un enchaînement étant l'unité de description de séquences d'actions.

Ø Ligne de vie : Représente l'ensemble des opérations exécutées par un objet.

Ø Message: Un message est une transmission d'information unidirectionnelle entre deux objets, l'objet émetteur et l'objet récepteur. Dans un diagramme de séquence, deux types de messages peuvent être distingués :

Ø Message synchrone : Dans ce cas l'émetteur reste en attente de la réponse à son message avant de poursuivre ses actions.

Ø Message asynchrone : Dans ce cas, l'émetteur n'attend pas la réponse à son message, il poursuit l'exécution de ses opérations.

3. Diagramme d'Activités

Ce diagramme donne une vision des enchaînements des activités propres à une opération ou à un cas d'utilisation. Il permet aussi de représenter les flots de contrôle et les flots de données.

Ø Action : correspond à un traitement qui modifie l'état de système. L'enchaînement des actions constitue le flot de contrôle.

Le passage d'une action à une autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d'une action et provoquent le début d'une autre (elles sont automatiques).

Ø Activité : représente le comportement d'une partie du système en termes d'actions et de transitions.

4. Diagramme de Classe

Le diagramme de classes est le point central dans un développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure d'un code orienté.

Ø Une classe : Représente la description abstraite d'un ensemble d'objets possédant les mêmes caractéristiques. On peut parler également de type.

Ø Un objet: Est une entité aux frontières bien définies, possédant une identité et encapsulant un état et un comportement. Un objet est une instance (ou occurrence) d'une classe.

Ø Un attribut : Représente un type d'information contenu dans une classe.

Ø Une opération: Représente un élément de comportement (un service) contenu dans une classe.

Ø Une association: Représente une relation sémantique durable entre deux classes.

Ø Une superclasse : Est une classe plus générale reliée à une ou plusieurs autres classes plus spécialisées (sous-classes) par une relation de généralisation. Les sous-classes« Héritent » des propriétés de leur superclasse et peuvent comporter des propriétés spécifiques supplémentaires.

5. Diagramme de Déploiement

Ce diagramme décrit l'architecture technique d'un système avec une vue centrée sur la répartition des composants dans la configuration d'exploitation.

I.4. Le Processus Unifié (UP)

I.4.1. Définition

Pour définir le processus unifié, nous allons simplement définir les deux termes qui le composent :

Ø Processus : Suite continue d'opérations constituant la manière de fabriquer. En d'autres termes, c'est une succession de tâches dans le but d'accomplir un travail ou un projet.

Ø Unifié : Etre amené à l'unité, se fondre en un tout. En fait, les méthodes d'analyse et de conception orientées objet, étaient variées jusqu'à ce que Rambaugh, Jacobson et Booch eussent eu l'idée de les unifier.

I.4.2. Caractéristiques

D'après les auteurs d'UML, un processus de développement qui possède ces qualités devrait favoriser la réussite d'un projet. Cependant, dans le cadre de la modélisation d'une application informatique, les auteurs d'UML préconisent d'utiliser trois démarche :

Ø Itérative et incrémentale ;

Ø Guidée par les besoins des utilisateurs du système ;

Ø Centrée sur l'architecture logicielle.

I.4.3 Une démarche Itérative et Incrémentale

L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par étapes. Cette démarche devrait aussi s'appliquer au cycle de développement dans le but de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes complexes.

I.5. Une Démarche Pilotée par les Besoins des Utilisateurs

Avec UML, ce sont les utilisateurs qui guident la définition des modèles :

Ø Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce que doit être le système).

Ø Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système).

Ø Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de développement (itératif et incrémental) :

Ø A chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs.

Ø A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs.

Ø A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.

I.5.1. Une Démarche Centrée sur l'Architecture

Une architecture adaptée est la clé de voûte du succès d'un développement. Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité...). Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui permettent de définir un modèle d'architecture.

I.5.2. Cycle de vie du Processus

Le processus unifié se déroule en quatre phases, incubation, élaboration, construction et transition. Chaque phase répète un nombre de fois une série d'itérations. Et chaque itération est composée de cinq activités : capture des besoins, analyse, conception, implémentation et test.

Figure 3 : Cycle de la vie du processus UP

I.6. Incubation

C'est la première phase du processus unifié. Il s'agit de délimiter la portée du système, c'est-à-dire tracer ce qui doit figurer à l'intérieur du système et ce qui doit rester à l'extérieur, identifier les acteurs, lever les ambiguïtés sur les besoins et les exigences

Nécessaires dans cette phase. Il s'agit aussi d'établir une architecture candidate, c'est à dire que pour une première phase, on doit essayer de construire une architecture capable de fonctionner. Dans cette phase, il faut identifier les risques critiques susceptibles de faire obstacles au bon déroulement du projet.

I.6.1. Elaboration

C'est la deuxième phase du processus. Après avoir compris le système, dégagé les fonctionnalités initiales, précisé les risques critiques, le travail à accomplir maintenant consiste à stabiliser l'architecture du système. Il s'agit alors de raffiner le modèle initial de cas d'utilisation, voire capturer de nouveaux besoins, analyser et concevoir la majorité des cas d'utilisation formulés, et si possible implémenter et tester les cas d'utilisation initiaux.

I.6.2. Construction

Dans cette phase, il faut essayer de capturer tous les besoins restants car il n'est pratiquement plus possible de le faire dans la prochaine phase. Ensuite, continuer l'analyse, la conception et surtout l'implémentation de tous les cas d'utilisation. A la fin de cette phase, les développeurs doivent fournir une version exécutable du système.

I.6.3. Transition

C'est la phase qui finalise le produit. Il s'agit au cours de cette phase de vérifier si le système offre véritablement les services exigés par les utilisateurs, détecter les défaillances, combler les manques dans la documentation du logiciel et adapter le produit à l'environnement (mise en place et installation).

I.7. Réseau Informatique

I.7.1. Concepts Réseau

Un réseau : Est un ensemble d'objets interconnectés les uns avec les autres. Il permet de faire circuler des éléments entre chacun de ces objets selon des règles bien définies.

Un réseau extranet est un réseau du type internet, dont la liste de sécurité est externalisée c'est-à-dire gérée par un organisme ou une entité externe aux utilisateurs. Par opposition, pour un réseau intranet, la liste de sécurité est gérée en interne.

La liste de sécurité est l'ensemble des données regroupant les identifiants (nom d'utilisateur (login), adresse IP, adresses MAC, clefs logiques ou physiques) autorisés à se connecter.

Un intranet est un ensemble de services internet (par exemple un serveur web) interne à un réseau local, c'est-à-dire accessible uniquement à partir des postes d'un réseau local, ou bien d'un ensemble de réseaux bien définis, et invisible de l'extérieur. Il consiste à utiliser les standards client-serveur de l'internet (en utilisant les protocoles TCP/IP), comme par exemple l'utilisation de navigateurs internet (client basé sur le protocole HTTP) et des serveurs web (protocole HTTP), pour réaliser un système d'information interne à une organisation ou une entreprise^14(*).

I.7.2. Avantage d'un Réseau Informatique

Le réseau informatique permet :

Ø De Partager des fichiers, des applications et des ressources ;

Ø La communication entre plusieurs ordinateurs (des personnes grâce aux courriers électroniques, la discussion en temps réel) ;

Ø L'unicité de l'information ;

Ø L'accès aux données en temps utiles.

I.7.3. Type des Réseaux

On distingue différents types de réseaux (privés) selon leur taille (en termes de nombre de machines), leur vitesse de transfert des données ainsi que leur étendue. Les réseaux privés sont des réseaux appartenant à une même organisation. On distingue fait généralement trois catégories de réseaux:

§ LAN (Local Area Network)

§ MAN (Métropolitain Area Network)

§ WAN (Wide Area Network)

§ PAN (Personal Area Network)

1. Les réseaux personnels, ou PAN (Personal Area Network), interconnectent sur quelques mètres des équipements personnels tels que terminaux GSM, portables, organiseurs, etc., d'un même utilisateur ;

2. Les réseaux locaux, ou LAN (Local Area Network), correspondent par leur taille aux réseaux intra-entreprises. Ils servent au transport de toutes les informations numériques de l'entreprise. En règle générale, les bâtiments à câbler s'étendent sur plusieurs centaines de mètres. Les débits de ces réseaux vont aujourd'hui de quelques mégabits à plusieurs centaines de mégabits par seconde ;

3. Les réseaux métropolitains, ou MAN (Metropolitan Area Network), permettent l'interconnexion des entreprises ou éventuellement des particuliers sur un réseau spécialisé à haut débit qui est géré à l'échelle d'une métropole. Ils doivent être capables d'interconnecter les réseaux locaux des différentes entreprises pour leur donner la possibilité de dialoguer avec l'extérieur ;

4. Les réseaux étendus, ou WAN (Wide Area Network), sont destinés à transporter des données numériques sur des distances à l'échelle d'un pays, voire d'un continent ou de plusieurs continents. Le réseau est soit terrestre, et il utilise en ce cas des infrastructures au niveau du sol, essentiellement de grands réseaux de fibre optique, soit hertzien, comme les réseaux satellite.

· Topologies

Un réseau informatique est constitué d'ordinateurs reliés entre eux grâce à des lignes de communication (câbles réseaux, etc.) et des éléments matériels (cartes réseau, ainsi que d'autres équipements permettant d'assurer la bonne circulation des données). L'arrangement physique, c'est-à-dire la configuration spatiale du réseau est appelé topologie physique. On distingue généralement les topologies suivantes :

· topologie en bus

· topologie en étoile

· topologie en anneau

La topologie logique, par opposition à la topologie physique, représente la façon dont les données transitent dans les lignes de communication. Les topologies logiques les plus courantes sont Ethernet, Token Ring et FDDI.

1. Topologie en bus

Une topologie en bus est l'organisation la plus simple d'un réseau. En effet, dans une topologie en bus tous les ordinateurs sont reliés à une même ligne de transmission par l'intermédiaire de câble, généralement coaxial. Le mot « bus » désigne la ligne physique qui relie les machines du réseau.

Cette topologie a pour avantage d'être facile à mettre en oeuvre et de posséder un fonctionnement simple. En revanche, elle est extrêmement vulnérable étant donné que si l'une des connexions est défectueuse, l'ensemble du réseau en est affecté.

2. Topologie en étoile

Dans une topologie en étoile, les ordinateurs du réseau sont reliés à un système matériel central appelé concentrateur (en anglais hub).

Il s'agit d'une boîte comprenant un certain nombre de jonctions auxquelles il est possible de raccorder les câbles réseau en provenance des ordinateurs. Celui-ci a pour rôle d'assurer la communication entre les différentes jonctions.

Contrairement aux réseaux construits sur une topologie en bus, les réseaux suivant une topologie en étoile sont beaucoup moins vulnérables car une des connexions peut être débranchée sans paralyser le reste du réseau. Le point névralgique de ce réseau est le concentrateur, car sans lui plus aucune communication entre les ordinateurs du réseau n'est possible.

En revanche, un réseau à topologie en étoile est plus onéreux qu'un réseau à topologie en bus car un matériel supplémentaire est nécessaire (le hub).

3. Topologie en anneau

Dans un réseau possédant une topologie en anneau, les ordinateurs sont situés sur une boucle et communiquent chacun à leur tour.

En réalité, dans une topologie anneau, les ordinateurs ne sont pas reliés en boucle, mais sont reliés à un répartiteur (appelé MAU, Multistation Access Unit) qui va gérer la communication entre les ordinateurs qui lui sont reliés en impartissant à chacun d'entre eux un temps de parole.

Les deux principales topologies logiques utilisant cette topologie physique sont Token ring (anneau à jeton) et FDDI.

· Architectures

1. Client/Server

De nombreuses applications fonctionnent selon un environnement client/serveur, cela signifie que des machines clientes (des machines faisant partie du réseau) contactent un serveur, une machine généralement très puissante en termes de capacités d'entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que l'heure, des fichiers, une connexion,...

Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines clientes. On parle ainsi de client FTP, client de messagerie, ..., lorsque l'on désigne un programme, tournant sur une machine cliente, capable de traiter des informations qu'il récupère auprès du serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour le client messagerie il s'agit de courrier électronique).

Dans un environnement purement Client/serveur, les ordinateurs du réseau (les clients) ne peuvent voir que le serveur, c'est un des principaux atouts de ce modèle.

Avantages de l'architecture client/serveur

Le modèle client/serveur est particulièrement recommandé pour des réseaux nécessitant un grand niveau de fiabilité, ses principaux atouts sont:

des ressources centralisées: étant donné que le serveur est au centre du réseau, il peut gérer des ressources communes à tous les utilisateurs, comme par exemple une base de données centralisée, afin d'éviter les problèmes de redondance et de contradiction

une meilleure sécurité: car le nombre de points d'entrée permettant l'accès aux données est moins important

une administration au niveau serveur: les clients ayant peu d'importance dans ce modèle, ils ont moins besoin d'être administrés

un réseau évolutif: grâce à cette architecture il est possible de supprimer ou rajouter des clients sans perturber le fonctionnement du réseau et sans modifications majeures

Inconvénients du modèle client/serveur

L'architecture client/serveur a tout de même quelques lacunes parmi lesquelles:

un coût élevé dû à la technicité du serveur

un maillon faible: le serveur est le seul maillon faible du réseau client/serveur, étant donné que tout le réseau est architecturé autour de lui! Heureusement, le serveur a une grande tolérance aux pannes (notamment grâce au système RAID)

Fonctionnement d'un système client/serveur

Un système client/serveur fonctionne selon le schéma suivant:

Le client émet une requête vers le serveur grâce à son adresse et le port, qui désigne un service particulier du serveur

Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client et son port.

* ⁵ BALUMANGANI K., cous de conception des systèmes d'informations, cours L1 INFO, 2014.

* ⁶REIX ,R., Informatique appliquée à la Comptabilité et à la gestion, Ed. Foucher, Paris, 1987

* ⁷ QUAU,P., division de l'information et de l'informatique, Ed. Paris, France, P23

* ⁸www.supinfo-projects.com consulté le 05-04- 2014

* ⁹Juliard , F. , UML , Journal Université de Bretagne Sud UFR SSI-IUP Vannes, 2001-2002, p15.

* ¹⁰ http://fdigallo.online.fr/, consulté le 05-04- 2014

* ¹¹ http://fdigallo.online.fr/, consulté le 05-04- 2014

* ¹²http://fdigallo.online.fr/, consulté le 05-04- 2014

* ¹³Gabay,J ., David, G ., Mise en oeuvre guidée avec études de cas, édition Dunod, Paris 2008.

* ¹⁴ www.commentcamarche.com/initiation/concept.html