Développement d'une application web de gestion des activités académiques de l'U.AC

Conclusion

Dans ce chapitre, il a été question de présenter, dans un premier temps, notre milieu d'étude, l'Université de l'Assomption au Congo. En effet, l'Université de l'Assomption au Congo est une institution privée d'enseignement supérieur et universitaire en R.D.Congo. Elle est une initiative de l'ASBL-Pères Assomptionnistes. L'Université de l'Assomption au Congo est d'obédience catholique, ce qui ne veut pas dire que son enseignement est confessionnel. Elle veut que ses étudiants soient « formés à devenir des hommes éminents par leur science, prêts à assumer les plus lourdes tâches dans la société, en temps qu'à être des témoins de la foi dans le monde ». Dans la seconde partie de ce chapitre, nous avons essayé de définir certains concepts en rapport avec notre thématique, à savoir une application Web, Web, Internet, http, système de l'information, système informatique, base de données, système de gestion de base de données, etc.

³³ Georges GARDARIN, Op.Cit., p. 3.

³⁴ Nicolas LARROUSSE, Création de bases de données, Coll. « Synthex », Paris, Pearson Education, 2009, p.2.

³⁵ Georges GARDARIN, Op.Cit., p. 4.

Deuxième chapitre :

ANALYSE ET CONCEPTION DU SYSTÈME FUTUR

II. 0 Introduction

Après avoir présenté notre milieu d'étude et donner le cadre théorique de notre travail, dans ce deuxième chapitre, il s'agit essentiellement de faire l'analyse et la conception pour une solution adéquate d'informatisation de notre système. En effet, analyse et conception sont fondamentalement différentes. L'analyse correspond à la modélisation du problème tandis que la conception correspond à la modélisation de la solution. Entre ces deux niveaux, il y a une relation de résolution, puisque la conception résout l'analyse. Il existe une réelle différence entre le problème et la solution. C'est là d'ailleurs que le travail de développement prend tout son sens : fournir la meilleure solution susceptible de répondre au problème. Avant de développer ces deux niveaux (analyse et conception), nous allons d'abord faire une étude préliminaire.

II.1 Étude préliminaire

L'étude préliminaire nous sert à poser les bases de la capture des besoins de la solution que nous voulons réaliser. Dans un premier temps, nous allons présenter le cahier des charges du projet. Dans un second temps, nous allons identifier les acteurs qui interagiront avec le système. Enfin, nous allons énumérer les différents cas d'utilisation.

II.1.1 Élaboration de cahier de charges

Le cahier des charges est une représentation approximative des besoins réels de l'utilisateur.

17

CAHIER DES CHARGES

Ce projet est à réaliser au sein de l'UAC. Son domaine d'application concerne

certaines activités académiques de l'UAC, et son utilisation quotidienne ne devra pas laisser place à l'éventuel point faible. Ce système répondra donc aux besoins suivants :

1. Besoins fonctionnels L'application doit :

> Permettre l'inscription des nouveaux étudiants et la réinscription des anciens

étudiants.

> Permettre la modification des données enregistrées sur les étudiants et les cours.

> Permettre le suivi automatique des étudiants pendant leur cursus académique.

> Permettre l'impression des listes des étudiants inscrits, des résultats des étudiants.

> Permettre l'affectation des étudiants aux cours.

> Permettre l'attribution des cours aux enseignants.

> Permettre la cotation en ligne par les enseignants.

> Permettre la consultation des résultats en ligne par les étudiants.

2. Besoins non fonctionnels

> L'ergonomie : L'application devra être cohérente du point de vue ergonomique. La qualité de l'ergonomie sera un facteur essentiel, étant donnée l'utilisation intensive qui sera faite de l'application. Un fichier d'aide à l'utilisateur, présentant l'interface et les fonctionnalités seront disponibles.

> Avoir un accès sécurisé et les utilisateurs doivent avoir un accès individualisé et limité aux données.

3. Choix techniques

> Nous avons choisi comme langage de programmation PHP. Pour la réalisation des

interfaces, nous allons utiliser les classes du framework Bootstrap et HTML5.

> SGBD : MySQL

> Langage de modélisation : UML³⁶

> Architecture : client /serveur du type 3-tiers³⁷.

Tableau 1 : Cahier des charges

³⁶ UML (Unified Modeling Language, que l'on peut traduire par « langage de modélisation Unifié ») est un langage permettant de modéliser un problème de façon standard. Ce langage est né de la fusion de plusieurs méthodes existantes auparavant (OMT, BOOCH, OOSE), et est devenu désormais la référence en terme de modélisation objet, à tel point que sa connaissance est nécessaire pour conduire un grand projet. Il est fondé sur les concepts orientés objets et a été conçu pour la modélisation de tous les phénomènes de l'activité de l'entreprise indépendamment des techniques d'implémentation mise en oeuvre par la suite. Il n'est ni une méthode, ni un processus mais un langage de modélisation (Cf. Joseph GABAY et David GABAY, UML2. Analyse et conception. Mise en oeuvre guidée avec études de cas, Coll. « Etudes développement », Paris, Dunod, 2008).

³⁷ Pour l'architecture client/serveur, la charge de travail est répartie entre un ordinateur centralisé, le serveur, et des ordinateurs qui lui sont connectés, les clients. Dans le cas d'une architecture 3-tiers, on sépare les trois « couches » interface homme-machine, application et gestion des données. Un ordinateur client (la couche IHM) transmet ainsi ses requêtes à un serveur d'application qui lui répond en faisant appel à un autre serveur, le serveur de données. L'architecture 3-tiers est le modèle principal d'une informatique distribuée sur Internet (cf. Jean François PILLOU et Christine EBERHARDT, Tout sur le développement logiciel. Écrire du code efficace, Coll. « Comment ça marche », Paris, Dunod, 2011, p.166).

18

II.1.2 Identification des acteurs et leurs rôles

Il s'agit ici d'identifier les acteurs qui interagissent avec le système. Un acteur représente « un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié »³⁸. Pour notre système, nous avons trois acteurs : l'appariteur, l'enseignant et l'étudiant.

						^L'appariteur gère les étudiants. Il s'occupe de l'attribution des cours, de l'affectation ^aux cours, de la gestion des cours par filière et par promotion. Il s'occupe aussi de ^l'impression des listes des étudiants inscrits, des relevés de cotes. Il attribue aux ^enseingants comme aux étudiants des mots de passe afin qu'ils se connectent au système
^Appariteur

^{L'enseignant évalue et dirige l'étudiant inscrit.}

^Enseignant

^{L'étudiant s'inscrit, consulte et imprime ses résultats}

^Etudiant

Figure 3 : Identification des acteurs et leurs rôles

II.1.3 Identification des cas d'utilisation

Les cas d'utilisation pour notre système futur sont : s'authentifier au système, s'inscrire, affecter au cours, attribuer les cours, évaluer l'étudiant, diriger l'étudiant, consulter les résultats, imprimer les résultats et gérer les étudiants.

II.2 Analyse et modélisation du système futur

L'analyse sert à modéliser la « compréhension du problème »³⁹ posé par le client. En fait, l'analyse essaie de comprendre, d'expliquer et de représenter la nature profonde du système qu'elle observe. Elle identifie le quoi faire et l'environnement d'un système, sans décrire le comment qui est le propre de la conception⁴⁰. C'est grâce à cette phase d'analyse que nous saurons ce qui doit être intégré dans la solution, mais aussi ce qui ne doit pas l'être.

³⁸ Pascal ROQUES, UML2 par la pratique. Études de cas et exercices corrigés, 6^e édition, Paris, éd. Eyrolles, 2008, p.16.

³⁹ Xavier BLANC et Isabelle MOUNIER, UML2 pour les développeurs. Cours avec exercices corrigés, Paris, Eyrolles, p. 110.

⁴⁰ Cf. Pierre-Alain MULLER, Modélisation objet avec UML, Eyrolles, Paris, sd, p. 205.

19

Idéalement, une analyse doit être réalisée par l'équipe de développement (MOE) et validée par le client (MOA). « Cette communication est essentielle pour aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la maîtrise d'ouvrage et la maîtrise d'oeuvre informatique) et précises d'un problème donné »⁴¹.

Pourquoi modéliser ? De la même façon qu'il vaut mieux dessiner une maison avant de la construire, il vaut mieux modéliser un système avant de le réaliser. Comme le note Pascal Roques, le recours à la modélisation est depuis longtemps une pratique indispensable au développement logiciel, car un modèle est prévu pour arriver à anticiper les résultats du codage. Un modèle est une représentation abstraite d'un système destiné à en faciliter l'étude et à le documenter. En sus, les systèmes devenant de plus en plus complexes, leur compression et leur maîtrise globale dépassent les capacités d'un seul individu. La construction d'un modèle abstrait aide à y remédier. Le modèle présente l'atout de faciliter la traçabilité du système, à savoir la possibilité de partir d'un de ses éléments et de suivre ses interactions et ses liens avec d'autres parties du modèle⁴². Disons que modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence. Dans le cas qui est le nôtre, nous allons utiliser UML⁴³ pour la modélisation.

II.2.1 Diagramme de cas d'utilisation

Le diagramme de cas d'utilisation est celui qui permet de recueillir, d'analyser et d'organiser les besoins. Il montre les interactions fonctionnelles entre les acteurs et le système à l'étude. Un cas d'utilisation (en anglais « use case ») représente un ensemble de séquences d'actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier. Chaque cas d'utilisation spécifie un comportement attendu du système considéré comme un tout sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce que le système futur devra faire, sans spécifier comment il le fera⁴⁴. L'objectif poursuivi est que « l'ensemble des cas d'utilisation doit décrire exhaustivement les

⁴¹ Laurent AUDIBERT, UML2. De l'apprentissage à la pratique, sl, 2009, pp.12-13.

⁴² Cf. Pascal ROQUES, Les cahiers du programmeur. UML2. Modéliser une application web, 4^e édition, Eyrolles, Paris, 2008, p. 2. Notons qu'« a priori, il n'y a pas une modélisation fausse, il y a seulement de modélisation qui ne reflète pas la réalité » (Jacques GUYOT, Op. Cit., p. 77).

⁴³ UML est avant tout une notation et non une méthode. En d'autres termes, UML ne dicte pas le processus d'élaboration de la modélisation. Il est ouvert aux sociétés de service, éditeurs de logiciel, méthodologues qui peut y ajouter une valeur propre. En effet, UML unifie à la fois les notations et les concepts orientés objet mais également les notations nécessaires aux différentes activités d'un processus de développement et offre le moyen d'établir le suivi des décisions prises, depuis l'expression de besoin jusqu'au codage. UML est un langage de modélisation graphique à base de diagrammes (Cf. ibidem, p. 75).

⁴⁴ Cf. Pascal ROQUES, UML2 par la pratique. Études de cas et exercices corrigés, 6^e édition, Paris, Eyrolles, 2008, pp. 16-17.

20

exigences fonctionnelles du système »⁴⁵. En d'autres termes, chaque cas d'utilisation correspond à une fonction métier du système, selon le point de vue d'un de ses acteurs. Retenons que c'est avec le diagramme de cas d'utilisation que commence l'étape d'analyse.