Outil pour la répartition des enseignements

Septembre - 2017

ECOLE SUPERIEURE D'INFORMATIQUE SALAMA
République Démocratique du Congo
Province de Haut-Katanga
Lubumbashi
www.esisalama.org

OUTIL POUR LA REPARTITION DES ENSEIGNEMENTS

Travail présenté et défendu en vue de l'obtention du grade d'ingénieur technicien en Génie Logiciel.

Par Jean-Luc KAHENGA NYEMBO Option Système Informatique

Septembre - 2017

ECOLE SUPERIEURE D'INFORMATIQUE SALAMA
République Démocratique du Congo
Province de Haut-Katanga
Lubumbashi
www.esisalama.org

OUTIL POUR LA REPARTITION DES ENSEIGNEMENTS

Travail présenté et défendu en vue de l'obtention du grade d'ingénieur technicien en Génie Logiciel.

Par Jean-Luc KAHENGA NYEMBO Option Système Informatique

Directeur Patrick KASONGA TSHIBANGU Co-Directeur Emmanuel NTUMBA

EPIGRAPHE

« Car la sagesse viendra dans ton coeur, et la connaissance fera les délices de ton âme »

Proverbes 2:11

II

IN MEMORIUM

A toi feu grand-père Thomas KISUKULU que la mort a impitoyablement précipité dans l'au-delà, laissant ainsi malgré toi, tes chers enfants au grès de vague dans une pirogue sans gouvernail. Souvent mes illusions et rêves, me rapportent ton visage et ta voix. Je nourris toujours l'espoir que nous nous verrons un jour tant qu'il est vrai que les morts ne sont pas morts.

Jean-Luc KAHENGA NYEMBO

III

DEDICACE

A vous cher papa Vincent de Paul NYEMBO KUSUBA, en me permettant de goûter aux splendeurs de la nature, tu m'as ouvert le chemin de la vie. C'est pour moi un précieux héritage que tu m'auras légué.

A vous chère mère Marie-Claire FATUMA KISIMBA, je réalise que votre affection maternelle exceptionnelle, et vos incessantes prières à notre Dieu ont été depuis toujours source intarissable de mon confort moral et spirituel ; nécessaire à mon épanouissement. Si donc j'ai quelque chose à mon humanité c'est à vous mes parents qu'appartient le droit de recueillir ce talent.

Jean-Luc KAHENGA NYEMBO

IV

Que tous ceux qui ne sont pas mentionnés ici nommément ne se sentent ni oubliés, ni frustrés, qu'ils trouvent ici notre sincère reconnaissance à leur égard.

REMERCIEMENTS

Ce travail est le couronnement de nos efforts déployés durant ces quatre années de notre formation, c'est sans doute l'occasion pour moi de rendre grâce à Dieu, le tout puissant, créateur du ciel et de la terre pour m'avoir accordé le privilège de réaliser ce travail.

Néanmoins, nous tenons à exprimer nos sincères gratitudes d'abord à Monsieur Patrick KASONGA TSHIBANGU qui malgré ses multiples préoccupations a accepté d'être sous notre direction.

Nous remercions également Monsieur Emmanuel NTUMBA notre codirecteur, qui a lu et corrigé ce travail de fin de cycle. Il nous a encadré sans cesse tout au long de l'année, cette confiance fondée en nous, nous a permis d'apprendre énormément, et de profiter de sa très grande expérience.

Nos remerciements vont également à notre chère tante Julienne Marie Chantal MBOMBO MALELE LILIANE pour vos sacrifices et temps de souffrance que vous avez faite et adressez à mon égard.

Qu'il nous soit permis de remercier notre papa Espérant MUZIMBA SINAWAZO, vous qui ne cessiez de nous redonner l'espoir, le courage et la force de toujours avancer. Nous avons finalement compris que la vie n'était pas un cadeau. On ne peut reculer, on se doit d'avancer.

Qu'il nous soit également permis de remercier particulièrement nos soeurs : Lisette TABU NYEMBO, Christelle KUNGWA NYEMBO et Charlène SAFI NYEMBO.

Nos attention se tourneront également à nos cousins et cousines : Vincent AMSINI, Frédéric MWEHU MBAYO, Yves NTAMBWE, Christian KISUKULU, Angelo KISUKULU, Marie SAGALI, Gracia MWAMINI, Cécile KUNGWA, Bénédicte ANGALI, Prodige MBOMBO, Marlène KISULULU, Vanissa KISUKULU, Shekinah LWAMBA, Joël LWAMBA, Audrey KITENGE. Sincères remerciements du plus profond de mon coeur. Nous pensons d'une manière particulière à notre belle-soeur Angel AMSINI.

Nous serions ingrats si nous passons sous silence sans remercier vivement nos camarades, amis et connaissances : Marie ILUNGA PERROS, Ken KAHAMBWE MBUYU, Jerry NKULU MULONGOY, Shadrack ILUNGA MWENZE, Magloire MWENZE, Gaylord KAYEMBE, Phineas LUKUSA, Judo MBAYO.

V

LISTE DES FIGURES

Figure 1.1 : Organigramme de l'ESIS 10

Figure 2.1 : Exemple de représentation d'un acteur .. 16

Figure 2.2 : Exemple de représentation d'un acteur sous la forme d'un classeur . 16

Figure 2.3 : Exemple de représentation d'un cas . 17

Figure 2.4 : Diagramme de cas d'utilisation . 18

Figure 2.5 : Diagramme de séquence du cas « S'authentifier » ... 20

Figure 2.6 : Diagramme de classes participantes du cas « S'authentifier » .. 20

Figure 2.7 : Diagramme de séquence du cas « Consulter cours » 21

Figure 2.8 : Diagramme de classes participantes du cas « Consulter cours » 21

Figure 2.9 : Diagramme de séquence du cas « Consulter enseignants » 22

Figure 2.10 : Diagramme de classes participantes du cas « Consulter enseignants » 22

Figure 2.11 : Diagramme de séquence du cas « Consulter candidats » . 23

Figure 2.12 : Diagramme de classes participantes du cas « Consulter candidats » 23

Figure 2.13 : Diagramme de séquence du cas « Consulter voeux » . 24

Figure 2.14 : Diagramme de classes participantes du cas « Consulter voeux » 24

Figure 2.15 : Diagramme de séquence du cas « Saisir voeu » 25

Figure 2.16 : Diagramme de classes participantes du cas « Saisir voeu » 25

Figure 2.17 : Diagramme de séquence du cas « Concevoir plan du cours » 26

Figure 2.18 : Diagramme de classes participantes du cas « Concevoir plan du cours » 26

Figure 2.19 : Diagramme de séquence du cas « Se déconnecter » 27

Figure 2.20 : Diagramme de classes participantes du cas « Se déconnecter » .. 27

Figure 2.21 : Diagramme de séquence du cas «Poser candidature » . 28

Figure 2.22 : Diagramme de classes participantes du cas « Poser candidature » . 28

Figure 2.23 : Diagramme de séquence du cas « Attribuer cours » 29

VI

Figure 2.24 : Diagramme de classes participantes du cas « Attribuer cours » . 30

Figure 2.25 : Diagramme de séquence du cas « Valider plan du cours » . 30

Figure 2.26 : Diagramme de classes participantes du cas « Valider plan du cours » 31

Figure 2.27 : Diagramme de séquence du cas « Modifier plan du cours » 31

Figure 2.27 : Diagramme de classes participantes du cas « Modifier plan du cours »... 32

Figure 2.28 : Diagramme de séquence du cas « Supprimer plan du cours » . 32
Figure 2.29 : Diagramme de classes participantes du cas « Supprimer plan du cours » 33

Figure 2.30 : Diagramme de séquence du cas « Créer compte » 34

Figure 2.31 : Diagramme de classes participantes du cas « Créer compte » . 34

Figure 2.32 : Modèle du domaine . 36

Figure 3.1 : Logo Netbeans 38

Figure 3.2 : Logo de MySQL 38

Figure 3.3 : Logo de Html/CSS . 39

Figure 3.4 : Logo de Bootstrap . 39

Figure 3.5 : Logo de JavaScript 39

Figure 3.6 : Logo de Pace Start . 39

Figure 3.7 : Architecture logicielle 40

Figure 3.8 : Diagramme de déploiement 42

Figure 3.9 : Cycle d'itération . 42

Figure 3.10 : Code correspondant à la création de la base de données . 43

Figure 3.11 : Code de création des tables de la base de données .. 47

Figure 3.12 : Interface d'authentification .. 48

Figure 3.13 : Extrait de code de la page d'authentification 48

Figure 3.14 : Interface d'accueil 49

Figure 3.15 : Interface d'attribution des cours .. 49

Figure 3.16 : Liste des enseignants 50

VII

Figure 3.17 : Liste des cours 51

Figure 3.18 : Extrait de code affichant les informations d'un cours 51

Figure 3.19 : Liste des candidats 52

Figure 3.20 : Extrait de code affichant la liste des candidats . 52

Figure 3.21 : Interface de conception du plan 53

Figure 3.22 : Extrait de code de l'interface Saisir voeu .. 53

VIII

LISTE DES TABLEAUX

Tableau 2.1 : Description textuelle du cas « S'authentifier » 20

Tableau 2.2 : Description textuelle du cas « Consulter cours » 21

Tableau 2.3 : Description textuelle du cas « Consulter enseignants » .. 22

Tableau 2.4 : Description textuelle du cas « Consulter candidats » .. 23

Tableau 2.5 : Description textuelle du cas « Consulter voeux » 24

Tableau 2.6 : Description textuelle du cas « Saisir voeux » .. 25

Tableau 2.7 : Description textuelle du cas « Concevoir plan du cours » .. 26

Tableau 2.8 : Description textuelle du cas « Se déconnecter » . 27

Tableau 2.9 : Description textuelle du cas « Poser candidature » . 27

Tableau 2.10 : Description textuelle du cas « Attribuer cours » 29

Tableau 2.11 : Description textuelle du cas « Valider plan du cours » . 30

Tableau 2.12 : Description textuelle du cas « Modifier plan du cours » 31

Tableau 2.13 : Description textuelle du cas « Supprimer plan cours » 32

Tableau 2.14 : Description textuelle du cas « Créer compte » .. 33

IX

LISTE DES ACRONYMES

UE : Unité d'Enseignement

UML : Unified Modeling Language

ESIS : Ecole Supérieure d'Informatique Salama

ITS : Institut Technique Salama

RDC : République Démocratique du Congo

JEE : Java Entreprise Edition

EDI : Environnement de Développement Intégré

API: Application Programming Interface

CSS: Cascading Style Sheet

HTML: Hypertext Markup Language

XML: Extensible Markup Language

AJAX: Asynchronous JavaScript XML

ORM: Object Relational Mapping

DSG : Design et Multimédia

SI : Système informatique

GST : Gestion

AS : Administration système

TLC : Télécommunication

IHM : Interface Homme Machine

IIPE : Institut International de Planification de l'Education

SQL: Structured Query Language

DAO: Data Access Object

SGA : Secrétaire Général Académique

X

TABLE DES MATIERES

EPIGRAPHE I

IN MEMORIUM II

DEDICACE III

REMERCIEMENTS IV

LISTE DES FIGURES V

LISTE DES TABLEAUX VIII

LISTE DES ACRONYMES IX

TABLE DES MATIERES X

AVANT-PROPOS XIII

CHAPITRE 0 : INTRODUCTION 1

0.1. Problématique .1

0.2. Hypothèses 1

0.3. Choix et intérêt du sujet .2

a. Intérêt social 2

b. Intérêt scientifique 2

c. Intérêt personnel 3

0.4. Méthodologie 3

a. Méthodes 3

b. Techniques 3

0.5. Etat de l'art 3

0.6. Délimitation du travail 4

0.7. Subdivision du travail 4

CHAPITRE 1 : ETUDE PREALABLE ET REPARTITION DES ENSEIGNEMENTS 5

1.1. Introduction 5

1.2. Répartition des enseignements 5

1.2.1. Définition 5

1.2.2. Avantages liés à la répartition des enseignements 6

1.2.3. Conséquences de manque de répartition 7

1.3. Présentation de l'Ecole Supérieure d'Informatique Salama 8

1.3.1. Historique 8

XI

1.3.2. Situation géographique 8

1.3.3. Mission 8

1.3.4. Vision 8

1.3.5. Formation 9

1.3.6. Organigramme 10

1.4. Technique et récolte d'information 11

1.5. La répartition des enseignements à l'ESIS 11

1.5.1. Critères d'attribution des cours 11

1.5.2. Contenu du cours 12

1.5.3. Les conflits dans la répartition des enseignements 12

1.5.4. Moyen de prévention contre les conflits 12

1.5.5. Documents de répartition 13

1.6. Commentaires, critiques et suggestions 14

1.7. Conclusion partielle 15

CHAPITRE 2 : MODELISATION DE L'OUTIL DE REPARTITION DES

ENSEIGNEMENTS 16

2.1. Introduction 16

2.2. Etude des besoins 16

2.2.1. Acteurs 16

2.2.2. Cas d'utilisation 17

2.2.3. Diagramme de cas d'utilisation 17

2.3. Etude détaillée des besoins des utilisateurs 19

2.3.1. Description textuelle 19

2.3.2. Diagramme de séquence 19

2.3.3. Diagramme de classes participantes 19

2.4. Modèle de domaine et modèle relationnel 34

2.4.1. Règle de transformation entre modèle de domaine et modèle relationnel 35

2.4.2. Modèle de domaine 35

2.4.3. Modèle relationnel 36

2.5. Conclusion partielle 37

CHAPITRE 3 : MISE EN PLACE D'UN OUTIL DE REPARTITION DES

ENSEIGNEMENTS 38

3.1. Introduction..................................................................................................................................38

XII

3.2. Langages et outils utilisés 38

3.3. Architecture logicielle et déploiement 40

3.3.1. Architecture logicielle 40

3.3.2. Déploiement du système 41

3.4. Rapport sur le développement 42

3.4.1. Méthodes agiles 42

3.4.3. Nombre d'itération 42

3.5. Mise en oeuvre sous MySQL 43

3.6. Capture d'écran 47

3.7. Conclusion partielle 53

CONCLUSION GENERALE 54

REFERENCES 55

XIII

AVANT-PROPOS

Le ministère de l'enseignement supérieur et universitaire en République Démocratique du Congo prévoit une défense sur un projet qui est récompensé par un diplôme de graduat d'ingénieur technicien. C'est dans cette optique que s'inscrit ce présent travail de fin de cycle intitulé : « OUTIL POUR LA REPARTITION DES ENSEIGNEMENTS ».

Ce travail est élaboré à l'Ecole Supérieure d'Informatique Salama, dans la filière Génie Logiciel, option Système Informatique.

L'enseignement, étant à la base de l'éducation de l'humanité, est une profession dont la mission est de contribuer à forger la société, à pérenniser la culture. L'éducation est un mécanisme qui permet aux jeunes générations d'assimiler tous les principes moraux, sociaux et affectifs permettant de s'intégrer correctement au groupe humain. Elle permet de développer les aptitudes physiques et intellectuelles qui autorisent ensuite le futur adulte à offrir à l'humanité l'ensemble de son potentiel.

Il est évident que la qualité d'un bon enseignement dépend cependant de plusieurs facteurs parmi lesquels nous allons nous atteler sur quelques un afin d'améliorer tant soi peu la gestion des enseignements.

D'où, dans le souci d'améliorer la qualité des enseignements, nous avons élaboré ce travail qui présente des pistes de solutions pour une bonne gestion des enseignements au sein d'une institution universitaire.

Enfin, il est important de noter que l'aboutissement de ce projet est le fruit de multiples efforts conjugués avec nos directeurs et co-directeurs, professeurs et collègues sans oublier l'appui des travaux élaborés par nos prédécesseurs. Ce travail n'est pas une invention, car déjà existant sous d'autre cieux, mais juste une analyse et une conception, qui est appliquer à une entité bien définit.

1

CHAPITRE 0 : INTRODUCTION

0.1. Problématique

La définition de la problématique s'avère indispensable pour tout travail scientifique, dans la mesure où l'aboutissement de ce dernier, dépend de la manière dont les questions sont articulées en vue d'y proposer les réponses. C'est à ce titre qu'elle est définie comme un ensemble des questions qu'une science ou une philosophie pose relativement à un domaine particulier.

Une bonne organisation peut influer sur le succès d'un enseignant, une planification bien réfléchie peut également l'aider à faire face avec confiance aux situations imprévues.

La qualité d'un enseignement dépend en partie de la personne qui le transmet, la facilité de s'adapter au niveau de son auditoire, la manière de ressortir ses idées et ses pensées afin de favoriser à l'ensemble de son auditoire les apprentissages prescrits dans le programme-cadre, etc. Au-delà de tout ça, s'ajoute aussi la manière de préparer son enseignement avant de le transmettre.

Cependant, la tache de planifier et attribuer les cours aux enseignants dans une institution universitaire a toujours été une opération assez complexe dans le sens où l'on doit gérer au-delà des critères d'attribution de cours, les conflits pouvant se créer afin de prévenir le cas où plus d'un enseignant se retrouvent titulaire d'un même cours et bien d'autre forme de problème susceptible d'apparaitre.

Dans le souci d'améliorer le processus de répartition des enseignements entre les enseignants, dans le souci de nous rapprocher de plus en plus de la perfection dans le secteur de l'enseignement, ainsi l'inquiétude qui plane dans notre travail s'illustre à travers ces principales questions ci-dessous :

? Pourquoi faut-il répartir les enseignements aux enseignants ?

? Comment assurer la mise en place d'un outil qui permettra aux institutions universitaires de bien répartir leurs enseignements ?

Ces interrogations nous renvoient directement à l'hypothèse du travail. 0.2. Hypothèses

Chaque problématique nécessite une hypothèse qui est entendue comme des suppositions des réponses aux questions posées. Partant des définitions données de l'hypothèse, nous tenterons de répondre provisoirement aux questions posées.

La répartition des enseignements entre les enseignants est un processus majeur pour une bonne tenue des opérations dans une institution universitaire. Il est évident que c'est une tâche très délicate qui nécessite beaucoup d'attention afin de gérer les conflits lors des attributions des cours aux enseignants.

2

Une institution universitaire possède la connaissance qui doit être transmise aux étudiants. Face à l'effectif considérable des étudiants dans les milieux universitaires, il est évident que c'est plus difficile pour un seul enseignant de s'occuper d'un ci-grand nombre d'étudiant car limité dans la connaissance, l'endurance physique, etc.

Face à ces difficultés, il serait raisonnable que cette tache soit subdivisée en fonction de plusieurs paramètres afin de permettre à l'enseignant de bien transmettre la connaissance et aux étudiants de bien assimiler la matière. Ainsi chaque cours sera attribué à un enseignant, et chaque enseignant pourra enseigner devant un nombre restreint d'étudiant pendant un temps bien limité, cela a pour conséquence d'optimiser la qualité de l'enseignement.

Pour une bonne mise en place d'un outil de répartition des enseignements, nous allons étudier le choix de différentes technologies qui doivent être utilisées en vue d'élaborer une solution facile à utiliser donnant un accès facile à ses utilisateurs.

0.3. Choix et intérêt du sujet

Le présent travail est élaboré dans le cadre de l'aboutissement de notre cycle de graduat, conformément au prescrit de l'enseignement supérieur et universitaire.

Le choix de notre sujet est porté sur deux raison :

V' Ce sujet cadre avec notre domaine de formation ;

V' En tant qu'analyste programmeur, il importe de savoir que nombre des institutions universitaires fait déjà cela mais rencontrent parfois des difficultés de le faire plus facilement par manque des outils adéquats pour la bonne gestion du dit processus.

Outre le choix évoqué plus haut, il s'avère que ce dernier a été orienté par un intérêt. A ce titre, retenons que ce travail ci-présent revêt un triple intérêt envisagé sur trois plans à avoir :

a. Intérêt social

En ce qui concerne l'intérêt social, nous dirons a notre manière que ce sujet apporte une solution pratique aux institutions universitaires ayant des problèmes dans la répartition des enseignements entre les enseignants et ce, en garantissant une gestion plus facile et sans conflit.

b. Intérêt scientifique

En ce qui concerne l'intérêt scientifique, nous avons espéré traiter ce sujet dans le but de proposer une contribution dans le secteur de l'enseignement qui est un domaine noble et prestigieux.

3

c. Intérêt personnel

Pour ce qui est de l'intérêt personnel, nous pensons pouvoir mettre en place toutes les notions apprises dans la conception des systèmes informatiques.

0.4. Méthodologie

a. Méthodes

En fonction de l'objectif de notre étude qui est celui d'améliorer la répartition des enseignements aux enseignants, nous avons choisi d'utiliser les méthodes suivantes pour ce qui est de notre sujet :

? Analytique : qui consiste en la décomposition de l'objet d'étude allant du plus complexe au plus simple.

b. Techniques

Les techniques sont des procédés opératoires mises à la disposition du chercheur par la science pour atteindre les objectifs que l'on s'est assigné lors de la recherche, ce sont des instruments, des outils pratiques des travaux permettant au chercheur d'accéder à une réalité au sein d'un groupe donné.

Dans le cadre de ce travail, nous avons appliqué le l'interview qui nous a permis d'avoir des échanges avec le Secrétaire Général Académique afin d'avoir les informations nécessaires relatives à notre travail. Au-delà de l'interview, soulignons aussi que nous avons fait recours à la technique documentaire (livre, site web, tutoriel) qui nous a permis de faire la lecture des ouvrages et autre document déjà écrit ayant un trait à notre sujet.

0.5. Etat de l'art

Dans le cadre de notre recherche, le sujet que nous allons traiter ne pas l'oeuvre d'une invention ni une création mais plutôt un ajout sur ce qui a déjà été développer par certains de nos prédécesseurs pour qui je dois beaucoup du respect et d'estime. Nous n'avons pas trouvé de sujet similaire à celui de notre travail au sein de notre institution mais nous allons donner une idée sur ce qui a déjà été fait ailleurs et qui cadre avec notre sujet.

Louis AJOUNTIMBA « Stratégies d'amélioration de la gestion des enseignants ». De l'Institut International de Planification de l'Education (IIPE)/UNESCO, en décembre 2005. L'auteur se base sur la gestion du personnel enseignant au sein d'une institution.

Joël HUMBERT & Laurent LOPEZ « La planification de l'enseignement au cycle élémentaire ». De l'Université de Genève Faculté de psychologie et des sciences de l'éducation, en Juillet 2007. Ils traitent des pratiques d'enseignants débutants dans le domaine de la planification de leur enseignement.

Mais pour notre cas nous voulons améliorer le processus de répartition des enseignements à ESIS.

4

0.6. Délimitation du travail

Devant une réalité complexe à appréhender et dans le souci de faire un bon travail, il est souvent recommandé de délimiter le sujet dans le temps et dans l'espace. Il est vrai que la réalité observée dans le cadre de ce travail n'est pas un fait nouveau, et elle ne se situe pas à un niveau restreint, elle est donc générale.

Dans le temps, notre travail s'étendra sur une étude sur la répartition des enseignements.

Dans l'espace, notre travail se limite à l'Ecole Supérieure d'Informatique Salama (ESIS) dans la province du Haut-Katanga ville de Lubumbashi.

0.7. Subdivision du travail

Outre l'introduction et la conclusion générale, la charpente de ce travail est subdivisée en trois chapitres.

Le premier chapitre est consacré à l'étude préalable et à la répartition des enseignements ; dans ce chapitre nous allons présenter le cadre d'étude et expliquer le processus de répartition de cours au sein de l'institution.

Le deuxième chapitre porte sur la modélisation de l'outil de répartition des enseignements ; dans ce chapitre nous allons faire l'analyse ainsi que la conception d'une solution informatique permettant aux enseignants de répartir leurs enseignements tout en gérant les chevauchements de leurs des enseignements.

Le troisième chapitre enfin, qui est l'épine dorsale de notre dissertation, mise en place d'un outil de répartition des enseignements ; dans ce chapitre nous allons présenter l'architecture logicielle de notre solution, nous allons expliquer son déploiement, et nous finirons par la présentation de la solution.

5

CHAPITRE 1 : ETUDE PREALABLE ET REPARTITION DES
ENSEIGNEMENTS

1.1. Introduction

L'enseignement en RDC est en chute libre depuis déjà plusieurs décennies, qu'il s'agisse de l'enseignement primaire, secondaire, supérieur ou universitaire. Les causes de cet état de chose sont multiples et avant de s'attaquer aux causes, il faut surtout songer à la relève des enseignants comme thérapeutique de choc, comme véritable défi à relever. Mais arriver à relever ce défi ne semble pas vraisemblable au vu des données sur le terrain. [1]

L'enseignement qui est l'éducation est une réalité au coeur de toute société. Elle constitue de nos jours une réelle préoccupation d'ici et d'ailleurs du fait des problèmes qu'elle regorge en tant que système. Ceci non sans répercussion sur la pratique professionnelle dans ce corps de métier.

C'est ainsi que le désengagement des enseignants qui en sont les principaux acteurs va sans cesse croitre. Si beaucoup de choses ont été déjà dites sur le sujet, nous nous intéressons à notre tour afin de déceler la cause de certains problèmes qui persistent dans l'enseignement en RDC.

Ainsi nous relevons un problème majeur et délicat retrouvé dans la plupart des institutions universitaires en République Démocratique du Congo et plus particulièrement à l'Ecole Supérieure d'Informatique Salama, celui de gérer au-delà des critères d'attribution de cours aux enseignants ; les conflits pouvant se créer afin de prévenir le cas où un enseignement prévu pour un cours, soit également donné dans un autre cours ; et le cas où un cours qui demande des prérequis soit programmé avant celui qui devrait passer en premier afin de poser les bases.

Dans ce chapitre, nous allons parler de la répartition des enseignements en général en relevant les avantages qui en découlent directement ainsi que les inconvénients qui peuvent arriver lorsque l'on ne repartitionne pas ses enseignements. Après la présentation de l'Ecole Supérieure d'Informatique Salama, nous parlerons du processus de répartition des enseignements à ESIS et nous finirons par émettre quelques critiques, commentaires et suggestions sur le processus de répartition des enseignements en donnant à l'Ecole Supérieure d'Informatique Salama.

1.2. Répartition des enseignements 1.2.1. Définition

La planification (répartition) est le processus par lequel l'enseignant s'assure de mettre en place les dispositifs pédagogiques nécessaires qui vont favoriser, pour l'ensemble de son auditoire ; les apprentissages prescrits dans le programme-cadre, tout en respectant les principes pédagogiques qui le sous-tendent. [2]

6

Planifier c'est organier selon des critères précis. Un enseignant qui prépare une matière à donner à un auditoire doit se rassurer de ne pas donner une matière prévue pour un autre cours, une matière déjà vue dans un autre cours, une matière prévue pour à niveau inférieur ou supérieur à son auditoire, etc.

Planifier revient à décrire la manière d'investiguer le champ notionnel en prenant en compte, d'une part, les processus d'apprentissage, la motivation des élèves et la métacognition et d'autre part, les recommandations institutionnelles en termes d'approches didactiques disciplinaires, et de démarches d'enseignement. [3]

Elle présente beaucoup d'avantage pour l'enseignant et pour les étudiants tout en leur apportant une meilleure compréhension des enseignements car un enseignant qui commence par planifier son enseignement avant de le transmettre à son auditoire va bénéficier de tous les avantages qui en découlent que nous allons voir au point suivant.

1.2.2. Avantages liés à la répartition des enseignements

Nous parlons de la répartition des enseignements entre les enseignants, et avant d'aller plus loin ; nous allons présenter les quelques avantages que va bénéficier un enseignant qui répartit de manière correcte ses enseignements avant de les transmettre à son auditoire.

Voici donc de manière générale les points positifs que présente une bonne répartition :

1. Le bénéfice du succès

L'enseignant qui organise de façon réfléchie ses enseignements bénéficie de l'influence sur le succès ; c'est-à-dire que l'enseignant qui planifie bien son enseignement pourra bien maitriser les contours de son enseignement, ce qui donnera à l'auditoire l'impression d'avoir devant lui un enseignant compétent et fort en la matière.

2. La confiance aux situations imprévues

L'enseignant qui planifie correctement son enseignement peut faire face avec confiance aux situations imprévues c'est-à-dire qu'il pourra répondre avec succès aux questions inattendues de son auditoire et le satisfaire.

3. L'assurance de donner un enseignement efficace

Une planification réussie et bien faite lui évitera de donner des apprentissages non prévus ou inappropriés pour le niveau de son auditoire, il lui sera plus facile de donner un enseignement adapté à son auditoire.

7

4. Le bénéfice de temps

Une planification réussie et bien faite lui mettra également à l'abri des conflits, c'est-à-dire qu'il donnera des notions qui ne sont pas prévues dans un autre cours.

Au-delà des avantages que nous venons de présenter par rapport à la répartition des enseignements entre les enseignants, il y'a aussi quelques inconvénients qui sont liés au manque de répartition des enseignements. C'est ainsi que nous nous apprêtons à énumérer au point suivant quelques inconvénients que voici.

1.2.3. Conséquences de manque de répartition

Nous avons pu relever les quelques avantages liés à une bonne répartition des enseignements bien avant leur transmission à un auditoire. Il est temps d'en relever aussi quelques inconvénients liés au manque de répartition des enseignements.

Nous devons savoir que ne pas planifier son enseignement avant de le transmettre présente beaucoup de points négatifs mais nous n'allons citer que quelques-uns que voici :

1. L'inconfort moral

Ne pas planifier son enseignement engendre chez l'enseignant l'anxiété, l'hésitation et l'incohérence.

2. La perte du temps

Ne pas planifier son enseignement fait perdre le temps par l'éparpillement, le tâtonnement, des redites. Cela s'explique par le fait que l'enseignant qui ne planifie pas son enseignement aura du mal à s'exprimer aisément car ne sachant pas quoi dire, il ne peut que procéder par tâtonnement.

3. L'inefficacité

Ne pas planifier son enseignement abouti à un mauvais rendement. Un enseignement mal repartit et mal transmis peut faire à ce que la leçon soit moins abordable et incompréhensible ce qui par conséquent conduit à un mauvais rendement.

Après avoir vu les avantages et les inconvénients liés à la répartition des enseignements, nous allons maintenant présenter au point suivant l'Ecole Supérieure d'Informatique Salama qui est notre cadre d'étude.

8

Elle a pour vision de faire des étudiants des incubateurs d'entreprise, de société et des services informatiques. Elle met à la disposition de la communauté

1.3. Présentation de l'Ecole Supérieure d'Informatique Salama 1.3.1. Historique

L'Ecole Supérieure d'Informatique Salama, ESIS en sigle, est une institution supérieure et universitaire catholique d'obédience salésienne, située dans l'enceinte de la communauté Salama sise avenue Femme Katangaise de la commune de Lubumbashi dans la ville portant le même nom, en République Démocratique du Congo.

Elle fut créée en 2001, sous l'initiative du père Joa, comme un prolongement dans l'enseignement supérieur de l'ITS (institut technique Salama) qui offre des formations de niveau secondaire dans les domaines de la mécanique, de l'électricité, de l'électronique, de la sérigraphie et de l'imprimerie.

Dans son cheminement, ESIS a connu plusieurs personnes à sa tête entre autre : le père Joa (Premier Directeur Générale), M. Serge MUKANYA (Secrétaire académique), M. BAKASANDA, M. Karl, M. MAMADOU, M. Albert HAMOUGO (secrétaire académique), Mr. Éric (appariteur) ; Père Germain ; M. Patrick MUKENDI ; Père Dieudonné MAKOLA ; Père Jean Marc KABONDO MUTANGALA.

Et actuellement Monsieur Jacquis PUNGU est à la tête comme Directeur Général, Monsieur Patrick KASONGA au Secrétariat Général Académique, Monsieur Polydore KATOLO aux finances et le Père Isaac KAMIBA au Secrétariat Général Administratif.

1.3.2. Situation géographique

L'Ecole Supérieure d'Informatique SALAMA est située dans l'enceinte de la communauté Salama sise sur l'avenue Femme Katangaise de la commune de Lubumbashi dans la ville portant le même nom, en République Démocratique du Congo. Elle est limitée au nord par le quartier Salama, au sud par SAFINA, à l'est par l'avenue Femme Katangaise à l'ouest par l'école KILELA BALENDA.

1.3.3. Mission

Former des ingénieurs en informatique avec des solides bases scientifiques et des réelles habiletés techniques et managériales, former l'homme intégral.

1.3.4. Vision

9

congolaise, et plus particulièrement celle de la ville de Lubumbashi et celle de son entourage une main d'oeuvre apte à répondre aux besoins en solutions informatiques d'entreprises ainsi que des citoyens près à se lancé dans la création d'emplois pour diminuer le taux de chômage.

1.3.5. Formation

Elle organise, mis à part, le tronc commun fait des années préparatoire et premier graduat (ou sciences de bases), trois filières dont le génie logiciel, le design et les réseaux

V' Le design et multimédia (DSG)

V' Le génie logiciel filière dite de la programmation a également deux

branches, à savoir :

V' Système informatique (SI)

V' Gestion (GST)

V' Les réseaux, subdivisés aussi en deux options à savoir : V' Télécommunication (TLC)

V' Administration système (AS)

10

1.3.6. Organigramme

Figure 1.1 : Organigramme de l'ESIS

11

1.4. Technique et récolte d'information

Les informations que nous allons présenter dans la suite de ce travail en rapport avec l'Ecole Supérieure d'Informatique Salama ont été récoltées lors d'un échange avec le Secrétaire Général Académique de l'Ecole Supérieure d'Informatique Salama M. Patrick KASONGA.

Nous lui avons posé différentes questions sur base desquelles nous avons pu récolter les informations nécessaires à notre travail nous permettant de comprendre le processus de répartition des cours et d'attribution des cours aux enseignants à l'Ecole Supérieure d'Informatique Salama et ainsi faire une analyse afin d'en relever le côté positif et le côté négatif du dit processus dans la partie réservée aux commentaires.

1.5. La répartition des enseignements à l'ESIS

Après avoir effectué un échange avec le Secrétaire Général Académique de l'Ecole Supérieure d'Informatique Salama dans le but de pouvoir récolter certaines informations nécessaires pour notre travail, nous allons présenter de manière succincte quelques points soulevés lors de l'entretien.

1.5.1. Critères d'attribution des cours

Pour bien comprendre et maitriser les contours du problème dont il est question dans notre travail, nous avions jugé bon de commencer par le commencement. C'est ainsi que nous avions voulu avoir une idée claire et nette sur les critères d'attribution des cours sur base desquels l'Ecole Supérieure d'Informatique Salama choisi ses enseignants.

Le Secrétaire Général Académique de l'Ecole Supérieure d'Informatique Salama nous a présenté 4 critères, sur base desquels il peut décider si un enseignant peut ou ne pas être retenu comme enseignant selon qu'il a répondu aux critères de base que nous citons ici-bas :

1. La compétence

La compétence fait référence au diplôme, à l'expérience professionnelle dans le domaine de l'enseignement, la formation reçue, etc. de l'enseignant candidat.

2. La moralité

Nombre d'institution universitaire de la place connaissent la pratique de corruption qui se présente sous différentes formes. L'Ecole Supérieure d'Informatique Salama veuille à ce que cette pratique reste en dehors de son système/cadre d'enseignement, elle s'assure que l'enseignant candidat ne soit pas actif dans ladite pratique pourvu qu'il ne soit pas un danger dans son système d'enseignement.

3. 12

L'esprit de recherche

L'esprit de recherche est un facteur très important dans la sélection des enseignants car il permet de s'assurer que l'enseignant pourrait souvent mettre à jour sa connaissance ainsi que son enseignement, ce qui est préférable pour un enseignement riche et efficace.

4. La méthodologie

La méthodologie est facteur aussi important que pertinent dans le choix d'un enseignant car elle permet de nous montrer l'attitude pédagogique que l'enseignant aura dans son auditoire. A partir d'elle, on saura déterminer si l'enseignant pourrait mieux transmettre la matière, écouter l'auditoire, maitriser et maintenir la bonne humeur dans laquelle les enseignements doivent se passer.

1.5.2. Contenu du cours

Le contenu du cours n'est pas imposé par l'Ecole Supérieure d'Informatique Salama mais cependant, l'enseignant sera informé bien avant des objectifs de l'école ainsi que des objectifs de la filière pour qu'il prenne conscience du profil d'ingénieur que l'école veut avoir afin de donner les enseignements appropriés aux étudiants devant lesquels il fera face.

1.5.3. Les conflits dans la répartition des enseignements

L'ESIS est une institution universitaire qui organise des cours pour former des étudiants, qui, au terme de leur cycle deviennent ingénieurs technicien. Parmi les cours qui sont organisés à l'Ecole Supérieure d'Informatique Salama, certains d'entre eux se ressemblent par leurs noms ou par leurs contenus, et portent confusion.

Voici de manière très courte, une brève explication sur la source du conflit qui se produit parfois entre les enseignements. Nous sommes devant deux cours de même catégorie et programmés dans la même promotion à des moments différents. L'enseignant du premier cours programmé, ne sachant pas ce que l'autre enseignant aurait prévu pour son cours, peut donner son enseignement avec le risque de toucher quelques points prévus dans le deuxième cours.

Pour soutenir cela, nous pouvons soulever le cas du cours de SQL et SQL Server vus en deuxième graduat au cours de l'année académique 2015-2016 où ce genre de conflit s'était produit.

1.5.4. Moyen de prévention contre les conflits

L'Ecole Supérieure d'Informatique Salama prévoit de faire les Unités d'Enseignement (UE). Les unités d'enseignement représentent les éléments d'un parcours de formation. Chaque unité d'enseignement correspond à une matière, matière qui peut être enseignée sous différentes formes : cours théoriques et

13

magistraux, de travaux dirigés, de travaux pratiques et/ou d'activités appliquées comme le stage, un projet, un mémoire ou un projet de fin d'études. [4]

Autrement dit, une unité d'enseignement est un ensemble de matières choisies pour leurs cohérences et peuvent être classées selon 3 types :

V' Les unités fondamentales

Elles regroupent les enseignements de base ou matières élémentaires.

V' Les unités de découverte

Elles permettent à l'étudiant de découvrir d'autres disciplines et de l'aider en cas de réorganisation.

V' Les unités transversales

Elles regroupent les enseignements de langues étrangères, d'informatique, etc. pour l'acquisition d'une culture générale et des techniques méthodologiques. [5]

C'est dans ce sens que l'Ecole Supérieure d'Informatique Salama cherche à faire les Unités d'Enseignement qui consisteraient à mettre ensemble les cours de même catégorie afin de répartir (séparer) les matières dans chaque unité pour gérer les conflits entre les enseignements.

NB : Signalons que cette technique n'est pas encore en application mais que cela sera fait dans les jours à venir.

1.5.5. Documents de répartition

Lorsqu'un enseignant sollicite un cours à l'Ecole Supérieure d'Informatique Salama, il lui sera demandé de présenter un document reprenant les informations assez détaillées en rapport avec le cours dont il souhaite avoir la responsabilité, bien sûr hormis les autres documents officiels nécessaires pour appuyer sa candidature.

Voici de manière détaillée les informations ainsi que les documents dont il est censé apporter pour sa candidature :

1. Une lettre de demande adressée au Secrétaire Général Académique ;

2. Un Curriculum Vitae (CV)

3. Un document reprenant les informations suivantes :

V' L'intitulé du cours

V' La description des matières à enseigner

14

y' Les objectifs (généraux et spécifiques) que ces matières

permettent d'atteindre

y' Le programme détaillé du cours

y' La bibliographie

y' La webographie (si possible)

y' Le plan du cours

y' La répartition des chapitres dans le temps
y' La méthodologie

y' La stratégie d'évaluation

y' Le nombre d'heures nécessaires

y' La disponibilité en termes de mois de l'année, jour de la
semaine et d'heures

Nous devons alors comprendre qu'il n'y a pas de document spécifique et préétabli qu'on donne aux enseignants en rapport avec la répartition de leurs enseignements.

1.6. Commentaires, critiques et suggestions

Comme nous l'avions dit plus haut, l'attribution de la charge de cours est une opération assez complexe dans le sens où avant de donner la responsabilité d'un cours à un enseignant au sein d'une institution universitaire, nous devons faire la part de chose en déterminant les notions qui « peuvent » être vues et celles qui font objet d'un autre cours.

Nous avons vu que lorsqu'un nouvel enseignant débute à l'Ecole Supérieure d'Informatique Salama, il est habituellement appelé à créer un projet de plan de cours détaillé et le faire approuver par le Secrétaire Général Académique. C'est après la validation de son projet de plan de cours que l'enseignant peut avoir la responsabilité du cours.

L'enseignant candidat doit prendre connaissance du plan du cours existant (au cas où il s'agit d'un ancien cours) et l'adapter en fonction de l'évolution tout en prenant en compte le profil d'étudiants pour qui, il crée ce projet de plan de cours. Pour ce qui est d'un nouveau cours, la démarche reste la même, l'enseignant désirant faire un enseignement nouveau pour l'institution devra également créer un projet de plan de cours bien détaillé qui devra être approuvé par le Secrétaire Général Académique avant d'être attribué. Cela est certainement une bonne façon de faire parce que dans tous les cas, cela anticipe la gestion des conflits pouvant se produire au cas où le cours, nouveau comme ancien aurait des cohérences avec un ou d'autre cours.

Nous signalons que hormis cela il y'a deux autres documents qu'il devra déposer notamment une lettre de demande adressée au Secrétaire Général Académique et un curriculum vitae. Pour une institution informatique à l'instar de l'Ecole Supérieure d'Informatique Salama, il serait préférable que les enseignants apprennent à utiliser les nouvelles technologies de l'information et de la communication: Ordinateurs, internet, vidéoprojecteurs, téléviseur, fax, etc.

15

La création d'une unité d'enseignement règlerait beaucoup de problème en rapport avec les conflits entre les enseignements mais cela ne constituera pas l'ultime solution pour gérer ces problèmes. Voilà pourquoi il serait préférable pour l'Ecole Supérieure d'Informatique Salama de posséder un outil pouvant contenir l'ensemble de plans des cours de l'institution dans le but de faciliter la consultation et l'élaboration des plans de cours. Ainsi chaque enseignant pourra consulter le plan d'un cours dont il trouve le contenu cohérent à celui de son cours afin de gérer déjà à son niveau les éventuels conflits et éviter d'aller au-delà de ses limites c'est-à-dire rester dans son cadre d'enseignement.

La tenue des documents pédagogiques concerne tous les enseignants parce qu'ils tirent une importance majeure pour les enseignants garants du savoir et pour les enseignés aspirants du savoir, mais aussi pour les recherches scientifiques.

1.7. Conclusion partielle

Dans ce chapitre il a été question de voir les différents avantages découlant directement d'une bonne répartition des enseignements ainsi que les inconvénients qui peuvent arriver lorsqu'un enseignant ne tient pas compte de cet aspect de chose.

Nous avons aussi vu le processus de répartition des cours à l'Ecole Supérieure d'Informatique Salama et l'avons critiqué en émettant quelques suggestions de manière à améliorer tant soit peu le processus de répartition des enseignements entre les enseignants de l'ESIS.

Ainsi, nous retiendrons que la planification d'un enseignement présente plusieurs avantages pour l'enseignant et pour l'auditoire. C'est une tâche que les enseignants devront apprendre à réaliser bien avant de transmettre leur savoir devant un auditoire.

Dans le chapitre qui suit nous allons essayer de résoudre les problèmes liés à la répartition des enseignements en montrant de manière progressive les étapes de conception en commençant par l'analyse jusqu'au déploiement de l'application.

16

CHAPITRE 2 : MODELISATION DE L'OUTIL DE REPARTITION DES
ENSEIGNEMENTS

2.1. Introduction

Dans le chapitre précédent nous avons pu relever le problème dont il sera question dans notre travail. Nous avons soulevé le problème de chevauchement qui s'explique par le fait qu'un cours peut contenir une ou plusieurs notions prévue(s) dans un autre cours.

Dans ce chapitre, nous allons faire l'étude des besoins des utilisateurs afin appréhender le système et nous permettre de bien le modéliser. Puisque la modélisation est un processus de traduction du monde réel sous une forme compréhensible par l'ordinateur, nous nous proposons de recourir à un langage de modélisation objet. Pour ce faire, nous avons opté pour le langage UML (Unified Modeling Language) que nous allons présenter au point suivant.

2.2. Etude des besoins

UML est dit langage de modélisation objet. L'approche objet nécessite une analyse approfondie sur les objets et leurs interactions. Nous allons voir aux points qui suivent les éléments nécessaires qui interviennent dans la modélisation d'un système par le langage UML.

2.2.1. Acteurs

Un acteur est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système. [6] Il se représente par un petit bonhomme avec son nom (son rôle) inscrit dessous comme le montre la figure suivante :

Figure 2.1 : Exemple de représentation d'un acteur

Il est également possible de représenter un acteur sous la forme d'un classeur stéréotypé comme le montre la figure suivante :

Figure 2.2 : Exemple de représentation d'un acteur sous la forme d'un classeur

17

Dans notre travail, nous n'avons que deux acteurs :

a. L'administrateur

C'est le responsable qui gère le système entier sans aucune limite. Il s'occupe des mises à jour des informations, il veuille sur le bon fonctionnement, il crée les nouveaux comptes utilisateurs, etc. il s'agit dans ce cas de l'académique de l'Ecole Supérieure d'Informatique Salama.

b. L'enseignant

Est l'utilisateur simple du système, il s'agit ici des autres enseignants de l'Ecole Supérieure d'Informatique Salama.

2.2.2. Cas d'utilisation

Les cas d'utilisation décrivent le comportement du système du point de vue de l'utilisateur. Ils permettent de définir les limites du système et les relations entre le système et son environnement. Pour donner une autre définition du cas d'utilisation, on peut dire que c'est une collection de scénarios de succès ou d'échec qui décrit la façon dont un acteur particulier utilise un système pour atteindre un objectif.

Il se représente par une ellipse contenant le nom du cas (un verbe à l'infinitif), et optionnellement, au-dessus du nom, un stéréotype.

En voici un exemple :

Figure 2.3 : Exemple de représentation d'un cas d'utilisation 2.2.3. Diagramme de cas d'utilisation

Le diagramme de cas d'utilisation permet d'analyser, d'organiser les besoins des utilisateurs et de recenser les grandes fonctionnalités du système. Il modélise les services rendus par le système aux utilisateurs.

Nous avons dans notre système des acteurs qui doivent interagir avec ce dernier et la règle en UML dit qu'un cas d'utilisation doit modéliser une grande fonctionnalité du système qui produit un résultat palpable. De ce fait, nous allons présenter les cas d'utilisation par rapport à chaque acteur du système et expliquer en quoi cela consiste. Rappelons que ces cas d'utilisation représentent les besoins même de l'utilisateur.

a. Pour l'administrateur, il aura besoin de :

? De s'authentifier afin d'avoir accès à l'application

? D'attribuer un cours à un enseignant

18

V' De créer un compte utilisateur/administrateur

V' De valider, modifier ou supprimer un plan du cours V' De consulter sa boite aux lettres

V' De se déconnecter

b. Pour l'enseignant, il aura besoin :

V' De s'authentifier pour accéder à l'application

V' De consulter les cours, les enseignants, les enseignants

candidats, les enseignements, les voeux de ces collègues

V' D'exprimer ses attentes par rapport à un cours

V' De concevoir un plan du cours

V' De demander un cours

V' De consulter sa boite aux lettres

V' De se déconnecter

Voilà comment nous représentons tous les cas ainsi que les acteurs sur notre diagramme de cas d'utilisation :

Figure 2.4 : Diagramme de cas d'utilisation

19

2.3. Etude détaillée des besoins des utilisateurs

Après avoir représenté les cas d'utilisation (pour les grandes fonctionnalités) de chaque acteur, nous allons maintenant détailler ici chaque cas d'utilisation afin de mieux comprendre leurs déroulements.

2.3.1. Description textuelle

Le langage UML est à la fois un langage graphique et textuelle, il est donc important de commenter et de décrire chaque cas d'utilisation. Nous allons présenter dans des tableaux les descriptions textuelles de nos cas d'utilisation. Ils seront accompagnés d'un diagramme de séquence pour expliciter chaque scénario.

2.3.2. Diagramme de séquence

Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation UML. Ce type de diagramme sert à modéliser les aspects dynamiques des diagrammes des systèmes temps réels et des scénarios complexes.

2.3.3. Diagramme de classes participantes

Le diagramme de classes participantes modélise l'ensemble de classes d'analyse qui concourent à la réalisation d'un cas d'utilisation. [7] Il décrit chaque cas d'utilisation, les 3 principales classes d'analyse et leurs relations.

a. Les classes dialogues

Possèdent des attributs et des méthodes. Les attributs représentent des champs de saisie ou des résultats. Les opérations elles, représentent des actions de l'utilisation sur l'Interface Homme Machine (IHM).

b. Les classes contrôles

Contiennent les opérations qui représentent la logique applicative de l'application, les règles métiers ou les comportements du système informatique.

c. Les classes entités

Possèdent en général des informations persistantes de l'application. Elles sont persistantes en ce sens qu'elles survivent à l'exception des cas d'utilisation. Elles proviennent du modèle de domaine et permettent le stockage de données dans des fichiers ou base de données.

Voici la description textuelle de chaque cas d'utilisation de notre

système :

20

1. S'authentifier

Tableau 2.1 : Description textuelle du cas « S'authentifier»

Nom du cas Objectif	S'authentifier Avoir accès aux informations
Acteur principal	Enseignant, Administrateur
Acteur secondaire	-
Précondition	Compte actif
Scénarios	Nominal Saisir informations de connexion Clic sur bouton « Connexion »
	Alternatif Modifier mot de passe
	Exception Message d'erreur en cas de champ vide Reprise d'authentification si login erroné
Post-condition	Accès au menu principal

Figure 2.5 : Diagramme de séquence du cas « S'authentifier »

Figure 2.6 : Diagramme de classes participantes du cas « S'authentifier »

21

Figure 2.8 : Diagramme de classes participantes du cas « Consulter cours »

2. Consulter cours

Tableau 2.2 : Description textuelle du cas « Consulter cours »

Nom du cas Objectif	Consulter cours Afficher la liste de tous les cours
Acteur principal	Enseignant
Acteur secondaire	-
Précondition	S'authentifier
Scénarios	Nominal Cliquer sur le menu « Consulter » Cliquer sur le sous-menu « Cours »
	Alternatif -
	Exception -
Post-condition	Liste des cours affichée

Figure 2.7 : Diagramme de séquence du cas « Consulter cours »

22

3. Consulter enseignants

Tableau 2.3 : Description textuelle du cas « Consulter enseignants »

Nom du cas Objectif	Consulter enseignants Afficher la liste de tous les enseignants
Acteur principal	Enseignant
Acteur secondaire	-
Précondition	S'authentifier
Scénarios	Nominal	Cliquer sur le menu « Consulter » Cliquer sur le sous-menu « Enseignants »
	Alternatif	-
	Exception	-
Post-condition	Liste des enseignants affichée

Figure 2.9 : Diagramme de séquence du cas « Consulter enseignants »

Figure 2.10 : Diagramme de classes participantes du cas « Consulter enseignants »

23

4. Consulter candidats

Tableau 2.4 : Description textuelle du cas « Consulter candidats »

Nom du cas Objectif	Consulter candidats Afficher la liste des enseignants souhaitant faire un enseignement
Acteur principal	Enseignant
Acteur secondaire	-
Précondition	S'authentifier
Scénarios	Nominal	Clic sur menu « Consulter » Clic sur sous-menu « Candidats »
	Alternatif	-
	Exception	-
Post-condition	Liste des candidats affichée

Figure 2.11 : Diagramme de séquence du cas « Consulter candidats »

Figure 2.12 : Diagramme de classes participantes du cas « Consulter

candidats »

24

5. Consulter voeux

Tableau 2.5 : Description textuelle du cas « Consulter voeux »

Nom du cas Objectif	Consulter voeux Afficher les voeux des cours
Acteur principal	Enseignant
Acteur secondaire	-
Précondition	-
Scénarios	Nominal	Clic sur menu « Consulter » Clic sur sous-menu « Voeux » Choisir cours Clic sur bouton « Lire voeux »
	Alternatif	Changer cours
	Exception	-
Post-condition	Voeux affichés

Figure 2.13 : Diagramme de séquence du cas « Consulter voeux »

Figure 2.14 : Diagramme de classes participantes du cas « Consulter voeux »

25

6. Saisir voeux

Tableau 2.6 : Description textuelle du cas « Saisir voeux »

Nom du cas Objectif	Saisir voeux Exprimer ses attentes par rapport à un cours
Acteur principal	Enseignant
Acteur secondaire	Enseignant
Précondition	S'authentifier
Scénarios	Nominal	Clic sur menu « Faire un voeu » Choisir cours Saisir ses voeux Clic sur bouton « Soumettre »
	Alternatif	Modifier cours, annuler
	Exception	Message d'erreur si un champ obligatoire est vide
Post-condition	Voeu publié

Figure 2.15 : Diagramme de séquence du cas « Saisir voeu »

Figure 2.16 : Diagramme de classes participantes du cas « Saisir voeu »

26

7. Concevoir plan du cours

Tableau 2.7 : Description textuelle du cas « Concevoir plan du cours »

Nom du cas Objectif	Concevoir plan du cours Elaborer un plan du cours
Acteur principal	Enseignant
Acteur secondaire	Administrateur
Précondition	Avoir la responsabilité du cours
Scénarios	Nominal Ouvrir fenêtre Saisir plan du cours Valider
	Alternatif Annuler
	Exception Message d'erreur si un champ obligatoire est vide
Post-condition	Plan du cours élaboré

Figure 2.17 : Diagramme de séquence du cas « Concevoir plan du cours »

Figure 2.18 : Diagramme de classes participantes du cas « Concevoir plan du

cours »

27

8. Se déconnecter

Tableau 2.8 : Description textuelle du cas « Se déconnecter »

Nom du cas Objectif	Se déconnecter Quitter l'application
Acteur principal	Enseignant, Administrateur
Acteur secondaire	-
Précondition	S'authentifier
Scénarios	Nominal Cliquer sur menu « Déconnexion »
	Alternatif -
	Exception -
Post-condition	Utilisateur déconnecté

Figure 2.19 : Diagramme de séquence du cas « Se déconnecter »

Figure 2.20 : Diagramme de classes participantes du cas « Se déconnecter »

9. Poser candidature

Tableau 2.9 : Description textuelle du cas « Poser candidature »

Nom du cas Poser candidature

Objectif Demander la responsabilité d'un cours

Acteur Enseignant

principal

Acteur Administrateur
secondaire

28

Précondition Compte actif

Scénarios Nominal Cliquer sur menu « Candidature »

Choisir cours

Saisir suggestion

Clic sur bouton « Valider »

Alternatif Annuler

Exception -

Post-condition Demande envoyée

Figure 2.21 : Diagramme de séquence du cas «Poser candidature »

Figure 2.22 : Diagramme de classes participantes du cas « Poser candidature »

29

10. Attribuer cours

Tableau 2.10 : Description textuelle du cas « Attribuer cours »

Nom du cas Objectif	Attribuer cours Donner à un enseignant la responsabilité d'un cours
Acteur principal	Administrateur
Acteur secondaire	Enseignant
Précondition	S'authentifier
Scénarios	Nominal	Cliquer sur menu « Attribution » Choisir cours Choisir enseignant Clic sur bouton « Attribuer »
	Alternatif	Changer cours Changer enseignant
	Exception	Message d'erreur si l'enseignant n'est pas choisi
Post-condition	Cours attribué

Figure 2.23 : Diagramme de séquence du cas « Attribuer cours »

30

Figure 2.24 : Diagramme de classes participantes du cas « Attribuer cours »

11. Valider plan du cours

Tableau 2.11 : Description textuelle du cas « Valider plan du cours »

Nom du cas Objectif	Valider plan du cours Accepter le plan du cours qui respecte la norme requise
Acteur principal	Administrateur
Acteur secondaire	-
Précondition	-
Scénarios	Nominal	Ouvrir liste plan des cours Choisir plan du cours Valider
	Alternatif	Changer plan du cours
	Exception	-
Post-condition	Plan du cours validé

Figure 2.25 : Diagramme de séquence du cas « Valider plan du cours »

31

Figure 2.26 : Diagramme de classes participantes du cas « Valider plan du

cours »

12. Modifier plan du cours

Tableau 2.12 : Description textuelle du cas d'utilisation « Modifier plan du cours »

Nom du cas Objectif	Modifier plan du cours Corriger un plan du cours afin de l'améliorer
Acteur principal	Administrateur
Acteur secondaire	-
Précondition	-
Scénarios	Nominal	Afficher liste plan des cours Choisir plan du cours Saisir les informations correctes Confirmer modification
	Alternatif	Supprimer plan du cours
	Exception	Message d'erreur si un champ obligatoire est vide
Post-condition	Plan du cours modifié

Figure 2.27 : Diagramme de séquence du cas « Modifier plan du cours »

32

Figure 2.27 : Diagramme de classes participantes du cas « Modifier plan du

cours »

13. Supprimer plan du cours

Tableau 2.13 : Description textuelle du cas « Supprimer plan cours »

Nom du cas Objectif	Supprimer plan du cours Effacer un plan du cours
Acteur principal	Administrateur
Acteur secondaire	-
Précondition	-
Scénarios	Nominal Afficher liste plan des cours Choisir plan du cours Supprimer plan du cours Confirmer suppression
	Alternatif Annuler
	Exception -
Post-condition	Plan du cours supprimé

Figure 2.28 : Diagramme de séquence du cas « Supprimer plan du cours »

33

Figure 2.29 : Diagramme de classes participantes du cas « Supprimer plan du

cours »

14. Créer compte

Tableau 2.14 : Description textuelle du cas « Créer compte »

Nom du cas Objectif	Créer compte Ouvrir un compte pour un enseignant
Acteur principal	Administrateur
Acteur secondaire	-
Précondition	-
Scénarios	Nominal	Ouvrir formulaire d'enregistrement Remplir formulaire Valider
	Alternatif	Annuler
	Exception	Message d'erreur si un champ obligatoire est vide
Post-condition	Compte créé

34

Figure 2.30 : Diagramme de séquence du cas « Créer compte »

Figure 2.31 : Diagramme de classes participantes du cas « Créer compte » 2.4. Modèle de domaine et modèle relationnel

Le modèle relationnel est une manière de modéliser les relations existantes entre plusieurs informations, et de les ordonner entre elles. A partir de la description conceptuelle que nous avons effectuée, on peut réaliser le modèle relationnel.

35

2.4.1. Règle de transformation entre modèle de domaine et modèle relationnel

Nous décrivons dans cette phase les transformations à effectuer afin de dériver un schéma logique relationnel ou objet. Les règles de passage du modèle de domaine au modèle relationnel sont :

a. Transformation des classes :

y' Chaque classe du diagramme UML devient une relation, il faut choisir un attribut de la classe pouvant jouer le rôle de clé y' Chaque entité devient une relation

y' L'identifiant de l'entité devient clé primaire pour la relation. y' Si aucun attribut ne convient en tant qu'identifiant, il faut en

ajouter un de manière à ce que la relation dispose d'une clé

primaire (les outils proposent l'ajout de tels attributs)

b. Transformation des associations

Nous distinguons trois familles d'associations :

y' Association 1.. : il faut ajouter un attribut de type clé étrangère dans la relation fils de l'association. L'attribut porte le nom de la clé primaire de la relation père de l'association.

y' Association 'K..'K, n-aires et classes-association : la classe-association devient une relation. La clé primaire de cette relation est la concaténation des identifiants des classes connectées à l'association.

y' Association 1..1 : il faut ajouter un attribut de type clé étrangère dans la relation dérivée de la classe ayant la multiplicité minimale égale à un. L'attribut porte le nom de la clé primaire de la relation dérivée de la classe connectée à l'association. Si les deux multiplicités minimales sont à un, il est préférable de fusionner les deux classes en une seule.

2.4.2. Modèle de domaine

Le modèle du domaine issu de notre analyse comprend 10 classes que nous présentons ici ainsi que les attributs (tous privés) de chaque classe :

- Archive : id, idCours, matricule, idPromotion, idFiliere, anneeAcad ; - Attribution : id, idCours, matricule, anneeAcad, statut;

- Candidat : id, idCours, matricule, date, motivation, statut, intitule, enseignant;

- Categorie : id, categorie ;

- Cours : id, intitule, plan, objectifGen, objectifSpec, idPromotion, idFiliere, idCategorie, nbrHeure, prerequis, fichier, statut, image, promotion, filiere;

- ARCHIVE (id, #id_cours, #matricule, #id_promotion,#id_filiere, annee_acad ) ; - ATTRIBUTION (id, #id_cours, #matricule, annee_acad, statut);

36

- Enseignant : matricule, nom, prenom, diplôme, option, experience,

dateNaiss, nomUtilisateur, motDePasse, idType, nomType, email,

genre, tel, image;

- Filiere : id, nom ;

- Notification : id, expediteur, destinataire, objet, message, date, statut,

prenomExp, nomExp, prenomDst, nomDst ;

- Plan : id, description, idCours, statut, cours ;

- Promotion : id, nom ;

- Type : id, categorie, valeur ;

- Voeu : id, commentaire, date, idCours, matricule, intitule, prenom, nom.

Figure 2.32 : Modèle du domaine 2.4.3. Modèle relationnel

En appliquant ces règles de transformation d'un diagramme de classe vers un modèle relationnel, nous avons abouti au schéma relationnel suivant :

37

- CANDIDAT (id, #id_cours, #matricule, date, motivation, statut, intitule,

enseignant);

- CATEGORIE (id, categorie) ;

- COURS (id, intitule, plan, objectif_gen, objectif_spec, #id_promotion,

#id_filiere, #id_categorie, nbr_heure, prerequis, fichier, statut, image, promotion,

filiere);

- ENSEIGNANT (matricule, nom, prenom, diplôme, option, experience,

date_naiss, nom_utilisateur, mot_de_passe, #id_type, nom_type, email, genre, tel,

image);

- FILIERE (id, nom) ;

- NOTIFICATION (id, expediteur, destinataire, objet, message, date, statut,

prenom_exp, nom_exp, prenom_dst, nom_dst) ;

- PLAN (id, description, #id_cours, statut) ;

- PROMOTION (id, nom ;

- TYPE (id, categorie, valeur) ;

- VOEU (id, commentaire, date, #id_cours, matricule, intitule, prenom, nom).

2.5. Conclusion partielle

Dans ce chapitre nous avons conçu un système d'information pour la répartition des enseignements en se basant sur les diagrammes du langage UML à savoir le diagramme de cas d'utilisation, le diagramme de séquence et le diagramme de classes participantes. Ceci en utilisant l'outil de modélisation «Pace star UML Diagrammer », ce qui nous a permis de concevoir notre dispositif.

Le chapitre suivant est consacré aux détails de l'implémentation de notre

solution.

38

CHAPITRE 3 : MISE EN PLACE D'UN OUTIL DE REPARTITION DES
ENSEIGNEMENTS

3.1. Introduction

Dans ce chapitre nous allons expliquer toutes les étapes de conception ainsi que celles fonctionnelles pour la mise en place de l'application. Nous allons également monter comment seront connectés les différents éléments (module ou composant) de notre application en faisant de petit commentaire pour chaque lien. Nous allons enfin montrer comment utiliser l'application en montrant juste quelques fonctionnalités de base. Et, parce que nous concevons une solution pour l'Ecole Supérieure d'Informatique Salama (ESIS), commençons par la présenter.

3.2. Langages et outils utilisés

Afin de réaliser ce travail, nous avons opté de travailler avec quelques technologies ainsi que logiciel notamment :

1. Netbeans

Est un environnement de développement intégré (EDI), il constitue par ailleurs une plateforme qui permet le développement d'applications spécifiques (bibliothèque Swing(Java)) sur laquelle l'EDI s'appuie. Il offre plusieurs outils de construction d'applications notamment : applications sur serveurs, application sur poste de travail, application java sur mobile (embarquées) ainsi que les web services.

Pour ce qui est de notre travail nous allons concevoir une application sur serveurs (application web et Java EE).

Figure 3.1 : Logo Netbeans

2. MySQL

Le logiciel MySQL est un serveur base de données SQL, très rapide, multithread, multi utilisateurs et robuste. Le serveur MySQL est destiné aux missions stratégiques ainsi qu'à l'intégration dans des logiciels déployés à grande échelle.

Figure 3.2 : Logo de MySQL

3. 39

Html/CSS

Le HTML est le format de données conçu pour représenter les pages Web. C'est un langage de balisage permettant d'écrire de l'hypertexte. Il permet également de structurer sémantiquement, logiquement et mettre en forme le contenu des pages. Le CSS quant à lui est un langage informatique qui décrit la présentation des documents HTML et XML.

Figure 3.3 : Logo de Html/CSS

4. Bootstrap

Est un Framework qui contient du CSS qui interagit avec une application JavaScript, qui utilise jQuery et ça permet de créer des sites internet pour les mobiles ainsi que les ordinateurs de bureau.

Figure 3.4 : Logo de Bootstrap

5. Javascript (JS)

Est un langage de programmation principalement utilisé pour créer des pages Web interactives. Incorporé dans un document HTML, il n'est pas visible dans la fenêtre du navigateur et permet d'exécuter des commandes du cote client c'est-à-dire au niveau du navigateur et non du serveur Web.

Figure 3.5 : Logo de JavaScript

6. Pace Start UML Diagrammer

Outil de création de diagrammes. Il nous a permis de créer facilement des diagrammes UML de qualité professionnelle.

Figure 3.6 : Logo de Pace Start

40

3.3. Architecture logicielle et déploiement 3.3.1. Architecture logicielle

Une architecture logicielle définit la structuration d'un système

informatique en termes de composants et d'organisation de ses fonctions. [8]

Pour notre solution, nous avons choisi l'architecture en 3 couches distinctes : la couche présentation, la couche métier ainsi que la couche d'accès aux données (DAO).

1. Présentation

Chargé de tout ce qui est affiché et visible par l'utilisateur.

2. Métier

Logique métier de l'application ; elle est le coeur et c'est elle qui définit toutes les règles régissant le fonctionnement de l'application.

3. Accès aux données

Intermédiaire entre les autres couches et la base de données.

Voici la figure correspondant à notre architecture logicielle détaillée :

Figure 3.7 : Architecture logicielle

3.3.1. Client

C'est une application qui interprète les pages HTML ou XML, il exécute les applets ou du code JavaScript et possède différents niveaux de sécurité configurable. Il interagit avec un serveur d'application via le protocole http.

3.3.2. Serveur web

C'est un programme qui utilise le protocole http pour fournir les fichiers qui constituent les pages Web que les utilisateurs ont demandées via des requêtes transmis par les clients http de leurs ordinateurs. Des ordinateurs et des Appliance dédiés peuvent également jouer le rôle de serveurs Web. [9]

3.3.3. Serveur d'application

41

C'est une solution serveur installée sur un ordinateur, placée sur un réseau distribué qui orchestre la logique métier d'une application. Il est fréquemment considéré comme une application trois-tiers ; comportant un serveur d'interface utilisateur graphique, une application serveur, une base de données et un serveur transactionnel. [10]

3.3.4. Base de données

C'est une collection de données organisées de façon à être facilement accessibles, administrées et mises à jour. Les bases de données peuvent être classées par type de contenu qu'elles renferment : bibliographie, textes, images, nombre. [11]

3.3.2. Déploiement du système

Dans cette partie, nous allons décrire l'implémentation physique de notre application grâce à un diagramme proposé par UML : le diagramme de déploiement.

Le diagramme de déploiement permet de représenter l'architecture physique supportant l'exploitation du système. Cette architecture comprend des noeuds correspondant aux supports physiques ainsi que la répartition des artefacts logiciels sur ces noeuds. C'est un véritable réseau constitué de noeuds et de connexions entre ces noeuds qui modélise cette architecture. [12]

Il est constitué de différents éléments, en voici une brève présentation :

1. Noeud

Un noeud correspond à une ressource matérielle de traitement sur laquelle des artefacts seront mis en oeuvre pour l'exploitation du système. Les noeuds peuvent être interconnectés pour former un réseau d'éléments physiques.

2. Artefact

Un artefact est la spécification d'un élément physique qui est utilisé ou produit par le processus de développement du logiciel ou par le déploiement du système. C'est donc un élément concret comme par exemple : un fichier, un exécutable ou une table d'une base de données.

Voici la figure correspondant à notre diagramme de déploiement :

42

Figure 3.8 : Diagramme de déploiement

3.4. Rapport sur le développement 3.4.1. Méthodes agiles

1. Développement incrémental

Dans le développement incrémental, l'on part de l'idée initiale complétement formée que l'on construit morceau par morceau jusqu'à la livraison finale et complète. [13]

2. Développement itératif

Dans le développement itératif, l'on part de l'idée grossière qu'on affine par retouches successives, chacune améliorant la qualité. [13]

3.4.3. Nombre d'itération

Après cours le développement de notre solution, nous avons eu 3 itérations que nous présentons :

Figure 3.9 : Cycle d'itération

43

a. Itération 1 : Mise en place de l'architecture logicielle

La mise en place de notre architecture logicielle nous a pris au maximum trois semaines. Il nous fallait choisir une architecture logicielle de manière à rendre le déploiement de notre solution le plus facile possible. Pour cela, nous avons étudié notre système et avons passé en revue quelques architectures logicielles afin d'en choisir la mieux adaptée.

b. Itération 2 : Développement des fonctionnalités de base de notre système

Cette étape nous a pris environ six semaines, c'est la base même du système. La difficulté majeure que nous avions rencontrée à ce niveau était l'acquisition des informations nécessaires liées au système existant. C'est grâce à un entretien avec le SGA de l'institution que nous avons eu assez d'information pour amorcer l'analyse du système existant et du nouveau système.

c. Itération 3 : Développement des fonctionnalités supplémentaires

Cette dernière étape nous a pris au minimum trois mois. Ici nous avons développé les fonctionnalités supplémentaires du système. Heureusement il n'y a pas eu des difficultés majeures à part les erreurs de codage. Pour les résoudre nous nous sommes servis des solutions proposées sur internet pour les gens qui ont eu les mêmes problèmes avant nous.

3.5. Mise en oeuvre sous MySQL

Dans cette partie nous allons détailler la structure de chaque table de notre modèle logique une fois créée sous MySQL.

1. Création de la base de données : dbteaching

Figure 3.10 : Code correspondant à la création de la base de données

44

2. Structure des tables de notre base de données

45

CREATE TABLE IF NOT EXISTS 'cours' (

'id' varchar{==) COLLATE utf8_unicode_ci NOT NULL,

'intitule' varchar(255) COLLATE utf8_unicode_ci NOT NULL,

'plan' text COLLATE utf8 unicodeci NOT NULL,

'objectif_gen' text COLLATE utf8 unicodeci NOT NULL,

' objectif_spec' text COLLATE utf8_unicode_ci NOT NULL,

'id_promotion' varchar(__) COLLATE utf8_unicode_ci DEFAULT NULL,

'id_fili ere' varchar(__) COLLATE utf8_unicode_ci DEFAULT NULL,

'nbr_heure' int(5) NOT NULL DEFAULT 'O',

'prerequis' varchar{__) COLLATE utf8_unicode_ci NOT NULL,

'statut' varchar(250) COLLATE utf8_unicode_ci NOT NULL DEFAULT 'circle-frame_basic_yellow.pnq',

'fishier' varchar(250) COLLATE utf8_unicode_ci NOT NULL,

'image' varchar(255) COLLATE ut£8_unicade_ci DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=ut£8 unicode ci;

CREATE TABLE IF NOT EXISTS 'enseignant' {

'matricule' varchar(__) COLLATE utf8_unicode_ci NOT NULL, 'nom' varchar( 5) CHARACTER SET utf8 NOT NULL,

'prenom' varchar( ) CHARACTER SET utf8 NOT NULL, 'dipl ome' varchar(50) COLLATE utf8_unicode_ci NOT NULL, 'options' varchar(2E E) COLLATE utf8_unicode_ci NOT NULL, 'experience' int(25) NOT NULL,

'date_naiss' date NOT NULL,

'nomutilisateur' varchar(Sn) ^CHARACTER SET utf8 NOT NULL, 'mot_de_passe' varchar(255) CHARACTER SET utf8 NOT NULL, 'id_type' varchar(=_) COLLATE utf8_unicode_ci DEFAULT NULL, 'email' varchar(255) CHARACTER SET utf8 DEFAULT NULL, 'genre' varchar{=0) CHARACTER SET utf8 NOT NULL, 'tel' varchar(_>;) CHARACTER SET utf8 DEFAULT NULL, 'image' varchar(25) CHARACTER SET utf8 DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATEutf8 unicode ci;

0 CREATE TABLE IF NOT EXISTS 'filiere` {

'id' varchar(--) COLLATE utf8_unicode_ci NOT NULL,

'nom' varchar(250) COLLATE utf8_unicode_ci NOT NULL

-) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATEutf8 unicode ci;

CREATE TABLE IF NOT EXISTS `notification' {

'id' varchar(LL) COLLATE utf8_unicode_ci NOT NULL, 'expediteur' varchar(__) COLLATE utf8_unicode_ci DEFAULT NULL, 'destinataire' varchar(--) COLLATE utf8_unicode_ci NOT NULL, 'objet' varchar(250) COLLATE utf8_unicode_ci NOT NULL, 'message' text COLLATE utf8_unicode_ci NOT NULL,

'date' date NOT NULL,

'statut' int(L) NOT NULL

ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8 unicode ci;

CREATE TABLE IF NOT EXISTS 'plan' {

'id' varchar(--) COLLATE utf8_unicode_ci NOT NULL,

'point' varchar(255) COLLATE utf8_unicode_ci NOT NULL, 'description' varchar(255) COLLATE utf8_unicode_ci NOT NULL, 'idCours' varchar(==) COLLATE utf8_unicode_ci NOT NULL ENGINE=InnoDB DEFAULT CHARSET=utf8 OOLLATEutf8 unicode ci;

0 CREATE TABLE IF NOT EXISTS 'promotion` {

'id' varchar(__) COLLATE utf8_unicodeci NOT NULL,

'nom' varchar(250) COLLATE utf8unicode_ci NOT NULL

-) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATEutf8 unicode ci;

CREATE TABLE IF NOT EXISTS 'type' {

'id' varchar(_') COLLATE utf8_unicode_ci NOT NULL, 'categorie' varchar(2) COLLATE utf8_unicode_ci NOT NULL, 'valeur' int(L) NOT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATEutf8 unicode ci;

46

CREATE TABLE IF NOT EXISTS 'voeu' (

'id' varchar(__) COLLATE utfO_unicode_ci NOT NULL,

'commentaire' text COLLATE utf8_unicode_ci NOT NULL, 'date' date NOT NULL,

'id_cours' varchar(__) COLLATE utf8unicodeci DEFAULT NULL, 'matricule' varchar(__) COLLATE ut£8_unicode_ci DEFAULT NULL ) ENGINE--InnoDB DEFAULT CHARSET--ut£8 COLLATEutf8 unicode ci;

E--

- - Index pour le,,s tables çxpu,t,ee,,s

- - Index pour la table 'archive'

ALTER TABLE 'archive'

ADD PRIMARY REY ('id'), ADD REY '£k arch teacher id ida' ('matricule'), ADD REY '£k arch attrib cours id ida' ('id cours');

E--

- - Index pour la table 'attribution'

ALTER TABLE 'attribution'

ADD PRIMARY REY ('id'), ADD REY 'fk attribution cours id idx' ('id cours'), ADD REY 'fk attribution enseignant id ida' ('matricule'):

E--

- - Index pour la table 'cauggat'

ALTER TABLE 'candidat'

ADD PRIMARY REY ('id'), ADD REY '£k cours id id.' ('id cours'), ADD REY 'fk candidat enseiguaut id idx' ('matricule');

-- Index pour la table 'may

ALTER TABLE 'cours'

ADD PRIMARY REY {'id'), ADD REY '0k_cour e_ teacher_ id_ida' C'objectif gen'(255)), ADD REY ' fk_promotion_id_ida' {'id_promotion'), ADD REY 'fk filiere id ida' ('id filiere');

- - Index pour la table 'RAB

ALTER TABLE 'enseignant'

ADD PRIMARY REY (matricule'), ADD REY 'fk teacher type id ida' ('id type');

-- Index pour la table 'fig'

ALTER TABLE 'filiere' ADD PRIMARY REY ('id');

- - Index pour la table 'notification'

ALTER TABLE 'notification'

ADD PRIMARY REY ('id'), ADD REY 'fk noti teacher itl ida ('expediteur');

- - Index pour la table 'plan'

ALTER TABLE 'plan'

ADD PRIMARY REY {'id'), ADD REY 'fk plan cours ida' ('idCours');

-- _x,54 pour la table '4

ALTER TABLE 'voeu'

ADD CONSTRAINT ' fk_vow_cours_id' FOREIGN REY ('id_cours') REFERENCES 'tours' ('id') ON DELETE SET NULL ON UPDATE SET NULL,

ADD CONSTRAINT 'ft vow teacher id' FOREIGN REY ('matricule') REFERENCES 'enseignant' {'matricule') ON DELETE SET NULL ON UPDATE SET NULL;

47

Figure 3.11 : Code de création des tables de la base de données

3.6. Capture d'écran

Dans cette partie, nous allons donner certaines vues de notre application associées à quelques lignes de code qui les composent. Cependant vue le nombre de ligne de code dans chaque page de notre solution, nous n'allons pas présenter sur chaque interface.

1. Interface de connexion

C'est le point d'entrer de l'application, la première page qui s'affiche vous permettant d'entre vos informations de connexion respectivement votre nom d'utilisateur et votre mot de passe afin d'avoir accès à l'application.

48

Vous devez être enseignant à l'Ecole Supérieure d'Informatique Salama pour avoir un compte et avoir accès aux services rendus par le système.

Figure 3.12 : Interface d'authentification

Figure 3.13 : Extrait de code de la page d'authentification 3. Page d'accueil

Lorsque l'authentification s'effectue avec succès, l'interface d'accueil sera affichée selon que vous êtes un administrateur ou un utilisateur simple

49

Figure 3.14 : Interface d'accueil 4. Attribution de cours

Seul l'administrateur a le droit d'attribuer les cours aux enseignants. Cette fonctionnalité est disponible en cliquant sur le menu Attribution, et ensuite on choisit l'enseignant qui doit prendre la charge du cours, et enfin on choisit le cours à attribuer.

Figure 3.15 : Interface d'attribution des cours 3. Liste des enseignants

Pour afficher la liste des enseignants, dérouler le menu Consulter , dérouler le sous-menu Enseignant et cliquer sur Afficher. Un tableau sera affiché reprenant toutes les informations en rapport avec les enseignants. Il sied de préciser que certaines informations ne seront pas visible que sur un compte utilisateur, c'est le cas de :

- Nom d'utilisateur

50

- Mot de passe

- Type du compte (utilisateur ou administrateur)

Figure 3.16 : Liste des enseignants

4. Liste des cours

Pour afficher la liste des cours, il faut dérouler le menu Consulter, ensuite dérouler le sous-menu Cours et cliquer sur Afficher. La liste de tous les cours sera affichée.

Chaque cours est représenté du côté gauche par un logo standard repris sur chaque cours, son intitulé, la promotion où est destiné le cours ainsi que son volume horaire ; et du côté droit, la filière ainsi que le statut du cours.

Le statut indique que le cours est validé ou pas. Le sens de la validation d'un cours s'explique par le fait que l'Ecole Supérieure d'Informatique Salama est une institution informatique, un nouveau cours peut être inséré dont le contenu doit être approuvé avant d'être programmé. Tout comme un cours peut être mise en évidence pour des raisons pédagogique et ne sera aligné qu'après avoir revu le contenu ou autre information ; face à ce genre de cas, le statut sera de couleur jaune juste pour indiquer que c'est un cours dont le contenu ou autre information doit être revu(e).

51

Figure 3.17 : Liste des cours

Figure 3.18 : Extrait de code affichant les informations d'un cours 5. Liste des candidats

La liste des candidats est accessible en déroulant le menu Consulter ensuite cliquer sur Candidat puis sur Afficher. Chaque candidat est représenté par un logo standard en bas duquel est repris le nom de l'enseignant candidat, et à coté l'intitulé du cours dont il réclame la responsabilité, la date ainsi que le motif de demande.

Aussi pour les enseignants souhaitant faire des enseignements, un statut pour exprimer l'état de leur candidature est visible à droite de chaque élément de la liste et peut prendre 3 icones différentes. L'icône verte indique que la candidature ou la demande a été acceptée, l'icône noire indique que la demande est en cours de traitement ou mise en attente et enfin l'icône rouge indique que la demande a été rejetée.

52

Figure 3.19 : Liste des candidats

Figure 3.20 : Extrait de code affichant la liste des candidats 6. Concevoir plan du cours

Voici l'interface qui permet aux enseignants de concevoir leur plan du cours. Accessible en déroulant le menu Consulter ensuite dérouler Cours puis cliquer sur Concevoir plan. L'interface est subdivisée en deux parties, la première c'est là où l'on saisit le plan et la deuxième c'est là où l'on choisit l'idée générale de ce qui sera vu dans le cours. On vérifie les correspondances avec les autres cours en cliquant sur Vérifier correspondance.

53

Figure 3.21 : Interface de conception du plan

Figure 3.22 : Extrait de code de l'interface Saisir voeu

3.7. Conclusion partielle

En guise de conclusion, l'expérience menée nous a permis de découvrir un bon nombre de techniques dans les domaines du développement d'applications informatiques et dans la conception de base de données. Le Teaching Manager a été l'occasion pour nous de mettre en pratique nos connaissances acquises tout au long de notre cursus universitaire.

54

CONCLUSION GENERALE

Nous voilà arriver au terme de notre travail qui s'intitule : « Outil pour la répartition des enseignements entre les enseignants ». L'idée d'un projet né toujours d'un besoin à satisfaire ; dans le cas précis, il s'agit d'un outil pour la répartition des enseignements entre les enseignants de l'Ecole Supérieure d'Informatique Salama.

Comme le travail de conception a toujours été le plus grand dans la fabrication des logiciels, une mauvaise conception produit toujours un logiciel raté. Pour arriver à solutionner un problème de ce genre, en informatique, on procède à plusieurs phases d'essai et jusqu'à la solution finale. C'est ainsi qu'après notre analyse, nous avons pu faire une ébauche juste pour simuler quelques scénarios de notre application d'étude. Nous pouvons ainsi souligner que l'implémentation que nous avons faite est à titre illustratif et nous laissons le travail ouvert à toutes personnes pouvant en faire objet d'une étude approfondie.

Néanmoins nous pouvons dire que les solutions que nous avons proposées dans notre travail d'analyse, portent solutions à notre problématique. Mais étant donné qu'il s'agit d'un travail scientifique, nous ne pouvons pas estimer avoir tout épuisé pour ce qui concerne ce sujet vu le domaine dans lequel il est traité, vu sa complexité et vu l'intérêt qu'il présente.

Ainsi nous laissons le libre arbitre à toutes personnes qui se sentiraient intéressées de traiter encore davantage ce sujet en vue d'une quelconque amélioration. Il y a encore beaucoup à traiter.

55

REFERENCES

[1] V. Wakudinga, «Secteur de l'enseignement en RDC/La relève des enseignants : un défi à relever,» [En ligne]. Available: http://www.onewovision.com/actu-rdc/Secteur-de-l-enseignement-en-RDC-La-releve-des-enseignants-un-defi-a-relever.

[2] Chabo, «Pour un enseignement efficace,» [En ligne]. Available:

http://aladecouverte.aefo.on.ca/gestion-de-classe/pour-un-enseignement-efficace.

[3] P. &. Tricot, «Comment concevoir un enseignement ?,» De Boeck, Bruxelles, 2012.

[4] M. Moulin, «Université: parlew-vous le LMD ?,» [En ligne]. Available: http://www.m.studyrama.com/formations/filieres/universite-parlez-vous-le-lmd-8163.

[5] M. Salid, «Unité d'enseignement,» [En ligne]. Available: http://www.univ-blida.dz/index.php?option=com_content&view=article&id=167&Itemid=549.

[6] L. Audibert, «UML 2 : De l'apprentissage à la pratique,» [En ligne]. Available: http://www.laurent-audibert.developpez.com/Cours-UML/?page=diagramme-cas-utilisation.

[7] J. Brès, Atélie génie logiciel 2, Bruxelle, 2012.

[8] M. Blay-fornarino, «Architecture logicielle,» [En ligne]. Available: http://anubls.polytech.unlce.fr/lut/2012-2013/lp/ldse/gl/management.

[9] M. Rousen, «Serveur Web,» [En ligne]. Available: http://www.lemagit.fr/definition/Serveur-Web.

[10] M. Rouse, «Serveur d'applications,» [En ligne]. Available: http://www.lemagit.fr/definition/Serveur-dapplications.

[11] M. Rouse, «Base de données,» [En ligne]. Available: http://www.lemagit.fr/definition/Base-de-donnees.

[12] J. Gabay, UML 2 Analyse et conception, Paris: Dunod, 2008.

[13] R. Tetue, «De vit incre,» [En ligne]. Available: http://www.romy.tetue.net/mona-lisa-agile?lang=fr.