Professional Documents
Culture Documents
Sujet
A toute ma famille
A mes chers amis Abdellah, Amal, Bouchra et Taïb
A tous mes amis
A tous ceux qui m’aiment
A tous ceux que j’aime, je dédie ce travail …
Kamal
Avant propos
Jean Cocteau
i
Remerciements
Messieurs les membres du jury pour avoir accepté de juger mon travail.
Que tous ceux qui ont contribué de près ou de loin pour mener à bien ce
stage trouvent ici l’expression de ma parfaite considération et mes
remerciements.
ii
Liste des abréviations
Abréviation Description
AC Agence de Commercialisation
AD Agence de Distribution
API Application Programming Interface
BT Basse Tension
DCR Département de Conduite Régional
DRM Division Régional de Meknès
DTR Division de TRansport
HT Haute Tension
LMT Ligne Moyenne Tension
MT Moyenne Tension
ONE Office National de l’Electricité
SGBD Système de Gestion de Base des Données
STR Service Technique Régional
UML Unified Modeling Language
UNIPEDE Union Internationale des Producteurs et Distributeurs d'Energie Electrique
XML eXtenible Markup Language
iii
Liste des figures
iv
Figure 37 : Menu édition .......................................................................................................... 62
Figure 38 : Edition d'un rapport journalier ............................................................................... 63
Figure 39 : Modification d'une indisponibilité ......................................................................... 63
Figure 40 : Edition d'un rapport mensuel ................................................................................. 64
Figure 41 : Interface d'entretien des équipements .................................................................... 65
Figure 42 : Menu surgissant d'entretien des équipements ........................................................ 65
Figure 43: Ajout d'un poste MT ............................................................................................... 66
Figure 44 : Résultat de l'ajout d'un poste MT à un tronçon ..................................................... 66
v
Sommaire
Remerciements..................................................................................................... ii
Sommaire ............................................................................................................ vi
Introduction ......................................................................................................... 1
vi
3.1 Simplification d’utilisation ................................................................................... 27
3.2 Sécurité ................................................................................................................. 28
3.3 Utilisation à distance ............................................................................................ 28
3.4 États édités............................................................................................................ 28
3.5 Objectifs et alarmes .............................................................................................. 28
4 Solution proposée ....................................................................................................... 29
4.1 Modélisation du réseau MT.................................................................................. 29
4.2 Utilisateurs ........................................................................................................... 29
4.3 Architecture .......................................................................................................... 30
Conclusion ........................................................................................................................... 30
Conclusion .......................................................................................................... 68
Bibliographie ...................................................................................................... 70
Glossaire ............................................................................................................. 71
Annexes............................................................................................................... 73
Annexe 1 : Exemple de calcul des indices UNIPEDE ................................................. 74
Annexe 2 : Tableau des critères UNIPEDE ................................................................ 77
Annexe 3 : L’ensemble des états à éditer..................................................................... 79
Annexe 4 : Le mappage Objet – Relationnel............................................................... 87
Annexe 5 : Dictionnaire des données ........................................................................... 90
vii
Projet de fin d’étude Introduction
Introduction
Le Maroc est un pays en voie de développement. Il est la porte de l’Afrique sur l’Europe et le
dernier port par lequel passent les pétroliers se dirigeant vers l’Amérique. Il offre aux
investisseurs un climat stable politiquement, une main d’œuvre de faible coût, et des zones de
libre échange avec les plus grandes puissances économiques, je cite les Etats Unis
d’Amérique et l’Union Européenne à titre d’exemples.
Malgré tous ces facteurs, l’investisseur étranger ne fait toujours pas confiance à l’économie
marocaine, le plus grand inconvénient de cette dernière étant les coûts élevés de l’énergie.
Pour contrer ce point, l’Office National de l’Electricité, le principal fournisseur de l’énergie
électrique, a mis au point un nombre de dispositifs visant la réduction des coûts de
1
Projet de fin d’étude Introduction
Pour satisfaire ces derniers, l’ONE a adopté une stratégie de qualité aux normes européennes.
En effet, il a mis en place un ensemble d’indicateurs de performance visant le contrôle et le
suivi de ses activités. Parmi eux, je cite en particuliers les critères UNIPEDE qui mesurent
l’impact des interruptions touchant le réseau de distribution sur les clients. Ils permettent,
aussi, la maîtrise de la disponibilité et des performances du réseau, objectif incontournable,
pour se préparer à faire face efficacement à l’environnement économique futur.
Pour se faire, il est naturel de souligner l’importance de la gestion des incidents et l’intérêt
porté à leur analyse, en ayant comme objectif la diminution de leur impact sur les clients. De
ce point de vue, et en complément à ce qui a été fait en matière d’analyse d’incidents, je me
suis intéressé, dans le cadre de mon projet de fin d’étude, au suivi et à l’analyse des incidents
touchant le réseau moyenne tension de la Division Régionale de Meknès. Je dois fournir un
système permettant à ses utilisateurs la prise en compte des différentes anomalies affectant le
fonctionnement normal du réseau d’alimentation moyenne tension, le calcul des critères de
qualité définis par l’ONE et l’édition des rapports qui en découlent.
2
Projet de fin d’étude Contexte général du projet
Introduction
Ce chapitre a pour but la présentation de l’organisme d’accueil et le contexte général du
projet. Le premier paragraphe sera consacré à la présentation de l’ONE, de la division
régionale de Meknès et des services en relation avec le projet. Le deuxième paragraphe
introduira des notions générales du projet et une description succincte pour comprendre sa
finalité.
3
Projet de fin d’étude Contexte général du projet
1.1.1 Historique
Au lendemain de l’indépendance, l’Etat a dû prendre lui-même en main le secteur électrique
afin de l’organiser, le soutenir et garantir le service public. L’Office National de l’Electricité a
été créé par Dahir en août 1963 et a été substitué à la Société Electrique du Maroc à qui était
confiée depuis 1924, la concession d’une organisation de production, de transport et de
distribution de l’énergie électrique. A cette date, les usines de l’énergie électrique du Maroc
assuraient 90% de la production nationale.
L’ONE est un établissement public à caractère industriel et commercial, doté de la
personnalité civile et de l’autonomie financière et a été investi depuis sa création de
l’exclusivité de la production et le transport. Il assure également la distribution de l’énergie
électrique dans plusieurs provinces du royaume notamment en milieu rural. Les droits et
obligations de l’ONE sont définis dans un cahier de charge approuvé par décret en 1974,
lequel définit les conditions techniques, administratives et financières relatives à
l’exploitation des ouvrages de production, transport et distribution de l’électricité [Site1].
1.1.2 Objectifs
L’ONE a pour mission la satisfaction dans les meilleures conditions techniques et
économiques :
- la demande de notre pays ;
- la généralisation de l’accès à l’électricité dans le monde rural ;
- œuvrer pour la promotion et le développement des ressources nationales
notamment les énergies renouvelables.
4
Projet de fin d’étude Contexte général du projet
5
Projet de fin d’étude Contexte général du projet
- DR de Casa,
- DR de Tensift,
- DR de Agadir,
- DR de Kenitra,
- DR de Meknès,
- DR de Fès,
- DR de Oujda.
Chaque Division Régionale est composée d’entités fonctionnelles d’appui et d’entités
opérationnelles :
- les entités fonctionnelles d’appui sont :
o le service contrôle de gestion,
o le service des ressources humaines,
o le service approvisionnement et gestion des stocks,
o le département études et analyses,
o le département de conduite régionale,
o le département comptabilité,
o l’unité de sécurité.
- les entités opérationnelles sont :
o les Services Techniques Régionaux,
o les Agences de Distribution,
o les Agences Commerciales.
6
Projet de fin d’étude Contexte général du projet
7
Projet de fin d’étude Contexte général du projet
8
Figure 1: Organigramme de l’ONE
Projet de fin d’étude Contexte général du projet
2 Présentation du projet
10
Projet de fin d’étude Contexte général du projet
11
Projet de fin d’étude Contexte général du projet
- réseaux MT aériens : plus exposés aux anomalie, les réseaux aériens classiques
sont constitués de départs MT avec trois phases et ils sont équipés de :
o les fils conducteurs (en alliage d'aluminium),
o des systèmes de protections qui comportent des disjoncteurs MT à cycles de
réenclenchement rapides puis lent, permettant d'éliminer les défauts auto
extincteurs fugitifs et semi permanents. Ce type de protection est utilisé dans
les postes sources,
o des interrupteurs qui permettent de faciliter la localisation des défauts
permanents et de réduire les tronçons non alimentés lors de réparation à la
suite d'incidents ou lors de travaux programmés.
13
Projet de fin d’étude Contexte général du projet
14
Projet de fin d’étude Contexte général du projet
Une fois l’anomalie est réparée, l’équipe qui a effectué l’intervention procède à un rapport
détaillé. Ce rapport présente tous les incidents du jour d’une manière bien précise (horaire
d’interruption, horaire de rétablissement, durée d’interruption, motif, localité coupée, dégât si
il y en a eu, etc.).
15
Projet de fin d’étude Contexte général du projet
16
Projet de fin d’étude Contexte général du projet
Le calcul du nombre de clients interrompus se fait en ne comptabilisant qu’une seule fois les
clients interrompus à plusieurs reprises.
DMC est égal à DMS dans le cas où chaque client du système a subi, au moins, une
interruption.
18
Projet de fin d’étude Contexte général du projet
Le nombre total des interruptions est la somme des interruptions subies par chaque client d’un
système.
IFC est toujours supérieur ou égal à 1, à la condition qu’au moins un client du système a subi,
au moins, une interruption.
Le nombre total des interruptions est la somme des interruptions subies par chaque client d’un
système.
IFC est égale à IFS dans le cas où chaque client du système a subi, au moins, une interruption.
19
Projet de fin d’étude Contexte général du projet
Dans les deux cas, les ventes ne correspondent pas aux achats. Pour avoir un aperçu sur ces
échanges de puissance, l’ONE s’est définit un taux d’échange de puissance :
Il est calculé pour une période donnée (année, trimestre, mois,…) et pour un système donné
(une AD, un départ, etc.).
Énergie = PAx0.86x(0.3HC+0.6HPL+HP)/60
20
Projet de fin d’étude Contexte général du projet
Conclusion
Ce chapitre représente un point de départ pour l’élaboration du système dans la mesure où il
définit son contexte général. L’organisme d’accueil a été présenté, et les objectifs et la
démarche de la mise en œuvre du nouveau système précisés. Le chapitre suivant décrit la
phase étude et spécification des besoins du projet.
21
Projet de fin d’étude Etude et spécification des besoins
Introduction
Ce chapitre résume la phase de l’étude et la spécification des besoins. Dans un premier temps,
le cahier des charges sera présenté. Puis, l’étude de l’existant donnera une idée sur l’ancien
système, ses fonctionnalités et ses failles. Les attentes des utilisateurs détermineront les
nouveaux besoins. Enfin, je vais proposer et détailler la solution adoptée.
22
Projet de fin d’étude Etude et spécification des besoins
23
Projet de fin d’étude Etude et spécification des besoins
Il faut noter que les calculs doivent être visualisables moyennant des graphiques, et qu’ils ne
doivent prendre en considération que les systèmes qui sont sous la responsabilité de
l'utilisateur.
2 Étude de l'existant
Suite à une anomalie (fugitif, incident, indisponibilité), un nombre d’actions sont prisent et
des rapports sont saisies ou/et édités. Ces rapports permettent le suivi des actions entrepris
pour pouvoir offrir aux consommateurs une qualité de service aux normes mondiales.
La saisie des rapports journaliers et l’édition de quelques rapports mensuels sont possibles en
utilisant l’application GEFOR. Les autres rapports (primes de réseau, fiche d’incidents …)
sont tirés de la base de données UNIPED après traitement avec Excel.
2.1 GEFOR
GEFOR (Gestion du fonctionnement du réseau) est une application développée en interne
avec Visual Basic. Elle offre les fonctionnalités suivantes :
- la saisie et la consultation des anomalies : la saisie se fait par le remplissage des
champs caractérisant l’anomalie (heure de début, heure de rétablissement, les
dégâts, les causes, etc.) pour chaque tronçon affecté.
- l’entretien des informations relatives au réseau MT : ce qui comprend l’ajout de
nouvelles installations électriques, et la modification ou la suppression de ceux
déjà existantes.
- la consultation des informations relatives aux installations électriques. Ces
informations comprennent le nombre de clients pour le sous système sélectionné,
le client important, la charge appelée, etc.
24
Projet de fin d’étude Etude et spécification des besoins
- l’édition du rapport des critères UNIPEDE : le calcul se fait pour un système et sur
une période. Le résultat peut être transféré vers un fichier Excel pour un traitement
plus approfondi et pour impression.
GEFOR est une application monoposte et multi utilisateurs. Elle est développée pour deux
types d’utilisateurs : administrateur et répartiteur. Ils sont décrit dans ce qui suit :
- le répartiteur : il se charge de la saisie des incidents et des indisponibilités et
l’édition des rapports des critères UNIPEDE pour un système donné et pour une
période déterminée. Il peut aussi apporter des modifications à l’architecture du
réseau électrique,
- l’administrateur : lui sont attribuées les tâches de compactage et de réparation de la
base de données et l’ajout de nouveaux utilisateurs. Il peut aussi faire les tâches du
répartiteur.
Cette application répond à un grand nombre de fonctionnalités, toutefois, un nombre
d’inconvénients a été dégagé. A titre d’exemple :
- le modèle adopté pour la représentation des défauts touchant le réseau moyenne
tension ne permet pas le calcul des taux de pertes et des primes de réseau.,
- la saisie des anomalies présente une charge considérable. Le répartiteur doit saisir
des informations redondantes (voir figure 5),
- les fonctionnalités les plus intéressantes (tableau de bord, import/export des
tronçons) ne sont pas fonctionnelles,
- elle ne tient pas compte de l’appartenance des postes sources au réseau électrique
MT,
- l’entretien de la base de données peut être effectué par les répartiteurs,
- l’interface Homme/Machine est déplorable.
Pour ce qui est de la sécurité d’utilisation, c’est l’administrateur qui enregistre les nouveaux
utilisateurs. Mais il ne peut ni changer ni modifier le profil des utilisateurs (rôle et mot de
passe).
De plus, l'absence de code source écarte toute possibilité de développement à base de cette
application.
25
Projet de fin d’étude Etude et spécification des besoins
26
Projet de fin d’étude Etude et spécification des besoins
3 Nouveaux besoins
Par rapport à ce qu’offre GEFOR, les utilisateurs désirent une application simple d’utilisation,
plus sécurisée, et permettant de consulter et d’éditer les différents états à distance. Ces états
concernent, en plus des critères calculés par GEFOR, les taux de pertes et les primes de
réseau. L’application devra aussi rappeler aux différents utilisateurs leurs objectifs et lancer
des alarmes au cas où ils les dépassent.
27
Projet de fin d’étude Etude et spécification des besoins
3.2 Sécurité
La sécurité se traduit par la sécurité d’utilisation et la sécurité des données.
La sécurité d’utilisation donne le droit à un administrateur la possibilité de créer plusieurs
utilisateurs et de changer leur rôle à volonté. Chaque rôle assure un nombre de fonctionnalités
prédéfinies.
La sécurité des données réside avant tout dans le choix du système de gestion de base de
données. Les vérifications effectuées avant l’importation des données et la possibilité
d’enregistrer les données sur un autre support pour prévention contre une éventuelle
défaillance technique ou humaine augmentent le niveau de sécurité offert par tout système.
28
Projet de fin d’étude Etude et spécification des besoins
4 Solution proposée
L’introduction des appareils de coupure dans le modèle adopté permet l’exploitation des
durées d’interruptions pour le calcul des taux des pertes. En effet, une interruption n’est plus
considérée comme une anomalie qui touche les tronçons formant le réseau, mais un ensemble
d’opérations élémentaires affectant l’état des appareils de coupure.
4.2 Utilisateurs
Les utilisateurs du nouveau système peuvent être regroupés en quatre catégories :
- le répartiteur : il est chargé de remplir le rapport journalier chaque fois qu’une
anomalie s’est produite. Il doit suivre l'état du réseau et peut consulter et éditer les
rapports mensuels.
- l’administrateur : en plus des tâches du répartiteur, l’administrateur s’assure de
l’homogénéité des informations de la base des données concernant les équipements
et les établissements, il suit aussi les rapports des ventes.
- le chef DCR : le chef hiérarchique du DCR suit l'état du réseau, les rapports des
ventes, les rapports mensuels et le rapport de prime du réseau.
29
Projet de fin d’étude Etude et spécification des besoins
- le chef STR : le chef hiérarchique du STR peut consulter les rapports mensuels et
les rapports de prime du réseau par agent. Il est chargé aussi de l’entretien des
informations relatives à son domaine et à ses équipes et leurs objectifs
4.3 Architecture
L'application devra offrir aux utilisateurs la possibilité d'accéder à l'application depuis leurs
bureaux. A noter qu'à l'heure actuelle l'ONE/DRM dispose d'un DCR et de deux STR : une à
MEKNES et l'autre à ERRACHIDIA.
Conclusion
Nous avons vu dans ce chapitre ce qu’offrait l’ancien système et les grandes lignes du
système futur. Ainsi, j’y ai proposé une solution permettant de répondre aux besoins exprimés
par les différents utilisateurs. Le chapitre suivant est consacré à présentation de l’analyse et
conception du nouveau système.
30
Projet de fin d’étude Analyse et conception du projet
Introduction
Dans l’optique de concevoir un système qui soit modulaire, facilement extensible est orienté
objet, le langage de modélisation UML s’est imposé comme l’outil le plus approprié pour la
modélisation de ce projet. En effet, UML [Ouv1] va permettre de mener la phase d’analyse et
de conception tout en bénéficiant de la puissance et de la simplicité de l’orienté objet.
Dans ce chapitre, je vais commencer par une brève présentation de la notation UML. Ensuite,
je passe en revue les différents diagrammes élaborés. La génération du modèle conceptuel des
données manipulées par le système sera traitée en fin de chapitre.
31
Projet de fin d’étude Analyse et conception du projet
32
Projet de fin d’étude Analyse et conception du projet
2 Diagrammes d’UML
Dans ce paragraphe, je présente les principaux diagrammes UML nécessaires à la
compréhension du système à réaliser, il s’agit du diagramme des cas d’utilisation, des
diagrammes de séquences, du diagramme des packages et des diagrammes de classes.
entretien equipements et
etablissements
saisir rapport
journalier
Repartiteur
Administrat
eur
suivre le réseau
suivre l'exploitation
entretien des equipes
et des objectifs
<<use>>
Le diagramme des cas d’utilisation (figure 8) détermine pour chaque utilisateur, l’ensemble
des fonctionnalités qu’il peut effectuer. Vu que tous les cas d’utilisation utilisent
l’identification, je l’ai omis du diagramme. Le nouveau système offre dix cas d’utilisation et
pour chaque cas d’utilisation je détaille dans ce qui suit, quelques scénarios importants.
33
Projet de fin d’étude Analyse et conception du projet
2.1.1 Identification
L’identification permet aux utilisateurs de se connecter à la base de données et d’utiliser les
applications du nouveau système. L’utilisateur donne son nom d’utilisateur et son mot de
passe. Après vérification, il a l’autorisation d’utiliser l’application (voir figure 9).
: Repartiteur dataBase
login + password
vérification
autorisation
Figure 9: Identification
34
Projet de fin d’étude Analyse et conception du projet
ListerPostes
liste des Poste Sources
choix poste
ListerDeparts
enregistrementFugitif
nouveauFugitif
fugitif créé
enregistrement effectué
35
Projet de fin d’étude Analyse et conception du projet
36
Projet de fin d’étude Analyse et conception du projet
changer l’ensemble des informations relatives à cette commune (nom, liste des
postes MT qui sont sous sa charge, etc.).
: etablissement AD AC commune
Administrateu
ListerAD
liste des AD
choix AD
DemandeInfo
info AD
ListerAC
Liste des AC
choix AC
DemandeInfo
info AC
ListerCommunes
liste des communes
choix Commune
DemandeInfo
info commune
ListerPostMT
Liste des postes MT
modification
EnregistrerModification
confirmation enregistrement
37
Projet de fin d’étude Analyse et conception du projet
etablissement AD AC Commune
:
Adminis trateur
rechercher( code)
rechercher( code)
AD avec meme code
rechercher( code)
AC avec meme code
rechercher(code )
DemandeInfo
info commune
modification
EnregistrementModification
confirmation enregistrement
38
Projet de fin d’étude Analyse et conception du projet
ListerPostes
liste des postes
ListeDepart
modification
end loop
saveModification( )
confirmation enregistrement
39
Projet de fin d’étude Analyse et conception du projet
modifier (figure 15). Il doit enregistrer ces modifications pour qu’elles soient
prises en compte.
STR equipe
: Chef STR
ListerEquipe
Liste des equipes
choix equipe
ListerAgents
liste des agents
DemanderObjectif
objectif de l'équipe
modification equipe
EnregistrerModification
confirmation modification
40
Projet de fin d’étude Analyse et conception du projet
choix equipe
ListerAgents
liste des agents
choix agent
SupprimerAgent
confirmation suppression
choix equipe
CréationObjectif
objectif créé
affecterObjectif
confirmation affectation objectif
41
Projet de fin d’étude Analyse et conception du projet
réseau
: Chef DCR
ListerAppExpParticuliere
Liste des appareils en exploitation particuliére
42
Projet de fin d’étude Analyse et conception du projet
choix opération
if [opération != validation]
while [opération != validation]
loop
ListerTroncon
Liste des tronçons
ListerPosteMT
Liste des postes MT
end loop
end if
end if
end if Période + périodicité
confirmation compatibilité
paramètres
Analyse
résultats
choix poste
ListerDeparts
Liste des départs
choix opération
if [opération = ajout] AjoutElement
demande d'ajout
confirmation ajout
end if
if [opération = navigation] ListerTroncons
Liste des tronçons
choix opération
if [opération = ajout] AjoutElement
demande d'ajout
confirmation ajout
end if
while [opération = navigation]
loop
ListerTroncons
Liste des tronçons
choix opération
demande d'ajout
confirmation ajout
end if
end loop
end if
end loop
période + périodicité
calcul
critères UNIPEDE
44
Projet de fin d’étude Analyse et conception du projet
- le suivi des ventes : pour avoir une idée sur les ventes, l’utilisateur détermine
la période et la périodicité à prendre en considération (figure 21). Les résultats
regroupent les ventes, les achats, les taux de pertes par AD et par AC.
établissements
: Chef DCR
période + périodicité
calcul
taux de pertes
45
Projet de fin d’étude Analyse et conception du projet
est l’ensemble des rapports mensuels par STR pour les STR qui sont sous la responsabilité du
DR Meknès. Il regroupe les scénarios suivants :
- le calcul des critères UNIPEDE : c’est l’union des résultats du calcul des critères
UNIPEDE pour chaque STR et pour une période et une périodicité déterminées.
- le calcul des critères UNIPEDE modifiés : c’est l’union des résultats du calcul des
critères UNIPEDE modifiés pour chaque STR et pour une période et une périodicité
déterminées.
A partir des diagrammes de séquence, on peut déduire le diagramme de classes. Pour plus de
clarté, les classes sont regroupées en packages.
46
Projet de fin d’étude Analyse et conception du projet
org.one.Equipe org.one.Interruption
org.one.Composant
org.one.Etablissement
47
Projet de fin d’étude Analyse et conception du projet
one.org.Composant
1..* 1..*
PosteSource
Depart
48
Projet de fin d’étude Analyse et conception du projet
Etablissement
Commune AC AD Etablissements
org.one.Composant
1..*
1..*
PosteMT Depart
49
Projet de fin d’étude Analyse et conception du projet
Indisponibilite
Fugitif Interruption
0..* Incident
1..*
OpElementaire
0..1
1 org.one.Composant
1
Depart ApCoupure
50
Projet de fin d’étude Analyse et conception du projet
LiaisonPT
LiaisonTP PosteMT
51
Projet de fin d’étude Analyse et conception du projet
52
Projet de fin d’étude Analyse et conception du projet
agent
matric ule temps_age nt
equipe nom agent
agent_equi pe nbr_jours
Code equipe 1,n 1,1 prenom age nt 1,n
note hierarc he
Nom equipe clas semen t
note Chef S ervise
1,1 habilitation
pos te_occu pe
AD
A D_A C
c ode A D 1,n
1,1 0,n 0,n
nom A D
1,1
depart mt 1,n
c ode depart MT 1,1
P oste Source loc alite imp ortante AC
code poste s ourc e nom dapart MT A D depart
1,1 c ode A C
puis sance installee P remier tronc on
nom A C
nom pos te source Max i
homeo 1,n
1,n
temporis ati on
1,1 1,n
Consommation
P oste Depa rt Depart Tron con A C_COMM
motif travail nombre clie nt
consomma tion
c ode motif
libelle moti f
0,1
T ronc
0,n 1,1
Code tronc
Nom tronc Comm
indis motif
Client important c ode comm
longueur nom comm
1,n type
0,1 s ection 1,n
1,n
1,n
appareil co uppure 0,n
indisponibi lite code A pp coupure
numero tronc _tronc 0,n Comm Pos teMtB t
code indis p onibilite 0,1
nom A pp c oupure
0,n etat actuel
1,n type App co upure 0,1
1,1
P t MT BT
indis op Op ApC alimenter CODE pt MtB t
1,1
puis sance pt_MtB t
nom pt MtB t
0,n 1,1
op elemnta ire incident
c aus e
c ode opera tion op incident c ode inc ide nt c aus e_inc i dent
0,n 1,n code cause
libelle man oeuvre 1,n nature dega t 1,n
libelle c aus e
date operat ion s iege dega t
53
Projet de fin d’étude Analyse et conception du projet
Conclusion
54
Projet de fin d’étude Réalisation du projet
Introduction
Après avoir mené à bien les phases de l’étude des besoins, l’analyse des spécifications et la
conception du nouveau système, j’ai entamé la phase de la réalisation.
Dans ce chapitre, je présente les outils de développement utilisés, pour finir avec quelques
scénarios d’utilisation commentés pour présenter le système réalisé
55
Projet de fin d’étude Réalisation du projet
1 Outils de développement
Pour réaliser mon projet, j’ai utilisé plusieurs outils de développement et technologies tels que
Java, JDBC et XML. Pour l’implémentation de la base de données, j’ai choisi Oracle 8i
Server. Dans ce qui suit, je donne un bref aperçu sur ces outils.
1.1 Java
Java est un langage récent développé par Sun MicroSystems depuis la fin des années 1980.la
première version de Java à été mise au point en 1991. Java a connu depuis un essor
considérable, notamment dans le domaine des applications distribuées via Internet, grâce au
soutien de Netscape depuis 1995.
L’aspect purement Objet de Java permet une meilleure répartition du travail entre les
programmeurs qui peuvent développer ou utiliser différents objets sans se préoccuper des
traitements réalisés à l’intérieur. De plus, il est plus facile d’adapter et de faire évoluer les
spécificités d’un objet à partir du moment où, vu de l’extérieur, cet objet réalise les mêmes
actions. Ainsi, les objets mis en œuvre en Java sont réutilisables à souhait.
Pour résumer, Java est portable, sûr, orienté objet et indépendant de toute plate forme [Ouv3].
56
Projet de fin d’étude Réalisation du projet
Le choix du langage XML est justifié aussi par l’existence d’une API dite DOM (Document
Object Model) implémentée en Java. Cette API permet de manipuler les fichiers XML d’une
manière simple et efficace et de naviguer dans leur structure en utilisant un ensemble de
classes.
2 Système réalisé
Pour des contraintes de temps et vu la complexité du projet, je n’ai pu répondre qu’à une
partie du cahier des charges. Le système ainsi réalisé comprend un serveur de données et un
prototype console. Le serveur de données est hébergé dans Oracle 8i Server. Le prototype est
développée en Java et joue le rôle du client. Pour garder les mêmes habitudes de travail, je
n’ai pas changé le nom de l’application. Ainsi, elle est nommée Gefor et permet aux
répartiteurs et aux administrateurs, selon les droits qui leurs sont accordés, de :
- saisir le rapport journalier
- entretenir les équipements et les établissements
- suivre le réseau
- suivre l’exploitation
- éditer quelque rapports mensuels
Pour décrire les fonctionnalités de l’application réalisée, des exemples d’utilisation
s’imposent. J’ai choisi trois activités récurrentes : la saisie et l’édition d’un rapport journalier,
57
Projet de fin d’étude Réalisation du projet
l’édition d’un rapport mensuel et la modification de l’architecture du réseau par l’ajout d’un
poste MT.
58
Projet de fin d’étude Réalisation du projet
59
Projet de fin d’étude Réalisation du projet
60
Projet de fin d’étude Réalisation du projet
61
Projet de fin d’étude Réalisation du projet
62
Projet de fin d’étude Réalisation du projet
63
Projet de fin d’étude Réalisation du projet
rapport des critères UNIPEDE modifiés. Le rapport mensuel des critères UNIPEDE respecte
les règles de calcul présentées dans l’annexe 2. Le deuxième type de rapport ne prend en
compte que les interruptions dues au mauvais entretien des équipements. Il est utilisé dans la
détermination des primes de réseau versées aux agents des équipes d’entretien.
Pour éditer un rapport mensuel, l’utilisateur choisit dans la barre des menus le menu "Edition"
puis "Rapport Mensuel" et clique sur "Critères UNIPEDE". L’utilisateur voit apparaître
l’interface de la figure 40.
64
Projet de fin d’étude Réalisation du projet
65
Projet de fin d’étude Réalisation du projet
66
Projet de fin d’étude Réalisation du projet
Conclusion
Le présent chapitre, le dernier dans ce rapport, a illustré la phase de la réalisation qui constitue
l’aboutissement du projet et la concrétisation des phases d’études, d’analyse et de conception.
J’y ai présenté, en plus des outils de développement utilisés, quelques scénarios d’utilisations
fréquents du système. Ce système permet le suivi des anomalies depuis leur saisie jusqu’à
l’édition de quelques rapports qu’ils lui sont liés. Il offre également un outil de modélisation
du réseau d’alimentation simple et pratique d’utilisation tout en restant ouvert à d’éventuelles
évolutions.
67
Projet de fin d’étude Conclusion
Conclusion
Mon projet consistait à mettre en place un système de suivi des incidents touchant le réseau
moyenne tension et permettant l’édition des rapports qui découlent de cette activité.
Auparavant, l’ensemble des applications qui permettaient ceci (Access, Excel, GEFOR)
consommait beaucoup de temps dans des saisies d’information redondantes et des tâches
répétitives non automatisées. Elles augmentaient la probabilité d’erreur surtout dans les
phases de transitions entre deux architectures du réseau d’alimentation.
68
Projet de fin d’étude Conclusion
Le système réalisé permet la saisie des différents éléments du rapport journalier (fugitif,
incident et indisponibilité), l’édition des critères UNIPEDE et l’exportation des résultats de
calcul sous format de fichier XML facilitant leur exploitation par des applications tierces. Il
est simple d’utilisation, conviviale et respecte la façon du travail des utilisateurs.
Ce projet de fin d’étude était pour moi, une occasion d’acquérir de nouvelles connaissances et
de maîtriser celles que j’avais déjà en matière de connaissances professionnelles. Il m’a
permit aussi m’intégrer au sein d’un office dont la mission est noble.
Enfin, je tient à rappeler que le système réalisé se veut le noyau d’un système intégré
englobant toute l’activité liée aux interruptions touchant le réseau de distribution, et plus
globalement, la gestion du fonctionnement du réseau de distribution. En effet, cette activité
est une activité complexe qui nécessite la collaboration d’un nombre important d’intervenants.
Pour permettre ceci, j’ai dégagé un nombre de recommandations et de perspectives présentées
dans ce qui suit :
- Implémenter les besoins des utilisateurs que j’ai pas pu prendre en compte (Chef du
DCR et Chef du STR),
- Etudier la possibilité d’englober les intervenants : Chef d’AD, et Chef d’AC,
- Généraliser son utilisation pour englober tout le territoire desservi par l’ONE,
- Faire évoluer le système vers une architecture plus adéquate,
- Faire évoluer le système vers un système d’information géographique.
69
Projet de fin d’étude Bibliographie
Bibliographie
Ouvrages :
[Ouv1] Michel LAI, UML la notation unifiée de modélisation objet, Edition interEdition,
1997
[Ouv2] E.MOREL, Modélisation objet avec UML, Eyrolles 1999
[Ouv3] N. BARKAKATI, JAVA, Osborne McGraw_Hill, 1999.
[Ouv4] A. MICHARD, XML, Langage et Applications, Eyrolles, 1999.
Sites Web:
[Site1] http://www.one.org.ma/
[Site2] http://www.unesco.org/uati/associations/http./www.unipede.org
[Site3] http://www.bfe-fpe.be/members/pt/C10_14FR%2023.01.2004.pdf
[Site4] www.oracle.com
70
Projet de fin d’étude Glossaire
Glossaire
API
Interface pour la programmation d'applications traduite du "Application and
Programming" Interface Ensemble de bibliothèques permettant une programmation plus
aisée car les fonctions deviennent indépendantes du matériel. On peut citer par exemple
les API de DirectX ou de Java
Client / serveur
Architecture qui s’appuie sur un concept de répartition des traitements et des données
sur un ensemble de systèmes comprenant à la fois des serveurs centraux, des
départements et des micros.
Java
Langage de développement créé par Sun. Dérivé du C++ dont il n'en possède pas la
complexité, Java est un langage orienté objet. Les programmes créés à partir de Java ont
la propriété de fonctionner sur n'importe quelle plate-forme matérielle grâce à un
système nommé "Machine virtuelle".
JDBC
"Java DataBase Connectivity", c’est une API standard de Java permettant l'accès à des
bases de données relationnelles (connexion, déconnexion, envoi de requête, réception de
la réponse, transaction ...). L'API permet également l'accès à divers types de données
tabulaires comme les feuilles de calcul d’un tableur ou les fichiers textes.
UML
UML est un langage de modélisation et non pas une méthode. Elle définit en fait
l'ensemble des notations graphiques nécessaires pour représenter des concepts orienté
objet mais ne spécifie pas une démarche pour conduire un projet ou une phase de
conception ou d'analyse orienté objet. Anglais : Unified Modeling Language
71
Projet de fin d’étude Glossaire
72
Projet de fin d’étude Annexes
Annexes
73
Projet de fin d’étude Exemple de calcul des indices UNIPEDE
74
Projet de fin d’étude Exemple de calcul des indices UNIPEDE
Remarque : la durée de rétablissement peut aussi être obtenue par l'application de la formule
75
Projet de fin d’étude Exemple de calcul des indices UNIPEDE
76
Projet de fin d’étude Tableau des critères UNIPEDE
77
Projet de fin d’étude Tableau des critères UNIPEDE
Désignation de
Unité Définition Mode de Calcul Observation
l'indicateur
C'est la durée moyenne • Le nombre des clients interrompus est
d'interruption pour chaque client Σ (des clients interrompus x heures interrompus) comptabilisé une seule fois
Durée moyenne qui a été interrompu dans un DMC = • DMC est dans tous les cas supérieur ou
d'interruption d'un Heures système pendant une période
Σ des clients interrompus égal à DMS
client (DMC) déterminée (Année, Trimestre, • Σ(Clients x heures interrompus) = durée
mois,...) totale des interruptions
C'est la durée moyenne • DMC est égal à DMS dans le cas où
d'interruption pour l'ensembles chaque clients du système a subi au
Durée moyenne
des clients d'un système pendant Σ (des clients interrompus x heures interrompus) moins une interruption
une période déterminée (Année, DMS =
d'interruption d'un Heures
Trimestre, mois,...). Dans ce cas, Nombre de clients connectés
système (DMS)
tous les clients du système sont
considérés interrompus
79
DIVISION REGIONALE DE MEKNES
RAPPORT JOURNALIER DU 19 -03 -2004 DR- MEKNES
DEPARTEMENT DE CONDUITE
REGIONALE DE MEKNES
Exploitations Particulières:_Rx Boufekrane-Meknes-sais-M'haya-Ain Kerma :PS 1=inter 69,PS 13= inter 31,, PS N°2= au Poste
de S Haj Kaddour
INDISPONIBILITES
POSTE BOUDNIB : Totalité de poste 60/22 kV de 9h00 à 12h08
TR/ L à 22kV PS M'rirt - inter 36bis(PS n°1) (LP Khenifra - M'rirt ) de10h30 à 11h00
TR/ L à 22kV inter 117 - inter 7bis(LP Haj Kaddour - Oued Jdida ) de 9h00 à 15h00
INCIDENTS
FUGITIFS
POSTE BOUFEKRANE : 1 R sur départ à 22 kV Ait Yazem à 8h55
TABLEAU DE BORD DE SUIVI DE LA QUALITE D'ALIMENTATION
DIVISION REGIONALE DE MEKNES MARS 2003
DMC
Nbre C, Nbre C,
STR STR CxH Nbre C, CxH Interromp CxH Interromp
STR ERRACHI STR ERRACHI interromp Interromp interromp us une interromp us une
MEKNES DIA DR MEKNES DIA DR ues us ues seules fois u seule fois
Janvier 1,35 0,51 1,15 1,20 0,00 1,20 55071 41120 55071 41120 0 0
Février 2,10 0,45 1,36 1,13 1,06 1,11 35860 30213 27493 22614 8367 7599
Mars 3,86 1,45 2,97 1,10 0,27 1,01 38579 37923 35170 30326 3409 7597
Avril 2,06 2,05 2,06
Mai 0,59 0,41 0,55
Juin 3,49 0,66 2,80
Juillet 5,63 1,89 4,57
Août 0,45 1,22 1,10
Septembre 0,41 0,49 0,44
Octobre 1,90 1,52 3,10
Novembre 4,38 0,33 4,93
Décembre 1,47 0,00 1,47
DMC
Cumulé 17,91 4,64 13,22 1,29 1,33 1,30 129510 86820 117734 79221 11776 7599
Objectif
2003 8
IFC
Nbr
Nbr Nbre C; Clients Nbre C; Nbr Nbre C;
STR MEKNES STR ERRACHIDIA DR STR MEKNES STR ERRACHIDIA DR Connecte Interrompu Connecte Interrompu Connecte Interrompu
Janvier 0,30 0,10 0,22 0,47 0,00 0,29 211323 62277 131689 62277 79634 0
Février 0,30 0,71 0,46 0,17 0,10 0,14 212099 30213 132321 22614 79778 7599
Mars 0,61 0,39 0,53 0,27 0,09 0,20 213704 43422 133079 35823 80625 7599
Avril 0,48 0,56 0,51
Mai 0,97 0,29 0,71
Juin 2,68 0,42 1,82
Juillet 6,63 1,77 4,78
85
Projet de fin d’étude L’ensemble des états à éditer
86
Projet de fin d’étude Le mappage Objet – Relationnel
87
Projet de fin d’étude Le mappage Objet – Relationnel
Les exemples de code qui suivent ont été générés automatiquement par l’outil Rational Rose
4.0, à partir de modèles UML. Ces exemples n’illustrent pas l’ensemble des capacités de
génération de code de Rose, mais décrivent les grandes lignes des correspondances entre
UML et le langage SQL ANSI.
Classe
- Classe vide
Association
- Association 1 vers 1
- Association N vers 1
88
Projet de fin d’étude Le mappage Objet – Relationnel
Héritage
Dans les exemples suivants chaque classe est réalisée par une table. L’identité d’un objet est
préservée dans la hiérarchie de classes par l’emploi d’un identifiant partagé.
- Héritage simple
- Héritage multiple
89
Projet de fin d’étude Dictionnaire des données
90
Projet de fin d’étude Dictionnaire des données
AC
Nom : AC
Code : AC
Libellé : Agence de Commercialisation
AD
Nom : AD
Code : AD
Libellé : Agence de distribution
Agent
Nom : agent
Code : AGENT
Libellé : Agent d’une équipe d’entretien
Appareil coupure
Nom : appareil coupure
Code : APP_COUP
Libellé : appareil coupure
91
Projet de fin d’étude Dictionnaire des données
Cause
Nom : cause
Code : CAUSE
Libellé : Cause de l’incident
Commune
Nom : Commune
Code : COMM
Libellé : commune
Départ MT
Nom : Départ MT
Code : DEP_MT
Libellé : Départ moyenne tension
Équipe
Nom : équipe
Code : EQUIPE
Libellé : équipe d’entretien
Équipe LMT
Nom : équipe LMT
Code : EQUIPE_LMT
Libellé : équipe ligne moyenne tension
92
Projet de fin d’étude Dictionnaire des données
Équipe poste
Nom : équipe poste
Code : EQUIPE_POSTE
Libellé : équipe responsable de l’entretien des postes sources
Fugitif
Nom : Fugitif
Code : FUGITIF
Libellé :
Incident
Nom : incident
Code : INCIDENT
Libellé :
Indisponibilité
Nom : indisponibilité
Code : INDISP
Libellé :
Motif travail
Nom : motif travail
Code : MOTIF_TRAVAIL
Libellé : motif de l’indisponibilité
93
Projet de fin d’étude Dictionnaire des données
Opération élémentaire
Nom : Opération élémentaire
Code : OP_ELEMNTAIRE
Libellé :
Poste Source
Nom : Poste Source
Code : POSTE_SOURCE
Libellé : Poste Source
Pt MT
Nom : Pt MT
Code : POSTE_MT
Libellé : poste moyenne tension
STR
Nom : STR
Code : STR
Libellé : service technique régional
94
Projet de fin d’étude Dictionnaire des données
Temps
Nom : temps
Code : TEMPS
Libellé : axe du temps pour les informations mensuelles
Tronc
Nom : Tronc
Code : TRONC
Libellé : tronçon
I : identifiant
O : Obligatoire
95