|
Outil pour la répartition des enseignementspar Jean-Luc Kahenga Ecole Supérieure d'Informatique Salama - Bac+3 en Génie logiciel système informatique 2017 |
CHAPITRE 3 : MISE EN PLACE D'UN OUTIL DE REPARTITION DESENSEIGNEMENTS 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 : INTRODUCTION0.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 :
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
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 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 :
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 :
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 :
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.
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 :
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 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 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 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 :
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).
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»
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 »
Figure 2.7 : Diagramme de séquence du cas « Consulter cours »
22 3. Consulter enseignants Tableau 2.3 : Description textuelle du cas « Consulter enseignants »
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 »
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 »
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 »
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 »
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 »
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 »
28 Précondition Compte actif Scénarios Nominal Cliquer sur menu « Candidature » Choisir cours Saisir suggestion Clic sur bouton « Valider »
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 »
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 »
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 »
Figure 2.27 : Diagramme de séquence du cas « Modifier plan du cours »
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 »
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 »
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 :
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 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 :
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
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).
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 :
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]
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
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--
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
