Mazari Yacine

Le résumé de mon projet de fin d’études :
J’ai travaillé sur un projet de gestion qui est la conception et réalisation d’une base de
données repartie sous Oracle 9i et Oracle forms builder 10G, ainsi que le langage de
programmation PL/SQL pour le suivi et la gestion du matériel informatique de la société de
distribution du centre SDC qui est à la fois filiale de SONELGAZ, à Tizi-Ouzou.
REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE
SCIENTIFIQUE
UNIVERSITE MOULOUD MAMMERI DE TIZI OUZOU
FACULTE DE GENIE ELECTRIQUE ET D’INFORMATIQUE
DEPARTEMENT D’INFORMATIQUE
Mémoire de fin d’étude

En vue de l’obtention du diplôme de Master II en informatique
Option : Ingénierie des systèmes d’information
Thème :
Conception et réalisation d’une base de données

Repartie sous oracle,
Cas : Gestion du matériel informatique à la
SDC de Tizi-Ouzou (filiale de SONELGAZ).
Réalisé par : Encadré par :

Mr. Yacine MAZARI Mr. CHAIEB Y. (UMMTO)
Mme: SADEG S. (Sonelgaz)
Promotion : 2011-2012
Remerciements
Mes remerciement les plus sincères sont destinés à :

Mon promoteur Monsieur CHAIEB Yazid pour avoir accepté de
m’encadrer, de m’orienter et de me venir en aide avec ses idées ;
Mademoiselle SADEG Sonia pour m’avoir encadré à la Sonelgaz de
Tizi-Ouzou, ainsi que monsieur IKENE Yahia, et toute l’équipe de la
subdivision affaire générales pour m’avoir fourni le maximum
d’informations nécessaires à mon projet ;
Monsieur REDAOUI Sofiane pour m’avoir aidé tout au long mon
projet ;
Mes amis qui ont été toujours présents pour me soutenir et
m’encourager ;
Les professeurs du département informatique qui m’ont enseigné tout
au long de mon cursus universitaire, pour avoir veillé à l’enrichissement
de mes connaissances dans le domaine ;
Toute personne ayant contribué de prés ou de loin à la réalisation de ce
travail.
Dédicace
Je dédie ce modeste travail à :

Mes parents qui m’ont guidé tout au long de ma vie, et qui ont veillé
au bon déroulement de mes études.
Ma sœur : Siham, et Mes frères : Azzedine, Ghiles, à qui je souhaite un
très bon parcours estudiantin et une très grande réussite à l’avenir.
Celle à qui je dois beaucoup de respect et de reconnaissance : Anissa
ainsi qu’à toute sa famille « grands et petits ».
Mes amis : Younes Salah, Sedik.K, le frère Younes, Aziz.I, Hacene.M,
Fatah.H, Cherif.O, Sofiane.R, Samir.I, Smail.B, Nacer.B, Farid.H,
Hamza, Smail.K…
Tous les étudiants du département d’informatique en particulier, et tous
les étudiants de l’UMMTO en général.
Yacine MAZARI
Sommaire
Sommaire
Chapitre 1 : Généralités sur les bases de données reparties.
Introduction générale.................................................................................................02
1. Introduction ...................................................................................................... 04
2. Evolution des bases de données ..................................................................... 04
2.1 La relation entre les bases de données et les systèmes d’information .............. 04
2.2 Evolution des bases de données ..................................................................... 01
1. Systèmes centralisés .............................................................................. 04
2. Les systèmes décentralisés ..................................................................... 05
3. Les systèmes répartis ............................................................................. 05
3. Définition d’une base de données repartie .................................................. 06
4. Caractéristiques d’une base de données repartie .......................................07

4.1 Transparence de localisation .......................................................................... 07
4.2 Transparence de partitionnement .................................................................. 07
4.3 Transparence de la duplication ....................................................................... 07
5. Architecture d’un système de gestion de BDD reparties SGBDR .............07

5.1 Niveau local ................................................................................................... 08
5.2 Niveau de communication ............................................................................. 08
5.3 Niveau interopérable ..................................................................................... 08
6. Fonctions de décomposition et optimisation de requêtes .......................09

6.1 Interface d’une base de données repartie ...................................................... 09
6.2 Décomposition des requêtes .......................................................................... 10
6.3 Contrôle de l’intégrité ................................................................................... 10

Sommaire
7. Conception d’une base de données répartie ....................................................10

7.1 Conception ascendante ....................................................................................... 10
7.2 Conception descendante ..................................................................................... 11
7.2.1 La fragmentation ................................................................................ 11
7.2.2 Allocation des fragments .................................................................... 14
7.2.3 La réplication ...................................................................................... 14
8. Avantages et inconvénients des bases d données reparties ..........................15

8.1 Les avantages ..................................................................................................... 15
8.2 Les inconvénients .............................................................................................. 16
9. Conclusion ..............................................................................................................16
Chapitre 2 : Etude et description de l’existant.
1. Introduction ............................................................................................................18
2. Présentation de l’organisme d’accueil ..............................................................18

2.1 Historique ......................................................................................................... 18
2.2 Missions ........................................................................................................... 19
2.3 Organigramme général de la DD de Tizi-Ouzou ................................................. 20
2.4 Mode d’organisation ........................................................................................ 20
3. Problématique ........................................................................................................24
3.1. Description des flux d’informations existants ..................................................... 24
3.2 Problématique rencontrée .................................................................................. 25
4. Les services du champ d’étude et les documents manipulés .........................25
5. Etude des documents .............................................................................................28

5.1 Les documents de la subdivision des affaires générales SAG ................................ 28
5.2 Les documents de la division de gestion des systèmes informatique .................... 32

Sommaire
6. Diagramme des flux................................................................................................35

6.1 Concepts utilisés .................................................................................................. 35
6.2 Liste des flux ........................................................................................................ 36
6.3 Diagramme des flux ............................................................................................. 37
7. Modèle organisationnel des traitements existant MOT ............................ 38

7.1 Concepts de base utilisés ..................................................................................... 38
7.2 Le formalisme utilisé ........................................................................................... 39
8. Conclusion ................................................................................................................44
Chapitre 3 : Analyse et conception.
1. Introduction ..................................................................................................... 46
2. Analyse ..............................................................................................................46
2.1. Présentation ................................................................................................. 47
2.2 Définition des besoins .................................................................................... 47
2.3 Définition des acteurs .................................................................................... 47
2.4 Diagramme de contexte ................................................................................. 48
2.5 Identification des espaces .............................................................................. 48
3. Conception .........................................................................................................48
3.1 Le niveau applicatif .............................................................................................. 49
Représentation des diagrammes de cas d’utilisation (Définition)............................... 49
Diagramme de cas d’utilisation global ................................................................ 50
Diagramme de cas d’utilisation « gérer matériel » .............................................. 50
Diagramme de cas d’utilisation « Mise à jour de la vue » ................................... 51
Diagramme de cas d’utilisation « Consulter vue » .............................................. 51
Diagramme de cas d’utilisation pour l’espace administrateur ............................. 51
Diagrammes de séquence (Définition) ................................................................. 52
Diagramme de séquence pour « Authentification » ............................................ 52

Sommaire
Le scénario nominal du cas d’utilisation « Authentification » ............................. 52
Diagramme de séquence pour « Ajouter matériel » ............................................ 53
Le scenario nominal du cas d’utilisation « Ajouter matériel » ............................. 53
Diagramme de séquence pour « Consulter vue » ............................................... 54
Le scenario nominal du cas d’utilisation « Consulter Vue » .................................. 54
Diagramme de déploiement (Définition)..................................................................... 54
Diagramme de déploiement pour notre application ........................................... 55
Diagrammes d’activité (Définition) ............................................................................ 55
Diagramme d’activité du cas d’utilisation « Authentification » ............................ 55
Diagramme d’activité pour le cas d’utilisation « Ajouter matériel » ..................... 56
Diagrammes de classes généraux (Définition) ............................................................. 57
Diagramme de classes du cas d’utilisation « Authentification » .......................... 57
Diagramme de classe pour le cas d’utilisation « Ajouter matériel » ..................... 57
Découpage du système en packages ........................................................................... 58
Diagramme de classe du package espace SAG .................................................... 59
Diagramme de classe pour le package Espace DGSI ............................................ 60
Diagramme de classes pour le package Administrateur ...................................... 61
3.2 Le niveau de données .......................................................................................... 62
Diagramme de classes final ................................................................................ 62
Dictionnaire de données ..................................................................................... 63
Le modèle physique de données ................................................................................ 63
4. Conclusion ...................................................................................................64
Chapitre 4 : Réalisation.
1. Introduction ......................................................................................................66
2. Outils de développement ...............................................................................66
Sommaire
3. Environnement de programmation ............................................................66

4. Présentation de la base de données ............................................................67
5. Présentation des interfaces de notre application ......................................67
6. Conclusion .........................................................................................................70
Conclusion générale....................................................................................................72
Bibliographie ................................................................................................................74
Annexes ........................................................................................................................76
Liste des figures :
- Figure 1 : Une Base de données dans un système repartie.

- Figure 2 : Architecture d’un SGBDR.
- Figure 3 : Décomposition fonctionnelle d’un SGBDR.
- Figure 4 : Etapes de la démarche ascendante.
- Figure 5 : Exemple sur la fragmentation horizontale.
- Figure 6 : Exemple sur la fragmentation verticale.
- Figure 7 : Organigramme de la direction de distribution de Tizi-Ouzou.
- Figure 8 : Organigramme de la division relations commerciales.
- Figure 9 : Organigramme de Division étude d’exécution des travaux électricité & gaz.
- Figure 10 : Organigramme de la Division Finance et Comptabilité.
- Figure 11 : Organigramme de la Division des Ressources Humaines.
- Figure 12 : Diagramme des flux.
- Figure 13 : Représentation graphique de la démarche de modélisation.
- Figure 14 : Diagramme de contexte.
- Figure 15 : Diagramme de cas d’utilisation global.
- Figure 16 : Diagramme de cas d’utilisation « gérer matériel ».
- Figure 17 : Diagramme de cas d’utilisation « mise à jour vue ».
- Figure 18 : Diagramme de cas d’utilisation « Consulter vue ».
- Figure 19 : Diagramme de cas d’utilisation pour l’espace administrateur.
- Figure 20 : Diagramme de séquence « Authentification ».
- Figure 21 : Diagramme de séquence « Ajouter matériel ».
- Figure 22 : Diagramme de séquence « Consulter vue ».
- Figure 23 : Diagramme de déploiement.
- Figure 24 : Diagramme d’activité pour « Authentification ».
- Figure 25 : Diagramme d’activité pour « Ajouter matériel ».
- Figure 26 : Diagramme d’activité pour « Consulter vue ».
- Figure 27 : Diagramme de classe pour « Authentification ».
- Figure 28 : Diagramme de classe pour « Ajouter matériel ».
- Figure 29 : Les packages du futur système.
Sommaire
- Figure 30 : Diagramme de classe général pour Espace SAG.

- Figure 31 : Diagramme de classe général pour Espace DGSI.
- Figure 32 : Diagramme de classe pour Espace Administrateur.
- Figure 33 : Diagramme de classe final.
- Figure 34 : Présentation de la base de données.
- Figure 35 : Page d’accueil.
- Figure 36 : Page d’authentification.
- Figure 37 : Page fichier auxiliaire.
- Figure 38 : Barre d’outils.
- Figure 39 : Page fichier auxiliaire du matériel informatique.
Liste des tableaux :

- Tableau 1 : Fiche d’étude du poste Nº 01 SAG
- Tableau 2 : Liste des documents manipulés par la SAG, pour la gestion du matériel.
- Tableau 3 : Fiche d’étude du poste Nº 02 DGSI.
- Tableau 4 : Liste des documents manipulés par la DGSI.
- Tableau 5 : Fiche d’étude du document Nº 01 : Bordereau d’expédition.
- Tableau 6 : Fiche d’étude du document Nº 02 : Demande de prestation de service.
- Tableau 7 : Fiche d’étude du document Nº 03 : décision d’affectation.
- Tableau 8 : Fiche d’étude du document Nº 04 : Fichier auxiliaire.
- Tableau 9 : Fiche d’étude du document Nº 05 : Décharge.
- Tableau 10 : Fiche d’étude du document Nº 06 : Demande de prestation de service.
- Tableau 11 : Fiche d’étude du document Nº 07 : Fichier auxiliaire concernant le
Matériel de type informatique.
- Tableau 12 : La légende.
- Tableau 13 : Liste des flux.
- Tableau 14 : Le formalisme utilisé.
- Tableau 15 : Liste des procédures manipulées.
- Tableau 16 : Procédure Nº 01 : Fourniture du nouveau matériel informatique.
- Tableau 17 : Procédure Nº 02 : Teste du nouveau matériel informatique.
- Tableau 18 : Procédure Nº 03 : Enregistrement du matériel informatique testé.
- Tableau 19 : Procédure Nº 04 : Mise à jour de la base de données matériel
Informatique se trouvant au niveau de la DGSI.
- Tableau 20 : Procédure Nº 05 : Affectation du matériel informatique.
- Tableau 21 : Dictionnaire de données.
- Tableau 22 : Table UTILISATEUR.
- Tableau 23 : Table FICHIER_AUXILIAIRE.
- Tableau 24 : Vue de la table FICHIER_AUXILIAIRE : MATERIEL_INFORMATIQUE.
Introduction
Générale
Introduction générale
L'évolution des techniques informatiques depuis les vingt dernières années a permis
d'adapter les outils informatiques à l'organisation des entreprises, vu le grand volume de
données manipulées par ces dernières, la puissance des micro-ordinateurs, les performances
des réseaux et la baisse considérable des coûts du matériel informatique qui ont
permis l'apparition d'une nouvelle approche afin de remédier aux désagréments causés
par la centralisation des données, et ce en répartissant les ressources informatiques
tout en préservant leur cohérence.
La solution qui s'impose est de distribuer les données et les organiser dans des bases de
données sur différents sites de stockage. L'ensemble de ces sites constitue un système de
bases de données réparties offrant la possibilité aux utilisateurs de manipuler les différentes
bases via un réseau de manière transparente, comme dans une base de données globale.
Notre travail, consiste en la mise en place d’un système d’information pour la gestion du
matériel divers en général et du matériel informatique en particulier, en développant une
base de données qui sera la transformation d’une base déjà existante sur MS Excel. Par la
suite on fragmentera notre base à travers une vue pour but d’allouer ce fragment à un
service distant autre que celui contenant la base de données, permettant ainsi la répartition
de l’information concernant matériel informatique par le biais d’un réseau local, via des
consultations simultanées de la vue.
Pour ce faire, nous avons opté dans notre mémoire pour le plan de travail suivant :
- Chapitre 1 : Généralités sur les bases de données reparties.

- Chapitre 2 : Etude et description de l’existant (étude préalable du système existant).
- Chapitre 3 : Analyse et conception (étude détaillé du futur système d’information).
- Chapitre 4 : Réalisation de notre base de données.
- Puis on terminera avec une conclusion générale avec quelques annexes.
Chapitre I
Les bases de données reparties
Chapitre I Les bases de données réparties
1. Introduction :
Une base de données est un ensemble d’informations structurées et mémorisées sur un
support permanant. Elle peut être locale, ou répartie dont certaines données sont distantes,
en termes d’espaces de stockage, de machines…etc. De plus, elles doivent pouvoir être
accédées par plusieurs utilisateurs locaux ou distants. Afin de permettre aux utilisateurs
d’interagir avec la base de données de façon cohérente et performante, la présence des
bases de données réparties devient indispensable.
2. Evolution des bases de données :

2.1 La relation entre les bases de données et les systèmes d’information :
Un système d’information correspond à un ensemble de moyens et de processus assurant

le traitement de l’information à des fins de décisions. Plus précisément, un système
d’information est constitué :
- D’une base de données (au sens large, c’est-à-dire fichiers classiques ou base de
données), véritable mémoire de l’organisation puisqu’elle contient des informations
relatives au personnel, aux produits, aux clients de l’entreprise ;
- D’un ensemble de processus (et donc de processeurs humains ou automatiques)
capables de traiter ces données.
Le rôle essentiel d’un système d’information est de permettre le « pilotage » de

l’entreprise en fournissant aux décideurs (dirigeants, gestionnaires,...) des données fiables et
synthétiques sur l’état de l’entreprise et de son environnement.
La rapidité et l’efficacité d’une prise de décision sont naturellement induites par la qualité
du système d’information. Cette qualité est notamment liée à la cohérence et au niveau
d’évolution de la base de données, qui doit refléter le plus fidèlement possible la situation
de l’entreprise. Par exemple, la quantité d’un produit enregistrée dans un fichier doit
correspondre à la quantité réellement disponible en magasin.
2.2 Evolution des bases de données :
Depuis leur apparition, les bases de données ne cessent d’évoluer d’une manière
remarquable proportionnellement aux systèmes dans les quels ces dernières se retrouvent.
Ces systèmes peuvent être classés selon l’ordre chronologique comme suit :
1. Systèmes centralisés :
Pour obtenir la cohérence des données stockées, les informaticiens ont naturellement
songé à centraliser la base de données (ou les fichiers). Ainsi, les données sont stockées sur
un processeur unique auquel les utilisateurs accèdent à partir de terminaux.
4
Cette solution a l’avantage de la simplicité ; les informaticiens ont l’entière maîtrise de
l’informatique : choix cohérent des matériels et logiciels, application d’une méthode et de
standards dans le développement et la maintenance des programmes, contrôle de la
cohérence des données grâce à une administration centralisée des données.
D’autre part, cette solution correspond bien à la technologie des années 60 et 70 où un

système informatique est généralement constitué d’un ordinateur central auquel sont
connectés un ensemble de terminaux passifs.
2. Les systèmes décentralisés :
Face à la multiplication des micro-ordinateurs et des stations de travail dans les entreprises
au début des années 80, les informaticiens ont été conduits à décentraliser le traitement de
l’information. Par exemple, une des formes de décentralisation appelée Infocentre, consiste
à remplacer les terminaux des utilisateurs par des micro-ordinateurs connectés au
processeur central ; le principe de fonctionnement de l’Infocentre est alors le suivant :
- Le stockage et les mises à jour de la base de données sont réalisés sur le processeur
central.
- Les traitements autres que les mises à jour peuvent être conçus, réalisés et mis en
œuvre par les utilisateurs directement sur leurs micro-ordinateurs.
Les avantages d’un tel système sont indéniables :
- La cohérence de la base de données est préservée grâce à la centralisation du

stockage et des mises à jour ;
- L’utilisateur peut développer localement ses propres applications sur son micro-
ordinateur à partir de données extraites de la base centrale : utilisation de tableurs,
de logiciels de statistiques, d’éditeurs d’états,…etc. ;
- On évite le développement anarchique d’applications gérant des données stockées
localement sur des micro-ordinateurs ;
- Les utilisateurs peuvent concevoir et réaliser des applications simples déchargeant
ainsi les informaticiens de ce type de développement.
3. Les systèmes répartis :
Dans les systèmes centralisés et décentralisés, le fonctionnement du système

d’information automatisé repose en grande partie sur la disponibilité du processeur central
qui gère la base de données.
Dans un système réparti, un ensemble de processeurs autonomes reliés par un réseau de

communication coopèrent pour assurer la gestion des informations. Un tel système présente
des avantages certains. Tout d’abord, en préservant certains apports de la solution
5
décentralisée, le système réparti permet de limiter la vulnérabilité des centres
informatiques.
Le principe est simple : le système d’information (données et traitements) est réparti sur
différents sites (processeurs de traitement autonomes) interconnectés par un réseau de
communication. Ainsi, la défaillance d’un site ne peut entraîner à elle seule l’indisponibilité
totale du système.
D’autre part, ce type de système préserve l’autonomie des sites en permettant à un

groupe d’utilisateurs de créer et de gérer sa propre base de données tout en autorisant un
accès aux autres utilisateurs via le réseau.
3. Définition d’une base de données repartie :

Une base de données répartie BDR est une collection de bases de données localisées sur
différents sites, généralement distants, mises en relations les unes avec les autres à travers
un réseau d'ordinateurs, perçues par l'utilisateur comme une base de données unique. Elle
permet de rassembler des données plus ou moins hétérogènes, disséminées dans un réseau
sous forme d'une base de données globale, homogène et intégrée, utilisant pour ça un
système de gestion de bases de données réparties.
Le SGBDR repose sur un système réparti qui est constitué d'un ensemble de
processeurs autonomes appelés sites ou serveurs (micro-ordinateurs, stations de travail, ...
etc.) reliés par un réseau de communication qui leur permet d'échanger des données.
Un SGBDR suppose que les données soient stockées sur deux processeurs au moins, ceux-ci
étant dotés de leur SGBD propre. Ainsi, dans l’exemple d’une configuration constituée de
trois processeurs interconnectés, dont l’un est chargé de la gestion des données (serveur
base de données), la base de données n’est évidemment pas répartie, bien que l’on soit en
présence d’un système réparti.
Figure1 : Une Base de données dans un système repartie.
6
La BDR est décrite par un schéma global qui contient la localisation des données, et qui
permet ainsi d’aiguiller un traitement sur les processeurs détenant les données à traiter.
Lorsque les BD qui composent la BDR reposent sur des modèles de données différents
(hiérarchique, réseau, relationnel, orienté objet), on parle de BDR hétérogène. Par voie de
conséquence, le SGBDR est également hétérogène puisqu’il est constitué de SGBD de types
différents.
4. Caractéristiques d’une base de données repartie :

Au niveau de la BDR, la transparence est un principe fondamental qui apparaît dans la
localisation, le partitionnement et la duplication des données :
4.1 Transparence de localisation :
La transparence de la localisation des données sous-entend que ni les applications, et

niles utilisateurs n'ont besoin de connaître la position réelle des tables auxquelles ils
accèdent. Autrement dit, ils ne doivent pas connaître la localisation physique des
données.
Les utilisateurs accèdent à la BD soit directement par le schéma conceptuel soit

indirectement à travers les vues externes, mais en aucun cas, ils n'ont les moyens pour
accéder aux schémas locaux.
4.2 Transparence de partitionnement :
Les utilisateurs n'ont pas à connaître les partitionnements de la base de données. Ils ne
doivent pas savoir si telle information est fractionnée et ne doivent donc pas se
préoccuper de la réunifier. C'est le système qui gère les partitionnements et les modifie
en fonction de ses besoins. Et c'est donc lui qui doit rechercher toutes les partitions et les
intégrer en une seule information logique présentée à l'utilisateur.
4.3 Transparence de la duplication :
Enfin, le principe de transparence de la duplication est que les utilisateurs n'ont pas à
savoir si plusieurs copies d'une même information sont disponibles. La conséquence directe
est que lors de la modification d'une information, c'est le système qui doit se préoccuper
de mettre à jour toutes les copies.
5. Architecture d’un système de gestion de bases de données reparties

SGBDR :
Cette architecture s’articule autour de trois niveaux de fonctionnalités :
7
5.1 Niveau local : présent sur chaque serveur permet d’exporter les données locales.
- Adaptateur local : Le niveau local est constitué par un adaptateur local, ce module réalise
le passage du schéma exporté (ce dernier décrit les données exportées par un site vers les
sites clients) au schéma local (qui décrit les données d’une base de données locale) et
traduit les requêtes en programmes d’accès au SGBD local. En sens inverse, il traduit aussi
les réponses aux requêtes. Donc il est véritablement une passerelle depuis le SGBD distribué
vers un SGBD local.
5.2 Niveau de communication : requêtes en provenance d’un site client au serveur de

données. Ces sous requêtes référencent le schéma exporté vers ce site client; en sens
inverse ce niveau transmet les réponses en conformité au schéma exporté.
5.3 Niveau interopérable : permet de formuler des requêtes mettant en jeu des vues
intégrées de la base ; il assure la décomposition des requêtes en sous requêtes, et
le passage des vues intégrées aux différents schémas importés .Une vue intégrée décrit
les données de la base de données répartie accédées par une application.
Le schéma importé est un schéma exporté par un serveur vu d’un site client.
La figure ci-dessous, illustre l’architecture d’un système de gestion de bases de données

reparties SGBDR avec ses différents niveaux :
Figure2 : Architecture d’un SGBDR.
8
6. Fonctions de décomposition et optimisation de requêtes :

Les fonctions suivantes mettent en lumière l’originalité d’un SGBDR par rapport à un SGBD.
Nous considérons que le réseau de communication assure le transport et le contrôle des
messages entre les différents processeurs du système réparti :
Figure3 : Décomposition fonctionnelle d’un SGBDR.
6.1 Interface d’une base de données repartie :
Comme toute base de données, une BDR est décrite dans un dictionnaire de données sous
la forme de schémas globaux distincts conformément à l’architecture ANSI/SPARC :
- Le schéma conceptuel où les données sont représentées sans prendre en compte des
contraintes techniques ou de mise en forme, toutes les données sont décrites dans
ce schéma, indépendamment de leur localisation dans le système réparti ;
- Les schémas externes où les données sont décrites sous forme de vues, chacune
d’elles étant adaptée à une classe particulière d’utilisateurs ; un schéma externe,
élaboré à partir du schéma conceptuel, peut naturellement mixer des données
stockées dans différentes bases ;
- Le schéma interne où sont notamment spécifiées la fragmentation des données et la
localisation de ces fragments ; les données y sont décrites en fonction de
l’architecture du système réparti et des spécificités techniques du système
informatique (diversité des matériels et des modèles de données, architecture du
réseau,...). C’est au travers de ces différents schémas que l’utilisateur (programmeur
ou utilisateur final) peut accéder aux données réparties ; le langage utilisé est
généralement un langage de type SQL.
9
6.2 Décomposition des requêtes :
Un traitement réparti fait appel à des données gérées par des SGBD distincts. Un
traitement réparti contient donc des requêtes formulées à partir d’un schéma externe
global, ces requêtes correspondent à un ensemble d’opérations de recherches et de mises à
jour sur des données de la BDR. Le SGBDR contrôle et analyse chaque requête et la
décompose en opérations locales (plan d’exécution réparti) qui seront soumises pour
exécution aux SGBD concernés.
6.3 Contrôle de l’intégrité :
Le contrôle de l’intégrité des données par un système informatique permet d’assurer que
tout traitement (transaction) sur la base de données fait passer celle-ci d’un état cohérent
(ou supposé tel) à un autre état cohérent. Nombreuses sont les sources pouvant engendrer
des anomalies : absence d’expression de certaines contraintes d’intégrité dans le schéma
des données, perte d’opérations suite à un enchevêtrement de mises à jour concurrentes,
panne du réseau,… etc.
Ce type de problème existe aussi dans les SGBD centralisés qui proposent des solutions
adaptées notamment pour gérer les accès concurrents aux données (techniques d’évitement
ou de détection des incohérences).
7. Conception d’une base de données répartie :

Dans la phase de conception d’une base de données répartie, l'administrateur doit prendre
des décisions dont l'objectif est de minimiser le nombre de transferts entre sites, les
temps de transfert, le volume de données transférées,….etc.
Deux approches fondamentales sont à l'origine de la conception des bases de

données réparties : la conception ascendante « Bottom up design » et la conception
descendante « Top down design ».
7.1 Conception ascendante :
L’approche se base sur le fait que la répartition est déjà faite, mais il faut réussir à
intégrer les différentes bases de données existantes en une seule base de données globale.
En d’autres termes, les schémas conceptuels locaux existent et il faut réussir à les
unifier dans un schéma conceptuel global et donner aux utilisateurs une vue unique des
données implémentées sur plusieurs systèmes a priori hétérogènes (plates-formes et SGBD).
10
- Etapes de la démarche ascendante :
Au premier lieu il existe plusieurs sites dispersés. Chaque site possède un traducteur. Ce
dernier réalise des fonctions telles que la traduction du schéma exporté vers un schéma
équivalent en modèle canonique (intermédiaire).
Au deuxième lieu l’intégration des schémas fait référence au choix de la représentation la

plus adéquate pour le schéma global, ainsi que l’identification des éléments de base qui
sont liés et l’intégration des schémas intermédiaires.
La figure ci-dessous illustre les étapes de la démarche ascendante :
Figure 4 : Etapes de la démarche ascendante.
7.2 Conception descendante :
On commence par définir un schéma conceptuel global de la base de données répartie,

puis on le distribue sur les différents sites en des schémas conceptuels locaux. La répartition
se fait donc en deux étapes, en première étape la fragmentation et en deuxième étape
l'allocation de ces fragments aux sites.
7.2.1 La fragmentation :
La fragmentation est le processus de décomposition d'une base de données en un

ensemble de sous bases de données. Cette décomposition doit être sans perte
d'information. La fragmentation peut être coûteuse s'il existe des applications qui
possèdent des besoins opposés. On est en quelque sorte dans le cas d'une exclusion
mutuelle qui empêche une fragmentation correcte.
11
Par ailleurs, la vérification des dépendances sur différents sites peut être une
opération très longue.
- Objectifs de la fragmentation :
Les applications ne travaillent que sur des sous-ensembles des relations. Une
distribution complète des relations générerait soit beaucoup de trafic, soit une
réplication des données avec tous les problèmes que cela occasionne : problèmes de
mises à jour, problèmes de stockage. Il est donc préférable de mieux distribuer ces sous-
ensembles.
L'utilisation de petits fragments permet de faire tourner plus de processus

simultanément, ce qui entraîne une meilleure utilisation des capacités du réseau
d'ordinateurs.
- Types de fragmentation :
1. Fragmentation horizontale :
C'est un découpage d'une table en sous tables par utilisation de prédicats

permettant de sélectionner les lignes appartenant à chaque fragment. L'opération de
fragmentation est obtenue grâce à la sélection des tuples d'une table selon un ou des
critères bien précis.
Exemple :
Figure 5 : Exemple sur la fragmentation horizontale.
12
2. Fragmentation verticale :
Elle est le découpage d'une table en sous tables par projection permettant de
sélectionner les colonnes composant chaque fragment.
Figure 6 : Exemple sur la fragmentation verticale.
3. La fragmentation mixte :
Elle résulte de l'application successive d'opérations de fragmentation horizontale et

verticale sur une relation globale.
- Les règles de la fragmentation :
Pour réaliser une fragmentation correcte, il faut respecter les trois règles suivantes:
1. Complétude :
pour toute donnée d'une relation globale R, il existe au moins un fragment Ri de la

relation R qui possède cette donnée.
2. Reconstruction :
Pour toute relation R décomposée en un ensemble de fragments Ri, il existe une opération
de reconstruction à définir en fonction de la fragmentation. Pour les fragmentations
horizontales, l'opération de reconstruction est une union. Pour les fragmentations
verticales c'est la jointure.
13
3. Disjonction :
Une donnée n'est présente que dans un seul fragment, sauf dans le cas de la
fragmentation verticale pour la clé primaire qui doit être présente dans l'ensemble des
fragments issus d'une relation.
7.2.2 Allocation des fragments :
Suite à la fragmentation des données, il est nécessaire de les placer sur les
différentes machines. Un schéma doit être élaboré afin de déterminer la localisation de
chaque fragment, et sa position dans le schéma global est ce qu'on appelle l'allocation.
- Allocation avec duplication :
Cette technique consiste à dupliquer (répliquer) des parties de la base c'est à dire les
fragments sont dupliqués sur plusieurs sites selon les besoins (la réplication est
détaillée en section suivante). Cette approche est très intéressante car elle améliore
considérablement les performances du système, étant donné que les fragments sont
dupliqués un peu partout et que les accès aux données sont locaux, évitant ainsi la
congestion du réseau et améliorant les temps de réponse. Le principal inconvénient de
cette technique est la difficulté des mises à jour de tous les fragments dupliqués.
- Allocation dynamique :
Avec cette technique, l'allocation d'un fragment peut changer en cours d'utilisation de la
BDR, c'est à dire qu'un fragment qui se trouve sur un site A à un instant T, peut être retrouvé
sur un site B à un instant T+1. Cette technique est efficace mais exige le maintien du schéma
d'allocation et des schémas locaux.
7.2.3 La réplication :
La réplication consiste à copier les informations d'une base de données sur une
autre. L'objectif principal de la réplication est de faciliter l'accès aux données en
augmentant la disponibilité. Soit parce que les données sont copiées sur différents sites
permettant de répartir les requêtes, soit parce qu'un site peut prendre la relève lorsque le
serveur principal s'écroule. Une autre application tout aussi importante est
l'amélioration des performances des requêtes sur les données locales, et ceci permet
d'éviter les transferts de données et d'accroître la résistance aux pannes.
- Types de réplication :
1. Réplication asymétrique :
La réplication asymétrique distingue un site maître appelé site primaire, chargé de

centraliser les mises à jour. Il est le seul autorisé à mettre à jour les données, et
chargé de diffuser les mises à jour aux copies dites secondaires. Le plus gros problème de la
gestion asymétrique est la panne du site primaire. Dans ce cas, il faut choisir un
14
remplaçant si l'on veut continuer les mises à jour. On aboutit alors à une technique
asymétrique mobile dans laquelle le site primaire change dynamiquement. On distingue
l'asymétrie synchrone et l'asymétrie asynchrone :
1.1 Réplication asymétrique synchrone :
Elle utilise un site primaire qui pousse les mises à jour en temps réel vers un ou
plusieurs sites secondaires. La table répliquée est immédiatement mise à jour pour
chaque modification, par utilisation de trigger sur la table maîtresse.
1.2 Réplication asymétrique asynchrone :
Elle pousse les mises à jour en temps différé via une file persistante. Les mises à jour
seront exécutées ultérieurement, à partir d'un déclencheur externe, l'horloge par
exemple.
2. Réplication symétrique :
A l'opposé de la réplication précédente, la réplication symétrique ne privilégie aucune

copie c'est-à-dire chaque copie peut être mise à jour à tout instant et assure la
diffusion des mises à jour aux autres copies. Cette technique pose problème de la
concurrence d'accès risquant de faire diverger les copies. Une technique globale de
résolution de conflits doit être mise en œuvre.
On distingue la symétrie synchrone et la symétrie asynchrone :
2.1 Réplication symétrique synchrone :
Lors de la réplication symétrique synchrone, il n'y a pas de table maîtresse. L'utilisation de

trigger sur chaque table doit différencier une mise à jour client à répercuter d'une mise
à jour par réplication. Cette technique nécessite l'utilisation de jeton.
2.2 Réplication symétrique asynchrone :
Dans ce cas, la mise à jour des tables répliquées est différée. Cette technique risque de
provoquer des incohérences de données.
8. Avantages et inconvénients des bases d données reparties :
8.1Les avantages :
- Reflète une structure organisationnelle : amélioration de l’autonomie locale.
15
- Disponibilité améliorée : une panne dans un site d’un SGBDR ou une rupture de ligne
de communication isolant un ou quelques sites n’immobilise pas l’ensemble du
système.
- Economie : l’ajout de stations de travail à un réseau est nettement moins
couteux que l’extension d’un gros système centralisé.
- Facilité d’accroissement (scalability) : Ajouter des machines aux réseaux sans
toucher a la cohérence de la base de données.
8.2 Les inconvénients :

- Sécurité : dans un système centralisé, l’accès aux données est d’un contrôle
facile, tandis que dans un système réparti, non seulement il faux contrôler l’accès aux
données dupliquées dans les emplacements multiples, mais le réseau lui-même
doit être sécurisé.
- Coût : La distribution des données entraîne des coûts supplémentaires en
termes de communication (trafic réseau), et en gestion des communications
comme le hardware et software à installer afin de gérer les communications et la
distribution.
La distribution est également coûteuse en matière du personnel utilisé car il faut payer les
administrateurs de chaque site.
9. Conclusion :
Les bases de données réparties sont une solution séduisante pour parvenir à maîtriser la
distribution des ressources informatiques sur plusieurs processeurs interconnectés.
Actuellement, beaucoup de systèmes offrent certaines fonctionnalités sans atteindre

toujours la transparence à la répartition souhaitée par l’utilisateur tel que les systèmes
commerciaux.
Mais, au-delà de la complexité des techniques mises en œuvre et des performances qui se
révèlent parfois décevantes (comparées aux temps de réponse de certains systèmes
centralisés), d’autres écueils freinent le développement des bases de données réparties.
En effet, l’hétérogénéité actuelle et le manque de compatibilité des matériels et des

logiciels au sein d’une même entreprise rendent particulièrement délicate la mise en place
d’un SGBDR. Par conséquent, l’avènement d’un tel système ne peut être qu’un processus
long et progressif qui devrait débuter par une prise de conscience collective des différents
acteurs de l’entreprise de la nécessité d’un tel système (politique d’homogénéisation des
matériels et logiciels, mise en place d’un réseau de communication fiable, répartition des
responsabilités,...).
16
Chapitre II
Etude et description de l’existant
Chapitre II Etude et description de l’existant
1. Introduction :
Au cours de ce chapitre, nous allons nous consacrer à l’étude de l’existant pour
comprendre le fonctionnement de l’organisme d’accueil, et mettre en évidence les
différents documents manipulés et aussi les acteurs intervenant dans ce système, et leurs
besoins.
2. Présentation de l’organisme d’accueil :

2.1 Historique :
SONELGAZ est une entreprise nationale dans le domaine de fourniture de des énergies
électriques et gazières. Ses missions principales sont : la production, le transport et la
distribution de l’électricité, ainsi que le transport et la distribution du gaz naturel par
canalisation.
Depuis la promulgation de la loi sur l’électricité et la distribution du gaz par canalisation,

SONELGAZ s’est restructurée pour s’adapter au nouveau contexte. Elle est arrivée
aujourd’hui à la catégorie de groupe industriel composé de 8 filiales. Elle emploie plus de
40 000 travailleurs.
SONELGAZ d’aujourd’hui a plus d’un demi-siècle d’existence :
- En 1947, est créé l’établissement public EGA « Electricité et Gaz d’Algérie », au quel
est confié le monopole de la production, du transport et de la distribution de
l’électricité et du gaz.
- En 1969, EGA soutient le développement économique et social, et de vient par la
suite SONELGAZ « Société Nationale d’Electricité et GAZ », à ce moment c’était déjà
une entreprise de taille importante dont le personnel était d’environ 6000 agents.
- En 1991, SONELGAZ devient EPIC « Etablissement Public à caractère Industriel et
Commercial ». tout en confirmant sa mission de service publique, elle pose la
nécessité de la gestion économique et de la prise de compte de la commercialité.
Dans ce même objectif, l’établissement devient en 2002, une société par actions
« SPA ». cette promotion donne à SONELGAZ la possibilité d’élargir ses activités à
d’autres domaines relevant du secteur de l’énergie et aussi d’intervenir hors des
frontières d’Algérie.
- En 2006, la fonction de distribution est structurée en quatre filiales :
• Alger.
• Région du centre.
• Région Est.
• Région Ouest.
- En 2008, le nombre de filiales es passé de quatre à huit qui sont :
• SPE : Société de production d’électricité.
18
• GRTE : Société de transport d’électricité.

• GRTG : Société de transport du gaz.
• OSE : Operateur systèmes électriques.
• SDE : Société de distribution Est.
• SDA : Société de distribution d’Alger.
• SDC : Société de distribution du centre.
• SDO : Société de distribution Ouest.
Au-delà de cette évolution, assurer le service public reste la mission essentielle de

SONELGAZ. L’élargissement de ses activités et l’amélioration de sa gestion économique,
bénéficie en premier lieu à cette mission qui constitue le fondement de sa culture
d’entreprise.
Comme nous réalisons ce projet au sein de la direction de distribution de l’électricité et du

gaz de Tizi-Ouzou qui appartient à la filiale SDC, nous allons présenter ci-dessous son
organisation générale :
2.2. Missions :
La direction de distribution de Tizi-Ouzou participe à l’élaboration de la politique de la

direction générale de distribution (en matière présentation, rendus aux clients,
développement des ventes, recouvrement des créances…).
- Mettre en œuvre la politique commerciale de l’entreprise et en contrôler

l’application.
- Satisfaire dans les meilleures conditions de couts et de délais aux demandes de
raccordement des clients MT/BT (Moyenne tension/Basse tension), MP/BP
(Moyenne pression/Basse pression) en leur apportant conseil et assistance.
- Assurer la gestion (conduite, exploitation, et maintenance), et le développement des
réseaux MT/BT et MP/BP et des installations annexes.
- Elaborer et mettre en œuvre le développement de la construction et la maintenance
et l’exploitation des ouvrages.
- Etablir les programmes de travaux qui se rapportent à ces missions et en assurer la
maitrise d’œuvre.
- Assurer la gestion et le développement des ressources humaines et des moyens
matériels nécessaires au fonctionnement du centre.
- Assurer la sécurité du personnel et des biens en rapport avec les activités de
distribution.
- Assurer la représentation de SONELGAZ au niveau local.
2.3. Organigramme général de la direction de distribution d’électricité et du gaz de Tizi-

Ouzou :
19
Direction Régionale
Chargé des Affaires Juridiques Secrétaire de coordination
Chargé de la Communication
Chargé de la Sécurité
Chargé de la Sureté interne
Division Exploitation Electricité Division Exploitation Gaz Division Etude Exécution et Travaux
Division Relations Commerciales Division Finance et Comptabilité Division Ressources Humaines
Subdivision Affaires Générales Division de Gestion des Systèmes

Informatiques
: Les services du champ d’étude.
Figure 7 : Organigramme de la direction de distribution de Tizi-Ouzou.
2.4. Mode d’organisation :

a. Chargé de la communication :
Son rôle est de :
- Proposer les thèmes sur la publicité et l’information de la clientèle sur la base

d’observation locale.
20
- Concevoir et organiser l’information destinée au publique et à la clientèle en utilisant

les supports appropriés (dépliants, affiches, presses, radio locale, brochures…) en
s’appuyant sur la politique de l’entreprise.
- Entretenir des relations étroites avec les medias (TV, radio, presse…).
b. Chargé des affaires juridiques :

- Prend en charge les affaires d’ordre juridique de la direction régionale, et les mesures
permettant d’assurer le recouvrement des créances de toutes natures.
- Examiner et traiter les demandes d’indemnisation, ainsi que le suivi de l’exécution
des décisions de justice.
c. Chargé de la sécurité :
- Planifier des visites avec programmation des actions de sensibilisation.
- Préparer les simulations d’incidents gaz et électricité avec les services technique.
- Participer aux prévisions d’équipements matériels de sécurité.
d. Chargé de la sureté interne :

- Suivre d’une manière permanente tous les aspects de la sureté interne de la direction
régionale et service technique d’électricité et gaz (district), ainsi que les services
commerciaux/ subdivisions commerciales (agences).
- Faire des visites périodiques des structures relevant de la direction régionale pour
contrôle de l’état du dispositif de la sureté interne.
e. Division relations commerciales :

- Cette division est chargée de l’inspection et du contrôle. Son rôle consiste à élaborer
des actions commerciales et le développement des ventes, apporter assistance aux
clients. Elle a aussi le rôle de repérer les clients potentiels à travers les différents
circuits d’information, contrôler la relève, la facturation et le recouvrement de la
clientèle.
Organigramme :
Division Relations Commerciales

Agence
Commerciale
Service techno-commercial Service Clientèle
Figure 8 : Organigramme de la division relations commerciales.
21
f. Division Etude d’exécution de travaux d’électricité et gaz :
Cette division est chargée de :
- La maitrise d’œuvre.
- Etude de travaux électricité et gaz.
- La gestion des investissements en matière de crédit et d’ordonnancement.
Organigramme :
Division étude d’exécution des

travaux électricité et gaz
Service Etude et Travaux Subdivision Marché

Electricité
Subdivision Gestion des Service Etude et Travaux Gaz

Investissements
Figure 9 : organigramme de la Division étude d’exécution des travaux électricité et gaz.
g. Division finance et comptabilité :
Elle est chargée d’assurer les règlements décentralisés, procéder au suivi des
rapprochements des comptes bancaires et CCP ainsi qu’à l’élaboration du tableau de bord et
du budget annuel de la direction régionale et assurer les travaux de contrôle et
comptabilisation de toutes les opérations de cette dernière.
Organigramme :
Division Finance et comptabilité
Service Finance Service Exploitation Comptable Service Budget et Contrôle

de Gestion
Figure 10 : Organigramme de la Division Finance et Comptabilité.
22
h. Division d’Exploitation :
Le service exploitation est chargé de la supervision, de la conduite et la surveillance des

installations de production et de l’élaboration du programme d’essais, d’analyse et de
contrôle des équipements, pour l’amélioration de leurs performances. Il a aussi pour mission
d’assurer la continuité de service de la disponibilité des moyens de production.
i. Division des Ressources humaines :
Elle est chargée de gérer les agents et les apprentis, élaborer les prévisions budgétaires et
les plans de formation et de carrières. Elle est chargée de la préparation et réalisation des
plans de recrutements de l’unité.
Organigramme :
Division Ressources Humaines
Service Administration Service Formation
Figure 11 : Organigramme de la Division des Ressources Humaines.
j. Division des Affaires Générales :
Elle est chargée de la gestion des moyens internes et des affaires générales de l’unité. Elle
assure les activités suivantes :
- La gestion du parc véhicules de l’unité et le transport des agents.

- La gestion immobilière.
- La gestion de la documentation, archives et courriers.
- Les travaux de reproduction.
- Gestion de l’ensemble des moyens et matériels utilisés par la direction de
distribution de Tizi-Ouzou.
k. Division de Gestion des Systèmes Informatiques :

- Elle est chargée de gérer le centre de traitement informatique et la promotion des
systèmes au niveau de la direction générale.
- Assurer la gestion du centre de traitement informatique.
- Gérer l’ensemble du matériel informatique et périphérique affecté à la direction
régionale.
23
- Approvisionner et contrôler la fourniture en consommables.
- Veiller à la maintenance des systèmes.
- Développer les applications propres à la direction régionale.
3. Problématique :
Notre étude se déroule entre les deux sites : la division de gestion des systèmes
informatiques « DGSI », et la subdivision des affaires générales « SAG » au niveau de la
direction de distribution de Tizi-Ouzou, concernant le suivi de la gestion du matériel
informatique. Afin d’invoquer la problématique rencontrée, on va d’abord commencer par
une description des flux existants et la relation qu’il y a entre ces deux services.
3.1. Description des flux d’informations existants :
• Chaque année, la SAG établit une liste de tout le matériel informatique manquant à
la direction de distribution de Tizi-Ouzou et ses agences. Cette liste est accompagnée
par un bilan annuel des couts des achats, et est envoyée à la division de finance et
comptabilité DFC.
• Après étude, la division comptabilité et finances alloue un budget annuel qui va
couvrir l’ensemble des achats de la SAG pendant une année.
• La liste de tout le matériel informatique manquant est communiquée à la direction
des affaires générales DAG se trouvant à Blida, qui à son tour s’occupe de faire le
grand achat et de le fournir au niveau de la SAG de Tizi-Ouzou.
• Cette fourniture est accompagnée par « un bordereau » d’expédition, dans le quel
sont mentionnés : la quantité, la désignation et le prix de chaque matériel fourni. Ce
bordereau est envoyé en deux exemplaires qui seront signés par le directeur de la
distribution de Tizi-Ouzou. La DFC gardera un exemplaire, et l’autre sera archivé au
niveau la SAG.
• La DGSI teste l’ensemble du matériel informatique fourni, pour détecter les défauts
et les anomalies pouvant paraitre sur celui-ci. Si le matériel est défectueux, il sera
réexpédié vers la direction des affaires générales de Blida DAG. S’il est bon, la SAG
s’occupera de l’enregistrer et de le stocker dans ses magasins, et il sera par la suite
expédié vers la division ou le district qui le sollicitera.
• L’enregistrement du matériel (informatique, bureautique et autre) se fait par deux
agents à la subdivision des affaires générales SAG. L’enregistrement consiste en
l’attribution d’un code barre interne à la direction de distribution de Tizi-Ouzou ainsi
que d’autres coordonnées comme le numéro de série déjà existant. Le tout sera
porté dans un fichier électronique se trouvant sur Microsoft Excel appelé fichier
auxiliaire.
• Dans le fichier auxiliaire, on trouve des informations concernant chaque matériel : le
code barre, l’affectation, le type, la désignation, le numéro de série, la marque, le
mode et type, et l’observation concernant le matériel.
24
• Si une division ou un district sollicite un matériel quelconque appart le matériel

informatique, ceci se fait par le biais d’une demande de prestation de service dans
laquelle sont mentionnées : la quantité et la désignation du matériel sollicité.
• En ce qui concerne le matériel informatique, c’est la DGSI qui s’occupe de recenser le
matériel manquant au niveau des divisions et districts de la direction de distribution
de Tizi-Ouzou, et décide de son affectation.
• L’affectation est accompagnée par une « décision d’affectation » dans laquelle sont
portés : la quantité, la désignation, et le prix total du matériel en deux exemplaires.
• Ces deux exemplaires seront signés par le récepteur du matériel (agent de la division
ou district) puis seront renvoyés au directeur pour signature. un exemplaire sera
remis à la division finance et comptabilité pour justification, et l’autre sera archivé au
niveau de la SAG.
• Une mise à jour est portée au fichier auxiliaire à chaque modification portée au
matériel, exemple sur le déplacement ou autres changements. La mise à jour du
fichier auxiliaire est assurée par l’agent de la SAG.
• Une base de données intitulée « matériel informatique » est disponible au niveau de
la DGSI, celle-ci comporte le fichier auxiliaire concernant le matériel de type
informatique. Elle est mise à jour à chaque nouvelle fourniture après enregistrement,
et à chaque affectation du matériel informatique vers une division ou un district
quelconque, pour garder sa traçabilité.
3.2 Problématique rencontrée :
La problématique rencontrée concerne la mise à jour de la base de données se trouvant à

la DGSI : Les informations protées au fichier auxiliaire de la SAG concernant le matériel
informatique, doivent être les mêmes que celles portées à la base de données de la DGSI. Ce
qui n’a pas été toujours le cas, car le manque de communication entre les deux divisions a
conduit à un manque de disponibilité d’information, et probablement à des erreurs de
gestion.
Pour pallier à ce problème, nous avons décidé de mettre en œuvre une base de données
au niveau de la SAG sous le SGBD Oracle 9i pour la transformation du fichier auxiliaire se
trouvant sur Microsoft Excel. Et à travers une vue de cette base de données concernant le
matériel de type informatique uniquement, ce qui nécessitera d’effectuer une
fragmentation horizontale, on va permettre à la DGSI de consulter le suivi et la gestion de
l’ensemble de ce matériel et extraire toutes les informations nécessaires pour la mise à jour
de sa base de données, à travers un réseau local qu’on va installer entre ces deux services.
Avec cette manière, on parviendra à garder la confidentialité des informations jugées privées
au niveau de la SAG, portant sur l’ensemble du matériel autre que celui d’informatique.
4. Les services du champ d’étude et les documents manipulés :

A. la subdivision des affaires générales SAG : (tableau 1):
25
Fiche d’étude du poste Nº 01
Désignation du poste : Gestion de stock.

Service de rattachement : Subdivision affaires générales SAG.
Nombre d’agents : 02, un archiviste et un gestionnaire de stock.
Responsabilité : gestion du stock se trouvant au niveau de la SAG
Taches du poste
- Enregistrer le nouveau matériel à chaque nouvelle fourniture, par l’attribution d’un code
barre interne à l’entreprise, et d’un numéro de série.
- Porter les informations du matériel enregistré sur le fichier auxiliaire.
- Veiller à la mise à jour du fichier auxiliaire, en gardant la traçabilité de l’ensemble
matériel manipulé par la SAG.
- Archiver les différents documents utilisés par la SAG, dans des boites d’archivage portant
une date indiquée par le mois et l’année selon la chronologie du document.
- Etablir la liste du matériel manquant chaque fin d’année.
Documents entrants provenance Documents sortants Destination
Bordereau Direction affaires Décision d’affectation Service vers le quel sera

d’expédition générales DAG de affecté le matériel
Blida
Demande de Service ou division

prestation de service sollicitant un
_ _
matériel
quelconque
A.1 Liste des documents manipulés par la subdivision des affaires générales, pour la
gestion du matériel (tableau 2):
Nº CODE DESIGNATION
01 BE Bordereau d’expédition
02 DPS Demande de prestation de service
03 DA Décision d’affectation
04 FA Fichier auxiliaire
26
B. Division de gestion des systèmes informatiques (tableau 3) :
Fiche d’étude du poste Nº 02
Désignation du poste : Gestion du matériel informatique.

Service de rattachement : Division de gestion des systèmes informatiques DGSI.
Nombre d’agents : 01.
Responsabilité : gestion et maintenance de l’ensemble du matériel informatique de la direction
de distribution de Tizi-Ouzou
Taches du poste
- Veiller à la mise à jour de la base de données disponible au niveau de la DGSI à chaque

nouvelle fourniture, ou affectation du matériel informatique vers un site le sollicitant,
pour le suivi parfait de sa traçabilité.
- Recenser le matériel informatique manquant au niveau de la direction de distribution de
Tizi-Ouzou et l’ensemble de ses agences, et districts.
- Tester le matériel informatique fourni par la DAG.
- Etablir une décharge à chaque affectation du matériel informatique, qui sera archivée par
la suite au niveau de la DGSI et SAG « en deux exemplaires ».
Documents entrants provenance Documents sortants Destination
-Demande de -Subdivision affaires

prestation de service générales SAG.
_ _
DPS
_ _ -Décharge -Subdivision affaires

générales SAG.
B.1 Liste des documents manipulés par la DGSI (tableau 4) :
Nº CODE DESIGNATION
05 DEC Décharge
06 DPS Demande de prestation de service
07 FA Fichier auxiliaire
27
Remarque :
Le fichier auxiliaire et la demande de prestation de service utilisés par la DGSI, sont les
mêmes que ceux utilisés par la SAG. Sauf que la DGSI n’utilise qu’une partie précise du
fichier auxiliaire concernant le matériel informatique.
5. Etude des documents :

5.1 Les documents de la subdivision des affaires générales SAG :
Fiche d’étude du document Nº 01 : Bordereau d’expédition (tableau 5) :
Code et rôle du document
Code : BE
Désignation : Bordereau d’expédition.
Rôle : Ce document contient la quantité, la désignation et le montant de l’ensemble du matériel

fourni De la DAG de Blida à la SAG de Tizi-Ouzou.
Caractéristiques du document
Nature : Externe.
Acheminement du document
Provenance Transit Destinataire archivage
Direction affaires Division comptabilité et Subdivision affaires Boites d’archivage au

générales de Blida finance DFC générales SAG niveau de la SAG
DAG
Élément d’information
Attribut Désignation Type Taille
Qte Quantité N 3
Des-Mat Désignation des AN 50

matériels
Num-Ser Numéro de série AN 20
Mnt Montant N 30
28
Dest destinataire A 30
Dat-Exp Date d’expédition N 10
Nom-Rec Nom de l’agent A 30

récepteur
Fiche d’étude du document Nº 02 : Demande de prestation de service (tableau 6).
Code : DPS
Désignation : Demande de prestation de service.
Rôle : Ce document est utilisé pour demander la fourniture d’un matériel quelconque au niveau de la
subdivision des affaires générales SAG.
Nature : interne
Divisions et districts Le document ne Subdivision affaires Subdivision affaires

sollicitant le transite pas par un générales SAG. générales SAG.
matériel. service intermédiaire.
Num-Dem Numéro de la demande N 6
Serv-Exp Service Expéditeur A 50
Serv-Dest Service Destinataire A 50
Qte Quantité N 3
Des Désignation AN 50
29
Impu-Dep Imputation des N 10

dépenses

récepteur.
Fiche d’étude du document Nº 03 : décision d’affectation (tableau 7).
Code : DA
Désignation : Décision d’affectation.
Rôle : Ce document est destiné au service ou division vers le quel sera affecté le matériel
informatique, portant ainsi la quantité et désignation du matériel.
Nature : interne
Subdivision affaires lors de l’envoi, pas de Service ou district L’archivage se fait après le
générales SAG service intermédiaire. sollicitant le matériel. renvoi du document.
Signé et renvoyé Directeur. Subdivision affaires Boite d’archivage au niveau

par le récepteur du générales SAG. de la SAG.
Division finances et
matériel.
comptabilité DFC.
Num Numéro de la décision AN 20
Dat-Etab Date d’établissement N 10

de la décision.
30
Qte Quantité N 3
Cod-Bar Code barre N 10
Obs Observation AN 30
Dat-Rec Date de réception de la N 10

décision.

récepteur.
Fiche d’étude du document Nº 04 : Fichier auxiliaire (tableau 8).
Code : FA
Désignation : Fichier auxiliaire.
Rôle : Ce document est utilisé pour enregistrer et garder la traçabilité de tout le matériel manipulé
par la SAG.
Nature : interne
Subdivision affaires Le document est Subdivision affaires Disque dur de la subdivision

générales SAG. interne à la SAG. générales SAG. affaires générales SAG.
Cod-Bar Code Barre. N 10
Afect Affectation A 30
31
Typ Type A 10
Marq Marque A 30
Mod-Typ Mode et Type AN 30
5.2 Les documents de la division de gestion des systèmes informatique DGSI :
Fiche d’étude du document Nº 05 : Décharge (tableau 9).
Code : DEC
Désignation : Décharge.
Rôle : Ce document est établi par la DGSI à chaque affectation du matériel informatique vers un
destinataire l’ayant sollicité, en deux exemplaires.
Nature : interne
Division de gestion Pas de service Division ou district vers Pas d’archivage lors de
des systèmes intermédiaire lequel a été affecté le l’envoi du document
informatiques DGSI matériel informatique
Signé et renvoyé Pas de service Division de gestion des 1 exemplaire stocké dans la
par le récepteur du intermédiaire systèmes informatique boite d’archivage de DGSI
matériel-info. DGSI
1 exemplaire stocké dans la
boite d’archivage de la SAG.
32
Num-Dec Numéro de la décharge AN 20
Dat-Etab Date d’établissement N 10

de la décharge
Nom-Rec Nom du récepteur A 30
Qte Quantité N 3
Cod-Bar Code barre N 10
Fiche d’étude du document Nº 06 : Demande de prestation de service (tableau 10).
Code : DPS
Désignation : Demande de prestation de service.
Rôle : Ce document est utilisé pour demander la fourniture d’un matériel quelconque au niveau de la
SAG, sauf le matériel informatique.
Nature : interne
Division de gestion Le document ne Subdivision affaires Subdivision affaires

des systèmes transite pas par un générales SAG. générales SAG.
informatiques DGSI service intermédiaire.
Num-Dem Numéro de la demande N 6
33
Serv-Exp Service Expéditeur A 50
Serv-Dest Service Destinataire A 50
Qte Quantité N 3
Impu-Dep Imputation des N 10

dépenses

récepteur.
Fiche d’étude du document Nº 07 : Fichier auxiliaire concernant le matériel de type

informatique (tableau 11) :
Code : FA
Désignation : Fichier auxiliaire.
Rôle : Une partie du fichier auxiliaire se trouvant à la SAG, sert à mettre à jour la base de données
qui est au niveau de la DGSI portant sur le matériel informatique, à fin de garder la traçabilité et les
informations de ce dernier après enregistrement.
Nature : interne
Subdivision affaires Pas de service Division de gestion des Disque dur de la subdivision
générales SAG. intermédiaire. systèmes informatiques affaires générales SAG.
DGSI.
34
Cod-Bar Code Barre. N 10
Afect Affectation A 30
Typ Type A 10
Masrq Marque A 30
Mod-Typ Mode et Type AN 30
6. Diagramme des flux:

Apres avoir décrit les flux d’informations entre les deux champs d’étude SAG et DGSI, il est
important de les recenser et de les schématiser dans un diagramme, montrant ainsi les la
circulation des informations entre acteurs internes et externes.
Le diagramme des flux permet de :
• Mieux identifier les acteurs internes et externes au domaine d’étude.

• Identifier les flux échangés entre les acteurs.
• Délimiter les champs du projet.
6.1 Concepts utilisés :
a. Acteur : En règle générale, un acteur représente un rôle qu’un homme, une machine ou
même un système joue avec un autre système. Il est représenté par un petit personnage.
b. Flux : graphiquement, il est représenté par une flèche orientée de l’acteur émettant vers
l’acteur recevant. Le libellé du flux est inscrit à coté de la flèche tracée.
c. La légende (tableau 12) :
35
6.2 Liste des flux (tableau 13) :
Code Désignation
01 Etablissement de la liste du matériel informatique manquant et son montant à la DFC.
02 Envoi de la liste du matériel manquant pour la DAG.
03 Fourniture du nouveau matériel selon la liste.
03.a Bordereau d’expédition.
03.b Bordereau signé par le directeur.
03.c Archivage d’un exemplaire du bordereau d’expédition par la DFC.
03.d Archivage d’un exemplaire du bordereau d’expédition par la SAG.
04 Tester le nouveau matériel informatique par DGSI.
04.a Réexpédition du matériel informatique défectueux.
05 Réception du matériel informatique testé de la DGSI.
06 Enregistrement du nouveau matériel dans le fichier auxiliaire.
07 Recensement du matériel informatique manquant au niveau des divisions.
07.a Demande de fourniture en matériel informatique pour un service quelconque par DGSI
08 Etablissement d’une décision d’affectation.
08.a Fourniture du matériel sollicité.
09 Remise de la décision d’affectation.
09.a Signature de la décision d’affectation par le directeur.
09 .b Archivage de la décision d’affectation au niveau de la SAG.
10 Etablissement d’une décharge au niveau de la DGSI.
11 Mise à jour du fichier auxiliaire global par la SAG.
12 Mise à jour de la BDD matériel-Info. Au niveau de la DGSI.
6.3 Diagramme des flux :
36
(2)
DAG DFC
(3.c)
(4.a) (3), (3.a)

(1)
(5), (6), (7.a), (9)
DGSI SAG
(4)
(12) (11)
(8), (8.a)
(7)
(9) (3.b), (9.a) (3.d), (9.b)
Service ou DIRECTEUR
Division
Figure 12: Diagramme des flux.
37
7. Modèle organisationnel des traitements existant MOT :

L’objectif de cette étape est de fournir une représentation schématique de
l’organisation existante de l’entreprise. A cette étape, on doit répondre aux questions : OU
? QUI ? Et QUAND ?
A la première interrogation répondra le poste de travail concerné, à la seconde le

choix entre un traitement automatique ou manuel, et à la dernière question on précisera le
déroulement dans le temps des différentes actions.
7.1 Concepts de base utilisés :
• La procédure : Elle est constituée d’un ensemble de phases, déclenchées par un ou

plusieurs événements externes pour produire un résultat.
• La phase : C’est un sous ensemble de la procédure dont les traitements se font
dans la même périodicité, nature et manière d’exécution.
• La tâche : Une tâche est un ensemble de traitements élémentaires exécutés à
l’intérieur d’une phase.
• L’événement : C’est un fait réel dont le but est de déclencher l’exécution d’une ou
plusieurs tâches.
• La synchronisation : Elle correspond à une règle associant les événements à
l’aide des connecteurs logiques. Elle exprime les conditions requises pour déclencher
une série d’événements.
• Les règles d’émissions : Condition traduisant les règles de gestion et
d’organisation, à laquelle est soumise l’émission des résultats d’une phase.
• Les résultats : C’est le produit de l’exécution d’une phase. C’est un fait réel de
même nature que l’événement, et pourra être un déclencheur d’une autre
phase.
7.2 Le formalisme utilisé (tableau 14):
38
Période Enchainement des phases Poste de travail
Evènement 1 Evènement N
ET /O
Nº Nom de la phase
Nature Règle d’émission
Résultat 01 Résultat N
a. Liste des procédures manipulées (tableau 15) :
Voici la liste des procédures manipulées entre la DGSI et la SAG, concernant le matériel de
type informatique dans le système existant :
Nº Nom de la procédure
01 Fourniture du nouveau matériel
02 Teste du nouveau matériel
03 Enregistrement du nouveau matériel
04 Mise à jour de la base de données DGSI
05 Affectation du matériel
b. Description des procédures :
39
Procédure Nº 01 : Fourniture du nouveau matériel informatique (tableau 16) :
Arrivée du matériel Bordereau

informatique fourni par la DAG d’expédition
A l’arrivée Subdivision des

du matériel affaires générales
informatique SAG
au début de
l’année ET
01 Signature du bordereau par le directeur.
02 Transite du bordereau par la DFC pour

justification, et archivage d’une copie.
03 Archivage d’une copie du bordereau au

niveau de la SAG
MA Toujours
Bordereau Matériel
d’expédition informatique
archivé disponible
40
Procédure Nº 02 : Teste du nouveau matériel informatique (tableau 17) :
Envoi du nouveau matériel

informatique fourni, à la
DGSI
Apres la Division de gestion
fourniture des systèmes
du matériel informatiques
informatique
DGSI
01 Tester tout le nouveau matériel informatique

fourni, par l’agent de la DGSI
MA Toujours
Garder le matériel jugé Réexpédition du

bon après le teste, au matériel défectueux à
stock de la SAG la DAG
41
Procédure Nº 03 : Enregistrement du matériel informatique testé (tableau 18) :
Réception du matériel
informatique provenant de
la DGSI après le teste
A la remise Subdivision affaires
du bon générales SAG
matériel
informatique
à la SAG
01 Attribution d’un code barre interne au

matériel informatique.
02 Enregistrement du nouveau matériel dans le

fichier auxiliaire
MA Toujours
Nouveau matériel Fichier auxiliaire

informatique mis à jour
enregistré
42
Procédure Nº 04 : Mise à jour de la base de données matériel-informatique se
trouvant au niveau de la DGSI (tableau 19) :
Réception du fichier
auxiliaire portant sur le
matériel informatique
Apres Division de gestion
enregistrement des systèmes
du matériel au informatiques
fichier
DGSI
auxiliaire
01 Enregistrement du nouveau matériel

informatique dans la base de données
MA Toujours
Matériel informatique Base de données

enregistré dans la base mise à jour
de données DGSI
43
Procédure Nº 05 : Affectation du matériel informatique (tableau 20):
Réception de la décharge
établit par la DGSI
Lors du Subdivision des

recensement affaires générales
du matériel SAG
informatique
manquant
par DGSI
01 Etablissement d’une décision d’affectation
02 Affectation du matériel informatique au

service recensé par DGSI
03 Mettre à jour le fichier auxiliaire par

actualisation de l’affectation.
MA Toujours
Matériel informatique Fichier auxiliaire mis à

affecté jour
8. Conclusion :
Au cours de ce chapitre, nous avons essayé de décrire au mieux la situation existante et le
fonctionnement de notre organisme d’accueil. Cependant, nous avons remarqué qu’il y a un
inconvénient concernant le partage d’information réclamée par la DGSI au niveau de la SAG
pour la mise à jour de sa base de données, due à l’absence d’un réseau local entre les deux
services. Au cours de l’étude conceptuelle qui suit, nous allons essayer de pallier à ce
problème par la mise en œuvre d’une architecture repartie, permettant ainsi d’avoir
l’information en temps réel à travers une vue d’une partie de la base de données de la SAG
qui sera allouée à la DGSI, et accessible via un réseau.
44
Chapitre III
Analyse et Conception
Chapitre III Analyse et Conception
1. Introduction :
Au cours du chapitre précédent, nous avons recueilli toutes les informations
nécessaires au fonctionnement du système existant ainsi qu’aux acteurs intervenants. Dans
ce chapitre, on va aborder l’étude conceptuelle de notre base de données repartie avec le
langage de modélisation UML, illustrant ainsi la démarche orientée objet, à fin de concevoir
un système qui pourra répondre aux besoins des deux services du champ d’étude.
Notre démarche s’articule au tour de deux étapes : L’analyse et la conception.
• En phase d’analyse, nous mettons en évidence les acteurs du système et leurs

interactions.
• En phase de conception, nous présentons les descriptions détaillées des résultats de
l’analyse.
La figure suivante montre La représentation graphique de la démarche de modélisation

que nous avons choisie pour concevoir notre application :
Figure 13: Représentation graphique de la démarche de modélisation.
2. Analyse :
Dans cette partie nous allons spécifier d’une manière bien détaillée et claire les
interactions significatives (interaction entre le système et les acteurs, interaction entre les
objets) du point de vue de la base de données de gestion et suivi du matériel manipulé par la
SAG de la direction de distribution de Tizi-Ouzou. Pour cela nous allons procéder en premier
lieu à la détermination d’une manière globale de ce qui se trouve dans le champ de
l’application.
46
2.1. Présentation :
Notre base de données s’occupe essentiellement de la gestion et le suivi du matériel divers

et informatique, depuis son arrivée jusqu’à son affectation à un district ou une agence le
sollicitant, permettant ainsi le partage d’un taux d’information suffisant entre les deux
services du champ d’étude à travers le réseau local mis en œuvre.
2.2 Définition des besoins :
Notre travail consiste à :
• Transformer une base de données existante sur Microsoft Excel appelée « Fichier
auxiliaire » se trouvant au niveau de la subdivision des affaires générales SAG, en une
base de données sous le SGBD Oracle.
• Cette base de données comportera toutes les coordonnées et traçabilités de
l’ensemble du matériel manipulé par la SAG y compris le matériel informatique.
• Attribuer les droits d’administration « Ajout, mise à jour… » à l’agent de la SAG
responsable de la gestion du stock et du fichier auxiliaire.
• Mise en œuvre d’un réseau informatique local, entre la SAG et la DGSI.
• Implémenter une vue sous Oracle de cette base de données, portant uniquement sur
le matériel de type informatique.
• Permettre à la division de gestion des systèmes informatiques DGSI de consulter la
vue de la base de données en se connectant à l’application, grâce au réseau local
établi entre les deux services. Ainsi, extraire les informations nécessaires à la mise à
jour de sa base de données, et éviter les erreurs.
2.3 Définition des acteurs :
Durant la période de stage qu’on a effectué au sein de notre organisme d’accueil, nous
avons procédé en premier lieu à la localisation des centres d’activité de la gestion du
matériel, et en second lieu on a identifié les principaux acteurs qui seront les futurs
utilisateurs de la base de données :
• Administrateur (Admin) : gère particulièrement les accès à la base de données, et

s’occupe aussi de la maintenance du système.
• Agent de la subdivision des affaires générales SAG : qui a pour missions
d’enregistrer, modifier, et supprimer le matériel divers ainsi que le matériel
informatique.
• Agent de la division de gestions des systèmes informatiques DGSI : qui a pour
missions dans le nouveau système de se connecter à l’application pour consulter la
vue qui contient toutes les coordonnées du matériel informatique.
2.4 Diagramme de contexte :
47
Le diagramme de contexte est un modèle conceptuel de flux qui permet d'avoir une vision
globale des interactions entre le système et les liens avec l'environnement extérieur. Il
permet aussi de bien délimiter le champ d’étude. Pour notre cas le diagramme de contexte
est donné par la figure suivante:
Base de données repartie pour la gestion et

suivi du matériel divers et informatique.
ADMIN
SAG DGSI
Figure 14 : Diagramme de contexte.
2.5 Identification des espaces :
A chaque agent est identifié un espace qui regroupe toutes les actions et tâches qu’il peut
effectuer. Pour notre application on a identifié 3 espaces :
• Espace administrateur (Admin).

• Espace agent de la subdivision affaires générales SAG.
• Espace agent de la division de gestion des systèmes informatiques DGSI.
3. Conception :
Le processus de conception de notre système comprend deux niveaux :
• Le niveau applicatif.
• Le niveau de données.
Le niveau applicatif : S’appuie essentiellement sur quelques diagrammes d’extension

pour les applications web du langage de modélisation UML. A cet effet, nous avons
adopté la démarche suivante :
• Après l’identification des différents acteurs, ainsi que les différentes fonctions du
système à concevoir durant la partie d’analyse, nous allons mettre en évidence
les cas d’utilisations mis en œuvre par les différents acteurs du système.
48
•Le diagramme de cas d’utilisation global est élaboré, ensuite des diagrammes de
cas d’utilisation plus détaillés seront présentés.
• A l’aide des diagrammes de séquence, on formalise graphiquement le ou les
scénarios qui décrivent chaque cas d’utilisation.
• Le diagramme de déploiement nous aidera à donner une schématisation des
différents nœuds du système.
• A partir des diagrammes d’activités, on identifie les classes, ensuite des
diagrammes de classes généraux sont élaborés.
Le niveau Données : Ce niveau concerne l’organisation conceptuelle, logique et
physique des données. Les données de l’application sont identifiées durant la phase
d’analyse de notre démarche au niveau applicatif, les classes significatives seront
dégagées, à ce stade, la conception de la base de données peut être élaborée.
La démarche que nous avons adoptée pour la conception de notre base de données
s’étale sur les étapes suivantes :
• Elaboration du diagramme de contexte du système à étudier.

• Identification et représentation des cas d’utilisation.
• Elaboration des diagrammes de séquences.
• Elaboration des diagrammes d’activités.
• Elaboration du diagramme de déploiement.
• Elaboration des diagrammes de classes généraux.
3.1 Le niveau applicatif :

Représentation des diagrammes de cas d’utilisation :
Définition d’un cas d’utilisation :
La description d’un cas d’utilisation définit ce qui survient dans le système quand le cas est
exécuté. Il correspond à une séquence d’actions exécutée par le système et qui fournit un
résultat à un acteur particulier. Il permet de décrire ce que le système devra faire, sans
spécifier comment le faire.
Diagramme de cas d’utilisation :
Représente un ensemble de cas d’utilisation et d’acteurs avec leurs relations. Ils

présentent la vue statique des cas d’utilisation d’un système.
Dans ce qui suit nous allons identifier les différents cas d’utilisation.
Diagramme de cas d’utilisation global :
La figure suivante montre le diagramme global des cas d’utilisation de la base de données
gestion et suivi du matériel :
49
Gérer le matériel
« include »
« include »
Mise à jour de la Vue
Matériel-Informatique
SAG « include »
Consulter la vue Matériel-
Informatique
Authentification
« include »
DGSI Gérer les accès à la base de

données
« include »
Maintenance du système
Admin
Figure 15 : Diagramme de cas d’utilisation global.

Diagrammes de cas d’utilisation détaillés :
- Diagramme de cas d’utilisation « gérer le matériel » :
Connexion à l’espace SAG
Ajouter nouveau matériel
Modifier matériel
SAG Consulter matériel
Supprimer matériel
Figure 16 : Diagramme de cas d’utilisation « gérer matériel ».
50
Diagramme de cas d’utilisation « Mise à jour de la vue » :
Connexion à l’espace SAG
Ajouter matériel-informatique
Modifier matériel-informatique
SAG
Supprimer matériel-informatique
Figure 17 : Diagramme de cas d’utilisation « mise à jour vue ».
- Diagramme de cas d’utilisation « Consulter vue » :
Connexion à l’espace DGSI
Entrer en rubrique de consultation

DGSI
Figure 18 : Diagramme de cas d’utilisation « Consulter vue ».
- Diagramme de cas d’utilisation pour l’espace administrateur :
Création de nouveaux utilisateurs
Attribution de privilèges et rôles
Admin
Maintenance et extension de la BDD
Figure 19 : Diagramme de cas d’utilisation pour l’espace administrateur.
51
Diagrammes de séquence :
Les diagrammes de séquences sont utilisés pour croiser la description des classes et des
cas d’utilisation, ils montrent les interactions entre objets selon un point de vue temporel.
On définie ainsi le rôle joué par les objets dans la réalisation des scénarios, ainsi que les
mécanismes de collaboration associés.
Ces diagrammes peuvent être utilisés pour modéliser les responsabilités et les
collaborations sans prendre en compte les mécanismes définis par l’architecture du
système. Ils permettent de mieux visualiser la séquence des messages par une lecture de bas
en haut. L’axe vertical représente le temps et l’axe horizontal représente les objets qui
collaborent, une verticale en pointillé est attachée à chaque objet qui représente sa ligne de
vie.
- Diagramme de séquence pour le cas d’utilisation « Authentification » :
Page Utilisateur Construit

d’accueil
page
Utilisateur
Atteint
Affiche
Remplit
Valide Ramène
Atteint
Accès refusé
Atteint
Construit
Affiche
Figure 20 : Diagramme de séquence « Authentification ».
Le scénario nominal du cas d’utilisation « Authentification » :
• L’utilisateur atteint la page d’accueil et clique sur Entrer.

• Le système affiche le formulaire d’authentification.
52
• L’utilisateur remplit le formulaire et le soumet.

• Le système contrôle les informations, atteint la page utilisateur si les informations
sont correctes, sinon il affiche un message d’erreur.
• Le système affiche un message de confirmation.
- Diagramme de séquence pour « Ajouter matériel » :
Espace MSG
SAG confirm.
SAG
Atteint
Affiche
Atteint
Affiche
Saisit et soumet
Atteint
Construire
Figure 21 : Diagramme de séquence « Ajouter matériel ».
Le scenario nominal du cas d’utilisation « Ajouter matériel » :
• L’agent de la SAG atteint son espace.

• Il sélectionne la rubrique ajouter-matériel dans la barre d’outils.
• Le système crée automatiquement un nouveau champ vide pour saisir le nouveau
matériel.
53
• L’agent rempli le champ de saisi puis enregistre, et le nouveau matériel s’enregistre

automatiquement.
- Diagramme de séquence pour « Consulter vue » :
Espace
DGSI
DGSI
Atteint
Affiche
Construit
Affiche
Figure 22 : Diagramme de séquence « Consulter vue ».
Le scenario nominal du cas d’utilisation « Consulter Vue » :
• L’agent DGSI atteint son espace après authentification.

• Il tombe directement sur le fichier auxiliaire contenant les coordonnées du matériel
informatique, puis il consulte.
Diagramme de déploiement :
Les diagrammes de déploiement montrent la disposition physique des différents nœuds

(matériels) qui entrent dans la composition d’un système, et la répartition des programmes
exécutables sur ces nœuds.
Pour notre application, on aura à implémenter deux nœuds :
• Le poste navigateur (client) de la DGSI, qui va consulter une partie de la base de

données à distance via un réseau local entre les deux services.
• Le poste administrateur (serveur) dans le quel sera programmée la base de données
qui va contenir les tables et les vues nécessaires à l’application, ainsi que le serveur
de base de données Oracle et le serveur d’application Forms builder.
54
- Diagramme de déploiement pour notre application :
Niveau 1 Niveau 2
Poste LAN Poste

navigateur DGSI administrateur
SAG, Oracle 9i,
Forms builder 10g
Serveur de données
Client
et d’application
Figure 23 : Diagramme de déploiement.
Diagrammes d’activité :
Le diagramme d’activités fait partie des cinq diagrammes d’UML utilisés pour la
modélisation des aspects dynamiques des systèmes. C’est une variante des diagrammes
d’états transition organisé par rapport aux actions et principalement destiné à préciser des
spécifications sous une forme procédurale, soit au niveau du domaine (enchaînement des
processus et logique applicative), soit au niveau du système (algorithmes et scripts
d’exploitation).
- Diagramme d’activité du cas d’utilisation « Authentification » :
Figure 24 : Diagramme d’activité pour « Authentification ».
55
- Diagramme d’activité pour le cas d’utilisation « Ajouter matériel » :
Figure 25 : Diagramme d’activité pour « Ajouter matériel ».
- Diagramme d’activité pour le cas d’utilisation « Consulter vue » :
Figure 26 : Diagramme d’activité pour « Consulter vue ».
56
Diagrammes de classes généraux:
Les diagrammes de classes sont les plus courants dans la modélisation des systèmes
orientés objets, ils fournissent le cadre dans lequel s’organise le développement des objets
du système. Ils représentent un ensemble de classes, d’interfaces et de collaboration ainsi
que leurs relations. Ces diagrammes sont utilisés pour modéliser la vue de conception
statique.
Dans ce qui suit nous allons présenter les diagrammes de classes de quelques cas
d’utilisation.
- Diagramme de classes du cas d’utilisation « Authentification » :
Figure 27 : Diagramme de classe pour « Authentification ».
- Diagramme de classe pour le cas d’utilisation « Ajouter matériel » :
Figure 28 : Diagramme de classe pour « Ajouter matériel ».
57
Découpage du système en packages :
Pour rendre le diagramme de classe du système plus aisé à comprendre, nous allons le
découper selon un critère fonctionnel en packages. Le package contient les éléments du
modèles c'est-à-dire les classes, diagrammes, composants et interfaces.
Ce principe s’applique généralement lorsqu’on a à manipuler un nombre potentiellement

élevé de classes, d’interfaces, de composants, de diagrammes et autres éléments (la
résolution de problèmes complexes).
La figure suivante montre les packages de notre système :
Espace SAG Espace DGSI Espace

Administrateur
Figure 29 : Les packages du système futur.
Pour le diagramme de classe général de chaque package, nous avons choisi d’utiliser la
légende suivante :
Client
Formulaire
Serveur
- Diagramme de classe du package espace SAG :
58
«submit » Redirect
Page Page Build Form. Authentif. MSG

d’accueil authen. Authentif. SAG Erreur
SAG
« Link »
« Link »
« Link »
Submit Redirect
Fichier Form. Ajouter MSG
Espace
auxiliaire ajouter matérie Erreur
SAG
matériel
« Build »
MSG
Confirmation
« Link »
Form. Supprimer MSG

sélection matériel Erreur
Submit
matériel
« Redirect »
« Build »
MSG
Confirmation
« Link »
« Submit » MSG
Modifier
Erreur
matériel
« Redirect »
« Build »
MSG
Confirmation
Figure 30 : Diagramme de classe général pour Espace SAG.
59
- Diagramme de classe pour le package Espace DGSI :
«submit » Redirect
Page Page Build Form. Authentif. MSG

d’accueil authen. Authentif. DGSI Erreur
DGSI
« Link »
« Link »
Submit
Fichier Form. Consulter Imprimer
Espace
auxiliaire Consulter matériel
DGSI
matériel info. « Build »
« Build »
Mise à jour
BDD Mat-Info
Figure 31 : Diagramme de classe général pour Espace DGSI.
- Diagramme de classe pour le package Administrateur :
Dans notre cas, l’administrateur se connecte à la base de données via Oracle Manager
Console pour effectuer toutes les taches qui lui sont propres : Ajouter de nouveaux
utilisateurs, attribuer des privilèges, modifier ou supprimer des utilisateurs, créer des tables
ou des vues.
Donc le diagramme de classe qui représente le package administrateur est le suivant:
60
Redirect
Submit
Build
Oracle EM Page Form. Authentif. MSG
console authen. Authentif. Admin Erreur
Admin.
« Link »
« Link »
Submit « Link »
Base de Redirect MSG
Espace Form. Créer
données Création USER Erreur
Admin
SAG USER
« Build »
MSG
Confirmation
« Link »
Form. Modifier ou MSG

Modifier supprimer Erreur
Submit
ou supp. USER
USER « Redirect »
« Build »
MSG
Confirmation
Form. Créer MSG

Créer table
table ou vue Erreur
ou vue
« Submit » « Redirect »
« Build »
MSG
Confirmation
Figure 32 : Diagramme de classe pour l’espace Administrateur.
61
3.2 Le niveau de données :

Dans cette partie du chapitre, nous allons décrire la manière de concevoir la structure
de la base de données à travers un modèle conceptuel : le diagramme de classe (classe
entité). Puis, dans un second temps, le modèle physique qui représente l’implémentation
des tables dans la base de données
Conception de la base de données :
Après la traduction des diagrammes des cas d’utilisation en diagrammes de séquences puis
en diagrammes de classes nous allons élaborer le diagramme de classes final (classe entités)
qui sera la référence pour l’implémentation de la base de données, et cela parce qu’il met en
évidence les classes entités et leurs attributs.
- Diagramme de classes final :
Agent SAG 1 Manipule

Agent DGSI
USER
USER
Password
1 Password
1 Fichier_Auxiliaire 1
Cod_bar.Matériel
Affect.Matériel
Typ.Matériel
DES .Matériel Consulter
Gérer
Num_Séri.Matériel
Marque.Matériel
Mod_Typ.Matériel
Obs.Matériel
1
* 1 1
Matériel Vue Matériel

Cod_bar Informatique
* Contient Mettre à jour 1
Affect Cod_bar.Matériel
Typ Affect.Matériel
DES Typ.Matériel
Num_Séri DES.Matériel
Marque Num_Séri.Matériel
Mod_Typ Marque.Matériel
Obs Mod_Typ.Matériel
Obs.Matériel
Figure 33 : Diagramme de classe final.
62
Dictionnaire de données (tableau 21) :
Le tableau suivant représente un descriptif du codage de l’information utilisé dans le

model de la base de données:
Code Désignation Type Taille
COD_BAR Code barre N 10
AFFECT Affectation A 30
TYP Type A 10
DES Désignation A 50
NUM_SER Numéro de série AN 30
MARQ Marque A 30
MOD_TYP Mode et type AN 30
OBS Observation AN 30
USER User A 15
PASSWRD Password AN 10
Le modèle physique de données :
Ce modèle nous donne la représentation physique de l’ensemble des tables de la base de

données du système étudié :
• Table UTILISATEUR (tableau 22) :
Nom du champ NULL ? Type
USER NOT NULL VARCHAR (15)

PASSWORD NOT NULL VARCHAR (10)
63
• Table FICHIER_AUXILIAIRE (tableau 23):
COD_BAR NOT NULL NUMBER (10)

AFFECT NOT NULL VARCHAR (30)
TYP NOT NULL VARCHAR (10)
DES NOT NULL VARCHAR (50)
NUM_SER NULL VARCHAR (30)
MARQ NULL VARCHAR (30)
MOD_TYP NULL VARCHAR (30)
OBS NULL VARCHAR (30)
• Vue de la table FICHIER_AUXILIAIRE : MATERIEL_INFORMATIQUE : Condition

TYP=Info (tableau 24) :
COD_BAR NOT NULL NUMBER (10)

AFFECT NOT NULL VARCHAR (30)
TYP NOT NULL VARCHAR (10)
DES NOT NULL VARCHAR (50)
NUM_SER NULL VARCHAR (30)
MARQ NULL VARCHAR (30)
MOD_TYP NULL VARCHAR (30)
OBS NULL VARCHAR (30)
4. Conclusion :
Dans ce chapitre nous avons présenté l’analyse et la conception de notre application en
utilisant le langage UML pour le web. En premier lieu on a commencé par l’analyse des
besoins ensuite on a entamé la partie conception qui comprend deux niveaux, le niveau
applicatif et le niveau de données. Le niveau applicatif concerne les fonctionnalités et les
traitements de l’application, ensuite on est passé au niveau de données qui concerne la
définition et la construction de la base de données. Dans le chapitre qui suit, nous allons
présenter la phase réalisation de l’application.
64
Chapitre IV
Réalisation
Chapitre IV Réalisation
1. Introduction
Dans ce chapitre nous allons présenter notre plate forme de développement et les outils
utilisés pour mener à terme la réalisation de notre base de données, ainsi que quelques
interfaces du logiciel.
2. Outils de développement :
Avant la réalisation de notre application, nous avons opté pour l’utilisation de la plate-
forme Windows avec son système d’exploitation Windows XP service pack 3, sur lequel sont
installés :
• Le SGBD Oracle version 9i pour l’implémentation de notre base de données.

• Les outils de développement d’Oracle pour les applications permettant
l’interrogation des bases de données : Oracle DevSuit 10g (permet aussi le
développement d’applications web et les applications de type client/serveur).
Le choix d’Oracle 9i sous Windows s’est porté pour diverses raisons :
• Oracle est parfaitement intégré à Windows, ce qui permet d’exploiter les

caractéristiques les plus poussés de Windows.
• Windows est parmi les plates-formes auxquelles oracle accorde une priorité en cas
de sortie d’une nouvelle version.
• Windows est plus adapté pour des réseaux réduits (d’entreprise) qui n’ont pas
besoins d’une administration complexe.
3. Environnement de programmation :
Tout développement de logiciel nécessite le choix d’un langage adéquat. Pour notre
logiciel, qui est une base de données repartie, on a utilisé l’outil de développement Forms
Builder de la plate forme Oracle DevSuit 10g, qui offre une convivialité de travail et une
souplesse de programmation pour les applications déployées sur le réseau (développement
des applications graphiques tel que : fenêtres, formulaires …).
Le langage est porté sur le PL/SQL qui est un langage de programmation d’Oracle
Corporation qui combine toutes les possibilités de manipulation des données proposées par
SQL en relation avec un langage de programmation procédural de haut niveau. Il offre de
nombreux avantages :
• Langage parfaitement intégré à Oracle 9i et Java.

• Il propose toutes les notions classiques des langages de programmation évolués
(variables, structures de contrôle,…) tout en facilitant les accès à la base de données
grâce à la puissance de SQL.
• Performant, facile à la programmation et permet la portabilité.
66
• Supporte le modèle Client/serveur.

• Supporte la programmation Orienté Objet.
• Permet la modularité et l’ouverture sur d’autres langages de troisième génération
(L3G).
4. Présentation de la base de données :

Après avoir définit l’espace disque logique (tablespace), nous avons choisis nos privilèges
autant qu’administrateur de notre base de données SAG, ensuite nous avons crée notre
propre schéma sous le nom de YACINE pour pouvoir y créer les objets de la base (tables,
vues et triggers) à l’aide de la Console Oracle Entreprise Manager.
La figure suivante montre l’interface graphique d’OEM dans laquelle sont montées les
tables, vue ainsi que le schéma de leur appartenance :
Figure 34 : Présentation de la base de données.
5. Présentation des interfaces de notre application :
Page d’Accueil : c’est la première page qui apparaît au lancement de l’application.
67
Figure 35 : Page d’accueil.
Page Authentification : En cliquant sur « Entrer », la page d’authentification

s’affiche :
Figure 36 : Page d’authentification.
En remplissant les champs de la page d’authentification, chaque utilisateur peut accéder à

son propre espace, l’agent de la subdivision affaires générales SAG peut accéder au fichier
auxiliaire dans le quel il peut gérer le matériel : ajouter, supprimer, modifier via la barre
d’outils qui est en haut de la page. Quand à l’agent de la DGSI, une fois authentifié il peut
accéder aussi à son espace pour consulter le fichier auxiliaire portant uniquement sur le
matériel de type informatique grâce à la vue qu’on programmé dans l’espace de notre base
68
de sonnées, sans avoir le droit de mettre à jour ou modifier les informations existantes. Tout
ça peut se faire à travers le réseau local mis en œuvre entre les deux services.
Page fichier auxiliaire : contenant tout le matériel au niveau de la SAG :
Figure 37 : Fichier auxiliaire de tout le matériel.
Verrouiller
Déconnecter
Supprimer enregistrement
Interroger un matériel
Enregist. Ajouter un
la BDD Suivant matériel
Enregistrer
Imprimer
Figure 38 : La barre d’outils.
Page du fichier auxiliaire qui donne les coordonnées et la trace du matériel

Informatique (Affiche le résultat de la vue) :
69
Figure 39 : Page fichier auxiliaire du matériel informatique.
6. Conclusion :
Dans ce chapitre nous avons présenté les outils et l’environnement de développement de
notre application. Nous avons en outre explicité les composants de la base de donnés à
travers OEMC (Oracle Enterprise manager console), puis pour terminer nous avons présenté
quelques interfaces destinées aux utilisateurs de l’application.
70
Conclusion
Générale
Conclusion générale
Toute entreprise, quelle que soit sa vocation et son caractère, doit se mettre au diapason
de la progression technologique et faire face par l’automatisation de ses structures et la
formation de son personnel, afin d’améliorer son rendement et son service et d’assurer sa
place sur le marché au milieu de la concurrence.
Le stage pratique que nous avons effectué au sein de la société de distribution de Tizi-
Ouzou (SDC filiale de SONELGAZ) nous a permis l’acquisition de connaissances multiples
comme l’implémentation des bases de données sous Oracle 9i avec l’utilisation de
quelques utilitaires de ce SGBD tel que Net manager pour les configurations réseaux, foms
builder pour le développement d’applications permettant l’interrogation des bases de
données , ainsi que le langage PL/SQL utilisé. Nous avons particulièrement appris à
concevoir et à réaliser des systèmes d’information de gestion des bases de données
réparties, tout en ayant une idée précise sur l’univers du travail.
Notre application a tendance à faciliter la collaboration et la communication entre les deux

services du champ d’étude en assurant un transfert en temps réel de l’information requise
avec exactitude vue son déploiement sur réseau, ce qui signifie un gain en temps, et une
épargne vis-à-vis les erreurs de gestion concernant la traçabilité du matériel informatique.
Enfin, nous souhaitons que ce modeste travail puisse répondre favorablement aux
besoins des futurs utilisateurs et servir comme un outil d’aide et de documentation pour les
étudiants à venir.
Bibliographie
Bibliographie
Mémoire de fin d’étude de Mr AMNACHE Sofiane intitulé « Conception et réalisation
d’une application client/serveur sous oracle, cas pratique INSIM de Tizi-Ouzou »
promotion Ingénieur 2009, UMMTO.
Mémoire de fin d’étude de Mr : REDAOUI Sofiane intitulé « Conception et réalisation
d’une base de données repartie sous oracle, cas pratique NAFTAL de Tizi-Ouzou ».
promotion master 2011, UMMTO.
Décision Nº 474/DG du 16 mai 2005 portant organisation de la DGCD « document
officiel de la SONELGAZ », pour ce qui est sur l’historique et l’organisation de la
société algérienne de distribution de l’électricité et du gaz SONELGAZ.
Oracle 10g sous Windows, EYROLLES édition, de l’auteur Gilles Briard.
Joseph GABAY et David GABAY, UML 2 Analyse et conception Edition DUNOD 2009.
Jérôme GABILLAUD, Le Guide de Formation Oracle 10g SQL, PL/SQL, SQL*Plus ENI
2005.
Christian Soutou avec la participation d’Olivier Teste dans SQL pour ORACLE 3eme
édition, EYROLLES édition.
Quelques sites web recommandés :

www.teching.com via le site www.sndl.cerist.dz dans le domaine des technologies de
l’information.
www.oracle.com
www.commentçamarche.net
www.sonelgaz.dz
www.dba-oracle.com
Annexes
Installation du SGBD oracle 9i :
Oracle version 9i est généralement disponible en 3 CD. Insérez le premier des 3 CD pour
commencer l’installation :
Si l'autorun ne démarre pas, lancez manuellement setup.exe

Cliquez ensuite sur Démarrer l'installation ou, si vous n'en êtes pas a votre première
installation, sur Installer/Désinstaller les produits.
Remarquez que la langue utilisée par l'Installer dépend de celle utilisée par votre système
d'exploitation.
Si une version Oracle n'est plus utile et existe encore, commencez par la supprimer via le
bouton Désinstaller les produits. Sinon, bouton Suivant.
C'est ici que nous déterminons la variable ORACLE_HOME, c'est-à-dire l'endroit physique
où le logiciel Oracle sera installé. Choisissez un disque sur lequel il y a 3GO de libre (hormis
pour une installation pure cliente).
Choix du produit à installer. Nous sommes intéressés à installer le serveur et son client sur
notre machine et choisissons donc la1ère option.
Notez le bouton Langue du produit

Si ce là vous intéresse, vous pouvez toujours ajouter un langage. Sinon, si l'anglais vous
suffit, vous pouvez allègrement sauter ce menu.
Passons maintenant au choix des produits à installer :
Choisissez l'installation standard afin de ne pas se priver de configurer la couche réseau.

En termes d'usine à gaz, en voilà encore une cheminée : si vous effectuez une installation
d'Oracle sous Windows, Oracle configure automatiquement un service MTS. Pour ce là, il lui
faut un Nº de port:
Voici donc le résumé des options choisies :
Si quelque chose vous semble louche, il est encore temps de revenir en arrière pour
apporter les corrections voulu.
Et c'est parti : le temps d'une bonne pause café...
... qui ne devrait pas vous faire oublier de changer les CDs !
Voilà, c'est fini. Pendant tout ce temps, Oracle a même pris le temps de configurer un
serveur http Apache. Vous pouvez choisir le bouton Quitter.
L'installation du logiciel s'est apparemment bien déroulée.

Mazari Yacine

Transféré par

Droits d'auteur :

Formats disponibles

Mazari Yacine

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mazari Yacine

Transféré par

Droits d'auteur :

Formats disponibles

Le résumé de mon projet de fin d’études :

Mémoire de fin d’étude

Option : Ingénierie des systèmes d’information

Conception et réalisation d’une base de données

Réalisé par : Encadré par :

Mme: SADEG S. (Sonelgaz)

Mes remerciement les plus sincères sont destinés à :

Je dédie ce modeste travail à :

2. Evolution des bases de données ..................................................................... 04

2.2 Evolution des bases de données ..................................................................... 01

1. Systèmes centralisés .............................................................................. 04

2. Les systèmes décentralisés ..................................................................... 05

3. Les systèmes répartis ............................................................................. 05

3. Définition d’une base de données repartie .................................................. 06

4. Caractéristiques d’une base de données repartie .......................................07

4.2 Transparence de partitionnement .................................................................. 07

4.3 Transparence de la duplication ....................................................................... 07

5. Architecture d’un système de gestion de BDD reparties SGBDR .............07

5.2 Niveau de communication ............................................................................. 08

5.3 Niveau interopérable ..................................................................................... 08

6. Fonctions de décomposition et optimisation de requêtes .......................09

6.2 Décomposition des requêtes .......................................................................... 10

6.3 Contrôle de l’intégrité ................................................................................... 10

7. Conception d’une base de données répartie ....................................................10

7.2 Conception descendante ..................................................................................... 11

7.2.1 La fragmentation ................................................................................ 11

7.2.2 Allocation des fragments .................................................................... 14

7.2.3 La réplication ...................................................................................... 14

8. Avantages et inconvénients des bases d données reparties ..........................15

8.2 Les inconvénients .............................................................................................. 16

Chapitre 2 : Etude et description de l’existant.

2. Présentation de l’organisme d’accueil ..............................................................18

2.2 Missions ........................................................................................................... 19

2.3 Organigramme général de la DD de Tizi-Ouzou ................................................. 20

2.4 Mode d’organisation ........................................................................................ 20

3.2 Problématique rencontrée .................................................................................. 25

4. Les services du champ d’étude et les documents manipulés .........................25

5. Etude des documents .............................................................................................28

5.2 Les documents de la division de gestion des systèmes informatique .................... 32

6. Diagramme des flux................................................................................................35

6.2 Liste des flux ........................................................................................................ 36

6.3 Diagramme des flux ............................................................................................. 37

7. Modèle organisationnel des traitements existant MOT ............................ 38

7.2 Le formalisme utilisé ........................................................................................... 39

Chapitre 3 : Analyse et conception.

2.2 Définition des besoins .................................................................................... 47

2.3 Définition des acteurs .................................................................................... 47

2.4 Diagramme de contexte ................................................................................. 48

2.5 Identification des espaces .............................................................................. 48

Représentation des diagrammes de cas d’utilisation (Définition)............................... 49

Diagramme de cas d’utilisation global ................................................................ 50

Diagramme de cas d’utilisation « gérer matériel » .............................................. 50

Diagramme de cas d’utilisation « Mise à jour de la vue » ................................... 51

Diagramme de cas d’utilisation « Consulter vue » .............................................. 51

Diagramme de cas d’utilisation pour l’espace administrateur ............................. 51

Diagrammes de séquence (Définition) ................................................................. 52

Diagramme de séquence pour « Authentification » ............................................ 52

Le scénario nominal du cas d’utilisation « Authentification » ............................. 52

Diagramme de séquence pour « Ajouter matériel » ............................................ 53