Conception et implémentation d'un site web de publication des résultats des étudiants dans une institution universitaire (cas de l'université de Kamina)

UNIVERSITE DE KAMINA

« UNIKAM »

B.P. 279

KAMINA

FACULTE DES SCIENCES INFORMATIQUES

DEPARTEMENT D'INFORMATIQUE DE GESTION

CONCEPTION ET IMPLEMENTATION D'UN SITE WEB DE PUBLICATION
DES RESULTATS DES ETUDIANTS DANS UNE INSTITUTION
UNIVERSITAIRE

« Cas de l'Université de Kamina »

Par BWANGA KATEBA Charles

Mémoire présenté et défendu en vue de l'obtention du grade de Licencié en Sciences Informatiques.

OPTION : CONCEPTION DES SYSTEMES D'INFORMATION

Directeur : Docteur Daily KALOMBO NSHIMBA VIDJE

ANNEE ACADEMIQUE 2020-2021

i

EPIGRAPHE

« Il n'y a aucun secret pour réussir. C'est le résultat de la préparation, le travail acharné et apprendre de l'échec. »

Colin Luther Powell

ii

IN MEMORIUM

A vous très chère Grand-Mère paternelle Véronique NKULU ;

A vous chers oncles paternels Jacques TSHIKALA et Faustin KATEBA.

Univers d'amour et de fiabilités, malgré les dures tempêtes que nous avons rencontrées ensemble toujours unis nous formons une armée abreuvant notre force d'amour, justice et vu nous avons grâce à vous pour avoir constitué une belle et grande famille, malgré votre départ survie par unité. Usé par les batailles que votre absence nous donne et là nous apprenons à pardonner la vie jamais je vais essayer de vous oublier.

Tout ce moment inavoué, est perdu, à tout jamais. Je braderai toutes les mères, les obstacles et les barrières rien ne pourra vous remplacer mes yeux s'allument quand je pense à vous mais le destin vous a récupéré si vite, vous me manquez vraiment ma dernière parole avant d'achever ma rédaction : « Que les âmes des fidèles défunts reposent en paix !».

BWANGA KATEBA Charles

iii

DEDICACE

Aux concepteurs des Systèmes d'information ;

Aux professionnels informaticiens ;

Au Monde Informatique ;

A tous ceux qui oeuvrent pour la paix dans le monde.

BWANGA KATEBA Charles

iv

REMERCIEMENTS

Nous voici à la fin de notre cycle de licence, grâce au concours de plusieurs personnes. Le travail que nous présentons ce jour n'est pas exclusivement le fruit de nos efforts personnels, il est au contraire, l'oeuvre provenant du concours de plusieurs personnes. Qu'elles soient toutes remerciées pour les peines consenties afin de nous aider à nous dépasser, à terminer ce cycle, malgré les difficultés quotidiennes.

« Dieu est en tous ses ouvrages, quoiqu'il n'y en ait aucun qui le contienne. » (SAINT AUGUSTIN), ainsi, lui étant omniscient, nous ne cesserons jamais d'oublier sa magnificence car il est notre rédempteur : merci Seigneur Dieu de nous avoir comblé de grâce, et de nous avoir accordé la chance d'étudier tout au long de notre cursus académique en Sciences Informatiques précisément au département de Conception des Systèmes d'Information.

PARKER dit : « Ne laissons pas les nobles hommes de nos jours passer sans recevoir l'honneur qui leur est dû. » de ce fait, nos mille mercis et reconnaissances s'adressent d'une façon particularisée à notre directeur Docteur Daily KALOMBO NSHIMBA VIDJE, qui, en dépit de ses multiples préoccupations a en assuré la direction de ce travail.

Aussi, il nous est agréable de rendre hommage au corps professoral de l'université de KAMINA, aux doyens de la faculté des Sciences Informatiques, aux chefs des travaux : Elie Louis KABWE KIONDE KABUTA et Lucide BULA, aux assistants : Hilaire KENDA, Bertin LOBO, Gabin NDAY A MANDE, Jean Paul BWANA, Baldo MWAMBA, Valéry KABONGO, David KADIATA, Gloire ILUNGA, et tant d'autres.

D'après QUINET « Une âme grande, pure, généreuse est un trésor, pour le peuple qui l'a enfantée et nourrie, car c'est le modèle sur lequel les autres se forment », en tout temps nos remerciements s'adressent mes chers parents d'avoir eu la bonne volonté, la patience et l'amour profonds pour que je sois scolarisé être solide pour supporter toutes les souffrances et les conditions scolaires et académiques, recevez ce travail fruit de vos efforts, encadrement et sages conseils : Voilà aujourd'hui nous sommes à la fin du cycle la résultante de vos ardents souhaits ; nous citons : notre Père NGOY KATEBA ALLUWAWA Symphorien, car, « Le père connaît les besoins de son fils. Faut-il pour cela que le fils n'ait jamais une parole de requête ou d'action de grâce pour son père ? » (LAMENNAIS) et notre Mère MBUYU MAUA

v

Sylvie, car selon le célèbre philosophe SOCRATE, « De quelles vertus serais-tu capable, si tu ne commençais pas par aimer ta mère ? ».

Nos remerciements s'adressent à vous mes frères Jacques KATEBA, Éric KATEBA, Patrick KATEBA, Deogratias KATEBA et mes soeurs Edouarde KATEBA, Sylvie KATEBA et Véronique KATEBA : que le bon Dieu puisse vous combler de grâce et de longévité.

Merci à vous tous mes oncles tant paternels que maternels, cousins et cousines qui ont contribués d'une manière ou d'une autre pour la réalisation de ce travail.

Nos remerciements à nos chers collègues de promotion de leurs participations et concours dans différents travaux d'évaluation, nous citons : Denis LENGE, NDENGANDENGA MAKENKEWE, Lambie BANZA, Gloire KAPONGO et aux autres dont leurs noms ne figurent pas ici qu'ils trouvent nos sentiments de gratitude.

Nous ne pouvons pas passer sous silence les hommes de bonne volonté pour leurs assistance et sacrifice multiforme dont on dit toujours « Les bienfaits n'ont jamais été oubliés », c'est le cas de la famille de AG Sophie KIPILI MABEMBA, des frères en Christ : Dadou, Hubert MAFUTA, Claude LUBOBO, Jean Paul MPOYO, Grâce NTUMBA, Innocent NYENGA, Lebrun KABONGO, Emile SHAKO, KYUNGU LUBATSHI ; des soeurs en Christ : Thérèse MIKOMBE, Julie ILUNGA, Mireille NUMBI, Anny MASANGU, ainsi qu'à tous les membres de l'ensemble vocal AVE MARIA.

A tous de près et de loin pour leur soutien moral, matériel et financier à notre égard qu'ils trouvent ici l'expression de notre gratitude pour les sacrifices et privation qu'ils ont endurés pour nous.

BWANGA KATEBA Charles

vi

LISTE DES ABREVIATIONS

2TUP: Two Truck Unified Process

AGL : Atelier de Génie Logiciel BDD : Base de données

CGI: Common Gateway Interface CMS: Content Management System CSS: Cascading Style Sheets

C.U: Cas d'utilisation

HTML: HyperText Markup Langage

HTTP: Hypertext Transfert Protocol

IP: Internet Protocol

MVC: Model-View-Controller

PHP: PHP Hypertext Preprocessor

RUP: Rational Unified Process

SGBD : Système de Gestion de Base de Données

SGBDR : Système de gestion de Base de Données Relationnelles

SMS: Short message System

SQL: Structured Query Language

UML: Unified Modeling Language UP: Unified Process

URL: Uniform Resource Locator W3C: World Wide Web Consortium WWW: World Wide Web

XAMPP: X Apache MySQL Perl PH XP : eXtreme Programming

vii

TABLE DES ILLUSTRATIONS

A. FIGURES ET DIAGRAMMES

Figure 1.1: WWW 14

Figure 1-2: Site web statique 16

Figure 1-3: site web dynamique 17

Figure 1-4: Serveur web 17

Figure 1-5: Les CMS 18

Figure 1-6: Les Framework web 19

Figure 1-7: Principes du Processus Unifié 21

Figure 1-8: Les phases du Processus Unifié 22

Figure 1-9: Le processus de développement en Y 24

Figure 2-1: Situation de l'étude préliminaire dans 2TUP 32

Figure 2-2: Diagramme de contexte statique du système de publication des résultats des

étudiants de l'UNIKAM 39

Figure 2-3: Situation de la capture des besoins fonctionnels dans 2TUP 40

Figure 2-4: Diagramme de cas d'utilisation pour la publication des résultats des étudiants de

l'UNIKAM 44

Figure 2-5: Diagramme de Séquence du C.U. « S'authentifier » 46

Figure 2-6: Diagramme de Séquence du C.U. « Gérer utilisateurs » 49

Figure 2-7: Diagramme de Séquence du C.U. « Gérer Secrétaires des jurys » 52

Figure 2-8: Diagramme de Séquence du C.U. « Consulter statistiques résultats » 54

Figure 2-9: Diagramme de Séquence du C.U. « Gérer paiements » 56

Figure 2-10: Diagramme de Séquence du C.U. « Publier résultats » 58

Figure 2-11: Diagramme de Séquence du C.U. « Gérer publications résultats » 60

Figure 2-12: Diagramme de Séquence du C.U. « S'inscrire » 62

Figure 2-13: Diagramme de Séquence du C.U. « Consulter résultats » 63

Figure 2-14: Diagramme de Séquence du C.U. « Introduire recours » 64

Figure 2-15: Diagramme de Séquence du C.U. « Consulter recours » 66

Figure 2-16: Diagramme de packages des cas d'utilisation 67

Figure 2-17: Diagramme de cas d'utilisation du package « gestion résultats » 68

Figure 2-18: Diagramme de classe participante du C.U. « S'authentifier » 69

Figure 2-19: Diagramme de classe participante du C.U. « Gérer utilisateurs » 69

Figure 2-20: Diagramme de classe participante du C.U. « Gérer Secrétaires des Jurys » 70

viii

Figure 2-21: Diagramme de classe participante du C.U. « Consulter statistiques résultats » . 70

Figure 2-22: Diagramme de classe participante du C.U. « Gérer paiements » 71

Figure 2-23: Diagramme de classe participante du C.U. « Publier résultats » 71

Figure 2-24: Diagramme de classe participante du C.U. « Gérer publications résultats » 72

Figure 2-25: Diagramme de classe participante du C.U. « S'inscrire » 72

Figure 2-26: Diagramme de classe participante du C.U. « Consulter résultats » 73

Figure 2-27: Diagramme de classe participante du C.U. « Introduire recours » 73

Figure 2-28: Diagramme de classe participante du C.U. « Consulter recours » 74

Figure 3-1: Premier découpage en catégories 78

Figure 3-2: Quelques associations concernant la classe Résultats 79

Figure 3-3: Illustration d'importations entre catégories 79

Figure 3-4: Diagramme de packages d'analyse 80

Figure 3-5: Diagramme de classes de conception 81

Figure 3-6: Diagramme d'interaction du C.U s'authentifier 82

Figure 3-7: Diagramme d'interaction du C.U gérer utilisateurs 83

Figure 3-8: Diagramme d'interaction du C.U gérer secrétaires des jurys 84

Figure 3-9: Diagramme d'interaction du C.U consulter statistiques résultats 85

Figure 3-10: Diagramme d'interaction du C.U Gérer paiements 86

Figure 3-11: Diagramme d'interaction du C.U Publier résultats 87

Figure 3-12: Diagramme d'interaction du C.U Gérer publications résultats 88

Figure 3-13: Diagramme d'interaction du C.U S'Inscrire 89

Figure 3-14: Diagramme d'interaction du C.U Consulter résultats 90

Figure 3-15: Diagramme d'interaction du C.U Introduire recours 91

Figure 3-16: Diagramme d'interaction du C.U Consulter recours 92

Figure 3-17: choix de style des architectures logiciels 94

Figure 3-18: Implémentation du modèle MVC 95

Figure 3-19: Diagramme de déploiement 96

Figure 4-1: Page d'accueil pour la gestion des publications des résultats des étudiants de

l'Université de Kamina 101

Figure 4-2: Pages d'authentification pour les utilisateurs 102

Figure 4-3: Pages de gestion d'utilisateurs 103

Figure 4-4: Page d'inscription 103

Figure 4-5: Pages de gestion d'affectation des secrétaires des jurys 104

ix

Figure 4-6: Pages de gestion de paiements 105

Figure 4-7: Pages de gestion des résultats 106

Figure 4-8: Page de statistiques résultats 106

Figure 4-9: Page de consultation des résultats 107

Figure 4-10: Page d'introduction d'un recours 107

Figure 4-11: Page de consultation de recours 107

B. TABLEAUX

Tableau 2-1: Inventaire des fonctions 34

Tableau 2-2: Liste des acteurs et des messages par cas d'utilisation 41

Tableau 2-3: Liste des cas d'utilisation et de leurs acteurs par package 67

Tableau 2-4: Définition des itérations par classement des cas d'utilisation 75

1

INTRODUCTION GENERALE

1. GENERALITES

En quelques siècles, l'Homme est passé du statut de spectateur impuissant à celui d'acteur sur son environnement. Le génie humain a développé au cours des siècles des sciences, des techniques et des technologies qui lui ont d'abord permis d'assurer la survie de l'espèce humaine, de comprendre l'environnement puis d'accroître toujours plus son pouvoir à le modeler. D'où l'avènement de l'ordinateur, grâce auquel il est désormais possible d'exécuter en un rien de temps, les lourdes tâches jadis difficiles si pas impossibles à réaliser.

N'empêche que l'entreprise souffre de certaines difficultés dans sa mise en oeuvre qui nécessite un énorme volume de travail (difficulté d'accéder aux résultats après publication, difficulté d'archivage des grilles de côtes et des grilles de délibération, difficulté de retrouver en un temps opportun les côtes et les résultats de l'étudiant ayant étudié dans les années antérieures, etc.) aussi la plupart exige un certain niveau de reconfiguration : ce qui représente un risque pour la stabilité du système de l'organisation de l'Université de Kamina, tout cela est due à la complexité de l'organisation de l'entreprise et au taux gigantesque d'informations.

Blogs, réseaux sociaux, pages d'accueil personnalisables... Depuis quelques années, les sites web ont gagné en fonctionnalités et sont devenus dans le même temps de plus en plus complexes. Que le temps de la "page web personnel" est loin ! Il y a une époque où l'on pouvait se contenter de créer un site basique. Un peu de texte, quelques images : hop là, notre site personnel était prêt. Aujourd'hui, c'est différent : il faut que ça bouge ! On s'attend à ce qu'un site soit régulièrement mis à jour : on veut voir des actualités sur la page d'accueil, on veut pouvoir les commenter, discuter sur des forums, bref, participer à la vie du site.

Le but, apparemment simple, de cette recherche est d'identifier l'information dont on a besoin, de savoir où on est susceptible de la trouver pour ensuite aller la chercher, le tout avec le plus d'efficacité possible. Tout cela rendra la réalisation d'un site web plus aisée, ce qui contribuera ultimement à sa démocratisation.

C'est dans cette optique que le sujet du présent travail s'intitule « Conception et implémentation d'un site web de publication des résultats des étudiants dans une institution universitaire (cas de l'UNIKAM) » car, ce afin de pousser cette institution vers l'émergence et qu'elle atteigne les objectifs qu'elle s'est assigné (construire la tradition des meilleurs).

2

2. CHOIX ET INTERETS DU SUJET 2.1.CHOIX DU SUJET

Nous tenons à faire remarquer que le choix que nous avons porté sur ce sujet n'est pas d'une complaisance quelconque, mais du fait que c'est de l'importance que nous accordons à cette institution universitaire qui doit assurer la formation des cadres de conception dans les domaines les plus divers de la vie nationale. A ce titre, elle dispense des enseignements de manière à favoriser l'éclosion des idées neuves et le développement des aptitudes professionnelles.

2.2.INTERETS DU SUJET

a) INTERET PERSONNEL

Ce travail va nous permettre des connaissances pratiques, tout d'abord dans le développement d'un site web dynamique ainsi que les outils adaptés pour le déployer sur le serveur, comment effectuer son hébergement, comment le gérer (du webmastering) sur le cas réel ; et avoir la maitrise dans les processus de délibération des étudiants et de publication des résultats des étudiants dans une Université.

b) INTERET SOCIAL

L'implémentation d'un site web pour la publication des résultats des étudiants de l'Université de Kamina va permettre à cette dernière la gestion de ses étudiants (du côté conflit après publication ( parlant de l'erreur faite) et le problème dû à la publication des résultats) afin d'améliorer la qualité du service rendu (par jury) et limiter les erreurs irréprochables, ainsi qu'à toute personne (l'internaute) voulant s'informer sur les résultats de son enfant soit de son ami ou de soi-même de pouvoir avoir l'accès aux informations recherchées et cela en temps réel et utile.

e) INTERET SCIENTIFIQUE

En tant que concepteur des systèmes d'information, notre apport dans le monde scientifique et plus particulièrement dans le monde informatique au besoin, est de perfectionner le modèle pour une utilisation efficace dans toutes les organisations en besoin, compléter d'autres recherches faites sur ce sujet et cela de par nos suggestions qui constitueront un apport pour augmenter les performances de la gestion car la conception d'un site web n'est pas un rêve nocturne qui peut se concrétiser en un clin d'oeil, mais c'est plutôt un projet qui pour le réaliser, il est vraiment nécessaire de suivre les étapes qu'impose une méthode de modélisation.

¹ Patrick IZATINA MBALA, « Conception d'une application web pour la publication des résultats académiques dans un portail documentaire. » TFE Inédit, Département de Télécommunications, ISTA/Kinshasa, 2014-2015.

3

3. ETAT DE LA QUESTION

Cette étape, appelée autrement « Revue de la littérature ». Il est important et nécessaire de consulter ceux qui ont déjà émis leurs idées sur le plateau scientifique dans le but de prendre les idées émises, d'éviter quelques erreurs, d'y passer ou de négliger les avances utiles. A cet effet, les travaux précédant serviront de garde-fou à notre étude.

Sur ce, nous avons pu lire ou consulter les prédécesseurs ci-après :

? Patrick IZATINA MBALA, dans son travail de fin d'études intitulé « Conception d'une application web pour la publication des résultats académiques dans un portail documentaire. » (Cas de l'Institut Supérieur de Techniques Appliquées (ISTA) de Kinshasa), Année académique 2014-2015.¹

Sa problématique était celle de dire : Souvent, les étudiants sont ignorants de la date exacte de la délibération. Ce qui leur cause préjudice aux recours étant donné qu'il y a un temps prédéfini pour le dépôt des recours : la connaissance des échecs ou de manque des côtes et les modifications intempestives.

Pour répondre aux problèmes de gestion cités ci-haut, Il a proposé comme hypothèse en disant que : nous pensons que l'implémentation d'un portail documentaire pour la consultation des résultats académiques par internet avec notification SMS au sein de son site web, pourra faire bénéficier au personnel oeuvrant dans l'administration d'envoyer les côtes des étudiants dans la base de données sans qu'il y ait modification. L'implémentation de ce portail documentaire permettra aussi aux étudiants en temps réel après délibération, grâce à une notification SMS de savoir que la délibération a eu lieu et peut voir son carnet de côte par internet quel que soit l'endroit où il se trouve.

Il a utilisé la méthode analytique et la méthode structuro-fonctionnelle comme démarche dans son travail.

En fonction des besoins réels de l'Institut Supérieur de Techniques Appliquées, différents arguments plaident en faveur d'un portail documentaire et sécurisé pour la délibération, raison pour laquelle la solution est d'implémenter cette technologie au sein du site web de l'ISTA et cela en utilisant le PHP et SGBD MySQL.

4

? Bienvenu WILONDJA KAKONDJA « Mise en place d'un modèle d'application web pour la publication des résultats académiques dans les institutions d'enseignement supérieur via la téléphonie cellulaire » (Cas de l'ISP/Bukavu), Année académique 2017-2018.²

L'auteur a souligné la problématique en disant : Dans le système actuel de publication des résultats académiques des étudiants à l'Institut Supérieur Pédagogique (ISP) de Bukavu nous constatons encore plusieurs failles comme quoi, pour qu'un étudiant puisse voir ses résultats, il doit faire un déplacement et venir jusqu'aux valves où les résultats sont affichés pour consultation. Cela prouve l'insuffisance dans ce système ainsi que dans certaines autres institutions d'enseignements supérieurs et universitaires de la place comme par exemple l'Université Officielle de Bukavu (UOB), l'Institut Supérieur de Développement Rural (ISDR), l'Université Libre de Grand Lac (ULGL), et bien d'autres. Cette manière de procéder est considérée comme manuelle et archaïque compte tenu de l'avancée technologie. Restant toujours dans le même contexte, nous remarquons aussi les retards de diffusions des résultats aux étudiant(e)s par les jurys, et même si ces résultats sont diffusés, problème encore aux certains étudiant(e)s d'y accéder facilement vu les encombrements qui se présente pendant cette période aux valves. Et tout cela c'est par manque d'un mécanisme pouvant faciliter la tâche aux jurys et aux étudiant(e)s. Le problème se remarque aussi aux étudiant(e)s vivant en dehors de la ville où, une fois en attente des résultats académiques à leurs domiciles, ils doivent appelés chaque fois leurs collègues, parfois même ils(elles) sont obligés de payer encore le transport jusqu'à l'institution en place pour s'informer de l'évolution ou du processus de publication des résultats. Parfois aussi le problème ou la manque de connexion du réseau Internet dans leurs milieux.

De ceux qui précèdent, il a proposé comme hypothèse : La technologie web intégrant ce modèle ou le système de télécommunication faciliterait la publication des résultats académique par les secrétaires des jurys aux étudiants (es) à travers les numéros des téléphones des étudiants ; et la réception de ces résultats parviendrait à ces derniers sans aucun déplacement et cela en temps réel.

Il s'est servi du processus UP (Unified Processus ou processus unifié) qui est une méthodologie Informatique de développement ainsi que du modèle UML (Unified Modeling Language).

2 Bienvenu WILONDJA KAKONDJA « Mise en place d'un modèle d'application web pour la publication des résultats académiques dans les institutions d'enseignement supérieur via la téléphonie cellulaire », TFE Inédit, Département d'Informatique de Gestion, ISP/Bukavu, 2017-2018.

5

? KALENGA LUBANGE Cédric « Développement d'une application web pour la publication des résultats dans une institution universitaire » (Cas de l'UNIKAM), Année académique 2019-2020. 3

Il a donné les problématiques lors de la publication à UNIKAM comme suites : les différents jurys sont butés à des difficultés du genre ils mettent toujours beaucoup de temps pour la publication des résultats des étudiants au quel l'effectif de ceux-ci est élevé. Avec la publication se faisant à travers la voix médiatique, cela oblige que les étudiants soient dans un espace non éloigné géographiquement pour ne pas manquer leurs côtes. Avec des moments de turbulences qu'a traversé la province du Haut-Lomami, avec des interruptions du courant électrique, où aucune d'entre les maisons de presse n'a pu émettre, l'UNIKAM s'est retrouvée dans l'obligation d'afficher les résultats à travers les fenêtres de différents décanats. Dans le cas où ceci n'a pas été le cas, l'un des nombres du jury devait se tenir au balcon de l'institution pour les publier et alors que les concernés devaient être en bas pour écoutes chacun sa suite.

Il a proposé comme hypothèses permettant de remédier à cette situation, de mettre en place une application web qui devra permettre aux étudiants de consulter leurs résultats de façon distante.

De notre part, nous allons rendre accessible la consultation et la recherche des résultats et faire l'Université de Kamina au grand public du monde estudiantin, et la publication se fera tout en commençant par des messages d'alertes dans le compte Gmail de chaque étudiant, notre institution universitaire sera épargnée de difficultés constatées pendant l'affichage des résultats académiques au valve.

3 KALENGA LUBANGE Cédric « Développement d'une application web pour la publication des résultats dans une institution universitaire » (Cas de l'UNIKAM), Mémoire Inédit, Département de Conception des Systèmes d'Information, Université de Kamina, 2019-2020.

6

4. PROBLEMATIQUE

La question de recherche est une préoccupation scientifique qu'un chercheur souline à propos de l'objet de sa recherche. En d'autres termes, questionner ou problématiser revient à mettre ensemble tous les problèmes qui doivent être éclairés au cours d'une étude scientifique.

Selon le professeur LUMBILA NGOIE Robert « la problématique est une approche ou une perspective théorique que l'on décide d'adopter pour traiter le problème posé par question de départ ».⁴

Voici quelques problèmes de gestion qui ont fait à ce que notre thème soit abordé à l'Université de Kamina :

4 Tout avait commencé par la publication des résultats au balcon soit au décanat, puis elle s'est faite par diffusion à la radio RCK, puis la radio RTU (presse de ladite institution) : mais tout cela ne parvenait pas toujours à rendre accessible les résultats des étudiants car il faudrait toujours être situé géographiquement à une distance non loin de ces maisons de média ;

4 Lors de la période de publication des résultats, les étudiants sont sensés attendre au sein de l'Université jusqu'à ce qu'ils aient leurs résultats, quel que soit l'heure ou le nombre de rendez-vous ratés ;

4 Parfois le décanat oblige à un étudiant qui n'a pas eu plus de précision sur ses résultats (en termes de points obtenus et pourcentage) après publication des résultats l'achat de relevé de côtes, tant que le jury lors de la publication des résultats n'a jamais cité le pourcentage et les points obtenus de l'étudiant (à part la mention) ;

4 En 2019, lors de la publication des résultats de la première session, le secrétariat général académique avait exigé de faire la publication par SMS (Short message System c.à.d. Court Message Textuel), mais cela n'a pas tenu : beaucoup d'étudiants ayant été en ordre n'avaient pas reçu de SMS ; pour ce faire il fallait passer par l'introduction du recours afin d'être délibéré et avoir ses résultats ;

4 Parfois l'étudiant parvient à échouer suite au malentendu entre le jury et l'enseignant c.à.d. souvent quand l'étudiant introduit le recours dans un cours, le jury envoi la

⁴ Prof. MWEMBO LUMBILA NGOIE Robert, Pour une pratique de la science, Prolégomènes à l'initiation à la recherche scientifique, Ed. Les moissonneurs, Lubumbashi, 2013, p.48.

7

victime auprès de l'enseignant : arriver chez l'enseignant, ce dernier la retourne soi-disant que vous avez réussi dans mon cours. C'est pour cela qu'il y a fluidité.

Pour pallier à tous ces problèmes de gestion, voici la question à laquelle nous allons tenter de répondre aux lignes du point suivant : « Quelle solution pouvons-nous implémenter afin rendre accessible et d'améliorer la gestion de publication des résultats des étudiants à l'UNIKAM dans la clarté pourvu d'éviter tout désagrément dans ce processus ? »

5. HYPOTHESE

L'hypothèse se définit comme étant une idée directrice, destinée à guider l'investigateur à être abandonné ou maintenue après les résultats de l'observation⁵.

Selon P. Rongere, l'hypothèse est une proposition de solutions aux questions que l'on se pose à propos de la recherche formulée en des termes tels que l'observation et l'analyse⁶. Quant à la question susmentionnée, il convient de souligner : y Rendre accessible la consultation et la recherche des résultats des étudiants et faire l'Université de Kamina au grand public du monde estudiantin, et la publication se tout en commençant par des messages d'alertes dans le compte Gmail de chaque étudiant ; y Que le jury disponibilise une seule grille Excel avec toutes les formules bien apprêtées, Que cette seule grille soit accessible à tous les enseignants concernés ; y Que chaque enseignant n'ait droit d'écriture que sur la colonne qui concerne le cours dont il est titulaire ;

y Plusieurs enseignants peuvent travailler simultanément sur la même grille tout en n'étant pas physiquement au même endroit. Dès que la dernière cote est saisie, le jury n'aura qu'à télécharger la grille et cela par la proposition du service de synchronisation de Google Drive ;

De ce fait, l'implémentation d'un site de publication des résultats des étudiants doit pouvoir répondre aux problèmes de processus de délibération des étudiants et celui de publication des résultats.

⁵ PINTO & GRAWITZ, Méthodes des Sciences Sociales, Ed. Eyrolles Paris, 1972, p.828.

6 Pierrette Rongere, Manuel de sociologie générale, Ed. Africa, Lubumbashi, 1999, p.21.

8

6. METHODE ET TECHNIQUES

6.1.METHODE

En vue d'appréhender concrètement notre objet d'étude, il nous est nécessaire de recourir à une méthode de recherche.

La méthode désigne un ensemble des opérations intellectuelles par les quelles une discipline cherche à atteindre les vérités qu'elle poursuit, les démontres et les vérifies⁷.

René Descartes défini aussi une méthode comme une marche rationnelle de l'esprit pour arriver à la vérité dans la science.⁸

La méthode d'informatisation en informatique de gestion⁹ :

- Définit un processus d'informatisation du Système d'Information (totalement ou partiellement i.e. pour tout ou partie du cycle de vie du logiciel) ;

- Possède une portée (champ d'étude i.e. domaine d'étude) ;

- Décrit une démarche i.e. un ensemble des travaux en les ordonnant (succession d'étapes).

Pour ce qui est de la méthodologie, nous avons opté pour le processus 2TUP (qui signifie Two Truck Unified Process), appelée autrement processus en Y.

Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées aux systèmes d'information de l'entreprise. En ce sens, il renforce le contrôle sur les capacités d'évolution et de correction de tels systèmes. « 2Track » signifie littéralement que le processus suit deux chemins. Il s'agit des chemins « fonctionnels » et « d'architecture technique », qui correspondent aux deux axes de changement imposés au système informatique¹⁰.

En outre, nous allons utiliser le langage UML « Unified Modeling Language » lors de la phase de conception de solution que nous aurons à proposer, et cela en utilisant ses diagrammes.

⁷ PINTO & GRAWITZ, Ibidem.

8 René Descartes, Discours de la méthode, Ed. J-VAZI, Paris, 1988, p.11.

⁹ M.NEMICHE, Cours d'Analyse et Conception des Systèmes d'Information, Inédit 2009-2010, p.78.

¹⁰ Pascal Roques et Franck Vallée, UML 2 en action, De l'analyse des besoins à la conception, Ed. Eyrolles, Paris, 2007, p.13.

9

6.2.TECHNIQUES

La technique est un ensemble des lignes directrices qui aident l'analyste à réaliser une activité ou une tâche de développement du système¹¹.

Une technique est un ensemble d'outils mis à la disposition du et organisés par la méthode utilisée pour collecter des données et est limitée en nombre et est commune à la plupart des sciences¹².

Voici quelques techniques que nous avons utilisées dans ce travail :

a) TECHNIQUE DOCUMENTAIRE

C'est grâce à cette technique que nous avons réalisé la recherche de revue de la littérature ayant trait à notre travail. Elle nous a permis d'être en possession des quelques ouvrages, journaux, notes de cours, revues etc... pour habiller notre travail en s'appuyant sur les arguments de valeur.

b) TECHNIQUE D'OBSERVATION

Cette technique nous a permis d'observer les réalités en rapport avec notre sujet et en effectuant la collecte des faits d'un phénomène dans leur déroulement naturel directement, sans intermédiaire humain (cf. le jury), en notant les résultats de l'observation, sur le champ ou immédiatement après, sur des fichiers.

e) TECHNIQUE D'INTERVIEW

Elle est une technique qui a pour but d'organiser un rapport de communication verbale entre deux personnes (l'enquêteur et l'enquêté) afin de permettre à l'enquêteur de recueillir certaines informations de l'enquête concernant un objet précis¹³.

L'interview nous a permis de poser certaines questions aux personnes concernées possédant les informations concernant notre étude (auprès du secrétaire académique de la faculté des sciences informatiques), l'entretien et la prise de connaissance par l'échange de dialogue avec les utilisateurs du système étudie ont été aussi nécessaire.

¹¹ Ferréol Gilles, La Dissertation Sociologique, Ed. ARMAND COLIN, Paris, 2000, P.192.

¹² PINTO & GRAWITZ, op.cit., p.261.

¹³ Albert Bruno, Les méthodes de sciences sociales, Ed. Mont Chrétien, Paris, 1972, p.207.

10

7. DELIMITATION DU SUJET

Etant donné que toute recherche scientifique doit répondre aux critères de délimitation quoiqu'elle soit pertinente, précise et concise. Cette délimitation nous permet de spécifier notre travail enfin d'avoir une précision et une clarté scientifique, de ne pas être dans une généralité des choses ; nous avons délimité notre travail dans le temps et dans l'espace.

Comme tout projet qui doit avoir une durée de vie, notre petit projet (on le qualifie ainsi car il est réalisé par une seule personne), s'étend de Mars en Septembre 2021 ; et son investigation est à l'Université de Kamina : précisément à la faculté des sciences informatiques. L'étude ne se limite que dans la conception et l'implémentation d'un site web pour gérer la publication des résultats des étudiants de l'UNIKAM, la création du forum pour les étudiants, la délibération en ligne, l'introduction du recours, gestion des paiements.

8. SUBDIVISION DU TRAVAIL

Notre travail sera subdivisé en quatre chapitres qui ont été précédé d'une introduction générale et qui seront clôturé d'une conclusion. Les quatre chapitres sont :

? Le Premier chapitre se nomme « Définition des concepts et considération théorique » ; ce chapitre traite sur les différentes définitions des concepts ou mots clés constituant notre thème, et quelques concepts liés à notre méthodologie et avec son langage, et, ce afin de pouvoir mieux comprendre ce qui se dit dans notre travail.

? Le Deuxième chapitre est « Etude préliminaire et capture des besoins fonctionnels » à ce niveau : Pour l'Etude Préliminaire, nous allons présenter le projet, recueillir les besoins fonctionnels, faire le choix technique, identifier les acteurs, identifier les messages enfin faire la modélisation du contexte. Pour la Capture des besoins fonctionnels, nous allons déterminer les cas d'utilisation, faire la description préliminaire des cas d'utilisation, faire la description détaillée des cas d'utilisation, faire la structuration des cas d'utilisation dans des packages, enfin identifier les classes candidates.

? Le Troisième chapitre s'intitule « Analyse et Conception du système informatique ». Lors de l'analyse, nous allons faire le Découpage en catégories, la Dépendance entre catégories, le Diagramme du package d'analyse, le Développement du modèle statique, enfin le Développement du modèle dynamique. A la conception, nous allons faire l'Architecture de l'application et la Construction de la base de données relationnelle.

11

? Le quatrième chapitre s'appelle « Implémentation » ; cette étape portera sur le développement du site web pouvant permettre aux attentes des personnels enseignants et membres du jury d'effectuer leurs taches, et aux étudiants d'être à jour avec leurs résultats.

12

CHAPITRE PREMIER : DEFINITION DES CONCEPTS ET
CONSIDERATION THEORIQUE

I.1. INTRODUCTION

Aucun travail scientifique ne peut dépasser ce cadre conceptuel, car : la science évolue, les langues aussi. La définition des concepts facilite la mise en lumière, de la précision des énoncés contenus dans le sujet. Les mots sont polysémiques, ceci veut dire qu'un même terme peut avoir plusieurs significations selon le contexte où il est placé, selon les auteurs, selon les objectifs poursuivis et selon les domaines. C'est pourquoi, pour éviter toute confusion, toute mauvaise interprétation nous définissons ci-dessous les concepts clés de notre sujet tels que nous les entendons dans le présent travail.

Pour les considérations théoriques, nous allons voir comment débuter le déroulement d'un projet avec le processus 2TUP, et en se basant sur son formalisme et ses principes.

I.2. DEFINITION DES CONCEPTS

I.2.1. Les concepts clés

Notre sujet est constitué de sept (7) mots clés, qui sont : conception de site web, implémentation de site web, site web, publication des résultats, résultat, étudiant, institution universitaire.

? Conception d'un site web

La conception de site web ou web design est la conception de l'interface web : l'architecture interactionnelle, l'organisation des pages, l'arborescence et la navigation dans un site web¹⁴. La conception d'un design web tient compte des contraintes spécifiques du support Internet, notamment en termes d'ergonomie, d'utilisabilité et d'accessibilité. La conception (design en anglais c'est la détermination du comment d'une application (par opposition à l'analyse qui spécifie le quoi). La conception permet d'étendre la représentation des diagrammes effectuée au niveau de l'analyse en y intégrant les aspects techniques plus proches des préoccupations physiques.

¹⁴ https://fr.m.wikipedia.org/wiki/Conception de site web consulté le 20/03/2021 à 13 : 54.

13

V Implémentation d'un site web

Autrement appelée la phase de réalisation, c'est la création des pages web (mise en place du contenu, des photos) et la conformité aux standards du web (W3C), intégration de la charte graphique.¹⁵

V Site web

Un site web est un ensemble de pages web hyper liées entre elles et accessibles à une adresse web. On dit aussi site internet par métonymie, le world wide web reposant sur internet¹⁶. Nous allons entrer en profondeur sur ce concept au point suivant (définition des concepts de la technologie du web).

V Publication des résultats

La publication est l'action de publier, de rendre publique. Publier est la façon de faire connaitre au public, rendre public par la parole, par des écrits ; annoncer, déclarer publiquement. La publication des résultats des étudiants est le processus de rendre accessible ou de mettre à la portée de ces derniers ses résultats.

V Résultat

Les résultats d'apprentissage se définissent comme une description des compétences, des aptitudes ou des habiletés que les étudiants détiennent à la fin du programme.¹⁷

V Etudiant

Le mot étudiant est comme étant une personne qui fait des études supérieures et suit les cours d'une université, d'une grande école.¹⁸

V Institution universitaire

Communément appelée Université, est une institution d'enseignements supérieurs, d'études et de recherches, constituée par la réunion de divers établissements nommés suivant les traditions "collèges" ou " facultés", "instituts", "départements", "centres", "sections", "unités" ou écoles spécifiques, mais aussi une bibliothèque ou atelier, médiathèque ou musée... formant un

¹⁵ Thierry Dubois, Tout pour réussir son site web, Tome2, Edition 2011, Paris, p34.

16 http://www.initiationreseau.com consulté le 20/03/2021 à 13:43.

¹⁷ https://saea.uottawa.ca/site/resultats-d-apprentissage-des-programmes consulté le 20/03/2021 à 14:03.

¹⁸ https://dictionnaire.lerobert.com/definition/etudiant consulté le 20/03/2021 à 14:10.

¹⁹ https://fr.m.wikipedia.org/wiki/Universit%C3%A9 consulté le 20/03/2021 à 14:30.

²⁰ Bruno Pouliquen, Cours de HTML, Université de Renne1, Inédit, Rennes, p.2

14

ensemble administratif cohérant avec un statut de droit défini, public, privé ou éventuellement mixte.¹⁹

I.2.2. Les concepts de la technologie du Web

Voici quelques concepts dont nous allons définir en clair pour partager le même langage lors du développement de site (en guise de la meilleure compréhension du développement d'un site web) : web, URL, protocole, page web, application web, site web, serveur Web, Client web, CMS, CGI, Framework, hébergeur, Ports d'Ecoute et protocoles.

Web, URL et Protocole

Le berceau du Web se situe au CERN (Organisation Européenne pour la Recherche Nucléaire). C'est au sein de cette organisation que le Web fut inventé en 1989 par une équipe de chercheurs notamment sous l'impulsion de Tim Berners-Lee et son collaborateur Robert Cailliau, ainsi que d'autres chercheurs ayant à leur manière collaborée au projet initialement baptisé World Wide Web. À l'origine le projet World Wide Web fut conçu et développé "en combinant trois technologies qui sont les éléments de base du Web, c'est-à-dire, l'adressage web par URL qui indique la localisation de la ressource sur l'internet, le protocole de transfert HTTP qui indique la méthode d'accès, et le Hypertexte Markup langage HTML qui permet de structurer des ressources" afin que les personnes travaillant dans les universités et les instituts du monde entier puissent librement échanger des documents et partager les informations utiles à leurs activités, tissant ainsi la première toile (en anglais : Web) sur le Net.

Le WWW Permet d'accéder à une masse gigantesque d'informations distantes ; Chaque individu peut y mettre les informations qu'il désire ; Le succès du Web : accès ergonomique et facile à une masse de données colossale et variée²⁰.

Figure 1.1 : WWW

15

Page web

La page web désigne l'unité élémentaire d'un site web, lui-même constitué d'un nombre plus ou moins important de pages web. Pour les internautes, la page web est accessible via un navigateur web (par exemple Firefox, Mozilla, Safari, etc.).

Sur le plan technique, la page web se résume la plupart de temps à un fichier HTML et un ensemble d'autres ressources indépendantes du World Wide Web comme des images, des vidéos, des sons, des animations, etc.²¹

Application web

En informatique, une application web est une application manipulable grâce à un navigateur web. De la même manière que les sites, une application web est généralement placée sur un serveur et se manipule en actionnant des widgets à l'aide d'un navigateur web, via un réseau informatique²².

Site web

? Catégories de site web :

On distingue habituellement plusieurs catégories de sites web, selon le but poursuivi :

? Site carte de visite : appelé également site vitrine ou site plaquette : il présente une information institutionnelle (produits ou services d'une entreprise).

? Site événementiel : il est dédié à la sortie d'un produit, à un jeu concours, à un événement (coupe de monde de rugby, salon professionnel, ...). Il est consacré exclusivement à ce sujet. Il ne comporte pas d'élément institutionnel ou catalogue, ou alors seulement en rappel ou propose un lien vers un autre site. Il appartient à la catégorie des sites dédiés, dans lequel trouver également les sites produits dédiés à un seul produit ou à une gamme.

? Site de contenu : il n'est pas forcément marchand. Il présente un volume de contenu plus ou moins important qu'il convient. Il demande souvent des développements spécifiques pour présenter, lier, gérer cette information.

? Site de communication : il est dédié aux outils de communication et d'échanges avec l'internaute et utilise des fonctionnalités telles que newsletter, forum, blog.

²¹ https://www.journaldunet.fr/web-techn/dictionnaire-du-webmastering/1203265-page-web-definition/ consulté le 24/03/2021 à 12:05.

22 http://fr.wikipedia.org/wiki/application-web consulté le 24/03/2021 à 12:20.

16

+ Site catalogue : il propose le catalogue de l'entreprise en ligne. Il peut s'agir de la consultation du catalogue « papier » avec pages qui se tournent par exemple ou d'une construction similaire à un site marchand sans paiement en ligne.

+ Site marchand ou site boutique : il consiste en un site catalogue avec une ou des solutions de commande et de paiement en ligne : paiement bancaire sécurisé, papal, chèque, virement.

+ Site de type intranet ou extranet avec accès privé (identifiant, mot de passe) : il peut être simple et présenter une liste de tarifs ou très complexes avec des accès réservés par catégories de collaborateurs (ou de clients ou de revendeurs), de multiples fonctionnalités et développements spécifiques pour calculer des commissions sur vente, établir des notes de frais, etc.

+ Site « sur mesure » : il peut reprendre des éléments de chaque type. Il désigne le site qui demande des développements informatiques spécifiques sur-mesure, adaptés de modules existants ou crées de toute pièce.

+ Site de e-Learning : il présente des modules d'information ou de formation, des tutoriaux ou des animations de formation accessibles à distance. L'interactivité avec l'apprenant est plus ou moins développée. Il est doté ou non d'un extranet à destination des formateurs (par exemple).

+ Site d'animation ou de jeux : il est parfois lié au site événementiel. Trouver des jeux en ligne simples ou très sophistiqués par exemple.

+ Site en Flash : il désigne en réalité d'avantage une technologie qu'un type de site. En effet, chacun des types de sites décrits ci-dessus peut être réalisé en Flash. Pour certains les inconvénients pourront être nombreux (site marchand), pour d'autres, l'utilisation de cette technologie se justifiera complètement (site de jeux).

Il existe deux types de sites web :

· Les sites statiques : leur contenu ne peut pas être mis à jour automatiquement. Ce sont des sites réalisés uniquement à l'aide des langages HTML et CSS.

			Figure 1-2 Site web statique

17

· Les sites dynamiques : Le contenu de ces sites web est dit « dynamique » parce qu'il peut changer. Plus complexes, ils utilisent d'autres langages en plus de HTML et CSS, tels que PHP et MySQL²³.

Lorsque le site est dynamique : Le client demande au serveur à voir une page web ; Le serveur

prépare la page spécialement pour le client ; Le serveur lui envoie la page qu'il vient de générer.

Figure 1-3 site web dynamique

Serveur Web

Un serveur est un ordinateur ou un dispositif connecté en permanence à Internet dont le rôle est de servir, comme son nom l'indique, de données à celui qui en demande. Il peut toutefois être aussi déployé en local. Ce demandeur peut être un autre serveur ou l'ordinateur d'un utilisateur final. Les données servies peuvent être de toute nature : sons, images, vidéos, textes, résultats mathématiques. Un serveur est localisé sur Internet par son adresse IP.²⁴

Serveur

www.unikam.org

Serveur
www.autre.com

Serveur web ( Apache )

Routeur

Internet

Réseau ethernet

Mac

PC

Client web ( netscape )

Figure 1-4: Serveur web

²³ www.coursgratuit.com/cours/php/php-4 consulté le 23/03/2021 à 13:11.

²⁴ Jean François PILLOU et Fabrice LEMANIQUE, Tout sur les réseaux et internet, éd. Dunod, Paris, 2012-2015, p.20.

18

Client web

Dans un réseau informatique, un client est le logiciel qui envoie les demandes à un serveur. Il peut s'agir d'un logiciel manipulé par une personne, ou d'un robot. Est appelé aussi client, l'ordinateur depuis lequel les demandes sont envoyées vers un serveur. Dans le web, il s'agit d'un navigateur (par exemple Mozilla, Firefox, Internet Explorer, Opera Mini, Safari, ...).

Système de Gestion de Contenu

On appelle Content Management System, ou en abrégé CMS, un Système de Gestion de Contenu. Le principe consiste à séparer le code, le design et le contenu (appel de la base de données). Le plus souvent, les CMS (comme Joomla, Typo3...) utilisent une base de données MySQL, et le PHP (accepté par la plupart des hébergeurs) pour intégrer la base de données. Cela permet donc d'éditer et de gérer un site vraiment complet et dynamique (gestion de membres, d'articles, de téléchargements, de sondages, de liens, de forums...).²⁵

Figure 1-5: Les CMS Common Gateway Interface

On appelle Common Gateway Interface, ou en abrégé CGI, une interface, utilisée par les serveurs HTTP, qui permet de générer la réponse du serveur par un programme, qui s'exécute sur le serveur. Le programme pourra, assez typiquement, générer du code HTML qui sera affiché par un navigateur côté client. L'interface CGI est indépendante du langage de programmation utilisée par le serveur, et n'utilise que les flux standards et les variables d'environnement.²⁶

Framework

Un Framework est un ensemble d'outils qui simplifie le travail d'un développeur. Traduit littéralement de l'anglais, un Framework est un « cadre de travail ». Il apporte les bases communes à la majorité des programmes ou des sites web. Celles-ci étant souvent identiques (le fonctionnement d'un espace membres est commun à une très grande majorité de sites web de nos jours), un développeur peut les réutiliser simplement et se concentrer sur les

²⁵ Thierry Dubois, op.cit., p15.

²⁶ Rémy Malgouyres, Programmation Web en PHP, Conception, Architectures et Développement de Web Services, département info, Université Clermont Auvergne, inédit, p.7.

19

particularités de son projet. Il s'agit donc d'un ensemble de bibliothèques coordonnées, qui permettent à un développeur d'éviter de réécrire plusieurs fois une même fonctionnalité, et donc d'éviter de réinventer constamment la roue.²⁷

L'objectif premier d'un Framework est d'améliorer la productivité des développeurs qui l'utilisent. Souvent organisé en différents composants, un Framework offre la possibilité au développeur final d'utiliser tel ou tel composant pour lui faciliter le développement, et lui permet ainsi de se concentrer sur le plus important.²⁸ Voici quelques-uns : Bootstrap, Bulma, Django, Symphony, Zend, Laravel, Phalcon, CakePHP, Yii, slim, etc.

Figure 1-6: Les Framework web

Hébergeur web

Un hébergeur web (ou hébergeur internet) est une entité ayant pour vocation de mettre à la disposition des internautes des sites web conçus et gérés par des tiers. Il donne ainsi accès à tous les internautes au contenu déposé dans leurs comptes par les webmestres souvent via un logiciel FTP ou un gestionnaire de fichiers. Pour cela, il maintient des ordinateurs allumés et connectés 24 heures sur 24 à Internet (des serveurs web par exemple) par une connexion à très haut débit (plusieurs centaines de Mb/s), sur lesquels sont installés des logiciels : serveur HTTP (souvent Apache), serveur de messagerie, de base de données. Ex : OverH, HostGator, ...

Ports d'Ecoute et protocoles

Le client et le service utilisent un langage spécial pour dialoguer entre eux, ce langage spécial est appelé Protocole. De plus, les ordinateurs échangent entre eux grâce à leurs adresses IP. Mais comme il peut y avoir plusieurs services sur un même serveur : C'est ici qu'entre en jeu une nouvelle notion : les Ports (canal de communication, souvent numéro. Ex : FTP : 80). Le protocole est un langage spécifique à un type de service ; il permet le dialogue entre le logiciel client et le logiciel serveur.²⁹

²⁷Ssx'z et MATHX, Développez votre site web avec le framework Django, inédit, 12 août 2019, p.9.

²⁸Alexandre Bacco, Développez votre site web avec le framework Symfony2, Ed. Dassault Systems, Paris 2013, p.9.

²⁹ Bertin LOBO MINGA, Cours de QSCSI, L2CSI, UNIKAM, inédit, 2020-2021, p.8.

20

I.3. CONSIDERATIONS THEORIQUES ET METHODOLOGIQUES

I.3.1. PROCESSUS DE DEVELOPPEMENT LOGICIEL

Un processus définit une séquence d'étapes, en partie ordonnées, qui concourent à l'obtention d'un système logiciel ou à l'évolution d'un système existant.

L'objet d'un processus de développement (de l'Anglais Software Process) est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles. En conséquence, le processus peut se décomposer suivant deux axes de contrôle sur le développement :

? L'axe de développement technique, qui se concentre principalement sur la qualité de la production ;

? L'axe de gestion du développement, qui permet la mesure et la prévision des coûts et des délais.³⁰

Ce qu'il faut aimer pour modéliser :

- Être à l'écoute du monde extérieur,

- Dialoguer et donc communiquer avec les gens (qui utiliseront le système informatique), - Observer et expérimenter : une conception n'est jamais bonne du premier coup,

- Travailler sans filet : créer quelque chose avec très peu de recettes toutes prêtes,

- L'abstraction : une carte routière est un modèle du territoire ; ce n'est pas le territoire

lui-même,

- Le travail à plusieurs : contribuer à l'intérieur d'un projet collectif - aller au résultat : en
plus il faut que ça marche !31

A) PRESENTATION DU PROCESSUS UNIFIE (UP)

Un processus unifié est un processus de développement logiciel construit sur UML ; il est itératif et incrémental, centré sur l'architecture, conduit par les cas d'utilisation et piloté par les risques.

Ses activités de développement sont définies par 6 disciplines fondamentales qui décrivent la modélisation métier, la capture des besoins, l'analyse et la conception, l'implémentation, le test et le déploiement.

³⁰ Pascal Roques et Franck vallée, UML 2 en action de l'analyse des besoins à la conception, 4^e édition, Eyrolles, Paris, février 2007, p.12 ;

³¹ Michel EBOUEYA, Analyse et Conception des Systèmes d'Information, Cours Inédit, Université de la Rochelle, Département de Systèmes d'Information, Douala, 2008, p.4.

21

a. Les principes du Processus Unifié (UP)

· Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1 mois) qui aident à mieux suivre l'avancement global. À la fin de chaque itération, une partie exécutable du système final est produite, de façon incrémentale.

· Centré sur l'architecture : tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution facilitées. Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas seulement documentée en texte.

· Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l'ordre des itérations.

· Conduit par les cas d'utilisation : le projet est mené en tenant compte des besoins et des exigences des utilisateurs. Les cas d'utilisation du futur système sont identifiés, décrits avec précision et priorisés.³²

Figure 1-7: Principes du Processus Unifié

b. Les phases du Processus Unifié (UP)

La gestion d'un tel processus est organisée d'après les 4 phases suivantes : préétude (ou Inception ou initialisation), élaboration, construction et transition.

La phase d'initialisation conduit à définir la « vision » du projet, sa portée, sa faisabilité, son business case, afin de pouvoir décider au mieux de sa poursuite ou de son arrêt.

La phase d'élaboration poursuit trois objectifs principaux en parallèle :

· Identifier et décrire la majeure partie des besoins des utilisateurs,

· Construire l'architecture de base du système,

· Lever les risques majeurs du projet.

³² Pascal Roques, Les Cahiers du programmeurs UML2 modéliser une application web, 4^e Edition, Eyrolles, Paris, 2007, p.9.

22

La phase de construction consiste surtout à concevoir et implémenter l'ensemble des éléments opérationnels (autres que ceux de l'architecture de base). C'est la phase la plus consommatrice en ressources et en effort.

Enfin, la phase de transition permet de faire passer le système informatique des mains des développeurs à celles des utilisateurs finaux.

Figure 1-8: Les phases du Processus Unifié

B) LES METHODES AGILES

Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling, noté AG) visent à réduire le cycle de vie du logiciel en développant une version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des tests tout au long du cycle de développement.

Les méthodes agiles prônent quatre valeurs fondamentales (entre parenthèse, les citations du manifeste) :

· L'équipe (« Personnes et interaction plutôt que processus et outils »).

· L'application (« Logiciel fonctionnel plutôt que documentation complète »).

· La collaboration (« Collaboration avec le client plutôt que négociation de contrat »).

· L'acceptation du changement (« Réagir au changement plutôt que suivre un plan »). Parmi les méthodes agiles, nous distinguons 2TUP, RUP (Rational Unified Process) et XP (eXtreme Programming).

23

C) PRESENTATION DE 2TUP (Two Truck Unified Process)

Two Track Unified Process, Instanciation de UP proposé par Valtech prenant en compte les aléas et contraintes liées aux changements perpétuels et rapides des SI des entreprises.

L'axiome fondateur du 2TUP consiste à constater que toute évolution imposée au système d'information peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un axe technique.³³

La branche gauche (branche fonctionnelle) comporte .

· La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système inadapté aux utilisateurs. De son côté, la maîtrise d'oeuvre consolide les spécifications et en vérifie la cohérence et l'exhaustivité l'analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en termes de métier. Les résultats de l'analyse ne dépendent d'aucune technologie particulière.

La branche droite (architecture technique) comporte .

· La capture des besoins techniques, qui recense toutes les contraintes et les choix dimensionnant la conception du système. Les outils et les matériels sélectionnés ainsi que la prise en compte de contraintes d'intégration avec l'existant conditionnent généralement des prérequis d'architecture technique ;

· La conception générique, qui définit ensuite les composants nécessaires à la construction de l'architecture technique. Cette conception est la moins dépendante possible des aspects fonctionnels. Elle a pour objectif d'uniformiser et de réutiliser les mêmes mécanismes pour tout un système. L'architecture technique construit le squelette du système informatique et écarte la plupart des risques de niveau technique. L'importance de sa réussite est telle qu'il est conseillé de réaliser un prototype pour assurer sa validité.

La branche du milieu comporte :

· La conception préliminaire, qui représente une étape délicate, car elle intègre le modèle d'analyse dans l'architecture technique de manière à tracer la cartographie des composants du système à développer ;

· La conception détaillée, qui étudie ensuite comment réaliser chaque composant ;

· L'étape de codage, qui produit ces composants et teste au fur et à mesure les unités de code réalisées ;

³³ Pascal Roques et Franck Vallée, op.cit., p.13

³⁴ Laurent DEBRAUWER et Fien VAN DER HIERDE, UML 2 Initiation, exemples et exercices corrigés, 2ième Edition, ENI Editions, Parsi, 2004, p.9.

24

· L'étape de recette, qui consiste enfin à valider les fonctions du système développé.

Figure 1-9: Le processus de développement en Y

I.3.2. LES LANGAGES DE MODELISATION

A) PRESENTATION DU LANGAGE UNIFIE DE MODELISATION (UML)

UML (Unified Modeling Language) est basé sur l'approche par objets. Il est un langage graphique destiné à la modélisation de systèmes et de processus. Simula, le tout premier langage à objets est né dans les années 1960. Ce langage connaît de nombreux successeurs : Smalltalk, C++, Java ou plus récemment C#.

UML est unifié car il provient de plusieurs notations qui l'ont précédé. Aujourd'hui, UML est promu par l'OMG (Object Management Group), un consortium de plus de 800 sociétés et universités actives dans le domaine des technologies de l'objet. OMG définit UML comme étant un langage visuel dédié à la spécification, la construction et la documentation des artefacts d'un système logiciel.

Dans les années 1980 et au début des années 1990, les notations graphiques se multiplient, chacun utilisant bien souvent sa propre notation. En 1994, James Rumbaugh et Grady Booch décident de se regrouper pour unifier leurs notations. Celles-ci provenaient de leurs méthodes : OMT pour James Rumbaugh et méthode Booch pour Grady Booch. En 1995, Yvar Jacobson décide de rejoindre l'équipe des "trois amigos". Cette équipe travaille alors au sein de Rational Software.³⁴

³⁵ Joseph Gabay et David Gabay, UML 2 analyse et conception (mise en oeuvre guidée avec étude de cas), Ed. Dunod, Paris, 2008, p.26.

25

Les grandes étapes de la diffusion d'UML peuvent se résumer comme suit :

1994-1996 : rapprochement des méthodes OMT, BOOCH et OOSE et naissance de la

première version d'UML.

23 novembre 1997 : version 1.1 d'UML adoptée par l'OMG.

1998-1999 : sortie des versions 1.2 à 1.3 d'UML.

2000-2001 : sortie des dernières versions suivantes 1.

2002-2003 : préparation de la V2.

10 octobre 2004 : sortie de la V2.1.

5 février 2007 : sortie de la V2.1.1.

2008 : sortie de la V2.2.

Octobre 2012 : sortie de la V2.5.

UML dans sa version 2.2 propose quatorze diagrammes qui peuvent être utilisés dans la description d'un système. Ces diagrammes sont regroupés dans deux grands ensembles.³⁵

· Les diagrammes structurels ou statiques : Ces diagrammes, au nombre de sept (7), ont vocation à représenter l'aspect statique d'un système (classes, objets, composants...).

- Diagramme de classe : Ce diagramme représente la description statique du système en intégrant dans chaque classe la partie dédiée aux données et celle consacrée aux traitements. C'est le diagramme pivot de l'ensemble de la modélisation d'un système.

- Diagramme d'objet : Ce diagramme permet la représentation d'instances des classes et des liens entre instances.

- Diagramme de composant : Ce diagramme représente les différents constituants du logiciel au niveau de l'implémentation d'un système.

- Diagramme de déploiement : Ce diagramme décrit l'architecture technique d'un système avec une vue centrée sur la répartition des composants dans la configuration d'exploitation.

- Diagramme de paquetage : Ce diagramme donne une vue d'ensemble du système structuré en paquetage. Chaque paquetage représente un ensemble homogène d'éléments du système (classes, composants...).

- Diagramme de structure composite : Ce diagramme permet de décrire la structure interne d'un ensemble complexe composé par exemple de classes ou d'objets et de composants techniques. Ce diagramme met aussi l'accent sur les liens entre les sous-ensembles qui collaborent.

26

- Diagramme de profils : depuis la version 2.5 d'UML datant d'octobre 2012, permet de spécialiser, de personnaliser pour un domaine particulier un Métamodèle de référence d'UML.

· Les diagrammes de comportement : Ces diagrammes représentent la partie dynamique d'un système réagissant aux événements et permettant de produire les résultats attendus par les utilisateurs. Sept (7) diagrammes sont proposés par UML :

- Diagramme des cas d'utilisation : Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans l'analyse d'un système.

- Diagramme d'état-transition (machine d'état) : Ce diagramme montre les différents états des objets en réaction aux événements.

- Diagramme d'activités : Ce diagramme donne une vision des enchaînements des activités propres à une opération ou à un cas d'utilisation. Il permet aussi de représenter les flots de contrôle et les flots de données.

- Diagramme de séquence : Ce diagramme permet de décrire les scénarios de chaque cas d'utilisation en mettant l'accent sur la chronologie des opérations en interaction avec les objets.

- Diagramme de communication (anciennement appelé collaboration) : Ce diagramme est une autre représentation des scénarios des cas d'utilisation qui met plus l'accent sur les objets et les messages échangés.

- Diagramme global d'interaction : Ce diagramme fournit une vue générale des interactions décrites dans le diagramme de séquence et des flots de contrôle décrits dans le diagramme d'activités.

- Diagramme de temps : Ce diagramme permet de représenter les états et les interactions d'objets dans un contexte où le temps a une forte influence sur le comportement du système à gérer.

27

I.3.3. THEORIE SUR L'IMPLEMENTATION ET LA PROGRAMMATION

A. BASE DE DONNEES ET SYSTEME DE GESTION DE BASE DE DONNEES

4 BASE DE DONNEES (Database)

Une Base de données (BDD en sigle) est un ensemble structuré des données conservées sur des supports accessibles par ordinateur afin de les utiliser pour répondre aux besoins d'un ou des plusieurs utilisateurs dans un système d'information au moment opportun³⁶.

L'histoire des bases de données

L'histoire des bases de données remonte aux années 1960, avec l'apparition des bases de données réseau et des bases de données hiérarchiques. Dans les années 1980, ce sont les bases de données object-oriented qui ont fait leur apparition. Aujourd'hui, les bases de données prédominantes sont les SQL, NoSQL et bases de données cloud.

Il est aussi possible de classer les bases de données en fonction de leur contenu : bibliographique, textes, nombres ou images. Toutefois, en informatique, on classe généralement les bases de données en fonction de leur approche organisationnelle. Il existe de nombreux types de bases de données différentes : relationnelle, distribuée, cloud, NoSQL...

Voici les différents types de bases de données

Les différents types de bases de données : bases de données hiérarchiques, bases de données réseau, bases de données orientée texte ou flat file database, bases de données relationnelles, bases de données distribuées, bases de données cloud, bases de données NoSQL, bases de données orientée objets, base de données orientée graphe.³⁷

4 SYSTEME DE GESTION DE BASE DE DONNEES (Database Management

System)

Le logiciel qui permet à un utilisateur d'interagir avec une base de données est un système de gestion de base de données (SGBD). Il permet principalement d'organiser les données sur les supports périphériques (Disque dur par exemple) et fournit les procédures de recherche et de sélection de ces mêmes données. Pour aboutir à ce résultat, l'utilisateur décrit en termes abstraits ce qu'il souhaite faire sur les données, laissant le soin au système d'effectuer

³⁶ C.T. Elie Louis KABWE KIONDE KABUTA, cours de MAI1, G2 INFO, UNIKAM, 2017-2018, inédit.

³⁷ https://www.lebigdata.fr/base-de-donnees consulté le 24/03/2021 à 19:19.

28

les tâches de recherche en fonction de la représentation et de l'organisation des données sur les supports physiques. Ce ne sont pas les seules fonctions que doit assurer un SGBD.³⁸

L'histoire de système de gestion de base de données

Le terme DataBase est de plus en plus utilisé comme abréviation pour DataBase Management System. Il existe beaucoup de DBMS différents. Certains sont des petits systèmes pouvant être lancés sur un ordinateur personnel, d'autres sont d'énormes systèmes nécessitant un mainframe.

Les DBMS ont été inventés dans les années 1960 pour prendre en charge les bases de données hiérarchiques. Les premiers systèmes étaient organisés de façon séquentielle (alphabétiquement, numériquement, ou chronologiquement). Il a fallu attendre l'apparition des appareils de stockage à accès direct pour pouvoir accéder aux données aléatoirement par le biais d'index. Parmi les DBMS les plus connus, on compte le IBM Information Management System, Microsoft office Access et le CA Integrated DataBase Management System.

Un RDBMS est un Relational DataBase Management System (système de gestion de base de données relationnel). Ce type de logiciel a été développé dans les années 70 en se basant sur le modèle relationnel. Encore aujourd'hui, il demeure la façon la plus populaire de gérer une BDD. Les RDBMS les plus connus sont Microsoft SQL Server, PostgreSQL, Informix, Oracle DataBase, IBM DB2 et MySQL.

B. LANGAGE DE PROGRAMMATION

Pour pouvoir développer des logiciels de qualité, vous avez besoin d'acquérir des connaissances et des compétences dans des domaines autres que les technologies de programmation, notamment le processus d'ingénierie, la méthodologie de développement, les exigences, la modélisation, la conception, le test, la gestion de projets, etc.

Un langage de programmation est comme un langage humain. Il y a un ensemble de lettres avec lesquelles on forme des mots. Les mots forment des phrases, les phrases des paragraphes, ceux-ci forment des chapitres qui se rassemblent et qui donnent naissance à un livre. C'est aussi un ensemble de signes et de conventions afin de permettre à la machine (ordinateur) de comprendre ce que l'homme veut donner comme ordre à exécuter.³⁹

³⁸ C.T. Elie Louis KABWE KIONDE KABUTA, Cours d'Introduction aux Bases de Données, G2 INFO, UNIKAM, 2017-2018, p.6.

³⁹ Dr. Daily KALOMBO NSHIMBA VIDJE, Cours de Langage de Programmation Orienté Objet, G3 Informatique, UNIKAM, 2018-2019, Dispensé par Ass. Prince KABONGO.

29

Par-là, pour réaliser des actions que l'ordinateur doit exécuter, il existe plusieurs langages de programmations tels que : l'assembleur (ASM), le Cobol, le BASIC, le JAVA, le C/C++/C#, le Pascal, le Visual Basic, le Delphi, les langages du web (HTML, CSS, Java Script, PHP, SQL), le flash.

Le développement des logiciels consiste à étudier, concevoir, construire, transformer, mettre au point, maintenir et améliorer des logiciels. Un logiciel est créé petit à petit par une équipe d'ingénieurs conformément à un cahier des charges établi par un client demandeur ou une équipe interne. Le logiciel est décomposé en différents modules et un chef de projet, ou architecte, se charge de la cohérence de l'ensemble.

Quelles plateformes de développement web choisir ?40

Les façons de développer en web sont aussi variées que complexes, mais toutes ont un seul but, générer une page de code HTML liée à une feuille de style CSS et à un fichier Javascript. Chaque technique possède ses avantages et inconvénients. Chaque développeur trouvera la solution qui lui conviendra le mieux. Voici comment s'y retrouver :

? Langages côté serveur

Afin de comprendre comment les plateformes web fonctionnent, il faut comprendre les langages de programmation installé sur le serveur tel que PHP, ASP et JSP. Ceux-ci permettent de créer des applications web dynamiques en insérant des variables dans une page HTML. L'ASP, avec sa licence Microsoft, est largement répandu car il permet de programmer des applications complexes et il est inclus dans presque toutes les versions de Windows. Son principal compétiteur est PHP. Gratuit et très performant, il est simple d'utilisation et les tutoriels abondent pour en comprendre les rouages. Finalement, JSP, développé par SUN Microsystem permet d'insérer du code Java dans des pages HTML afin de rendre l'application dynamique. Gratuit également, il est très performant mais assez complexe.

? Plateformes de développement

Une plateforme de développement a pour but de faciliter la tâche des développeurs en fournissant une librairie de fonctions pouvant être exécutées à l'aide de variables à l'intérieur de pages HTML. ASP .NET est la plateforme web principale fonctionnant à l'aide d'un serveur

⁴⁰ https://exob2b.com/plateformes-developpement-web/ consulté le 24/03/2021 à 23:03.

30

programmé en ASP. Cette plateforme permet une interopérabilité de tous les langages de programmation développés par Microsoft.

Parce qu'elles sont gratuites, les plateformes de développement en PHP abondent. Codeignitor, Symfony ou Cake PHP sont les plus populaires. Flexibles et simples d'utilisation, les plateformes PHP sont une bonne option pour développer des applications web complètes et efficaces.

Même principe sous JSP, où on retrouve plusieurs plateformes tel que Java SE ou AppFuse. Les plateformes de développement, quel que soit le langage, ont de nombreux atouts et facilitent la vie des développeurs.

Toutefois, le temps de développement nécessaire au déploiement de l'application sera directement proportionnel à la quantité de fonctions à programmer car ceux-ci n'offrent qu'une boîte à outil pour programmer. Cette solution sera donc développée exactement selon les besoins de client.

Il y a de nombreuses solutions, et il y en aura forcément une adaptée à vos besoins. Un facteur commun demeure, le temps. Et celui-ci influencera toujours votre décision !

31

CONCLUSION PARTIELLE

La seule contrainte morale que la théorie impose dès lors au modélisateur est celle d'une vérification a priori : a-t-il explicité les quelques axiomes sur lesquels il va, progressivement, appuyer ses inférences et graver son dessin ? Mais il doit choisir, librement, cette axiomatique, d'où la nécessité de tout ce qu'on a dit dans le premier chapitre (définir les concepts clés constituant le thème, définir les concepts de la technologie du web (site web, www, URL, port, etc.), quelques théories sur le développement logiciel, la présentation d'UP, 2TUP, UML enfin la théorie sur l'implémentation et la programmation).

32

CHAPITRE DEUXIEME : ETUDE PRELIMINAIRE ET CAPTURE DES
BESOINS FONCTIONNELS

II.1. INTRODUCTION

À ce niveau, nous allons entamer les premières étapes de la méthode 2TUP : Pour l'Etude Préliminaire, nous allons présenter le projet, recueillir les besoins fonctionnels, recueillir les besoins opérationnels, faire le choix technique, identifier les acteurs, identifier les messages enfin faire la modélisation du contexte. Pour la Capture des besoins fonctionnels, nous allons déterminer les cas d'utilisation, faire la description préliminaire des cas d'utilisation, faire la description détaillée des cas d'utilisation, faire la structuration des cas d'utilisation dans des packages, enfin identifier les classes candidates.

II.2. ETUDE PRELIMINAIRE

L'étude préliminaire (ou préétude) est la toute première étape de notre processus de développement. Elle consiste à effectuer un premier repérage des besoins fonctionnels et opérationnels, en utilisant principalement le texte, ou des diagrammes très simples. Elle prépare les activités plus formelles de capture des besoins fonctionnels et de capture des besoins techniques.⁴¹

A ce niveau, nous allons présenter le sujet de l'étude de cas l'UNIKAM, et commencer la modélisation de son contexte.

					Figure 2-1: Situation de l'étude préliminaire dans 2TUP

⁴¹ Pascal Roques et Franck Vallée, op.cit., p.45

33

II.2.1. PRESENTATION DU PROJET

L'Université de Kamina est un établissement public possédant en son sein plus ou moins 3000 étudiants. Du point de vue de l'organisation des examens : l'année académique se divise en deux semestres de 15 semaines chacun. Cette répartition permet une gestion rationnelle du temps des enseignements, des évaluations et est susceptible les chances de réussite des étudiants.

Nous souhaitons doter à cet établissement un système informatique (site web) performant afin de permettre la gestion de :

- Gestion des paiements des étudiants, qui va faciliter la caisse d'effectuer différents rapports et des opérations sur les paiements ;

- Contact des internautes ;

- Synchronisation des données sur une même grille des cotes ;

- Comptes des étudiants ;

- Recours des étudiants ;

- Les archives du jury pour chaque édition ;

- Publication des résultats des étudiants.

Parmi ces différentes tâches, nous relèverons l'enregistrement des informations relatives aux étudiants et enseignants, Grilles de côtes, lesquelles informations relèvent d'un processus à trois ordres : la consultation et la publication des résultats ainsi que la gestion des dossiers en termes des relevés des cotes des étudiants.

Comme tout projet qui doit avoir une durée de vie de l'élaboration, notre projet s'étend de Mars en Septembre 2021.

II.2.2. RECUEIL DES BESOINS FONCTIONNELS

En premier lieu, les besoins exprimés par les personnels administratifs du décanat de la faculté des sciences informatiques a permis afin qu'on établisse le cahier de charges. Cette phase correspond à une recherche sur le terrain pour bien définir le cadre de notre système afin de satisfaire les besoins des utilisateurs.

Elle permet d'obtenir un chiffrage au plus juste des devis lors d'un appel d'offre. Ce volet du cahier des charges décrit le périmètre couvert par le logiciel, c'est-à-dire les fonctions de l'entreprise impactées : saisie des épreuves, encodage des côtes, publication des résultats, etc. Elle décrit ensuite les fonctionnalités recherchées dans l'acquisition de l'outil informatique.

34

? Inventaire des fonctions

Une première phase consiste à lister l'ensemble des fonctions que l'outil doit couvrir. En fonction du budget, les applications identifiées ne pourront pas forcément couvrir l'ensemble des fonctionnalités souhaitées. Il faut donc hiérarchiser et prioriser les fonctions estimées nécessaires que voici :

Nom de la fonction	Description de la fonction
Saisie des examens	Le secrétaire devra saisir les examens des étudiants avant la session.
Encodage des cotes	Le secrétaire devra encoder les cotes d'une promotion où il est affecté.
Synchronisation des données	Le Webmaster devra donner à tout secrétaire un lien où ce dernier n'aura accès à la saisie que dans la promotion où il est affecté.
Conversion de la grille de délibération	Le jury devra télécharger le fichier sous format googlesheet et le convertir sous format PDF.
Inscription	Possibilité de s'inscrire, apporter des informations sur la fiche d'étudiant.
Recherche par mot clé	Recherche des résultats dans la base par mot clé.
Recherche par nom	Recherche des résultats par nom de l'étudiant.
Recherche par promotion	Recherche par promotion dans une année académique.
Affichage d'une liste de réponse après une recherche	Pouvoir voir la fiche à partir de cette liste de réponse.
Affichage d'une fiche	Voir la fiche.
Impression de la fiche	Imprimer la fiche
Prendre contact avec l'enseignant	Possibilité de prendre contact avec l'enseignant à partir d'un formulaire.
Destruction de la fiche	L'administrateur pourra détruire une fiche.
Publication des résultats	Le secrétaire du jury pourra publier les résultats des étudiants en ordre.
Production du rapport des différents paiements des étudiants	La caisse devra produire le rapport des différents paiements des étudiants et cela par faculté, par promotion, par date paiement, de toute l'université.
Impression des listes définitives	De par différents rapports, la caisse devra imprimer les listes des paiements des étudiants et cela par faculté, par promotion, par date paiement, de toute l'université.
...	...

Tableau 2-1: Inventaire des fonctions

35

II.2.3. CHOIX TECHNIQUES

Afin de maîtriser les risques, nous souhaitons utiliser une approche itérative et incrémentale, fondée sur le processus en Y.

Le choix d'un certain nombre de techniques clés pour ce projet stratégique sont principalement :

§ La modélisation objet avec UML ;

§ Avoir une base de données relationnelle unique partagée implémentée en MySQL pour le stockage de toutes les informations en rapport avec la publication des résultats des étudiants afin de permettre une manipulation et une mise à jour aisée de ladite base de données pour toutes les opérations effectuées ;

§ L'application devra fonctionner en mode 2 - tiers (client/serveur) ;

§ L'application doit être développée en utilisant les Framework CSS Boostrap et Bulma dans leurs dernières versions utilisant PHP 8.0.2 comme langage de programmation web ;

§ L'application doit respecter l'architecture MVC (Modèle-Vues-Contrôleur) ;

§ Le déploiement en client léger pour les fonctions les plus répandues ;

§ L'application doit être responsive c'est-à-dire l'affichage des interfaces devra s'adapter à chaque type d'écran sur lequel l'utilisateur consiste les informations de notre plateforme.

II.2.4. RECUEIL DES BESOINS OPERATIONNELS ? SECURITE

· Chaque utilisateur doit posséder un nom d'utilisateur et un mot de passe unique pour lui permettre d'accéder au site web ;

· Lors de sa connexion, chaque secrétaire doit être reconnu du système par un nom, un mot de passe et la fonction qu'il occupe (dans la promotion) ;

· Un client connecté via Internet doit également être identifié par un mot de passe et n'accéder qu'aux informations d'en-cours des résultats ou de recours qui le concernent ;

· Un administrateur système est chargé de définir les profils des utilisateurs ;

· L'application doit permettre de gérer les accès des utilisateurs selon un privilège et un état d'activation de chaque compte ;

· Il faut garantir la sécurité d'accès à l'espace administrateur pour protéger les données personnelles des utilisateurs ;

36

· Prévenir contre l'accès direct avec les liens URL et définir un délai de temps pour la fermeture de session non activé ;

· L'interface de ce site web doit être ergonomique, conviviale et même apte à aider l'utilisateur à mieux gérer son espace de travail.

? CARACTERISTIQUES DES UTILISATEURS

La plupart des utilisateurs (internautes et administrateurs) sont des utilisateurs lambda pas forcément aguerris à l'outil informatique, donc le site web se devait d'être le plus simple possible (très intuitif) et bien documenté (pas en langage de technicien).

? SAUVEGARDE DES DONNEES

Un plan de sauvegarde régulière des données sera mis en place, dans une deuxième phase d'évolution du produit, en cas de dysfonctionnement du serveur ou de destruction malveillante. Ce mécanisme pourra prendre plusieurs formes : une sauvegarde automatique sur le serveur à la déconnexion de l'administrateur, une sauvegarde automatique en local à l'ouverture de la partie administration et une sauvegarde manuelle dans le répertoire de son choix en cliquant simplement sur un bouton. Il faudra prévoir un bouton pour la restauration d'une sauvegarde.

? CONFIDENTIALITE

Le projet n'était pas classé « confidentiel » ou « secret défense » néanmoins les informations concernant l'institution ne devaient pas être communiquées à tierces personnes notamment les rapports de paiement, les grilles de côtes et de délibération pratiqués à l'Université et le fichier étudiants.

Une fois ce premier recueil de besoins effectué, la description du contexte du système peut commencer. Elle consiste en trois activités successives :

- l'identification des acteurs,

- l'identification des messages,

- la réalisation des diagrammes de contexte.

37

II.2.5. IDENTIFICATION DES ACTEURS

Un acteur représente une entité appartenant à l'environnement de l'application qui interagit avec l'application. Le concept d'acteur permet de classifier les entités externes à l'application. Un acteur est identifié par un nom.⁴²

Un acteur est la Construction qui représente un rôle joué par un utilisateur humain ou un autre système qui interagit directement avec le système étudié. Un acteur participe à au moins un cas d'utilisation.⁴³

Les acteurs suivants sont ceux qui interagissent avec le système informatique à développer :

? L'étudiant : C'est un acteur principal et déclencheur de l'application qui possède un espace d'authentification (un login et un mot de passe) pour pouvoir consulter ses résultats, introduire le recours, etc.

? Le Webmaster : a pour rôle de gérer : les comptes des utilisateurs, les vulnérabilités, les questionnaires, les recommandations et afficher l'historique des vulnérabilités. Il accède par l'intermédiaire d'un login et un mot de passe.

? La caissière : ajoute le paiement de l'étudiant, établit les listes définitives des étudiants en ordres avec les frais, et produit différents rapports de leurs paiements.

? Le secrétaire du jury : il a la gestion des résultats dans ses attributions (saisir, modifier, supprimer) et produit la statistique de la promotion où il est affecté, il a les tâches de publication.

? Le secrétaire Général Académique : il consulte différents rapports et statistiques sur les résultats des étudiants des différents jurys (validation des résultats), gérer les secrétaires des différents jurys (affectation, mis à jour et suppression de celle-ci).

II.2. 6. IDENTIFICATION DES MESSAGES

Un message représente la spécification d'une communication unidirectionnelle entre les objets, qui transporte de l'information avec l'intention de déclencher une activité chez le récepteur.

Un message est normalement associé à deux occurrences d'événements :

- un événement d'envoi,

- un événement de réception.

⁴² Xavier Blanc et Isabelle Mounier, UML2 pour les développeurs, Edition Eyrolles, Paris, 2007, p.99.

⁴³ Pascal Roques, UML2 par la pratique (Etudes de cas et exercices corrigés), 5^e édition, Ed. Eyrolles, Paris, 2006, p.341.

38

Nous allons décrire les interactions de plus haut niveau entre les acteurs et le système :

- Pour chaque acteur, identifier quels sont les messages qui déclenchent un comportement du système attendu par l'acteur dans le cadre de son activité.

- Pour le système, identifier quels sont les messages émis à l'intention d'un acteur particulier, et qui portent une information utilisée par ce destinataire.

§ Le système reçoit les messages suivants :

- Activer le système,

- Créer, modifier ou supprimer utilisateur,

- Gérer compte (modifier mot de passe),

- Ajouter paiement étudiant,

- Imprimer listes paiements,

- Créer, modifier ou supprimer secrétaire du jury,

- Affecter secrétaire du jury au jury de telle faculté,

- Consulter cotes,

- Publier résultats,

- Consulter statistiques résultats,

- Consulter résultats,

- Introduire recours,

- Valider, modifier ou supprimer résultats.

- Consulter recours,

- Affecter, mettre à jour ou supprimer secrétaire du jury...

§ Le système émet les messages suivants :

- Afficher écran Accès autorisé,

- Afficher liste utilisateurs,

- Afficher écran compte utilisateur,

- Afficher listes paiements,

- Afficher écran impression,

- Afficher listes secrétaires du jury,

- Afficher liste affectations,

- Afficher écran cotes étudiants,

- Afficher écran résultats,

- Afficher listes résultats,

- Afficher liste recours postés,

39

- Afficher liste résultats mis à jour.

- Afficher la liste des secrétaires du jury...

II.2.7. MODELISATION DU CONTEXTE

Tous les messages (système ? acteurs) identifiés précédemment peuvent être représentés de façon synthétique sur un diagramme, que l'on peut qualifier de diagramme de contexte dynamique. De notre part, nous allons illustrer le diagramme de contexte statique.

Figure 2-2: Diagramme de contexte statique du système de publication des résultats des étudiants de l'UNIKAM

II.3. CAPTURE DES BESOINS FONCTIONNELS

La capture des besoins fonctionnels est la première étape de la branche gauche du cycle en Y. Elle formalise et détaille ce qui a été ébauché au cours de l'étude préliminaire.

La technique des cas d'utilisation est la pierre angulaire de cette étape. Elle va nous permettre de préciser l'étude du contexte fonctionnel du système, en décrivant les différentes façons qu'auront les acteurs d'utiliser le futur système.⁴⁴

Nous verrons successivement à ce point comment :

? identifier les cas d'utilisation du système par ses acteurs, ? décrire les cas d'utilisation,

⁴⁴ Pascal Roques et Franck Vallée, op.cit., p.62.

40

? organiser les cas d'utilisation,

? identifier les classes candidates du modèle d'analyse.

Figure 2-3: Situation de la capture des besoins fonctionnels dans 2TUP

II.3.1. DETERMINATION DES CAS D'UTILISATION

Un cas d'utilisation (en anglais use case) représente un ensemble de séquences d'actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier.

Un cas d'utilisation spécifie une fonction offerte par l'application à son environnement. Un cas d'utilisation est spécifié uniquement par un intitulé. Le concept de cas d'utilisation offre une vue fonctionnelle sur l'application.⁴⁵

Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera. Dans le cadre de la branche fonctionnelle, le cas d'utilisation doit mettre en valeur les interactions métier entre les acteurs et le système. On exprimera donc des actions effectuées dans le cadre du métier de l'utilisateur, par opposition à des manipulations de l'application ou à des comportements techniques.

Un cas d'utilisation comporte donc :

- un acteur principal (c'est obligatoire),

- d'éventuels acteurs secondaires.

Le tableau ci-dessous permet d'établir le résultat de ce travail, en montrant le lien entre les cas d'utilisation identifiés, les acteurs principaux et secondaires, et les messages provenant du contexte.

⁴⁵ Xavier Blanc et Isabelle Mounier, op.cit., p.99.

41

LISTE PRELIMINAIRE DES CAS D'UTILISATION

N°	Cas d'utilisation	Acteur principal, acteurs secondaires	Message(s) émis/reçu par les acteurs
1.	S'authentifier	Utilisateur	Emet :se connecter, login + mot de passe, valider Reçois : Accès autorisé ou pas		2.
Gérer utilisateurs	Webmaster	Emet : s'authentifier, ajouter, modifier ou supprimer utilisateur Reçois : liste des utilisateurs	3.
Gérer Secrétaires des jurys	Secrétaire Général Académique	Emet : s'authentifier, afficher liste des secrétaires des jurys, sélectionner le code du secrétaire, affecter ou mettre à jour ou bloquer l'accès. Reçois : liste des Secrétaires du jury	4.
Consulter statistiques résultats	Secrétaire Général Académique	Emet : s'authentifier, consulter Reçois : statiques des résultats	5.
Gérer paiements	Caissière	Emet : s'authentifier, ajouter, modifier, supprimer paiement Reçois : liste des paiements mise à jour	6.
Publier résultats	Secrétaire du jury	Emet : s'authentifier, vérifier grilles de délibération des étudiants en ordre, charger grilles, publier Reçois : résultats disponibles	7.
Gérer publications résultats	Secrétaire du jury	Emet : s'authentifier, sélectionner publication, ajouter, modifier ou supprimer publication Reçois : liste des publications mise à jour	8.
S'Inscrire	Etudiant	Emet : Se connecter, s'inscrire Reçois : liste des étudiants inscrits au système	9.
Consulter résultats	Etudiant	Emet : s'authentifier, consulter Reçois : résultats disponibles	10.
Introduire recours	Etudiant	Emet : s'authentifier, introduire/joindre fichier de preuve Reçois : liste des recours postés	11.
Consulter recours	Secrétaire du jury	Emet : s'authentifier, sélectionner promotion, afficher recours postés, consulter Reçois : liste des recours postés

Tableau 2-2: Liste des acteurs et des messages par cas d'utilisation

42

II.3.2. DESCRIPTION PRELIMINAIRE DES CAS D'UTILISATION

Chaque cas d'utilisation doit faire l'objet d'une définition a priori qui décrit l'intention de l'acteur lorsqu'il utilise le système et les séquences d'actions principales qu'il est susceptible d'effectuer. Ces définitions servent à fixer les idées lors de l'identification des cas d'utilisation et n'ont aucun caractère exhaustif.

§ S'authentifier (Utilisateur)

Intention : S'authentifier au sein d'un système est une mesure de sécurité pour celui-ci ; Actions : se connecter, login + mot de passe, valider.

§ Gérer utilisateurs (Webmaster)

Intention : la gestion des utilisateurs est d'une importance capitale, il y a gestion d'accès dans la session ne vous concernant pas tout en étant utilisateur ;

Actions : S'authentifier, ajouter modifier et supprimer utilisateur, valider.

§ Gérer Secrétaires des jurys (Secrétaire Général Académique)

Intention : gérer affectations des secrétaires des différents jurys ;

Actions : s'authentifier, afficher liste des secrétaires des jurys, sélectionner le code du secrétaire, affecter ou mettre à jour ou bloquer l'accès.

§ Consulter statistiques résultats (Secrétaire Général Académique) Intention : valider les résultats dans différents jurys ;

Actions : s'authentifier, sélectionner numéro jury, afficher statistique.

§ Gérer paiements (Caissière)

Intention : permettre à la caissière de pouvoir gérer les paiements des étudiants afin de pouvoir s'informer en temps réel de l'état d'avancement des paiements.

Actions : s'authentifier, ajouter/modifier/supprimer paiements, produire rapport paiement.

§ Publier résultats (Secrétaire du jury)

Intention : mettre en ligne les résultats des étudiants ;

Actions : s'authentifier, vérifier grilles de délibération des étudiants en ordre, charger grilles, publier.

§ Gérer publications résultats (Secrétaire du jury)

Intention : permettre au Secrétaire du jury de pouvoir mettre à jour les publications. Il peut modifier ou supprime une publication des résultats des étudiants.

Actions : s'authentifier, sélectionner publication, ajouter, modifier ou supprimer publication.

43

§ S'Inscrire (Etudiant)

Intention : permettre à l'étudiant n'ayant pas accès à la consultation des résultats de s'inscrire c.à.d. faire partir à la plate-forme, lors de la publication de pouvoir s'authentifier pour pouvoir consulter ses résultats ou introduire un recours ;

Actions : Se connecter, s'inscrire.

§ Consulter résultats (Etudiant)

Intention : après publication des résultats la consultation des résultats est utile et, ce afin de pouvoir vérifier son bilan du travail ;

Actions : s'authentifier, sélectionner faculté/promotion, consulter.

§ Introduire recours (Etudiant)

Intention : En cas d'insatisfaction de ses résultats ou aux étudiants non délibérés, introduire recours après délibération est nécessaire pour leur bienêtre ;

Actions : s'authentifier, introduire recours, saisir les réclamations dans le formulaire, joindre les fichiers de preuve, valider, payer en ligne, choisir moyen de paiement, entrer numéro carte, introduire ;

§ Consulter recours (Secrétaire du jury)

Intention : Consulter les recours postés afin de les traiter ;

Actions : s'authentifier, sélectionner numéro promotion, afficher listes des recours postés, valider.

Maintenant que nous avons identifié les cas d'utilisation et leurs acteurs, nous allons pouvoir les représenter graphiquement sur un diagramme de cas d'utilisation, dont la notation graphique de base est la suivante :

^System

^S'inscrire

^{Consulter résultats}

^:Étudiant

^{Introduire recours}

^<<include>>

^<<include>>

^{Gérer résultats <<include>>}

^<<include>>

^{S'authentifier}

^{Publier résultats}

^<<include>>

^{:Secrétaire du jury}

^<<include>>

^{Consulter Recours}

^<<include>>

^<<include>>

^<<include>>

^{Gérer paiements}

^{Gérer utilisateurs}

^{Consulter statistiques}

^:Caissière

^{Gérer Secrétaires des jurys}

^:SGAC

^Utilisateur

^:Webmaster

44

Figure 2-4: Diagramme de cas d'utilisation pour la publication des résultats des étudiants de l'UNIKAM

45

II.3.3. DESCRIPTION DETAILLEE DES CAS D'UTILISATION

La fiche de description textuelle d'un cas d'utilisation n'est pas normalisée

par UML. Nous préconisons pour notre part la structuration suivante :

CAS D'UTILISATION « S'AUTHENTIFIER »

Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : S'authentifier

· Objectif : Ce cas d'utilisation permet de déterminer si l'utilisateur est ou non autorisé à se connecter au système. Les droits des utilisateurs sont par ailleurs utilisés pour donner ou interdire l'accès à certains éléments du système qui requièrent des privilèges adéquats.

· Acteur concerné : Utilisateur.

· Domaine fonctionnel : Gestion profils

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : L'utilisateur doit disposer un compte préalablement créé par l'administrateur système.

· Post condition : Le système autorise ou non l'accès à la page demandée à l'utilisateur.

· Scénario nominal

1. L'utilisateur saisit son nom d'utilisateur, son mot de passe et son mail.

2. Le système vérifie le nom d'utilisateur son mot de passe et son mail.

3. Le système affiche l'espace approprié pour chaque utilisateur.

· Scénario alternatif

Le nom d'utilisateur, le mot de passe et le mail sont erronés, le système affiche un message d'erreur précisant que tel champs n'est pas valide, on effectue un retour vers la page d'authentification.

Description des diagrammes d'analyse du cas d'utilisation

Pour documenter les cas d'utilisation, la description textuelle est indispensable, car elle seule permet de communiquer facilement avec les utilisateurs et de s'entendre sur la terminologie métier employée. En revanche, le texte présente des désavantages puisqu'il est difficile de montrer comment les enchaînements se succèdent, ou à quel moment les acteurs

46

secondaires sont sollicités. En outre, la maintenance des évolutions s'avère souvent fastidieuse. Il est donc recommandé de compléter la description textuelle par un ou plusieurs diagrammes dynamiques UML. La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.5.).

Figure 2-5: Diagramme de Séquence du C.U. « S'authentifier »

47

CAS D'UTILISATION « GERER UTILISATEURS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Gérer utilisateurs

· Objectif : ce cas d'utilisation permet au Webmaster de pouvoir ajouter, modifier ou supprimer un compte (profil utilisateur).

· Acteur concerné : Webmaster.

· Domaine fonctionnel : Gestion utilisateurs

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021

- Description des enchaînements

· Pré condition : Le Webmaster s'est authentifié correctement au système, doit être disponible pour effectuer n'importe quelle action.

· Post condition : Les informations de l'utilisateur doivent être mise à jour pour son compte.

· Scénario nominal

? CU1 : Créer un utilisateur

1. Le Webmaster choisit d'ajouter un compte utilisateur.

2. Le système affiche le formulaire à remplir.

3. Le Webmaster rempli et valide le formulaire.

4. Le système ajoute les informations dans la base de données.

5. Le système actualise la liste des utilisateurs et l'affiche. ? CU2 : Modifier un profil utilisateur

1. Le Webmaster choisit l'utilisateur à modifier.

2. Le système affiche le formulaire de modification.

3. Le Webmaster modifie les champs voulus.

4. Le système met à jour les informations dans la base de données.

5. Le système actualise la liste des utilisateurs et l'affiche. ? CU3 : Supprimer un profil utilisateur

1. Le Webmaster choisit l'utilisateur à supprimer.

2. Le système demande une confirmation.

3. Le Webmaster confirme ou annule la suppression.

4. Le système supprime l'utilisateur de la base.

48

5. Le système actualise la liste des utilisateurs et l'affiche.

· Scénario alternatif

V' L'utilisateur existe déjà ou valeurs des champs non conforme aux types de données, formulaire non rempli : un message d'erreur sera affiché par le système.

V' La modification de données avec des champs vides, champs non conformes aux types : un message d'erreur sera affiché par le système.

V' L'utilisateur inexistant dans la base de données : un message d'erreur sera affiché. Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.6).

49

Figure 2-6: Diagramme de Séquence du C.U. « Gérer utilisateurs »

50

CAS D'UTILISATION « GERER SECRETAIRES DES JURYS »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : Gérer Secrétaires des jurys

· Objectif : permettre au Secrétaire du jury de pouvoir gérer les secrétaires affectés dans différents jurys ;

· Acteur principal : Secrétaire Général Académique.

· Acteur secondaire : Secrétaire du jury

· Domaine fonctionnel : Gestion des Secrétaires des jurys.

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le Secrétaire Général Académique s'est authentifié correctement au système.

· Post condition : La liste des Secrétaires des jurys doit être mise à jour.

· Scénario nominal

- Demander page de gestion de Secrétaires des jurys ; - Le système affiche la page.

? CU1 : Affecter Secrétaire dans un jury

1. Le SGAC Demande page d'affection d'un Secrétaire dans un jury ;

2. Le système affiche la page ;

3. Le SGAC saisi les coordonnées d'affectation ;

4. Le système vérifie la conformité ;

5. Le système enregistre et met à jour si les coordonnées sont conformes. ? CU2 : Mise à jour d'une affectation

1. Le SGAC Demande page de modification ;

2. Le système affiche la page ;

3. Le SGAC sélectionne l'affectation ;

4. Le système affiche le détail ;

5. Le SGAC saisi les informations supplémentaires ;

6. Le système vérifie la conformité,

7. Le système met à jour si les informations sont conformes.

51

? CU3 : Suppression d'une affectation

1. Le SGAC Demande page de modification ;

2. Le système affiche la page ;

3. Le SGAC du jury sélectionne l'affectation ;

4. Le système affiche les détails de l'affectation ;

5. Le SGAC du jury supprime l'affectation ;

6. Le système demande la confirmation de la suppression ;

7. Le SGAC confirme la suppression ;

8. Le système supprime l'affectation du secrétaire dans un jury et actualise la liste des affectations des secrétaires.

· Scénario Alternatif

y Erreur d'une affectation

" Le système affiche un message d'erreur ;

" Le SGAC réessaye l'affectation ;

" Le système valide l'enregistrement d'une affectation et affiche la confirmation.

y Erreur de mise à jour d'une affectation

" Le système affiche un message d'erreur ;

" Le SGAC réessaye la mise à jour ;

" Le système valide la mise à jour et affiche la confirmation.

y Erreur de suppression d'une affectation

" Le système affiche l'erreur rencontrée lors de suppression ;

" Le SGAC corrige l'erreur détectée ;

" Le système valide et affiche la confirmation.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de

séquence (figure 2.7).

52

Figure 2-7: Diagramme de Séquence du C.U. « Gérer Secrétaires des jurys »

53

CAS D'UTILISATION « CONSULTER STATISTIQUES RESULTATS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Consulter statistiques résultats

· Objectif : permettre au Secrétaire Général Académique de consulter les statistiques des résultats dans différents jurys avant la publication des résultats pour prendre une certaine décision après constat.

· Acteur concerné : Secrétaire Général Académique.

· Domaine fonctionnel : Consultation statistiques résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le SGAC s'est authentifié correctement au système.

· Post condition : Le SGAC doit normalement consulter les statistiques des résultats.

· Scénario nominal

1. Le SGAC demande la page de consultation des statistiques des résultats d'un jury ;

2. Le système lui affiche la page des résultats par jury/promotion ;

3. Le SGAC décrit un critère de recherche des informations (par exemple : sélectionner un code d'un jury quelconque et le code d'une promotion qu'il doit consulter) ;

4. Le système recherche les informations ;

· Scénario alternatif

Point 1 du scénario nominal : Code Jury non trouvé ou critère non valide - Le système affiche un message d'erreur ;

- Afficher les détails de l'information ;

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.8).

54

Figure 2-8: Diagramme de Séquence du C.U. « Consulter statistiques résultats »

CAS D'UTILISATION « GERER PAIEMENTS »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : Gérer paiements

· Objectif : permettre à la caissière de pouvoir gérer les paiements des étudiants afin de pouvoir s'informer en temps réel de l'état d'avancement des paiements.

· Acteur concerné : Caissière

· Domaine fonctionnel : Gestion paiements

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : La Caissière s'est authentifiée correctement au système.

· Post condition : Les paiements sont mis à jour.

· Scénario nominal

? CU1 : Ajouter paiement

1. La Caissière choisit d'ajouter un paiement.

55

2. Le système affiche le formulaire à remplir.

3. La Caissière rempli et valide le formulaire.

4. Le système ajoute les informations dans la base de données.

5. Le système actualise la liste des paiements et l'affiche. ? CU2 : Modifier paiement

1. La Caissière choisit le numéro paiement à modifier.

2. Le système affiche le formulaire de modification.

3. Le Webmaster modifie les champs voulus.

4. Le système met à jour les informations dans la base.

5. Le système actualise la liste des paiements et l'affiche. ? CU3 : Supprimer un paiement

1. La Caissière choisit le numéro paiement à supprimer.

2. Le système demande une confirmation.

3. La Caissière confirme ou annule la suppression.

4. Le système supprime l'utilisateur dans la base de données.

5. Le système actualise la liste des paiements et l'affiche.

· Scénario alternatif

V' Les valeurs des champs non conforme aux types de données, formulaire non rempli : un message d'erreur sera affiché par le système.

V' La modification de données avec des champs vides, champs non conformes aux types : un message d'erreur sera affiché par le système.

V' Le numéro paiement inexistant dans la base de données : un message d'erreur sera affiché.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.9).

56

Figure 2-9: Diagramme de Séquence du C.U. « Gérer paiements »

57

CAS D'UTILISATION « PUBLIER RESULTATS »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : Publier résultats

Objectif : permettre au Secrétaire du jury de publier les résultats des étudiants sur le Web après validation du SGAC. L'étudiant peut venir consulter ses résultats.

· Acteur concerné : Secrétaire du jury.

· Domaine fonctionnel : Gestion résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le Secrétaire du jury s'est authentifié correctement au système.

· Post condition : Les résultats sont disponibles en ligne

· Scénario nominal

1. Le Secrétaire du jury demande la page de publication des résultats ;

2. Le système lui affiche la page correspondante ;

3. Le Secrétaire du jury charge l'élément à publier ;

4. Le Secrétaire du jury saisi les informations supplémentaire détaillant l'élément ;

5. Le système vérifie la conformité de l'élément à publier ;

6. Le système enregistre s'il est conforme.

· Scénario alternatif

Point 1 du scénario nominal : grille non conforme

- Le système renvoi l'erreur ;

- Le Secrétaire du jury réessaye ;

- Le système valide et émet un message de confirmation

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de

séquence (figure 2.10).

58

Figure 2-10: Diagramme de Séquence du C.U. « Publier résultats »

CAS D'UTILISATION « GERER PUBLICATIONS RESULTATS »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : Gérer publications résultats

· Objectif : permettre au Secrétaire du jury de pouvoir mettre à jour les publications. Il peut modifier ou supprime une publication des résultats des étudiants.

· Acteur concerné : Secrétaire du jury.

· Domaine fonctionnel : Gestion résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le Secrétaire du jury s'est authentifié correctement au système.

· Post condition : La liste des publications doit être mise à jour.

· Scénario nominal

? CU1 : Mise à jour d'une publication

1. Demander page de modification ;

2. Le système affiche la page

3. Le Secrétaire du jury sélectionne la publication ;

4. Le système affiche le détail ;

5. Le Secrétaire du jury saisi les informations supplémentaires ;

59

6. Le système vérifie la conformité,

7. Le système met à jour si les informations sont conformes. ? CU2 : Suppression d'une publication

1. Le Secrétaire du jury sélectionne la publication ;

2. Le système affiche les détails de la publication ;

3. Le Secrétaire du jury supprime la publication ;

4. Le système demande la confirmation de la suppression ;

5. Le Secrétaire du jury confirme la suppression ;

6. Le système supprime l'abonné et actualise la liste des publications.

· Scénario Alternatif

? Erreur de mise à jour d'une publication

" Le système affiche un message d'erreur ;

" Le Secrétaire du jury réessaye la mise à jour ;

" Le système valide la mise à jour et affiche la confirmation.

? Erreur de suppression d'une publication

" Le système affiche l'erreur rencontrée lors de suppression ;

" Le Secrétaire du jury corrige l'erreur détectée ;

" Le système valide et affiche la confirmation.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de

séquence (figure 2.11).

60

Figure 2-11: Diagramme de Séquence du C.U. « Gérer publications résultats »

61

CAS D'UTILISATION « S'INSCRIRE »

Description textuelle du Cas d'utilisation - Sommaire d'identification

· Titre : S'Inscrire

· Objectif : permettre à l'étudiant de s'inscrire c.à.d. faire partir à la plate-forme, lors de la publication de pouvoir s'authentifier pour pouvoir consulter ses résultats ou introduire un recours ;

· Acteur concerné : Etudiant.

· Domaine fonctionnel : Consultation résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Aucune condition.

· Post condition : compte créé (l'étudiant doit devenir un client lors de sa connexion).

· Scénario nominal

1. L'Etudiant demande la page d'inscription ;

2. Le système lui affiche la page demandée ;

3. L'Etudiant saisi les coordonnées d'inscription ;

4. Le système vérifie la conformité ;

5. Le système enregistre l'étudiant dans la catégorie des clients si les coordonnées sont valides.

· Scénario alternatif

Point 1 du scénario nominal : Coordonnées inscription non valide

? Le système émet un message d'erreur ;

? L'étudiant réessaye l'inscription ;

? Le système valide l'inscription et émet un message de confirmation.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de

séquence (figure 2.12).

62

Figure 2-12: Diagramme de Séquence du C.U. « S'inscrire »

CAS D'UTILISATION « CONSULTER RESULTATS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Consulter résultats

· Objectif : permettre à l'étudiant de consulter ses résultats après publication.

· Acteur concerné : Etudiant.

· Domaine fonctionnel : Consultation résultats

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : L'étudiant s'est authentifié correctement au système.

· Post condition : L'étudiant doit normalement consulter les résultats.

· Scénario nominal

1. L'Etudiant demande la page de consultation des résultats ;

2. Le système lui affiche la page des résultats publiées ;

3. L'Etudiant décrit un critère de recherche des informations ;

4. Le système recherche les informations ;

· Scénario alternatif

63

Point 1 du scénario nominal : Code étudiant non trouvé ou critère non valide

- Le système affiche un message d'erreur ; - Afficher les détails de l'information ;

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.13).

Figure 2-13: Diagramme de Séquence du C.U. « Consulter résultats »

CAS D'UTILISATION « INTRODUIRE RECOURS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Introduire recours

· Objectif : permettre à l'étudiant d'introduire ses déclarations de non satisfaction après publication des résultats.

· Acteur concerné : Etudiant.

· Domaine fonctionnel : Consultation résultats

· Version : 1.0

64

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : L'étudiant a consulté les résultats après publication.

· Post condition : Le jury a pris une décision de délibération et le client en a été averti.

· Scénario nominal

1. L'Etudiant choisit d'introduire un recours.

2. Le système affiche le formulaire à remplir.

3. L'Etudiant rempli les déclarations, joint les fichiers de preuve et valide le formulaire.

4. Le système ajoute les informations dans la base de données.

5. Le système actualise la liste des recours postés et l'affiche.

· Scénario alternatif

Au point 3 du scénario nominal : informations manquantes ou incorrectes, l'Etudiant doit compléter ou modifier sa déclaration de recours (retour au point 3 du scénario nominal). Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.14).

Figure 2-14: Diagramme de Séquence du C.U. « Introduire recours »

65

CAS D'UTILISATION « CONSULTER RECOURS » Description textuelle du Cas d'utilisation

- Sommaire d'identification

· Titre : Consulter recours

· Objectif : permettre à l'étudiant de consulter les recours postés par les étudiants en vue de pouvoir les traiter.

· Acteur concerné : Secrétaire du jury.

· Domaine fonctionnel : Gestion résultats.

· Version : 1.0

· Responsable : Charles KATEBA

· Date : 04/05/2021 - Description des enchaînements

· Pré condition : Le Secrétaire du jury s'est authentifié correctement au système.

· Post condition : Le Secrétaire du jury doit normalement consulter les recours postés.

· Scénario nominal

1. Le Secrétaire du jury demande la page de consultation des recours ;

2. Le système lui affiche la page des recours postés ;

3. Le Secrétaire du jury consulte les recours postés, sélectionné le nom de l'étudiant en question et télécharge les preuves de la déclaration de recours ;

4. Le système télécharge les preuves de la déclaration de recours.

· Scénario alternatif

Point 1 du scénario nominal : Critère non valide

- Le système affiche un message d'erreur ;

- Téléchargement réussie.

Description des diagrammes d'analyse du cas d'utilisation

La suite de l'analyse du cas d'utilisation se poursuit par l'élaboration du diagramme de séquence (figure 2.15).

66

Figure 2-15: Diagramme de Séquence du C.U. « Consulter recours »

II.3.4. STRUCTURATION DES CAS D'UTILISATION DANS DES PACKAGES

Pour définir la stratégie de regroupement des cas d'utilisation pour un projet, il convient de recourir à la liste suivante de critères : par domaine d'expertise métier, par acteur, par lot de livraison. Le mécanisme générique de regroupement d'éléments en UML s'appelle le package. Nous allons y recourir dans cette activité, afin de structurer notre ensemble de cas d'utilisation.

QU'EST-CE QU'UN PACKAGE ?

Un package UML représente un espace de nommage qui peut contenir : des éléments d'un modèle, des diagrammes qui représentent les éléments du modèle, d'autres packages.⁴⁶

Les éléments contenus dans un package : doivent représenter un ensemble fortement cohérent, sont généralement de même nature et de même niveau sémantique. Le critère de regroupement retenu pour le système de publication des résultats des étudiants de UNIKAM est le premier cité, soit le domaine d'expertise métier. Il correspond également à un découpage par ensemble d'acteurs fortement reliés. Si nous reprenons le tableau préliminaire, en affectant chaque cas d'utilisation à un package, nous obtenons ce qui suit :

⁴⁶ Pascal Roques et Franck Vallée, op.cit., p.83.

67

Cas d'utilisation	Acteurs	Package
S'authentifier	Utilisateur	Services support
Gérer utilisateurs	Webmaster
S'Inscrire	Etudiant
Consulter résultats	Etudiant	Consultation des résultats
Consulter statistiques résultats	Secrétaire Général Académique
Introduire recours	Etudiant
Gérer publications résultats	Secrétaire du jury	Gestion des résultats
Gérer Secrétaires des jurys	Secrétaire Général Académique
Publier résultats	Secrétaire du jury
Consulter recours	Secrétaire du jury
Gérer paiements	Caissière	Gestion des paiements

Tableau 2-3: Liste des cas d'utilisation et de leurs acteurs par package

Le cas d'utilisation inclus S'authentifier est mis dans un package à part, en tant que fragment commun, pour bien le distinguer des vrais cas fonctionnels qui l'incluent. Les flèches de dépendance entre packages de cas d'utilisation synthétisent les éventuelles relations entre les cas, c'est-à-dire ici les inclusions. Le schéma suivant présente la structuration proposée des cas d'utilisation. Il s'agit d'un diagramme de packages, officialisé par UML 2.

Figure 2-16: Diagramme de packages des cas d'utilisation

68

En effet, chaque package de cas d'utilisation occasionne la création d'un diagramme. La notation (from Fragments) n'est pas standard UML, mais est utilisée par plusieurs outils du marché. En voici le package attirant notre attention :

Figure 2-17: Diagramme de cas d'utilisation du package « gestion résultats »

I.3.5. IDENTIFICATION DES CLASSES CANDIDATES

Les premières classes candidates identifiées dans cette phase sont des concepts connus des utilisateurs du système, ce qu'on appelle couramment (et abusivement, puisque ce sont des classes) des objets métier. Exemples pour l'étude de cas : Cours, Etudiant, Enseignant, Paiements, etc.

Nous allons dans un second temps des concepts « applicatifs », liés à l'informatisation. Exemples pour l'étude de cas : Profil utilisateur, etc.

Nous allons formaliser ensuite ces concepts métier sous forme de classes et d'associations rassemblées dans un diagramme statique pour chaque cas d'utilisation. Ces diagrammes préliminaires, que nous appelons « diagramme de classes participantes », n'ont pas d'objectif d'exhaustivité.

Pour élargir cette première identification des concepts du système, nous allons utiliser une catégorisation des classes qui a été popularisée par le RUP. Les classes d'analyse

69

qu'ils préconisent se répartissent en trois catégories. Les trois catégories de classes d'analyse sont :

- Celles qui permettent les interactions entre le site et ses utilisateurs sont qualifiées de dialogues.

- Celles qui contiennent la cinématique de l'application sont appelés contrôles.

- Celles qui représentent les concepts métier sont qualifiées des entités.

A. DIAGRAMME DES CLASSES PARTICIPANTES

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « S'AUTHENTIFIER » Pour illustrer les différents objets en interaction en rapport avec ce cas d'utilisation Les objets y figurant sont représentés de la manière suivante :

Figure 2-18: Diagramme de classe participante du C.U. « S'authentifier »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « GERER UTILISATEURS»

« Gérer Utilisateurs » est un cas d'utilisation qui prend en compte la manipulation des objets décrits sur le diagramme de classes participantes, ci-après :

Figure 2-19: Diagramme de classe participante du C.U. « Gérer utilisateurs »

70

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « GERER SECRETAIRES DES JURYS »

Ce diagramme présente les objets qui sont en relation lors de la réalisation du cas d'utilisation « Gérer Secrétaires des Jurys ». La représentation est la suivante :

Figure 2-20: Diagramme de classe participante du C.U. « Gérer Secrétaires des Jurys »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « CONSULTER STATISTIQUES RESULTATS »

Pour illustrer les différents objets en interaction en rapport avec ce cas d'utilisation Les objets y figurant sont représentés de la manière suivante :

Figure 2-21: Diagramme de classe participante du C.U. « Consulter statistiques résultats »

71

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U « GERER PAIMENTS » Le cas d'utilisation « Gérer paiements » a comme les objets qui y participent ceux qui suivent :

Figure 2-22: Diagramme de classe participante du C.U. « Gérer paiements »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « PUBLIER

RESULTATS »

« Publier résultats » est un cas d'utilisation qui prend en compte la manipulation des objets décrits sur le diagramme de classes participantes, ci-après :

Figure 2-23: Diagramme de classe participante du C.U. « Publier résultats »

72

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « GERER PUBLICATIONS RESULTATS »

Ce diagramme présente les objets qui sont en relation lors de la réalisation du cas d'utilisation « Gérer publications résultats ». La représentation est la suivante :

Figure 2-24: Diagramme de classe participante du C.U. « Gérer publications résultats »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « S'INSCRIRE » Ce diagramme présente les objets qui sont en relation lors de la réalisation du cas d'utilisation « S'Inscrire ». La représentation est la suivante :

Figure 2-25: Diagramme de classe participante du C.U. « S'inscrire »

73

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « CONSULTER

RESULTATS »

Le cas d'utilisation « Consulter résultats » a comme les objets qui y participent ceux qui suivent :

Figure 2-26: Diagramme de classe participante du C.U. « Consulter résultats »

4 DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « INTRODUIRE

RECOURS »

Ce diagramme présente les objets qui sont en relation lors de la réalisation du cas d'utilisation « Introduire recours ». La représentation est la suivante :

Figure 2-27: Diagramme de classe participante du C.U. « Introduire recours »

74

? DIAGRAMME DE CLASSE PARTICIPANTE DU C.U. « CONSULTER

RECOURS »

« Consulter recours » est un cas d'utilisation qui prend en compte la manipulation des objets décrits sur le diagramme de classes participantes, ci-après :

Figure 2-28: Diagramme de classe participante du C.U. « Consulter recours »

II.3.6. DEFINITION DES ITERATIONS PAR CLASSEMENT DES CAS
D'UTILISATION

Dans le cadre d'un développement itératif et incrémental, il est très utile de recourir au découpage en cas d'utilisation pour définir les itérations. À cet effet, il convient en premier lieu d'identifier les cas d'utilisation les plus critiques en termes de gestion des risques. Ces cas d'utilisation devront être traités prioritairement afin de lever au plus tôt les risques majeurs. Il sera également demandé au client d'affecter une priorité fonctionnelle à chaque cas d'utilisation, afin de livrer d'abord les cas d'utilisation les plus demandés.⁴⁷

Le tableau ci-dessous nous permettra d'organiser la manière de concevoir les différentes fonctionnalités de notre site web en tenant compte de l'ordre de priorité, de risques à gérer au cours de la réalisation du système informatique par rapport à une fonctionnalité quelconque. Et cela donne lieu aux itérations représentées dans le tableau ci-après :

⁴⁷ Pascal Roques et Franck Vallée, op.cit., p.91.

75

N°	CAS D'UTILISATION	RISQUE	PRIORITE	ITERATION
1.	S'authentifier	Bas	Moyenne	8
2.	Gérer utilisateurs	Bas	Moyenne	8
3.	Gérer Secrétaires des jurys	Bas	Moyenne	6
4.	Consulter statistiques résultats	Moyen	Haute	5
5.	Gérer paiements	Bas	Basse	7
6	Publier résultats	Moyen	Haute	4
7.	Gérer publications résultats	Bas	Basse	7		8.
S'Inscrire	Haut	Haute	1	9.
Consulter résultats	Moyen	Moyenne	3	10.
Introduire recours	Moyen	Moyenne	3	11.
Consulter recours	Bas	Basse	7

Tableau 2-4: Définition des itérations par classement des cas d'utilisation

76

CONCLUSION PARTIELLE

Dans ce chapitre nous avons fait l'étude préliminaire et la capture des besoins fonctionnels :

Pour l'étude préliminaire, nous avons présenté notre projet, nous avons recueilli les besoins fonctionnels tout en faisant le choix technique et le choix technique opérationnel, nous avons identifié les acteurs de notre futur système (5 acteurs) et nous avons conclu par modéliser le contexte.

Pour la capture des besoins fonctionnels, nous avons identifié les cas d'utilisation du système par ses acteurs (11 C.U. et 4 acteurs), décrit d'une façon détaillée les cas d'utilisation en appuyant la description textuelle par les illustrations des diagrammes de séquence ; organisé les cas d'utilisation dans des packages (4 packages) et identifié les classes candidates du modèle d'analyse en utilisant le diagramme de classe participante et le diagramme des classes de conception, nous avons chuté tout en définissant les itérations et cela par classement des cas d'utilisation.

Somme toute, nous avons eu à Dialoguer avec le client sur son expression préliminaire de besoins grâce à une description fonctionnelle qu'il comprend facilement, et Réparer la modélisation orientée objet en aidant à trouver les classes principales du futur modèle statique d'analyse.

77

CHAPITRE TROISIEME : ANALYSE ET CONCEPTION DU SYSTEME INFORMATIQUE

III.1. INTRODUCTION

La conception des sites web est un sujet à la mode !

Bref, tout pour améliorer la forme, mais où est passé le fond ? Que vient faire l'internaute sur le site ? Quelles informations s'attend-il à trouver ? Comment ces informations sont-elles structurées, reliées entre elles, mises à jour ? Bref, comment garantir que les choix de réalisation de notre site web sont bien adaptés aux objectifs de l'utilisateur ?

La réponse tient en un seul mot : modéliser ! car, « Chercher une méthode, c'est chercher un système d'opérations extériorisables qui fasse mieux que le travail de l'esprit. » (Paul VALERY, Variétés.).

Ce chapitre traite du démarrage de l'analyse et de la conception objet du système à réaliser.

III.2. ANALYSE

Pour passer à l'analyse, nous allons changer radicalement l'organisation du modèle et nous fonder sur les principes de l'approche orientée objet, notamment sur celui d'encapsulation. À cet effet, nous allons passer d'une structuration fonctionnelle via les cas d'utilisation et les packages de cas d'utilisation, à une structuration objet via les classes et les catégories.

III.2.1. DECOUPAGE EN CATEGORIES

Le découpage en catégories constitue la première activité de l'étape d'analyse (il s'affine bien sûr de manière itérative au cours du projet). Il se situe sur la branche gauche du cycle en Y et succède à la capture des besoins fonctionnels. En fin d'analyse des besoins, nous obtenons un découpage fonctionnel exprimé à travers les cas d'utilisation organisés dans le modèle de spécification fonctionnelle.

Une catégorie consiste en un regroupement logique de classes à forte cohérence interne et faible couplage externe.⁴⁸ Nous la représentons par un stéréotype de package.

La démarche mise en oeuvre dans cette section se résume en disant que : pour parvenir à faire le découpage entre catégories il faut avant tout faire la structuration des packages de cas d'utilisation, établir le diagramme de classes participantes et par là : répartir les classes candidates en catégories, élaborer les diagrammes de classes préliminaires par catégorie et en fin décider des dépendances entre catégorie. En effet, de nouvelles classes (par

⁴⁸ Pascal Roques et Franck Vallée, op.cit., p.117.

78

exemple : administrateur, profil, utilisateur) vont probablement être introduites ; certaines pourront être déplacées afin de minimiser les dépendances entre catégories.

Figure 3-1: Premier découpage en catégories

Voici les raisons de ce premier découpage :

y' La catégorie Exploitation Informatique a été isolée de la catégorie Personnels car elle correspond à un service technique classique dans toute application informatique ou site web (et donc potentiellement réutilisable), mais pas à un service métier ;

y' Les catégories délibération et paiements sont séparées du fait que : pour délibérer un étudiant ce n'est ne pas nécessairement conditionnel que ce dernier soit toujours en ordre.

III.2.2. DEPENDANCES ENTRE CATEGORIES

Posséder des éléments, un package peut également importer des éléments visibles d'un autre package. UML définit ainsi deux niveaux de visibilité : public (+) : l'élément est utilisable par tout package relié par une dépendance ; private (-) : l'élément n'est utilisable que par son package parent. En analyse, nous préfixerons simplement les classes visibles par le symbole « + ». Pour les dépendances nous allons illustrer celles des associations ainsi que celles de l'importation.

Voici quelques associations concernant la classe Résultats et des classes d'autres catégories.

79

Figure 3-2: Quelques associations concernant la classe Résultats

Voici maintenant les importations concernant ces catégories :

Figure 3-3: Illustration d'importations entre catégories

Il est à noter que l'importation est une relation unidirectionnelle, qui offre un accès aux éléments du package Résultats pour les éléments du package Personnels. En somme, même si la catégorie Résultats importe la catégorie Personnels, la classe Caissier n'a toujours pas accès à la classe Résultats. La simple différence vient du fait que l'association est par défaut une relation bidirectionnelle entre classes.

80

III.2.3. DIAGRAMME DU PACKAGE D'ANALYSE

Le schéma ci-dessous schéma de la série représente ainsi l'état préliminaire des dépendances souhaitées entre les catégories au début de la phase d'analyse. C'est un diagramme de packages au sens UML 2.0.

Figure 3-4: Diagramme de packages d'analyse

III.2.4. DEVELOPPEMENT DU MODELE STATIQUE

Le développement du modèle statique constitue la deuxième activité de l'étape d'analyse. Elle se situe sur la branche gauche du cycle en Y et succède au découpage en catégories. Les diagrammes de classes établis sommairement dans les DCP (diagrammes des classes participantes), puis réorganisés lors du découpage en catégories, vont être détaillés, complétés, et optimisés.

Pour une démarche d'élaboration du modèle statique, de par le cahier des charges, les fiches de descriptions de cas d'utilisation et le diagramme de classes participantes que nous avons fait au chapitre deuxième, nous allons : affiner les classes, affiner les associations, Ajouter les attributs, ajouter les opérations (optionnel) et puis optimiser avec la généralisation le diagramme de classes. De par notre analyse, au lieu de reprendre tous les diagrammes des classes participantes nous préférons présenter ci-dessous, le diagramme de classe du modèle statique.

^gère

^1..*

¹

81

^<<entity>>

^Paiements

^{-N°_Paiement: Int}

^{-Motif_Paiement: String}

^{-Date_Paiement: Date}

^{+ajouter() +modifier() +supprimer() +rechercher() +imprimer()}

^1..*

^effectue

¹

^<<entity>>

^Etudiant

^{-Mat_Etudiant: Int}

^{-Nom_Etudiant: String}

^{-Sexe: String}

^+get()

^+set()

^appartient

^1..*

¹

^{être destiné}

^<<entity>>

^{Secrétaire du jury}

^+créer()

^+modifier()

^+supprimer()

^{1 1..*}

^Crée

^1..*

^<<entity>>

^Profil

^{-Num_Inscription: Int -Nom_Utilisateur: String -Gmail: String -Date_Creation: Date}

^+éditer()

^+modifier()

^+supprimer()

^<<entity>>

^<<entity>>

^Promotion

^{-CodePr: Int}

^{-NomPr: String}

^{-Faculte: String}

^+get()

^+set()

^1concerne1

^1..*

¹

^Caissière

^{-Mat_Caissière: Int}

^{-Nom_Caissière: String}

^-Contact

^{+créer() +modifier() +supprimer() +affecter()}

^<<entity>>

^Résultats

^{-Num_Resultat: Int}

^{-Date_Publication: Date}

^{+éditer() +charger() +publier() +consulter() +mettre à jour() +supprimer()}

^1..*

^encode

^1..*

¹

^{+créer() +modifier() +supprimer() +affecter() -Mat_SJ: Int -Nom_SJ: String -Gmail_SJ: String}

^évolue

1..*

^1..*

^{fait référence}

¹

^<<entity>>

^Jury

^{-CodeJ: Int}

^{-NomJ: String}

^{-Effectif_Total: Int}

^{-Annee_Ac: Date}

^{être affecté}

^0..*

^<<entity>>

^Recours

1..* 1

¹

¹

^{-Num_Recours: Int -Objet: String -Plaintes: String -Date_Recours: Date}

^{+éditer() +valider() +consulter() +rejetter()}

¹

^1..*

^<<entity>>

^Cours

^{-Code_Cours: Int -Nom_Cours: String -Volume_Horaire: String -Ponderation: Int}

^+get()

^+set()

Figure 3-5: Diagramme de classes de conception

Figure 3-6: Diagramme d'interaction du C.U s'authentifier

82

III.2.5. DEVELOPPEMENT DU MODELE DYNAMIQUE

Le développement du modèle dynamique constitue la troisième activité de l'étape d'analyse. Elle se situe sur la branche gauche du cycle en Y. Il s'agit d'une activité itérative, fortement couplée avec l'activité de modélisation statique, décrite au paragraphe précédent.

Partant de la démarche d'élaboration du modèle dynamique, en nous servant de diagramme de cas d'utilisation et des fiches de la description des cas d'utilisation il est nécessaire d'identifier les scénarios (liste de scénarios) et puis formaliser ces derniers à l'aide des diagrammes d'interactions.

1. Interaction du Cas d'utilisation « S'authentifier »

Le diagramme d'interactions qui illustre le contrat d'opérations « s'authentifier » est le suivant :

83

2. Interaction du Cas d'utilisation « Gérer utilisateurs »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer utilisateurs » est le suivant :

Figure 3-7: Diagramme d'interaction du C.U gérer utilisateurs

84

3. Interaction du Cas d'utilisation « Gérer secrétaires des jurys »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer secrétaires des jurys » est le suivant :

Figure 3-8: Diagramme d'interaction du C.U gérer secrétaires des jurys

85

4. Interaction du Cas d'utilisation « Consulter statistiques résultats »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer secrétaires des jurys » est le suivant :

Figure 3-9: Diagramme d'interaction du C.U consulter statistiques résultats

86

5. Interaction du Cas d'utilisation « Gérer paiements »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer paiements » est le suivant :

Figure 3-10: Diagramme d'interaction du C.U Gérer paiements

87

6. Interaction du Cas d'utilisation « Publier résultats »

Le diagramme d'interactions qui illustre le contrat d'opérations « Publier résultats » est le suivant :

Figure 3-11: Diagramme d'interaction du C.U Publier résultats

88

7. Interaction du Cas d'utilisation « Gérer publications résultats »

Le diagramme d'interactions qui illustre le contrat d'opérations « Gérer publications résultats » est le suivant :

Figure 3-12: Diagramme d'interaction du C.U Gérer publications résultats

89

8. Interaction du Cas d'utilisation « S'Inscrire »

Le diagramme d'interactions qui illustre le contrat d'opérations « S'Inscrire » est le suivant :

Figure 3-13: Diagramme d'interaction du C.U S'Inscrire

90

9. Interaction du Cas d'utilisation « Consulter résultats »

Le diagramme d'interactions qui illustre le contrat d'opérations « Consulter résultats » est le suivant :

Figure 3-14: Diagramme d'interaction du C.U Consulter résultats

91

10. Interaction du Cas d'utilisation « Introduire recours »

Le diagramme d'interactions qui illustre le contrat d'opérations « Introduire recours » est le suivant :

Figure 3-15: Diagramme d'interaction du C.U Introduire recours

92

11. Interaction du Cas d'utilisation « Consulter recours »

Le diagramme d'interactions qui illustre le contrat d'opérations « Consulter recours » est le suivant :

Figure 3-16: Diagramme d'interaction du C.U Consulter recours

93

III.3. CONCEPTION

Le glossaire IEEE 610.12-1990 définit la conception comme (1) le processus consistant à définir l'architecture, les composants, les interfaces et d'autres caractéristiques d'un système ou d'un composant et (2) le résultat même de ce processus.

Lors de la conception, il est à savoir qu'UML permet de visualiser, de spécifier, de construire et de documenter. Ces quatre aspects vont être maintenant décrits pour l'activité de conception sur la branche droite du processus 2TUP, à la conception générique (construire le modèle logique, le modèle d'exploitation, le modèle de configuration logicielle, faire le générateur de code puis le prototypage). Pour l'activité de conception sur la branche du milieu du processus 2TUP nous avons la conception préliminaire (concevoir le déploiement, concevoir le modèle d'exploitation, organiser le modèle logique, concevoir les interfaces, concevoir la structure de la présentation, organiser la configuration logicielle) et la conception détaillée (concevoir le modèle logique et développer la configuration logicielle).

A ce propos, nous allons juste concevoir l'architecture de l'application web et construire enfin la base de données relationnelle.

III.3.1. ARCHITECTURE DU LOGICIEL

« L'ergonomie des produits informatiques ? Au-delà de la fiabilité et de la performance, les utilisateurs réclament toujours plus de confort d'utilisation et d'efficacité de l'interface... à juste titre ! » Gilles Murawiec.

Le standard IEEE 1471 définit l'architecture d'un logiciel comme l'organisation fondamentale d'un système incorporée dans ses composants, leurs interrelations, leurs relations avec l'environnement et les principes qui guident toutes les tâches de conception et d'évolution du logiciel. L'architecture logicielle définit donc la structure interne du logiciel ; c'est une manière particulière de structurer et d'organiser les éléments internes d'un logiciel ou d'un composant.

Les caractéristiques d'une bonne architecture incluent les aptitudes telles que la modularité, l'extensibilité, la résistance aux pannes, la simplicité, etc.

Plusieurs auteurs ont contribué à identifier les styles architecturaux les plus importants en génie logiciel. On distingue les styles suivants :

? les structures générales telles que les modèles en couches, les modèles en pipe, les modèles à filtres et les modèles blackboard,

? les styles de systèmes distribués tels que le client/serveur, le modèle 3-tiers, le broker,

94

? les styles de systèmes interactifs tels que le modèle Modèle-Vue-Contrôleur, le modèle Présentation-Abstraction-Contrôle, les styles de systèmes adaptables tels que le micro noyau, la réflexion et

? bien d'autres utilisés pour les systèmes en batch, les interpréteurs, les systèmes de contrôle de processus, les systèmes à base de règles.

? Pour les styles des systèmes distribués, nous avons fait le choix de l'architecture client/serveur.

Dans une architecture client/serveur, les fonctionnalités du système logiciel sont organisées en services, chaque service étant délivré par un serveur différent. Les clients sont les utilisateurs de ces services ; ils contactent les serveurs sur le réseau.

Sur les réseaux actuels, les clients et serveurs exploitent essentiellement les fonctionnalités logicielles des protocoles TCP/IP pour pouvoir solliciter des services et échanger des informations.

Le schéma suivant présente le style d'architecture en 2-tiers (client/serveur) :

Figure 3-17: choix de style des architectures logiciels

? Pour les styles de systèmes interactifs, nous avons fait le choix du patron architectural modèle-vue-contrôleur (MVC, de l'anglais model-view-controller), car est un modèle en couches destiné à répondre aux besoins des applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective.

Ce modèle regroupe les fonctions nécessaires en trois catégories :

V' Un modèle (modèle de données),

V' Une vue (présentation, dialogue utilisateur),

V' Un contrôleur (logique de contrôle, gestion des événements, synchronisation).

95

Cette architecture peut être schématisée de la manière suivante :

Figure 3-18: Implémentation du modèle MVC

Il existe plusieurs architectures de références :

+ Applications web ;

+ Applications clientes riches ;

+ Applications web riches ;

+ Applications mobiles ;

+ Applications à base de services ;

+ ...

? Pour l'architecture de référence, nous avons fait le choix de l'application web client

léger, car c'est un pattern architectural le plus classique aujourd'hui et correspond donc aux applications Internet/intranet pour lesquelles la configuration du client n'est pas maîtrisable, à ceci près que l'on requiert côté client un navigateur web assez récent, comprenant le langage JavaScript. Le client navigue sur des pages dotées d'intelligence (programmée en JavaScript).

? Pour les composants logiciels, nous avons retenu comme composants ceux qui suivent : ? Le navigateur client : à l'occurrence de Google Chrome, d'Opera mini, Mozilla Firefox, ? Le Framework pour le développement du code source du logiciel, à l'instar de PHP, Symphony, Laravel, ASP.NET CORE, ...

? Le Framework pour le style de présentation et d'animation des pages web, comme Bootstrap, Bulma, MDB, JQuery, AdminLte, ...

? Le serveur de données à l'exemple de MySQL, SQL Server, Oracle Server, ...

? Le serveur d'application et le serveur Web(http) : Apache, Tomcat, Glashfish, IIS, ...

^{Navigateur Internet explorer}

^{Poste Secrétaire du Jury}

^{Navigateur Opera mini}

^{Navigateur Mozilla}

^{Navigateur Safari}

^{Poste Webmaster}

^<<artifact>>

^<<artifact>>

^<<artifact>>

^<<artifact>>

^<<device>>

^<<device>>

^{Poste SGAC}

^{Poste Caissière}

^<<device>>

^<<device>>

^{SERVEUR WEB}

^<<artifact>>

^{Site web de publication des résultats.php}

Figure 3-19: Diagramme de déploiement

96

? Le choix du serveur HTTP Apache est du fait qu'Apache est un serveur HTTP open-source pour les systèmes d'exploitation modernes. Le but de ce projet est de fournir un serveur sécurisé, efficace et extensible qui fournit des services HTTP respectant les standards HTTP actuels. Nous l'avons utilisé pour nous aider à configurer les Virtual hosts afin de nous permettre de faire des tests sur le déploiement en réseau local.

? Pour les composants matériels, les matériels suivants seront utilisés :

? Les postes de travail : Les Ordinateurs Personnels et/ou téléphones intelligents (Smart phones) ;

? Les différents éléments pour la connexion sans fil comme le routeur, modem, câbles réseaux, VSAT, le point d'accès, ...

? Quant au formalisme qui va nous servir à décrire graphiquement les aspects structurels liés à l'architecture d'un logiciel : nous avons choisi le diagramme de déploiement, pour visualiser, spécifier et documenter les décisions au sujet de la topologie et de la vue physique de notre système.

97

III.3.2. CONSTRUCTION DE LA BASE DE DONNEES RELATIONNELLE

Il est possible de traduire un diagramme de classes en modèle relationnel. Bien entendu, les méthodes des classes ne sont pas traduites. Aujourd'hui, lors de la conception de bases de données, il devient de plus en plus courant d'utiliser la modélisation UML plutôt que le traditionnel modèle entités - associations.

Cependant, à moins d'avoir respecté une méthodologie adaptée, la correspondance entre le modèle objet et le modèle relationnel n'est pas une tâche facile. En effet, elle ne peut que rarement être complète puisque l'expressivité d'un diagramme de classes est bien plus grande que celle d'un schéma relationnel.

Nous référant de toutes les notions sur la représentation d'un schéma relationnel, voici notre modèle physique de données :

CREATE DATABASE pubresultat; USE pubresultat;

CREATE TABLE promotion (codepr VARCHAR (10) NOT NULL PRIMARY KEY, nompr VARCHAR (25) NOT NULL, faculte VARCHAR (80) NOT NULL);

CREATE TABLE etudiant (mat_etudiant VARCHAR (10) NOT NULL PRIMARY KEY, nom_etudiant VARCHAR (30) NOT NULL, sexe VARCHAR (10) NOT NULL)

CREATE TABLE caissiere (mat_caissiere VARCHAR (10) NOT NULL PRIMARY KEY, nom_caissiere VARCHAR (30) NOT NULL,contact VARCHAR (20));

CREATE TABLE cours (code_cours VARCHAR (10) NOT NULL PRIMARY KEY, nom_cours VARCHAR (30) NOT NULL,volume_horaire INTEGER (10), ponderation Integer (3));

CREATE TABLE paiements (num_paiement INTEGER AUTO_INCREMENT PRIMARY KEY, facultes VARCHAR (30), codepr VARCHAR (10) NOT NULL, motif_paiement VARCHAR (30) NOT NULL, montant INTEGER (10), date_paiement date, mat_etudiant VARCHAR (10) NOT NULL, mat_caissiere VARCHAR (10) NOT NULL, FOREIGN KEY (mat_etudiant) REFERENCES etudiant(mat_etudiant),FOREIGN KEY (mat_caissiere) REFERENCES caissiere(mat_caissiere), FOREIGN KEY (codepr) REFERENCES promotion(codepr));

98

CREATE TABLE secretaire_jury (mat_sj VARCHAR (10) NOT NULL PRIMARY KEY, nom_sj VARCHAR (30) NOT NULL, gmail_sj VARCHAR (25));

CREATE TABLE profil (num_inscription INTEGER AUTO_INCREMENT PRIMARY KEY,mat_etudiant VARCHAR (10) NOT NULL, nom_utilisateur VARCHAR (30) NOT NULL,mot_passe VARCHAR (10) NOT NULL,gmail VARCHAR (25), date_creation DATE, FOREIGN KEY (mat_etudiant) REFERENCES etudiant (mat_etudiant));

CREATE TABLE utilisateur (user_name VARCHAR (20) NOT NULL PRIMARY KEY, pwd VARCHAR (10) NOT NULL);

CREATE TABLE jury (code_jury VARCHAR (10) NOT NULL PRIMARY KEY, nom_jury VARCHAR (10) NOT NULL, effectif_membre INTEGER (5));

CREATE TABLE affectation (num_aff INTEGER AUTO_INCREMENT PRIMARY KEY, mat_sj VARCHAR (10) NOT NULL, codepr VARCHAR (10) NOT NULL, code_jury VARCHAR (10) NOT NULL, date_aff DATE, FOREIGN KEY (mat_sj) REFERENCES secretaire_jury (mat_sj), FOREIGN KEY (codepr) REFERENCES promotion (codepr), FOREIGN KEY (code_jury) REFERENCES jury (code_jury));

CREATE TABLE recours (num_rec INTEGER AUTO_INCREMENT PRIMARY KEY, code_jury VARCHAR (10) NOT NULL, type_session VARCHAR (15) NOT NULL, mat_etudiant VARCHAR (10) NOT NULL,codepr VARCHAR (10) NOT NULL, plaintes VARCHAR (255) NOT NULL, date_rec DATE,FOREIGN KEY (codepr) REFERENCES promotion (codepr), FOREIGN KEY (code_jury) REFERENCES jury (code_jury), FOREIGN KEY (mat_etudiant) REFERENCES etudiant (mat_etudiant));

CREATE TABLE resultat (num_res INTEGER AUTO_INCREMENT PRIMARY KEY, code_jury VARCHAR (10) NOT NULL, types_session VARCHAR (15) NOT NULL, codepr VARCHAR (10) NOT NULL, mat_etudiant VARCHAR (10) NOT NULL,maxima_gen INTEGER (10) NOT NULL, pourcentage DECIMAL (10,0) NOT NULL,decision VARCHAR (5) NOT NULL, nbre_echec INTEGER (5), date_res DATE,FOREIGN KEY (codepr) REFERENCES promotion (codepr), FOREIGN KEY (code_jury) REFERENCES jury (code_jury), FOREIGN KEY (mat_etudiant) REFERENCES etudiant (mat_etudiant));

99

CONCLUSION PARTIELLE

Dans ce chapitre, nous avons vu en particulier comment utiliser la notion de package pour définir des catégories de classes d'analyse et découper le modèle UML en blocs logiques les plus indépendants possibles. Cette structuration logique a été ensuite affinée durant toute l'étape d'analyse. Pour la conception : nous avons défini les architectures nécessaires pour notre site web (client/serveur, modèle MVC, l'application web léger) et nous avons construit notre base de données relation en utilisant MySQL comme SGBD ; mais néanmoins l'analyse restera pour le chef de projet un outil essentiel qui lui permettra d'organiser son processus de développement.

100

CHAPITRE QUATRIEME : IMPLEMENTATION IV.1. INTRODUCTION

En effet, l'évolution de l'informatique a engendré de nouveaux challenges concernant la promotion de techniques et de méthodes permettant de concevoir des interfaces graphiques utiles et utilisables (Koua et Kraak, 2004).

Un service Web est un médium standardisé permettant la communication entre les applications clients et serveurs sur le World Wide Web. Il fournit une plateforme commune permettant à des multiples applications développées avec différents langages de programmation de communiquer entres elles.⁴⁹

Les diagrammes UML développés ne sont donc qu'une façon d'exprimer un problème, ils ne constituent pas une solution. Si nous implémentions les classes telles qu'elles sont identifiées dans les cas d'utilisation fonctionnels, nous passerions à côté d'un véritable travail de conception :

- il n'y aurait pas de recherche de composants existants à réutiliser ;

- aucune recherche d'optimisation ne serait réalisée ;

- les concepts seraient mélangés et on obtiendrait des classes concentrant trop de responsabilités, c'est-à-dire un code objet lourd à maintenir. Ce serait le syndrome des classes obèses.

⁴⁹ Guy PUJOLLE, Les réseaux 2ème édition, éd. Eyrolles, Paris, 2018

101

IV.2. PRESENTATION DES INTERFACES UTILISATEURS

Selon Tony Hoare : « Il y existe deux manières de concevoir un logiciel. La première, c'est de le faire si simple qu'il est évident qu'il ne présente aucun problème. La seconde, c'est de le faire si compliqué qu'il ne présente aucun problème évident. La première méthode est de loin la plus complexe. »

Une interface homme-machine est un assemblage de composants logiciels et matériels qui permet l'accomplissement de tâches avec le concours d'un ordinateur (Coutaz, 1988). L'interface utilisateur doit être conçue de manière à se conformer aux compétences, à l'expérience, aux attentes et au contexte de travail des utilisateurs.

Voici les interfaces utilisateurs de notre site web pour la publication des résultats des étudiants de l'UNIKAM :

1) Page d'accueil pour la gestion des publications des résultats des étudiants de l'Université de Kamina

Figure 4-1: Page d'accueil pour la gestion des publications des résultats des étudiants de l'Université de Kamina

102

2) Page d'authentification

Figure 4-2: Page d'authentification

3) Pages de gestion d'utilisateurs

103

Figure 4-3: Pages de gestion d'utilisateurs

4) Page d'inscription

Figure 4-4: Page d'inscription

104

5) Pages de gestion d'affectation des secrétaires des jurys

Figure 4-5: Pages de gestion d'affectation des secrétaires des jurys

6) Pages de gestion de paiements

105

Figure 4-6: Pages de gestion de paiements

7) Pages de gestion des résultats

Figure 4-8: Page de statistiques résultats

106

Figure 4-7: Pages de gestion des résultats

8) Page de statistiques résultats

107

9) Page de consultation des résultats

Figure 4-9: Page de consultation des résultats

10) Page d'introduction d'un recours

Figure 4-10: Page d'introduction d'un recours

11) Page de consultation de recours

Figure 4-11: Page de consultation de recours

108

CONCLUSION PARTIELLE

Ce chapitre a pour but de procéder à la matérialisation de la solution de conception et son intégration sur différents matériels que nous avons fait au choix technique.

En ingénierie et plus particulièrement en informatique, la mise en oeuvre désigne la création d'un produit fini à partir d'un document de conception ou de spécification. Une partie de l'implémentation ayant déjà été faite dans le chapitre précédant, de ce fait, nous avons présenté justement quelques interfaces illustrant notre site web qui a été développé.

109

CONCLUSION GENERALE

Selon Antoine de Saint-Exupéry, « la perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter mais lorsqu'il n'y a plus rien à retirer. », de ce fait, nous voici au terme de notre travail qui a eu comme thème : « conception et implémentation d'un site web de publication des résultats des étudiants dans une institution universitaire » (cas de l'Université de KAMINA).

« Quelle solution pouvons-nous implémenter afin rendre accessible et d'améliorer la gestion de publication des résultats des étudiants à l'UNIKAM dans la clarté pourvu d'éviter tout désagrément dans ce processus ? », cette question posée à la problématique nous a permis de pouvoir faire la rédaction du cahier des charges tout en captivant les besoins préliminaires et fonctionnalités du futur système.

Après avoir fixé le cahier des charges et les spécifications des fonctionnalités, nous avons procédé à l'analyse suivie par la conception du système informatique et cela selon la méthodologie 2TUP tout en utilisant UML comme langage de modélisation. Le présent travail met en évidence le déroulement et le développement de ces étapes.

Le Thème qui nous a été attribué est très instructif sur le plan pédagogique et très intéressant sur le plan technologique et développement. Nous en tant qu'étudiants en fin de cycle, il nous a permis de :

V' Accroitre nos connaissances.

V' Initier aux différentes technologies de développement (CSS, PHP, CMS, Framework, . . .)

V' Améliorer nos compétences dans la programmation web et dans la programmation orientée objet.

De ce fait, nous avons eu l'occasion au cours de ce projet d'utiliser un ensemble diversifié de logiciels en particulier, XAMPP comme serveur local, PHPStorm 2021.2.2 pour l'implémentation du site tout en utilisant le langage de balisage HTML version 5, le langage de stylisation CSS version 3 et le langage de programmation web dynamique PHP version 8.0.2, pour dessiner les diagrammes nous avons utilisés quelques AGLs dont Star UML version 5.0 et Visual Paradigm version 16.3.0.0.

110

Le but de ce projet était de publier les résultats des étudiants de l'UNIKAM, en assurant plusieurs avantages par rapport à la gestion manuelle des grilles de délibération et à la proclamation habituelle des résultats d'une session donnée à savoir :

- Gestion des paiements des étudiants, qui va faciliter la caisse d'effectuer différents

rapports et des opérations sur les paiements ;

- Contact des internautes ;

- Comptes des étudiants ;

- Recours des étudiants ;

- Les archives du jury pour chaque édition ;

- Publication des résultats des étudiants.

Le système réalisé (site web) permet d'assurer plusieurs fonctionnalités de base à

savoir l'authentification, la création du profil, l'affectation d'un secrétaire dans un jury

(création, modification et suppression), consultation des résultats, leurs statistiques, les recours

postés, l'impression des bons de paiements.

En effet, ce sont aux acteurs même d'assurer la vie de l'outil. Pour cela, ils doivent trouver un intérêt à l'utiliser, au cours de la démarche de conception j'ai toujours gardé cette question à l'esprit afin de créer une application répondant aux attentes tout en restant ouverte et transparente.

Alors, étant donné que nul ne peut se prétendre aborder un domaine dans son ensemble nous souhaiterons venir :

y' Améliorer les interfaces pour qu'elles répondent aux critères ergonomiques.

y' Etablir un système de sécurité des bases de données et limiter le nombre de tentatives d'authentification à l'application.

y' Héberger le site web sur un serveur.

En somme, VINET nous exhorte en disant : « Travaillons avec le même soin que si nos travaux et nous-même devions subsister toujours. Nous qui ne durons pas, faisons des oeuvres qui durent. »

Nous souhaitons que ce travail puisse servir comme un outil d'aide et de documentations pour les étudiants à l'avenir, et une base de travail pour les utilisateurs concernés.

111

BIBLIOGRAPHIE

[En ligne] www.coursgratuit.com/cours/php/php-4 .

[En ligne] https://www.journaldunet.fr.

[En ligne] https://fr.m.wikipedia.org/wiki.

[En ligne] https://saea.uottawa.ca.

[En ligne] https://dictionnaire.lerobert.com.

[En ligne] http://www.initiationreseau.com.

[En ligne] https://exob2b.com/plateformes-developpement-web/.

[En ligne] https://www.lebigdata.fr/base-de-donnees.

Bacco, Alexandre. 2013. Développez votre site web avec le framework Symfony2. Paris : Dassault Systems, 2013.

Blanc, Xavier et Mounier, Isabelle. 2007. UML2 pour les développeurs. Paris : Eyrolles, 2007. Bruno, Albert. 1972. Les méthodes de sciences sociales. Paris : Mont Chrétien, 1972.

Daily, KALOMBO NSHIMBA VIDJE. 2018-2019. Langage de Programmation Orienté Objet. s.l. : Cours Inédit, G3 Informatique, UNIKAM, 2018-2019.

Descartes, René. 1988. Discours de la méthode. Paris : j-VAZI, 1988.

Dubois, Thierry. 2011. Tout pour réussir son site web. Paris : Cours Inédit en ligne, 2011.

EBOUEYA, Michel. 2008. Analyse et Conception des Systèmes d'Information. Douala : Cours Inédit en ligne, 2008.

Gilles, Ferréol. 2000. La Dissertation Sociologique. Paris : ARMAND COLIN, 2000. GRAWITZ, PINTO &. 1972. Méthodes des Sciences Sociales. Paris : Eyrolles, 1972.

HIERDE, Laurent DEBRAUWER et Fien VAN DER. 2004. UML 2 Initiation, exemples et exercices corrigés. Paris : 2ième Edition, ENI Editions, 2004.

Joseph Gabay, David Gabay. 2008. UML 2 analyse et conception (mise en oeuvre guidée avec étude de cas). Paris : Dunod, 2008.

KABUTA, Elie Louis KABWE KIONDE. 2017-2018. cours de MAI 1. s.l. : Cours inédit, G2

INFO, UNIKAM, 2017-2018.

112

KAKONDJA, Bienvenu WILONDJA. 2017-2018. Mise en place d'un modèle d'application web pour la publication des résultats académiques dans les institutions d'enseignement supérieur via la téléphonie cellulaire. ISP/Bukavu : TFE Inédit, 2017-2018.

LEMANIQUE, Jean François PILLOU et Fabrice. 2012-2015. Tout sur les réseaux et internet. Paris : Dunod, 2012-2015.

Louis, KABWE KIONDE KABUTA Elie. 2017-2018. Cours d'Introduction aux Bases de Données. s.l. : Cours Inédit, G2 INFO/UNIKAM, 2017-2018.

M.NEMICHE. 2009-2010. Cours d'Analyse et Conception des Systèmes d'Information. Tunis : Cours inédit en ligne, 2009-2010.

MBALA, Patrick IZATINA. 2014-2015. Conception d'une application web pour la publication des résultats académiques dans un portail documentaire. ISTA/Kinshasa : TFE Inédit, 20142015.

MINGA, Bertin LOBO. 2020-2021. Cours de QSCSI. L2CSI, UNIKAM : Cours inédit, 2020-

2021.

P. Roques, F. Vallée. 2007. UML 2 en action de l'analyse des besoins à la conception. Paris : 4e édition, Eyrolles, 2007.

Pascal Roques. 2006. UML2 par la pratique (Etudes de cas et exercices corrigés). Paris : 5e édition, Eyrolles, 2006.

Pascal Roques, Franck Vallée. 2004. UML 2 en action, De l'analyse des besoins à la conception. Paris : Eyrolles, 2004.

Pascal, Roques. 2007. Les Cahiers du programmeurs UML2 modéliser une application web. Paris : 4e Edition, Eyrolles, 2007.

Pouliquen, Bruno. Cours de HTML. Université de Rennes1 : Cours Inédit.

Rémy Malgouyres. Programmation Web en PHP, Conception, Architectures et Développement de Web Services. Université Clermont Auvergne : Cours inédit.

Robert, MWEMBO LUMBILA NGOIE. 2013. Pour une pratique de la science, Prolégomènes à l'initiation à la recherche scientifique. Lubumbashi : Les moissonneurs, 2013.

Rongere, Pierrette. 1999. Manuel de sociologie générale. Lubumbashi : Africa, 1999.

Ssx'z, MATHX. 12 août 2019. Développez votre site web avec le framework Django. s.l. : inédit, 12 août 2019.

II.2. ETUDE PRELIMINAIRE 32

113

TABLE DES MATIERES

EPIGRAPHE I

IN MEMORIUM II

DEDICACE III

REMERCIEMENTS IV

LISTE DES ABREVIATIONS VI

TABLE DES ILLUSTRATIONS VII

INTRODUCTION GENERALE 1

1. GENERALITES 1

2. CHOIX ET INTERETS DU SUJET 2

2.1. CHOIX DU SUJET 2

2.2. INTERETS DU SUJET 2

3. ETAT DE LA QUESTION 3

4. PROBLEMATIQUE 6

5. HYPOTHESE 7

6. METHODE ET TECHNIQUES 8

6.1. METHODE 8

6.2. TECHNIQUES 9

7. DELIMITATION DU SUJET 10

8. SUBDIVISION DU TRAVAIL 10

CHAPITRE PREMIER : DEFINITION DES CONCEPTS ET CONSIDERATION THEORIQUE 12

I.1. INTRODUCTION 12

I.2. DEFINITION DES CONCEPTS 12

I.2.1. Les concepts clés 12

I.2.2. Les concepts de la technologie du Web 14

I.3. CONSIDERATIONS THEORIQUES ET METHODOLOGIQUES 20

I.3.1. PROCESSUS DE DEVELOPPEMENT LOGICIEL 20

I.3.2. LES LANGAGES DE MODELISATION 24

I.3.3. THEORIE SUR L'IMPLEMENTATION ET LA PROGRAMMATION 27

CONCLUSION PARTIELLE 31

CHAPITRE DEUXIEME : ETUDE PRELIMINAIRE ET CAPTURE DES BESOINS

FONCTIONNELS 32

II.1. INTRODUCTION 32

114

II.2.1. PRESENTATION DU PROJET 33

II.2.2. RECUEIL DES BESOINS FONCTIONNELS 33

II.2.3. CHOIX TECHNIQUES 35

II.2.4. RECUEIL DES BESOINS OPERATIONNELS 35

II.2.5. IDENTIFICATION DES ACTEURS 37

II.2. 6. IDENTIFICATION DES MESSAGES 37

II.2.7. MODELISATION DU CONTEXTE 39

II.3. CAPTURE DES BESOINS FONCTIONNELS 39

II.3.1. DETERMINATION DES CAS D'UTILISATION 40

II.3.2. DESCRIPTION PRELIMINAIRE DES CAS D'UTILISATION 42

II.3.3. DESCRIPTION DETAILLEE DES CAS D'UTILISATION 45

II.3.4. STRUCTURATION DES CAS D'UTILISATION DANS DES PACKAGES 66

I.3.5. IDENTIFICATION DES CLASSES CANDIDATES 68

II.3.6. DEFINITION DES ITERATIONS PAR CLASSEMENT DES CAS

D'UTILISATION 74

CONCLUSION PARTIELLE 76

CHAPITRE TROISIEME : ANALYSE ET CONCEPTION DU SYSTEME INFORMATIQUE 77

III.1. INTRODUCTION 77

III.2. ANALYSE 77

III.2.1. DECOUPAGE EN CATEGORIES 77

III.2.2. DEPENDANCES ENTRE CATEGORIES 78

III.2.3. DIAGRAMME DU PACKAGE D'ANALYSE 80

III.2.4. DEVELOPPEMENT DU MODELE STATIQUE 80

III.2.5. DEVELOPPEMENT DU MODELE DYNAMIQUE 82

III.3. CONCEPTION 93

III.3.1. ARCHITECTURE DU LOGICIEL 93

III.3.2. CONSTRUCTION DE LA BASE DE DONNEES RELATIONNELLE 97

CONCLUSION PARTIELLE 99

CHAPITRE QUATRIEME : IMPLEMENTATION 100

IV.1. INTRODUCTION 100

IV.2. PRESENTATION DES INTERFACES UTILISATEURS 101

CONCLUSION PARTIELLE 108

CONCLUSION GENERALE 109

BIBLIOGRAPHIE 111

115