République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université des Sciences et de la technologie Houari Boumediene

Faculté d’Electronique et d’Informatique

Département Informatique

Mémoire de licence
Option : Informatique Académique

Thème :

Outil d’aide à la Gestion de l’Organigramme des

Enseignements du Département Informatique

Sujet proposé et encadré par : Présenté par :

𝑀𝑚𝑒 MAZOUZ 𝑀𝑙𝑙𝑒 AMRAR Lilia

𝑀𝑚𝑒 ZAOUCHE 𝑀𝑙𝑙𝑒 DEHILI Ikram

Devant le jury composé de :

𝐌𝐦𝐞 . BABA ALI…………………….…………..……Présidente

M. AIT ZAI………………..……………………...….Membre

Binôme N° : 107/2015
 Remerciements

Tout d’abord nous tenons à remercier nos deux promotrices :

MADAME MAZOUZ, MADAME ZAOUCHE,
D’avoir accepté de nous encadrer, de nous avoir suivies tout au long
de la conception du projet, de nous avoir conseillées et guidées de
manière judicieuse, d’avoir été disponible à tout moment.

Nos remerciements s’adressent également à Monsieur MEKHALDI

et Madame BOUKALA,
Pour le temps qu’ils ont bien voulu nous accorder afin de répondre à
toutes nos questions.
Enfin, nous tenons à remercier tous les membres du jury d’avoir pris
le temps de lire notre mémoire.
 Dédicaces
Je dédie ce travail à mes très chers parents, que je remercie
profondément d’avoir été là pour moi, de m’avoir soutenue,
encouragé et guidé à tout instant.

A mon frère Yacine et à ma sœur Lamia qui ont su trouvé les mots
pour m’encourager.

A mes amis Nadjet, Ikram, Lynda, Nawel, Jackson, Mehdi, Nassima,

Ouiza, Maya, Lokmane, Sabrina , Adel, Abdelsamie, Hind, Moncef,
Amina, zahra ainsi qu’à Rafika.

Lilia.
 Dédicaces
Je dédie ce travail à mes très chers parents, que je remercie
profondément pour tous leurs sacrifices et leurs encouragements à
tout moment.
A mes très chers frères Mohammed, Ayoub et Youness qui m’ont fait
retrouver le sourire et qui ont su m’encourager.
A mes amis Lilia, Raouf, Abla, Adel, Mira, Malek, Lidia, Hadjer,
Nabila, Amina, Sabrina.
A toutes les personnes qui ont contribué de prés ou de loin à
l'aboutissement de cette étude.

Ikram.
 TABLE DES FIGURES
Figure I.1 : Fiche de Voeux ........................................................................................................ 4

Figure I.2 : Organigramme ......................................................................................................... 5

Figure I.3 : Diagramme de flux .................................................................................................. 6

Figure II.1 : Diagramme globale .............................................................................................. 10

Figure II.2 : Diagramme « Espace-Responsable » ................................................................... 10

Figure II.3 : Diagramme « Gérer organigramme» ................................................................... 11

Figure II.4 : Diagramme « Espace-Enseignant » ..................................................................... 12

Figure II.5 : Diagramme « Gestion du site » ............................................................................ 13

Figure II.6 : Diagramme « Gérer affectation »........................................................................ 13

Figure II.7 : Diagramme « Ajout Affectation » ....................................................................... 14

Figure II.8 : Diagramme «Ajout Affectation par enseignant » ................................................ 15

Figure II.9 : Diagramme « Ajout Affectation par module » .................................................... 16

Figure II.10 : Diagramme « Ajout Affectation par enseignant-module » ................................ 17

Figure II.11 : Diagramme « Choisir Module».......................................................................... 17

Figure II.12 : Diagramme « Choisir Enseignant et Rechercher ses affectations »................... 17

Figure II.13 : Diagramme « Valider Affectation».................................................................... 18

Figure II.14 : Diagramme « Supprimer Affectation ».............................................................. 18

Figure II.15 : Diagramme de classes ........................................................................................ 19

Figure III.1 : Page d’accueil Espace Enseignant ..................................................................... 25

Figure III.2 : Fiche de vœux .................................................................................................... 26

Figure III.3 : consulter / Imprimer fiche de vœux ................................................................... 27

Figure III.4 : Page d’accueil Espace Responsable .................................................................. 28

Figure III.5 : Interface Organigramme .................................................................................... 29

Figure III.6 : Affectation ......................................................................................................... 29

Figure III.7 : Module choisis / déjà Enseigné .......................................................................... 30

Figure III.8 : Espace Administrateur ........................................................................................ 31

Figure III.9 : Interface de l'authentification ............................................................................. 31

 TABLE DES MATIERS

Introduction Générale ................................................................................................................. 1

Chapitre I: Etude de l’existant
I.1 Introduction ........................................................................................................................... 2
I.2 Présentation du département d’informatique ........................................................................ 2
I.3 Postes de travail .................................................................................................................... 3
I.4 Documents utilisés ................................................................................................................ 3
I.5 Procédure de travail .............................................................................................................. 4
I.6 Diagramme de flux ............................................................................................................... 5
I.6.1 Définition des acteurs internes et externes ................................................................ 6
I.7 Problématique ....................................................................................................................... 6
I.8 Résolution des problématiques ............................................................................................. 7
I.9 Conclusion ............................................................................................................................ 8

Chapitre II : Conception
II.1 Introduction ......................................................................................................................... 9
II.2 Identification des acteurs du système ................................................................................. 9
II.2.1 Définition d’un acteur ............................................................................................... 9
II.3 Diagramme de cas d’utlisation ............................................................................................ 9
II.3.1 Diagramme globale ................................................................................................. 10
II.3.2 Diagramme Espace-Responsable ............................................................................ 10
II.3.3 Diagramme de gestion de l’organigramme ............................................................. 11
II.3.4 Diagramme Espace-Enseignant ............................................................................... 11
II.3.5 Diagramme de gestion du site ................................................................................. 12
II.4 Diagramme de séquence .................................................................................................... 13
II.4.1 Diagramme de séquence de la gestion des affectations .......................................... 13
II.4.2 Diagramme de séquence « Ajout Affectation » ...................................................... 14
II.4.3 Diagramme de séquence « Ajout Affectation par enseignant » .............................. 14
II.4.4 Diagramme de séquence « Ajout Affectation par module » ................................... 15
II.4.5 Diagramme de séquence « Ajout Affectation par enseignant-module » ................. 16
II.4.6 Diagramme de séquence « Choisir Module » ......................................................... 17
II.4.7 Diagramme de séquence « Choisir Enseignant et Rechercher ses affectations » ... 17
 II.4.8 Diagramme de séquence « Valider Affectation » ................................................... 18
II.4.9 Diagramme de séquence « supprimer Affectation » ............................................... 18
II.5 Diagramme de classes ....................................................................................................... 19
II.5.1 Définition des attributs du diagramme de classes ................................................... 20
II.5.2 Règles de gestion ..................................................................................................... 20
II.6 Les règles de passage du diagramme de classes vers le modèle relationnel .................... 21
II.6.1 Le shéma relationnel ............................................................................................... 22
II.7 Conclusion ......................................................................................................................... 23

Chapitre III : Implémentation

III.1 Introduction ...................................................................................................................... 24
III.2 Environnement de travail ................................................................................................. 24
III.2.1 Outils ...................................................................................................................... 24
III.2.2 Langages de développement .................................................................................. 24
III.3 Interfaces de l’application ................................................................................................ 25
III.3.1 Session Enseignant................................................................................................. 25
III.3.1.1 Page d’accueil Enseignant ............................................................................ 25
III.3.1.2 Interface Fiche de voeux ............................................................................... 25
III.3.1.3 Consulter / Imprimer fiche de voeux ............................................................ 27
III.3.2 Session Responsable .............................................................................................. 27
III.3.2.1 Page d’accueil Responsable ......................................................................... 27
III.3.2.2 Interfaces Organigramme ............................................................................. 28
III.3.3 Espace Administrateur ........................................................................................... 30
III.4 Interface de l’authentification .......................................................................................... 31
III.5 Conclusion ........................................................................................................................ 31
Conclusion Générale

Bibliographie

Webographie

Annexes
Introduction générale

Introduction Générale :

L’informatique est vue comme étant le moyen d’automatiser et de traiter les informations,
elle a pris une place impressionnante dans les entreprises, les universités et les domiciles et ce
grâce à tous les développements qu’elle a connu.

Parmi les plus grandes révolutions que l’informatique ait connu : L’Internet, dont l’utilisation
est sans doute devenue incontournable dans toutes les entreprises, universités, domiciles, et
surtout depuis l’invention du web. Grâce au web les communications et les échanges
d’informations entre les personnes ont été facilités et simplifiés et ce en établissant des outils
adéquats.

Au sein du département d’informatique de la faculté d’électronique et informatique de

l’université des sciences et de la technologie HOUARI BOUMEDIENE « USTHB », à
chaque fin d’année, une gestion de l’organigramme des enseignements est établie. Toutefois,
cette gestion se fait toujours manuellement par manque d’un système d’information
automatique qui pourrait faciliter, automatiser cette tâche et résoudre plusieurs problèmes tels
que l’absence d’informations et de communications.

Dans le cadre de notre projet de fin d’étude, il nous a été demandé de créer un outil d’aide à la
gestion de l’organigramme des enseignements du département d’informatique. L’objectif de
notre projet consiste à améliorer la gestion actuelle et faciliter la communication entre les
différents acteurs du système, ce qui permettra un gain de temps précieux.

Le présent mémoire est composé de trois chapitres comme suit :

Chapitre I : Dans ce premier chapitre intitulé « Etude de l’Existant », nous présenterons le

cadre de travail ainsi que la manière dont la gestion de l’organigramme se fait actuellement,
nous décèlerons aussi ses inconvénients.

Chapitre II : Le chapitre « Conception » aura pour objectif de modéliser le nouveau système

en adoptant comme langage de modélisation le langage UML.

Chapitre III : Le dernier chapitre « Implémentation » sera consacré à la réalisation de l’outil,

ou nous détaillerons les outils ainsi que les langages utilisés. Une description des différentes
fonctionnalités sera illustrée.

Nous terminerons par une conclusion.

1
Chapitre I :
Etude de l’Existant
Chapitre I : de l’Existant

I.1 Introduction
L’étude de l’existant est une étape importante dans le cycle du développement des logiciels et
des systèmes d’information automatisés. En effet, cette étude nous permettra de décrire le
système tel qu’il existe réellement, d’en déceler les composantes, comprendre le
fonctionnement et de cerner ses principaux acteurs. Cela consiste à construire une description
du système avec ses anomalies afin de pouvoir mieux identifier les problèmes et donc y
apporter des solutions à des phases ultérieures.

Pour cela, nous devrons recenser les postes de travail, les documents utilisés dans le système,
la manière dont la gestion de l’organigramme des enseignements se fait actuellement et
déceler les problématiques de cette dernière. Enfin, nous présenterons les solutions
envisagées pour créer le nouveau système.

I.2 Présentation du département d’informatique

Le département d’Informatique fut créé en 1974 au sein de l’Institut de mathématique. Ce
département formait des ingénieurs d’état en Informatique de l’USTHB. Il devint institut
d’Informatique en 1986.

L’institut redevient en l’an 2000 un département d’Informatique mais cette fois rattaché à la
faculté d’électronique et d’Informatique.

Le département d’Informatique a adopté le cursus d’étude LMD (Licence, Master, Doctorat)

depuis l’année 2005.

Il propose aux étudiants du domaine Mathématique et Informatique (MI) trois spécialités en

licence :

 Licence Informatique Générale (LIG).

 Génie des Télécommunications et Réseaux (GTR).
 Licence Ingénierie des Systèmes d’Information (ISIL).

Les masters proposés actuellement par le département sont :

 Master Réseaux et Systèmes Distribués (RSD).

 Master Ingénierie des Logiciels (IL).
 Master Systèmes Informatiques (SII).
 Master Sécurité des Systèmes Informatiques (SSI).
 Master Architecture parallèles et Calcul Intensif (APCI).
 Master Mathématique et Informatique décisionnelle (MIND).

Ces informations ont été prises du site de l’USTHB:http://www.usthb.dz/deptinfo/?q=node/1.

2
Chapitre I : de l’Existant

Durant tous leurs cursus, les étudiants sont suivis et accompagnés par les enseignants du
département dont le nombre ne cesse d’augmenter, et dont l’effectif est d’environ 170
enseignants en incluant les vacataires.

I.3 Postes de travail

Le poste de travail décrit la localisation, les responsabilités, et les ressources nécessaires pour
chaque profil d’utilisateurs du système [ALI, 10]. Dans le système étudié, nous avons recensé
les postes de travail suivants:

1. Responsable : c’est l’un des postes les plus importants dans le système. Il se
charge des affectations des enseignements du département.
2. Enseignant : l’enseignant a un poste de travail qui lui permet de renseigner une
fiche de vœux afin d’être affecté à un ou plusieurs modules, que ce soit un cours,
un TD ou un TP. Chaque enseignant possède des compétences nécessaire afin
d’enseigner ces modules.
3. Secrétariat : reçoit les fiches de vœux des enseignants et les transmets au
responsable et se charge de l’affichage de l’organigramme.

I.4 Documents utilisés

Ce sont les supports des informations nécessaires à la gestion du département. Ils transportent
le flux d’information entre les postes de travail (Voir Annexe A).Dans le système actuel,
nous avons recensé les documents suivants :

1. Fiche de vœux : Elle comprend les choix des enseignements que l’enseignant désire
assurer durant le 1er et 2èmesemestre. Cette fiche (Figure I.1) contient 4 choix par
semestre. L’enseignant indique les modules qu’il désire enseigner par priorité (choix 1
jusqu’au choix 4). Chaque choix possède un cours, un TD et un TP.

3
Chapitre I : de l’Existant

Figure I.1: Fiche de Vœux.

2. Liste des programmes : L’ensemble des programmes (Licence et Master) proposés

par le département d’Informatique qui est accessible via le site de l’université
(http://www.usthb.dz/deptinfo/?q=node/2).

3. L’organigramme : C’est un document qui contient les affectations des enseignants. Il

est établi par le responsable (Figure I.2).

I.5 Procédure de travail

Afin d’établir l’organigramme de chaque année universitaire (deux semestres), le rectorat
adresse au responsable du département d’Informatique le nombre de sections et groupes
concernant le tronc-commun (Licence 1).Le responsable à son tour informe le rectorat du
nombre de sections par palier et par spécialité ainsi que le nombre de groupes par section pour

4
Chapitre I : de l’Existant

les L2, L3, M1 et M2. Ensuite, le responsable envoi aux enseignants une fiche de vœux à
remplir à la fin de l’année (vers le mois de Mai). Cette fiche devra être remise avant une date
limite (première semaine de Juin généralement). L’enseignant quant à lui devra la renseigner.
Autrement dit, il doit préciser les modules qu’il souhaite assurer, puis il devra remettre sa
fiche de vœux au niveau du secrétariat.
Une fois la date limite atteinte, le responsable pourra débuter les affectations et ce en ayant
une liste des enseignants triée par ordre alphabétique sur un fichier enregistré sous EXCEL.
Une fois l’enseignant sélectionné, le responsable effectuera les affectations tout en se basant
sur l’organigramme de l’année précédente et les choix précisés sur la fiche de vœux.
Avant d’effectuer la validation des affectations pour chaque enseignant, une réunion est
programmée vers la première semaine de Septembre avec le responsable et tous les
enseignants. Si aucune réclamation n’est faite alors l’organigramme est validé, sinon une
modification sera établie. L’organigramme peut être éventuellement modifié au second
semestre pour des causes différentes :
1. Disponibilité de l’enseignant.
2. Arrêt de travail.

Enfin l’organigramme sera imprimé et affiché. Voici un exemple de la structure de

l’organigramme :

L2 ACAD B

ACAD S2

Section A Cours Td1 Td2 Td3 Tp1 Tp2 Tp3

POO E1 E1 E1 E1 E2 E3 E4
ARCHIT E5 E5 E5 E5 E5 E5 E5
BD E6 E6 E6 E6 E7 E8 E7
SYS01 E9 E9 E10 E10 E10 E10 E11
THL E12 E12 E12 E12
OPTION E13
ANGLAIS E14 E14 E14

Figure I.2 : Organigramme.

I.6 Diagramme de flux

Les flux d'informations sont un échange d'informations (message) entre des acteurs (externes
ou internes au système étudié) et le domaine étudié. On appelle Diagramme des flux (DFD),
une modélisation qui représente uniquement ces flux échangés, sans chronologie et sans
description des activités associées (en entrée ou sortie) à ces flux [WEB1].

5
Chapitre I : de l’Existant

I.6.1 Définition des acteurs internes et externes :

Acteur interne : L’acteur interne est celui qui appartient au domaine étudié (Voir Annexe A),
il y participe activement en effectuant des tâches, et en prenant des décisions importantes.

Acteur externe : L’acteur externe quant à lui appartient à l’environnement du système, son
activité est considérée comme éphémère et limitée.

Le diagramme de flux de notre système est représenté dans la figure ci-dessous (Figure I.3)

Figure I.3 : Diagramme de flux.

- (1) : Envoyer fiche de vœux.

- (2) : Déposer fiche de vœux remplie.
- (3) : Remettre les fiches de vœux déposées par les enseignants.
- (4) : Envoyer le nombre de sections et de groupes par section du tronc-commun (L1).
- (5) : Envoyer le nombre de sections par palier et par spécialité ainsi que le nombre de
groupes par section pour L2, L3, M1 et M2.
- (6) : Remettre organigramme pour Affichage.

I.7 Problématique
Nous avons pu déceler plusieurs anomalies lors de la description de la procédure de travail:

6
Chapitre I : de l’Existant

 Les enseignants doivent chercher les informations des modules sur le site de
l’USTHB.
 L’absence de moyens de partage des informations et documents.
 Le déplacement nécessaire des enseignants pour déposer la fiche de vœux au niveau
du secrétariat.
 L’affectation se fait manuellement, et vue que le nombre d’enseignants et le nombre
de spécialité par palier augmente, une affectation peut être oubliée, ce qui engendre :
1- Un module sans enseignant.
2- Un enseignant qui n’a pas une charge horaire complète.
3- Un enseignant peut avoir trop de charge.
 Le responsable ne dispose pas du nombre d’heures supplémentaires de l’enseignant et
ce si celui-ci désire en faire.
 Le responsable ne connait pas toutes les compétences des enseignants surtout celles
récemment acquises.

I.8 Résolution des problématiques

Le projet vise à mettre en place une application web qui offrira plusieurs fonctionnalités pour
le responsable et les enseignants. Cette application doit prendre en charge les différentes
opérations nécessaires à la gestion de l’organigramme des enseignements du département
d’Informatique. Elle vise à apporter les solutions suivantes :

 La fiche de vœux sera mise en ligne à la disposition des enseignants, après que le
responsable ait activé celle-ci, ce qui évitera aux enseignants tout déplacement.
 Une rubrique qui concerne les heures supplémentaires sera ajoutée sur la fiche de
vœux afin que l’enseignant puisse préciser s’il désire en faire ou pas en précisant le
nombre de séances.
 L’enseignant pourra spécifier ses compétences et les mettre éventuellement à jour.
 Une liste des programmes sera mise à la disposition des enseignants pour qu’ils
puissent avoir des informations sur les modules.
 L’enseignant pourra consulter son affectation une fois que l’organigramme des
enseignements est terminé.
 La liste des compétences des enseignants pourra être consultée par le responsable.
 Le responsable pourra vérifier la charge horaire d’un enseignant afin de confirmer que
celui-ci a sa charge complète.
 Une liste des modules sans enseignant sera générée.
 Le responsable pourra vérifier si un enseignant a déjà enseigné un module.
 Le responsable sera assisté pour élaborer son organigramme.

7
Chapitre I : de l’Existant

 Un système de messagerie sera proposé pour permettre une communication directe

entre les différents acteurs.
 Ajouter une base de données pour les enseignants vacataires pour faciliter la recherche
d’un enseignant dans le cas ou la liste des enseignants potentiels est vide ou bien le
résultat est non satisfait.

I.9 Conclusion
Dans ce chapitre, nous avons étudié la manière dont le système actuel de la gestion de
l’organigramme des enseignements du département d’Informatique fonctionne, comme nous
avons essayé de mentionner toutes ses anomalies et ses inconvénients.

La partie Analyse et critiques de ce chapitre nous a permis d’avoir une vision informatisée de
cette gestion qui minimisera certaines problématique de l’ancien système. Dans le chapitre
suivant « Conception » nous allons proposer le nouveau système qui répondra aux besoins de
la gestion de l’organigramme des enseignements.

8
Chapitre II :
Conception
Chapitre II : Conception

II.1 Introduction
Après avoir établi l’étude de l’existant, nous avons pu évaluer les problèmes liés à la gestion
de l’organigramme des enseignements qui se fait actuellement.

Dans ce chapitre, nous allons décrire la conception et la modélisation de notre système. Pour
cela nous allons utiliser le langage UML, qui est un langage de modélisation graphique qui va
nous permettre de comprendre et de décrire les besoins, de spécifier et documenter le système.

La conception de notre application se base sur :

 Les diagrammes des cas d'utilisation.

 Les diagrammes de séquences.
 Les diagrammes de classes.

Afin de pouvoir réaliser cette conception nous devrons recenser les acteurs du système ainsi
que leurs interactions avec celui-ci et qui seront représentés dans les diagrammes des cas
d’utilisation. Nous allons aussi donner les événements du système de manière chronologiques
qui seront établies dans les diagrammes de séquences, enfin nous décrirons la structure interne
du système dans le diagramme de classes.

II.2 Identification des acteurs du système

II.2.1 Définition d’un acteur

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel
ou autre système) qui interagit directement avec le système étudié. Un acteur peut consulter
et/ou modifier directement l’état du système, en émettant et/ou recevant des messages
susceptibles d’être porteurs de données [PAS, 06].

Les acteurs recensés dans notre système sont :

 Enseignant : tout enseignant du département d’informatique qui doit disposer d’un

compte personnel.
 Responsable : c’est la personne qui gère l’organigramme des enseignements.
Actuellement ce rôle est joué par le chef de département.
 Administrateur : personne chargée de la gestion du site et des comptes utilisateurs.

II.3 Diagramme de cas d’utilisation

Un cas d’utilisation (use case) modélise une interaction entre le système informatique à
développer et un utilisateur ou acteur interagissant avec le système. Plus précisément, un cas
d’utilisation décrit une séquence d’actions réalisées par le système qui produit un résultat
observable pour un acteur [SIG, 06].

9
Chapitre II : Conception

NB : Avant d’accéder au site, les acteurs doivent s’authentifier (insérer leurs username et mot
de passe).Nous n’avons pas représenté cette étape dans nos diagrammes afin de ne pas les
encombrer.

Nous commencerons par donner le diagramme de cas d’utilisation global, puis nous
détaillerons les autres diagrammes de cas d’utilisation du système.

II.3.1 Diagramme globale

Figure II.1 : Diagramme globale.

II.3.2 Diagramme Espace-Responsable

Le responsable a plusieurs fonctions à sa charge : la gestion de l’organigramme établie chaque
année, la gestion des enseignants et celle des programmes (Figure II.2). Le cas d’utilisation
"Gérer organigramme" représente le noyau de notre système, nous avons préféré le décrire
séparément (Figure II.3).

Figure II.2 : Diagramme « Espace-Responsable ».

10
Chapitre II : Conception

II.3.3 Diagramme de gestion de l’organigramme

Le responsable devra paramétrer l’organigramme afin de préciser le nombre de sections et de
groupes pour chaque palier, chaque spécialité et chaque niveau. Il pourra activer et désactiver
la fiche de vœux, ainsi que la consulter. Il aura la possibilité d’ajouter et supprimer des
affectations, et aussi consulter et imprimer l’organigramme (Figure II.3).

Figure II.3 : Diagramme « Gérer organigramme ».

II.3.4 Diagramme Espace-Enseignant

L’enseignant a pour fonctionnalité principale la gestion de sa fiche de vœux. Il doit la remplir
en fixant ses choix sur les modules qu’il désire enseigner. Le système permettra à l’enseignant
11
Chapitre II : Conception

de modifier ses choix avant une date limite fixée par le responsable. L’enseignant pourra
consulter son affectation, l’imprimer et éventuellement envoyer un recours s’il n’est pas
satisfait de son affectation. De plus il pourra gérer son profil et consulter les programmes des
différents paliers à tout moment (Figure II.4).

Figure II.4 : Diagramme « Espace-Enseignant ».

II.3.5 Diagramme de gestion du site

L’administrateur en plus de gérer le site, peut gérer les comptes des utilisateurs, soit en
ajoutant, en modifiant ou en le supprimant(Figure II.5).

12
Chapitre II : Conception

Figure II.5 : Diagramme « Gestion du site ».

II.4 Diagramme de séquence

Les diagrammes de séquences mettent en valeur les échanges de messages (déclenchant des
événements) entre les acteurs et le système et/ou les objets de celui-ci de manière
chronologique [SIG, 06].Il existe deux types de diagrammes de séquences : Diagramme de
séquence d’analyse et de conception. Un diagramme de séquence d’analyse permet de décrire
les interactions temporelles entre les acteurs et le système considéré comme une boite noire.
Il fournit une description graphique d’un cas d’utilisation. Par contre un diagramme de
séquence de conception décrit les interactions temporelles entre les acteurs et le système vu
comme un ensemble d’objets. Il modélise la réalisation d’un cas d’utilisation du système
décrit par le diagramme des classes.
Dans ce chapitre, nous avons utilisé les diagrammes de séquence d’Analyse pour documenter
nos cas d’utilisation.

II.4.1 Diagramme de séquence de la gestion des affectations

Le responsable gère les affectations en effectuant des ajouts, des suppressions et même des
consultations (Figure II.6).

Figure II.6 : Diagramme « Gérer affectation ».

13
Chapitre II : Conception

Dans ce chapitre, nous allons décrire les diagrammes de séquences de : « Ajout Affectation »
et « Supprimer Affectation ».

II.4.2 Diagramme de séquence « Ajout Affectation »

L’ajout des affectations peut être effectué de trois manières différentes : L’ajout par
enseignant, l’ajout par module ou par enseignant-module (Figure II.7).

Figure II.7 : Diagramme « Ajout Affectation ».

II.4.3 Diagramme de séquence « Ajout Affectation par enseignant »

L’ajout des affectations par enseignant consiste à fixer l’enseignant et lui chercher un module
pour le lui attribuer et ce tout en ayant des conditions et en prenant en compte certains
critères des modules (modules déjà enseignés, modules choisis, modules de licence, etc…)
pour établir la liste des modules potentiels1 (Figure II.8). Si la liste est vide ou aucun choix
n’est satisfaisant alors il est possible de choisir un module parmi l’ensemble des modules
proposés par le département. Une fois le module sélectionné et avant de valider l’affectation,
on doit vérifier qu’il n’a pas été déjà attribué à un autre enseignant.

1
: C’est les modules déjà enseignés ou bien demandés par un enseignant.

14
Chapitre II : Conception

Figure II.8 : Diagramme «Ajout Affectation par enseignant ».

II.4.4 Diagramme de séquence « Ajout Affectation par Module »

L’ajout d’affectation par module consiste à fixer le module et préciser si c’est un cours, un TD
ou un TP et lui chercher un enseignant pour l’y affecter en vérifiant des conditions et en
prenant en compte des critères (Figure II.9).

15
Chapitre II : Conception

Figure II.9 : Diagramme «Ajout Affectation par module ».

II.4.5 Diagramme de séquence « Ajout Affectation par enseignant-module»

Afin d’établir l’ajout par Enseignant-Module, le responsable fixe le module pour ensuite fixer
l’enseignant, l’ajout s’effectuera si le module n’a pas encore été affecté et si l’enseignant peut
encore avoir une (des) affectation (s) en plus. La Figure II.10 illustre les étapes de cet ajout.

16
Chapitre II : Conception

Figure II.10 : Diagramme « Ajout Affectation par enseignant-module ».

II.4.6 Diagramme de séquence « Choisir Module »

Figure II.11 : Diagramme « Choisir Module».

II.4.7 Diagramme de séquence « Choisir Enseignant et Rechercher ses

affectations »

Figure II.12 : Diagramme «Choisir Enseignant et Rechercher ses affectations».

17
Chapitre II : Conception

II.4.8 Diagramme de séquence « Valider Affectation »

Figure II.13 : Diagramme « Valider affectation».

II.4.9 Diagramme de séquence « Supprimer Affectation »

La suppression d’une affectation peut s’effectuer de trois manières différentes : en fixant
l’enseignant, le module ou en fixant l’enseignant-module (Figure II.14).

Figure II.14: Diagramme « Supprimer Affectation ».

18
Chapitre II : Conception

II.5 Diagramme de classes

Le diagramme de classes est le point central dans un développement orienté objet [PAS, 06].
Pour cela, il faut identifier les classes ainsi que les associations pertinentes entre celles-ci. Les
cardinalités (ou multiplicités) fournit une indication sur le nombre d’objets d’une même
classe participant à l’association. Elles sont extraites des règles de gestion du système étudié
données ci-dessous. La notation des cardinalités est la suivante :
 1 : Obligatoire (un et un seul).
 0..1 : Optionnel (0 ou 1).
 0..* ou * : Quelconque.
 N..* : Au moins N.
 N..M : Entre N et M.
 L, N, M : L, N, ou M.

Figure II.15 : Diagramme de classes

19
Chapitre II : Conception

II.5.1 Définitions des attributs du diagramme de classes

Attributs Significations

Grade C’est le grade de l’enseignant : MAA, MAB, MCA, MCB,

Professeur ou Vacataire.
Catégorie Vacataire, Permanent.

Palier Licence ou Master.

Spécialité Une spécialité concerne l’un des deux paliers comme suit :
- ACAD, ISIL, GTR pour le palier Licence.
- RSD, SII, SSI, MIND, APCI pour le palier Master.
Niveau - L1, L2, L3 pour Licence
- M1, M2 pour Master
Heures-Supp-Dem-S1 Les heures supplémentaires demandées par l’enseignant pour
le semestre 1.
Nb-Heures-Sup-Affectés-S1 Le nombre d’heures supplémentaires affectés à l’enseignant
pour le semestre 1.
Num-Choix C’est un numéro séquentiel

Type-Choix Le type de choix signifie : Cours, TD ou TP.

Priorité Les choix de la fiche de vœux sont ordonnés par ordre

décroissant de priorité (Choix1, Choix 2, Choix 3, Choix 4)
pour chaque semestre.
TypeAffectation Une affectation est soit pour un cours, pour un TD ou pour un
TP.
Intitulé C’est l’intitulé du module.

Abrev L’abréviation de module, exemple : Base de Données

BDD.

II.5.2 Règles de gestion

Les règles de gestion du système étudié sont :

 un département comprend un ou plusieurs enseignants, il a un et un seul de ces

derniers qui joue le rôle du chef de département. Un enseignant est rattaché à un seul
département.
 Un département a zéro ou plusieurs organigrammes, un organigramme concerne un
département.
 Un organigramme est composé de zéro ou plusieurs affectations.
 Une affectation concerne un seul module, un seul enseignant, une seule promotion et
zéro ou un groupe. Par contre, un module, un enseignant, une promotion et un groupe
peuvent avoir plusieurs affectations.
 Une promotion est composée de un ou plusieurs groupes, elle suit un seul programme.
Un programme peut être suivi par zéro ou plusieurs promotions.

20
Chapitre II : Conception

 Un programme est composé de deux programmes semestriels, un programme

semestriel est composé de plusieurs modules.
 Un enseignant peut enseigner zéro ou plusieurs modules, un module peut être assuré
par zéro ou plusieurs enseignants.
 Un enseignant établit zéro ou plusieurs choix de modules.
 Un module peut être choisi par plusieurs enseignants.

Un administrateur gère zéro ou plusieurs comptes, un compte est géré par un et un seul
administrateur.

II.6 Les règles de passage du diagramme de classes vers le modèle

relationnel :
Un des grands avantages du modèle relationnel est sa très grande simplicité. Il n’existe en
effet qu’une seule structure, la relation (ou table). Une relation a donc un nom et se compose
d’un ensemble d’attributs.
Le modèle relationnel inclut deux propriétés d’intégrité générales :
1. les clés primaires : une clé primaire d’une relation est simplement un identificateur
unique de cette relation.
2. les clés étrangères : ce sont les attributs qui font référence à une ligne dans une autre
table.

Pour traduire un diagramme de classe en un schéma relationnel équivalent, on a utilisé ces

règles de transformation [SOU, 12] :

Règle1 : Classes
Chaque classe du diagramme UML devient une relation dans laquelle les attributs de la
relation ou de la table traduisent les attributs de la classe. Il faut choisir un attribut de la classe
pouvant jouer le rôle d’identifiant. Si aucun attribut ne convient en tant qu’identifiant, il faut
en ajouter un de telle sorte que la relation dispose d’une clé primaire.

Règle2 : Association avec cardinalité plusieurs à plusieurs

Ajouter une troisième table qui aura comme attributs les clés des deux classes liées par
l’association et dont la clé primaire est composée de ces derniers.

Règle3 : Association avec cardinalité un à plusieurs

Ajouter la clé primaire de la relation dérivée de la classe (qui a la cardinalité 1) comme clé
étrangère dans la relation fils dérivée de la classe (qui a la cardinalité plusieurs).

Règle4 : Association avec cardinalité un-un

- Ajouter la clé primaire de la classe qui a une cardinalité minimale à 1 comme clé
étrangère dans l’autre classe.
- Si les deux cardinalités minimales sont à 1, fusionner les deux classes en une seule et
la clé de l’une des deux classes est prise comme clé primaire.

21
Chapitre II : Conception

- Si les deux classes sont très différentes, créer les deux relations et mettre comme clé
étrangère dans l’une des deux relations la clé primaire de l’autre.

Règle5 : Héritage
Trois décompositions sont possibles :
- Décomposition par distinction : La clé primaire de la sur-classe migre dans les
relations issues des sous-classes et devient à la fois clé primaire et clé étrangère.
- Décomposition descendante : faire migrer tous les attributs de la sur-classe dans les
relations issues des sous-classes.
- Décomposition ascendante : Il faut supprimer les relations issues des sous-classes et
faire migrer les attributs dans la relation issue de la sur-classe.

Règle6 : Composition
La clé primaire des relations déduites des classes composantes doit contenir la clé primaire de
la classe composite.

II.6.1 Le schéma relationnel :

En appliquant les règles de passages, nous avons recensé les relations suivantes :

 Administrateur (id_admin, #id-user Nom, Prénom, Email, Tel,).

 Utilisateur (id_user, Nom, Prénom, Email, Tel, #username)
 Enseignant (codeE, #id-user, grade, chargeMin, catégorie, chargeaffecté, nom,
prénom, Email, Tel, Heures-Supp-Dem-S1, Heures-Supp-Dem-S2, Nb-Heures-Sup-
Affectés-S1, Nb-Heures-Sup-Affectés-S2).
 Compte (username, password, #id_admin, #id-user).
 Département (NomDep, #Chef_Dep).
 Choix-Module (num_choix, type-choix, Priorité, #codeE, #codeM).
 Module (codeM, #id_semestre, #id_prog, intitule, abrev, NbSeanceCours,
NbSeanceTD, NbSeanceTP).
 Groupe (Numero_groupe, #id_promo).
 Programme (id_prog, PalierP, Nomspécialite, Niveau, dateDébutValidité,
DateFinValidité).
 Affectation (id_affect, #annéeUniv, TypeAffectaion, #id_promo, #codeE, #codeM,
#Numero_groupe).
 Promotion (id_promo, palier, spécialité, Année, Niveau, Section, #id_prog,
#NomDep).
 Organigramme (AnnéeUniv, #NomDep).
 Pouvoir_Enseigner( #codeE, #codeM).
 Prog_semestriel (id_semestre, #id_prog).

22
Chapitre II : Conception

Notation : Nous avons choisi de :

- Souligner et mettre en gras les clés primaires.

- Mettre en gras les clés étrangères et les faire précéder par un dièse (#).

II.7 Conclusion :
A l’issue de ce chapitre, la modélisation de notre système a été établie grâce à la méthode
UML, ce qui nous a permis de détailler les aspects fonctionnels, statiques et dynamiques du
système. Dans le chapitre qui suit « Implémentation » nous présenterons tous les outils ainsi
que les langages qui nous ont permis de réaliser l’implémentation du système, nous
exposerons aussi quelques fonctionnalités de l’outil.

23
Chapitre III :
Implémentation
Chapitre III : Implémentation

III.1 Introduction
Dans ce chapitre, nous allons présenter l’environnement de travail ainsi que les outils et les
langages de programmation utilisés, qui nous ont permis de réaliser notre système. Nous
présenterons l’outil avec des illustrations.

III.2 Environnement de travail

III.2.1 outils
Notepad++ : est un éditeur de code source qui prend en charge plusieurs langages tels que:
HTML, CSS, SQL, JavaScript…etc. cet éditeur est codé en C++ [WEB2].

WampServer : WampServer est une plate-forme de développement Web sous Windows pour
des applications Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et
d’une base de données MySQL. Il possède également PHPMyAdmin pour gérer plus
facilement les bases de données [WEB3].

III.2.2 Langages de développement

HTML :(HyperText MarkupLanguage) : Son rôle est de gérer et organiser le contenu.
C'est donc en HTML que l’on écrit ce qui doit être affiché sur la page : du texte, des liens, des
images [WEB4].

CSS (Cascading Style Sheets, aussi appelées Feuilles de style):Le rôle du CSS est de
gérer l'apparence de la page web (agencement, positionnement, décoration, couleurs, taille du
texte…). Ce langage est venu compléter le HTML [WEB4].

PHP: HypertextPreprocessor :est un langage de programmation libre principalement

utilisé pour produire des pages Web dynamiques via un serveur HTTP, mais pouvant
également fonctionner comme n'importe quel langage interprété de façon locale. PHP est
un langage impératif orienté objet comme C++ [WEB5].

SQL (StructuredQueryLanguage) : est un langage permettant de communiquer avec une

base de données. Ce langage informatique est notamment très utilisé par les développeurs web
pour communiquer avec les données d’un site web [WEB6].

JAVASCRIPT: Le JavaScript (JS) est un langage dit client-side, c'est-à-dire que les scripts
sont exécutés par le navigateur chez l'internaute (le client). Cela diffère des langages de
scripts dits server-side qui sont exécutés par le serveur Web. C'est le cas des langages comme
le PHP [WEB4].

AJAX : AJAX est l'acronyme d'Asynchronous JavaScript And XML, autrement

dit JavaScript Et XML Asynchrones. AJAX n'est ni une technologie ni un langage de
programmation ; AJAX est un concept de programmation Web reposant sur plusieurs
technologies comme le JavaScript et le XML – d'où le nom AJAX.L'idée même d'AJAX est
de faire communiquer une page Web avec un serveur Web sans occasionner le rechargement

24
Chapitre III : Implémentation

de la page. C'est la raison pour laquelle JavaScript est utilisé, car c'est lui qui va se charger
d'établir la connexion entre la page Web et le serveur [WEB4].

III.3 Interfaces de l’application

Dans cette partie, nous allons présenter les interfaces les plus pertinentes de l’outil d’aide à la
gestion de l’organigramme des enseignements du département d’informatique.

III.3.1 Session Enseignant

III.3.1.1 Page d’accueil Enseignant

La page d’accueil de l’espace enseignant (Figure III.1), offre à tout enseignant plusieurs
fonctionnalités : l’accès à la fiche de vœux, aux programmes, consultation de leurs
affectations, leur profil et leur messagerie.

Figure III.1 : Page d’accueil Espace Enseignant.

III.3.1.2 Interface Fiche de vœux

La figure ci-dessous illustre l’interface permettant de remplir la fiche de vœux de

l’enseignant (Figure III.2).

25
Chapitre III : Implémentation

Figure III.2 : Fiche de vœux.

26
Chapitre III : Implémentation

III.3.1.3 Consulter/imprimer fiche de vœux

L’enseignant peut consulter sa fiche de vœux et l’imprimer (figure III.3).

Figure III.3 : Consulter/Imprimer fiche de vœux.

III.3.2 Session Responsable

III.3.2.1 Page d’accueil Responsable

Le menu principal de la page d’accueil « Espace Responsable » est constitué (Figure III.4) :
Accueil, Organigramme, Enseignant, Programmes, Espace Enseignant et Messagerie.
« Espace Enseignant » permet au responsable d’accéder à son espace enseignant.

27
Chapitre III : Implémentation

Figure III.4 : Page d’accueil Espace Responsable.

III.3.2.2 Interface Organigramme

Le menu Organigramme permet au responsable de gérer les affectations, consulter

l’organigramme et les fiches de vœux ainsi que la possibilité de paramétrer l’organigramme
(Figure III.5).

28
Chapitre III : Implémentation

Figure III.5 : Interface Organigramme.

Si le responsable choisi le sous-menu « AFFECTATION » il aura les possibilités

suivantes (Figure III.6):

Figure III.6 : Affectation.

29
Chapitre III : Implémentation

La Figure III.7 illustre l’ajout d’une affectation par module.

Figure III.7 : Module choisis/déjà Enseigné.

La colonne « Compétences » représente les compétences de l’enseignant : Environnement de

programmes, langages de programmation,système d’exploitation et autres.

Dans ce cas, le responsable peut choisir un des enseignants de la liste proposée pour lui
affecter le module. Au préalable, il peut consulter la liste de ses affectations et ses
compétences.

III.3.3 Espace Administrateur

L’administrateur aura la possibilité : d’ajouter un compte utilisateur, le modifier ou le

supprimer (Figure III.8).

30
Chapitre III : Implémentation

Figure III.8 : Espace Administrateur

III.4 Interface de l’authentification

Avant tout accès aux différents espaces, chaque utilisateur devra s’authentifier (Figure III.9).

Figure III.9 : Interface de l’authentification.

III.5 Conclusion
Dans ce chapitre nous avons exposé l’environnement, les langages et les outils utilisés afin de
réaliser l’implémentation de l’outil d’aide à la gestion de l’organigramme des enseignements
du département informatique.

31
Conclusion Générale
Ce modeste travail consistait à réaliser un outil d’aide à la gestion de l’organigramme des
enseignements du département Informatique. Pour cela, nous avons commencé par établir
une étude du système présent afin d’assimiler le fonctionnement de la gestion actuel et de
détecter toutes les anomalies existantes. L’objectif de ce travail consistait alors à la résolution
de problématiques recensées lors de cette étude de l’existant. Par la suite, nous nous sommes
penchés sur la modélisation du nouveau système à réaliser et ce grâce au langage UML. Pour
finir nous avons utilisé différents langages afin d’implémenter notre outil d’aide à la gestion
de l’organigramme des enseignements du département Informatique : HTML5, CSS3, PHP,
etc…

Ce projet nous a permis :

 D’acquérir une vision méthodologique pour la réalisation des projets.

 Analyser les besoins et détections des anomalies du système actuel afin d’atteindre les
objectifs pour réaliser le nouveau système.
 S’initier dans le monde du travail.
 Améliorer nos connaissances dans le développement
 Apprendre de nouveaux langages tels que : HTML5, CSS3, PHP, AJAX, JavaScript,
MySQL.

L’application réalisée a atteint globalement les objectifs fixés. Cependant, tout travail est
perfectible, plusieurs perspectives peuvent être envisagées :

1. Certaines fonctionnalités pourraient être améliorées telles que :

 Actuellement, la consultation des formations se fait en sélectionnant le cahier
de charge de la spécialité recherchée (Chaque spécialité a sa propre fiche
technique) pour voir des informations sur les modules proposées par celle-ci.
Cette fonctionnalité peut être améliorée de façon à être dynamique
(c-à-d : écrire le nom d’une spécialité dans un formulaire donnera comme
résultat les modules qui la concerne avec tous ces renseignements).
 Améliorer la fonctionnalité du paramétrage des sections et groupes (lorsque
que l’on affecte le nombre de groupe et section pour chaque spécialité).
 Permettre la modification des paramètres même si les affectations ont
commencées.
 Actuellement, l’ajout et les modifications des programmes se fait par
l’importation des cahiers de charges sous format PDF. L’amélioration de cette
fonctionnalité va permettre au responsable d’ajouter, de modifier et même de
supprimer ces programmes d’une manière dynamique (en utilisant des
formulaires).
2. De nouvelles fonctionnalités peuvent être ajoutées :
 Installer un serveur de messagerie électronique afin de permettre la
communication entre le responsable et les enseignants (échange des Emails,
Recours, …).
 Ajouter d’autres critères pour la recherche des enseignants (respectivement
des modules) potentiels et permettre au responsable de choisir les critères
souhaités.
 Etablir la liste des Heures supplémentaires des enseignants.
Annexes
 Annexe A

1- Démarche à suivre pour une étude d’existant

La démarche possible qui pourra consister à faire ce qui suit :

- Découvrir l’entreprise et s’imprégner de son langage.
- Recenser les postes de travail ou stations.
- Recenser les documents et les étudier.
- Recenser les tâches intrinsèques à chaque poste de travail.
- Décrire et étudier les procédures de travail.

2- Définitions
a. Domaine d’étude : un domaine d’étude délimite le périmètre précis d’une ou de
plusieurs activités au sein d’une organisation spécifique.

b. Acteur : est un système actif intervenant dans le domaine d’étude capable de recevoir,
transformer et d’envoyer des informations.

c. Flux : Le « flux » est l’ensemble des informations véhiculées simultanément entre 2

stations, il est caractérisé par :
 La station de départ.
 La station d’arrivée.
 La nature des informations véhiculées.
 Le volume de l’information.

d. Une station : est un point d’utilisation, de contrôle ou de traitement de l’information.

e. Documents : Ce sont les supports des informations nécessaires à la gestion de

l’entreprise. Deux types de documents sont à distinguer :
 Les documents circulants : ils transportent le flux d’information entre les
stations.
 Les documents stationnaires : ils sont utilisés par une station et restent en
permanence dans celle-ci.

f. Une procédure : c’est est un séquencement de tâches ou d’opérations destinées à

réaliser un certain traitement. Elle peut engager plusieurs postes de travail au vu de la
réalisation d’un certain travail.
 BIBLIOGRAPHIE

[ALI, 10] Z.ALIMAZIGHI & L.MAHDAOUI. Cours Système d’Information (SI), Support
de cours, chapitre1 : Entreprises & Organisations. Cycle : LMD/ LicACAD/LicISIL FEI /
Département d’Informatique, USTHB 2010/2011.

[PAS, 06] PASCAL Roques. UML2 par la pratique 5e édition. Edition Eyrolles, 2006.

[SIG, 06] SIGAUD Olivier, Introduction à la modélisation orientée objets avec UML.2005-
2006.

[SOU, 12] SOUTOU Christian. UML2 pour les bases de données. Edition Eyrolles, 2012.
 WEBOGRAPHIE

[WEB1]: http://merise.developpez.com/faq/?page=Diagramme-des-flux.
Date de consultation : 12 Avril 2015.

[WEB2] : http://notepad-plus-plus.org/fr
Date de consultation : 10 Mai 2015.

[WEB3] : http://www.wampserver.com/
Date de consultation : 10 Mai 2015.

[WEB4] : http://openclassrooms.com/
Date de consultation : 10 Mai 2015.

[WEB5] : http://fr.wikipedia.org/wiki/PHP
Date de consultation : 10 Mai 2015.

[WEB6] : Sql.sh
Date de consultation : 15 Mai 2015.
Résumé
Le présent mémoire qui a pour intitulé « Gestion de l’organigramme des enseignements du
département informatique ». Ce projet a pour objectif d’informatiser, automatiser cette
gestion et de minimiser les problématiques du système.

Notre projet a débuté par une étude de l’existant qui est l’une des étapes les plus importantes
au développement des logiciels et des systèmes d’informations, par la suite nous avons suivi
une phase conceptuelle qui nous a permis d’interpréter et de décrire les nécessités du système
et ce en utilisant le langage UML.

Enfin afin de réaliser l’outil, différents langages ont été utilisés : HTML, CSS3, PHP,
Javascript, Ajax.