Projet de Fin d

(1)

REPUBLIQUE TUNISIENNE MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE ET DE LA

TECHNOLOGIE Université de Carthage

Faculté des Sciences Economiques et de Gestion de Nabeul

Réalisation d’une application de soumission de cours en ligne de l’Université Virtuelle de Tunis

Projet de Fin d’Etude

Elaboré par : BEN MESSAOUD Zied

Encadrant à l’UVT : LIMAM Oussama Encadrant à FSEGN : DAKHLAOUI Ahlem

2010-2011

(2)

2

Table des matières

Chapitre I. Présentation général ... 10

I. Introduction ... 11

II. Présentation de l’organisme d’accueil ... 11

II.1. Création de L’Université Virtuel de Tunis ... 11

II.2. Objectif de l’UVT ... 11

II.3. Missions de l’Université Virtuelle de Tunis ... 12

II.4. Organigramme de l'université ... 12

II.5. Présentation du département de l’UVT... 13

II.6. Problématique ... 13

II.7. Solution ... 13

III. Conclusion ... 13

Chapitre II. Etat de l’art ... 14

II. Application Web... 15

III. Architecture client/serveur ... 15

III.1. Caractéristiques d'un serveur ... 15

III.2. Caractéristiques d'un client ... 16

IV. MVC (Model–View–Controller) ... 16

IV.1. Conception au niveau architecture MVC ... 17

IV.1.1. Conception au niveau Modèle... 17

IV.1.2. Conception au niveau Vue ... 17

IV.1.3. Conception au niveau Contrôle ... 17

La raison pour laquelle on a choisi le MVC ... 18

IV.2. ... 18

V. Conclusion ... 18

Approche ... 19

II. Environnement de travail ... 21

II.1. Environnement matériel ... 21

II.2. Environnement Logiciel ... 21

Chapitre IV. Analyse des besoins ... 22

(3)

3

II. Besoins fonctionnels ... 23

II.1. Administration de soumission des cours ... 23

II.1.1. Nouvelle proposition... 23

II.1.2. Proposition incomplet ... 24

II.1.3. Proposition pré-retenu ... 24

II.1.4. Toutes les propositions ... 24

II.1.5. Evaluation ... 24

II.1.6. Production numérique ... 25

II.1.7. Propositions non retenues ... 25

II.1.8. Boite Email ... 25

II.1.9. Déconnexion ... 25

II.1.10. Gestion de contrat ... 25

III. Besoins non fonctionnel ... 26

IV. Conclusion ... 26

Chapitre V. Analyse d’existant ... 27

II. Système logistique déjà existant ... 28

II.1. Page authentification ... 28

II.2. Page de recherche ... 29

II.3. Page d’affichage de résultat de recherche ... 29

II.4. Page des nouvelles propositions... 30

II.5. Page des propositions incomplètes... 30

II.6. Page des propositions pré-retenues ... 30

II.7. Page d’Evaluateur... 30

II.8. Page de la production numérique ... 30

II.9. Page de la proposition non retenues ... 31

II.9.1. Page d’Envoi la proposition à la corbeille : ... 31

II.9.2. Page du rejet après évaluation : ... 31

II.10. Page de la Boite Email : ... 31

II.10.1.1. Page de la configuration : ... 31

II.10.2. Edition des mails type : ... 31

II.10.3. Liste des mails type : ... 32

Chapitre VI. Conception ... 33

(4)

4

II. Diagramme de cas d’utilisation ... 34

II.1. Cas d’utilisation : Gestion de l’Administrateur ... 34

II.2. Cas d’utilisation : l’enseignant ... 38

II.3. Cas d’utilisation : Gestion d’évaluation de cours ... 40

II.3.1. Gestion de fichier d’évaluation... 41

II.3.2. Décision ... 42

II.3.3. Gestion d’Envoi des E-mails ... 43

III. Diagramme de classes ... 44

III.1. Diagramme d’unité d’enseignement ... 44

III.2. Diagramme de gestion d’envoi Email ... 45

III.3. Diagramme de gestion de contrat ... 46

IV. Diagramme de séquence ... 47

IV.1. Gestion des mails ... 47

IV.2. Unité d’enseignement ... 48

IV.3. Gestion de contrat ... 49

V. Conclusion : ... 49

Chapitre VII. Réalisation ... 50

II. Technologie ... 51

II.1. Web 2.0 ... 51

II.2. Développement orienté objet et PHP5 ... 51

II.3. AJAX ... 52

III. Bibliothèques ... 52

III.1. Extjs ... 52

III.2. CodeIgniter ... 52

IV. Application réaliser ... 53

IV.1. Page authentification ... 53

IV.2. Menu de notre application ... 54

IV.3. Interface de toutes les propositions ... 55

IV.4. Interface des enregistrements de toutes les propositions ... 55

IV.5. Interface d’enregistrement d’un dépôt ... 56

IV.6. Interface de l’enregistrement de l’Unité d’Enseignement (UE) ... 56

IV.7. Fiche de proposition... 57

IV.8. Gestion des mails types ... 58

Conclusion ... 58

(5)

5

Table des Figures

Figure 1 : Organigramme de UVT (source UVT) ... 12

Figure 2: Architecture client/serveur (source UVT) ... 16

Figure 3:Schéma récapitulatif (source auteur) ... 17

Figure 4: Modèle en V (source auteur) ... 20

Figure 5:cas d’utilisation de gestion de l’Administrateur ... 34

Figure 6: cas d’utilisation de l’Enseignent... 38

Figure 7:cas d’utilisation d’évaluation de cours ... 40

Figure 8: cas d’utilisation d’évaluation de cours : Gestion d’évaluation ... 41

Figure 9:cas d’utilisation d’évaluation de cours : Décision ... 42

Figure 10: Diagramme d’unité d’enseignement ... 44

Figure 11: Diagramme de gestion d’envoi Email ... 45

Figure 12: Diagramme de gestion de contrat ... 46

Figure 13 : Gestion des mails ... 47

Figure 14: unité d’enseignement ... 48

Figure 15:Gestion de contrat ... 49

Figure 16 : Déblogueur FireFox ... 62

Liste des tables

Tableau 1 : Organigramme du département de L’UVT (source UVT) ... 13

Tableau 2: Environnement matériel (source auteur) ... 21

(6)

6

Tableau 3: Environnement logiciel (source auteur) ... 21

Liste des Fenêtres

Fenêtre 1 Interface authentification ... 28

Fenêtre 3 Page d’affichage des résultat de recherche ... 29

Fenêtre 4 : Page d’Edition des mails type ... 31

Fenêtre 5 : Interface d’authentifier 1 ... 53

Fenêtre 6 : Interface d’authentifier 2 ... 54

Fenêtre 7 : Menu de l’application ... 54

Fenêtre 8 : Interface de toutes les propositions ... 55

Fenêtre 9 : Tableau des enregistrements de toutes les propositions ... 55

Fenêtre 10 : Interface d’enregistrement d’un dépôt ... 56

Fenêtre 11 : Interface de l’enregistrement d’UE ... 56

Fenêtre 12 : fiche de proposition ... 57

Fenêtre 13 : Interface de Gestion des mails types ... 58

(7)

Remerciements

Ce projet est le fruit d'efforts de trois ans tant au niveau des études. C'est pourquoi, je tiens à adresser mes remerciements les plus sincères à tous ceux qui ont contribué à la réalisation de ce travail.

Il en est de même à ma famille qui a consenti des sacrifices et prodigué des encouragements tout au long de mes études

Je remercie Monsieur Oussama LIMAM, ingénieur à UVT et responsable de mon stage pour son encadrement.

Je remercie Madame Ahlem DAKHLAOUI, mon superviseur à l'FSEGN, pour ses conseils pertinents.

Je remercie à tous mes amis, qu'ils trouvent ici l'expression de mes sincères amitiés.

Je tiens aussi à remercier toute l'équipe de UVT pour la bonne ambiance de travail et l'expérience qu'elle m'a permis d'acquérir.

Souhaitons enfin que ce projet soit au niveau de vos attentes et qu'il permette d'enrichir un tant soit peu la bibliothèque de notre Institut.

(8)

Introduction Générale

(9)

Introduction générale

9

L’enseignement est l’une des composants les plus importants dans la société et qui doit suivre l’évolution de la manière dont laquelle les gens procèdent pour vivre. Dans le monde actuel le réseau informatique et l’internet jouent un rôle important dans le quotidien des personnes ce qui nécessite la présence de ce composant d’une façon permanente et bien étudier pour qu’il soit reçu par les étudiants d’une manière simple et rapide.

Le cours en ligne est l’une des plus importants objets qui doit être mis d’une façon numérique pour les étudiants, pour cela, l’Université Virtuelle de Tunis présente le noyau de l’enseignement virtuel en Tunisie regroupe les cours classiques des enseignants puis elle effectue une évaluation au niveau pédagogique et contenue pour qu’elle le reproduise sous un autre format numérique interactive qui lui permet d’être exploité par les étudiants.

Cette procédure devient de plus en plus importante pour réaliser le plus grand nombre de cours qui sera présenté à la fin dans les bibliothèques numériques de l’enseignement virtuelle, ce nombre présente une difficulté de gestion administrative et de suivit ce qui nécessite une application informatique qui permet l’automatisation de gestion et la rapidité de recherche et de traitement des informations qui les concernent jusqu'à le préparation des contrats pour la propriété intellectuelle de cours et conservé son authenticité pour l’enseignant.

Notre projet consiste a automatisé l’opération de gestion des propositions de cours et le suivit de l’évaluation pour que ça ne prend pas beaucoup de temps dans la production et répondre au demande des étudiants en cours interactive dans des divers matières dans des brèves délais.

Dans ce rapport nous présenterons les différentes phases que nous avons effectuées pour élaborer ce projet et donner une application évoluée qui suit les nouvelles technologies dans le développement web.

(10)

Chapitre I. Présentation générale

(11)

Présentation générale

11

I. Introduction

Dans ce chapitre, on présente le cadre général de notre projet. En effet, on commence par la présentation de l’organisme d’accueil. Ensuite, nous décrivons le sujet du projet.

II. Présentation de l’organisme d’accueil

L’Université Virtuelle de Tunis (UVT) est appelée, à long terme, à concrétiser le projet d’une formation ouverte et à distance (FOAD), axée fondamentalement sur l’exploitation des possibilités offertes par les NTIC (Nouvelles Technologies de l’Information et de la Communication) et couvrant une part planifiée de la formation initiale, continue et de l’apprentissage tout au long de la vie.

II.1. Création de L’Université Virtuel de Tunis

La création de l’UVT (1) s’inscrit dans le cadre de la politique de modernisation de l’enseignement supérieur et son ouverture à tous les tunisiens.

L’UVT témoigne du développement des NTIC en Tunisie et atteste l’adaptation de l’enseignement supérieur à ces technologies ainsi que son insertion dans la société du savoir et dans l’économie de la connaissance.

II.2. Objectif de l’UVT

L'objectif majeur de l'Université Virtuelle de Tunis est de proposer des programmes de formations en ligne de qualité utilisant des méthodes pédagogiques d'apprentissage adaptées aux nouvelles technologies et à l'enseignement en ligne.

(1) Par le décret n° 112-02 du 28 janvier 2002

(12)

12

II.3. Missions de l’Université Virtuelle de Tunis Les missions effectuées à l’Université Virtuelle de Tunis :

 Ont organisé, géré et développé l'enseignement non présent.

 Grâce à un accompagnement individualisé de l'apprenant, ont assuré par un tuteur affecté à cet effet et ont visé à mettre en ligne des formations diplômâtes et spécialisées telles que :

• Des formations classiques, visant le niveau de la maîtrise dans diverses disciplines et dont l'éventail s'élargit progressivement.

• Des formations spécialisées post-maîtrisant.

• Des formations courtes à vocation professionnelle.

 Ont mis en place progressivement les assises nécessaires au développement du télé-enseignement.

 Ont encadré les enseignants et les formateurs dans la conception et le développement des cours et des activités en ligne.

 Ont Assuré la formation des enseignants et des administrateurs de la plate- forme (Tutorat, télé-enseignement).

II.4. Organigramme de l'université

Figure 1 : Organigramme de UVT (source UVT)

(13)

13

II.5. Présentation du département de l’UVT

Equipe technique Equipe de production numérique Ingénieurs en informatique Techno-pédagogues

Techniciens (développement informatique, réseaux et sécurité, multimédia, maintenance…)

Techniciens multimédias

Techniciens audio-visuels Infographistes

Tableau 1 : Organigramme du département de L’UVT (source UVT)

III. Problématique

Dans le cadre de l’enseignement en ligne, l’université virtuelle de Tunis reçoit des propositions de cours envoyées par les enseignants pour produire des cours numériques qui seront émis à la disposition des étudiants dans le réseau internet, le nombre de proposition soumit devient de plus en plus nombreux et la gestion de ces cours devient difficile par l’administration.

IV. Solution

L’enseignant doit soumettre sa proposition de cours à l’université virtuelle de Tunis à travers un formulaire après inscription et création d’espace dans une application web qui sera élaboré dans ce contexte.

Ces propositions seront enregistrées dans la base de donnée qui seront traiter par l’administrateur qui va disposer d’un espace de gestion qui lui permet de visualiser l’ensemble des cours soumit et les manipuler selon le processus manuel habituel mais d’une façon automatique informatisé.

V. Conclusion

Ce chapitre nous a servi à mettre le projet dans son cadre. En effet, nous avons présenté l’UVT et notre sujet.

Le chapitre suivant permettra d’introduire plusieurs concepts nécessaires à la compréhension des outils essentiels pour notre projet.

(14)

Chapitre II. Etat de l’art

(15)

Etat de l’art

15 I. Introduction

Dans ce chapitre nous allons illustrer quelques concepts obligatoires dont leur compréhension facilitera le bien déroulement et mettra en évidence les principaux outils que nous aurons besoin dans la réalisation de notre projet.

Ce chapitre se limite à une étude théorique qui interprète les différents outils étudiés afin de garantir la sécurité complète dans la transmission des flux de données.

II. Application Web

Une application Web (aussi appelée site Web dynamique ou WebApp) est un logiciel applicatif manipulable grâce à un navigateur Web. De la même manière que les sites Web, une application Web est généralement placée sur un serveur et se manipule en actionnant des widgets [1] à l'aide d'un navigateur Web, via un réseau informatique (Internet, réseau local, etc.).

Les applications Web font parties de l'évolution des usages et de la technologie du Web appelée abusivement Web2.0.

III. Architecture client/serveur

L'architecture client/serveur désigne un mode de communication entre plusieurs ordinateurs d'un réseau qui distingue un ou plusieurs clients du serveur : chaque logiciel client peut envoyer des requêtes à un serveur. Un serveur peut être spécialisé en serveur d'applications, de fichiers, de terminaux, ou encore de messagerie électronique.

III.1. Caractéristiques d'un serveur

o Il est initialement passif (ou esclave, en attente d'une requête).

o Il est à l'écoute, prêt à répondre aux requêtes envoyées par des clients.

Dès qu'une requête lui parvient, il la traite et envoie une réponse.

(16)

Etat de l’art

16

III.2. Caractéristiques d'un client o Il active le premier (ou maître).

o Il envoie des requêtes au serveur.

o Il attend et reçoit les réponses du serveur.

Le client et le serveur doivent, bien sûr, utiliser le même protocole de communication. Un serveur est généralement capable de servir plusieurs clients simultanément.

Figure 2: Architecture client/serveur (source UVT)

IV. MVC (Model–View–Controller)

Le Modèle-Vue-Contrôleur est une architecture et une méthode de conception qui organise l'interface homme-machine (IHM) d'une application logicielle. Ce paradigme divise l'IHM en un modèle (modèle de données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements, synchronisation), chacun ayant un rôle précis dans l'interface.

L'organisation globale d'une interface graphique est souvent délicate. L'architecture MVC ne résout pas tous les problèmes. Elle fournit souvent une première approche qui peut ensuite être adaptée. Elle offre aussi un cadre pour structurer une application.

Ce modèle d'architecture impose la séparation entre les données, la présentation et les traitements, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la vue et le contrôleur.

(17)

Etat de l’art

17

IV.1. Conception au niveau architecture MVC IV.1.1. Conception au niveau Modèle

La conception adoptée au niveau modèle, consiste à associer une classe pour chaque table de la base de données. Cette conception nous permet de changer le type d'accès des membres d'un objet : nous changeons leurs visibilités (private, public, protected) afin de contrôler l’accès aux propriétés définies dans une classe, ainsi de définir les différentes fonctions appliquer sur une autre (insert, delete, update).

IV.1.2. Conception au niveau Vue

La conception adoptée au niveau vue, consiste à créer une classe qui s’appelle view, elle a comme rôle de charger les vue, en cas d’erreur ; cette classe affiche une page 404 non valide.

IV.1.3. Conception au niveau Contrôle

La conception adoptée au niveau contrôle, consiste à créer une classe qui s’appelle contrôle. Cette dernière est appelée à Contrôler les accès aux différentes layout selon le type de profile.

Figure 3:Schéma récapitulatif (source auteur)

(18)

Etat de l’art

18

IV.2. La raison pour laquelle on a choisi le MVC

Nous avons choisi cette méthode de conception parce qu’elle répond au besoin du notre projet. L’avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Nous avons intérêt à maintenir une grande indépendance entre L'interface utilisateur, La logique applicative et La source de données. Cela simplifie la tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le projet. En effet si l'une des entités change, les deux autres n'aient pas à changer.

V. Conclusion

L’objectif principal de ce chapitre est de définir la méthode de conception, la technique de développement et les différents outils utilisés pour assurer la sécurité des données.

Au niveau du chapitre suivant, nous présenterons l’environnement de travail et le cycle de vie adapté à notre projet.

(19)

Chapitre III. Approche

(20)

Approche

Selon les études que nous avons faites et selon les besoins que nous avons identifiés nous avons choisi de travailler avec le modèle en V afin de réaliser ce projet.

Le modèle en V nous permet de bien suivre notre projet car nous insistons sur la partie test réalisée à chaque étape.

Les étapes de cycle de vie :

1. Etude de faisabilité 2. Spécification 3. Conception globale 4. Conception détaillée

5. Codage

6. Tests unitaires 7. Tests d’intégration 8. Validation

9. Maintenance

Figure 4: Modèle en V (source auteur)

(21)

Approche

21

II. Environnement de travail

II.1. Environnement matériel

Durant tout le cycle du développement, nous avons utilisé un type de PC ayant les caractéristiques suivantes :

Premier PC Marque HP COMPAC

Processeur intel core Duo CPU Fréquence 1.86 GHz

Mémoire 2GO

Disque Dur 320Go

Tableau 2: Environnement matériel (source auteur)

II.2. Environnement Logiciel

Système d’exploitation Windows XP, Windows vista

Langages UML, PHP5, Java script, Java.

Librairies Extjs.

Environnement de

développement intégré (IDE)

Aptana studio.

Serveur XAMPP-MYSQL.

Environnement de conception Poseidon for UML 6 .0.

Tableau 3: Environnement logiciel (source auteur)

III. Conclusion

Dans ce chapitre, nous avons présenté la méthodologie et l’environnement de travail que nous avons élus pour la mise en place du prototype attendu.

Dans le chapitre suivant, nous allons définir les besoins fonctionnels et non fonctionnels de l’application à développer.

(22)

Chapitre IV. Analyse des besoins

(23)

Analyse des besoins

La capture des besoins est l’une des plus importantes activités du cycle de vie d’un logiciel. En effet, c’est dans cette partie qu’on développe les fonctionnalités du système par la description de ses besoins.

Pour assurer les objectifs de notre projet, il est essentiel que nous parvenions à une vue claire des différents besoins escomptés. Il faut déterminer au moindre détail les fonctionnalités attendues.

La spécification de cette partie réside dans l’utilisation du langage naturel permettant à l’utilisateur de lire et surtout de comprendre le résultat de la capture des besoins.

II. Besoins fonctionnels

Cette application permet aux enseignants de proposer ses propres cours en ligne et par la suite elle doit permettre le choix des bons travaux qui seront passés à la production numérique.

II.1. Administration de soumission des cours

Le système d’administration des soumissions de cours est composé par les étapes suivantes :

II.1.1. Nouvelle proposition

L’ensemble des unités d’enseignement soumit par les enseignants afin d’être traité et accepté par l’université virtuel de Tunis.

Cette phase consiste à traiter et suivre les propositions d’unité d’enseignement soumises par les enseignants en remplissant un formulaire sur le portail de l’UVT.

Dans cette phase l’administrateur peut effectuer, sur la base des formulaires déjà remplis, les manipulations suivantes :

 Afficher les soumissions en utilisant une interface de recherches avancées pour restreindre le nombre de soumissions à afficher. Le résultat de la recherche sera affiché dans un tableau contenant des informations utiles pour l’administrateur pour traiter les propositions.

 Traiter les propositions en choisissant un état pour chaque proposition.

L’administrateur a le choix entre trois états qui sont :

o Rejeter la proposition en laissant sa trace (classer la proposition rejeté dans un tableau de rejet).

(24)

24

o Mettre la proposition en Instance : permet à l’administrateur de la vérifier avant de prendre une décision définitive.

o Valider pour évaluation : permet à l’administrateur de vérifier le contenu de l’UE avant de le faire passer à l’évaluation scientifique proprement dite.

o Soumission incomplet : permet a l’administrateur de remettre la proposition à l’enseignant afin qu’ils puissent corriger ou compléter les informations manquantes.

Une case observation est mise à la disposition de l’administrateur qui motive sa prise de décision (exemple : un cours déjà existant, les informations sur l’enseignant ne sont pas encore vérifiées,…)

II.1.2. Proposition incomplet

L’ensemble des unités d’enseignement soumit, dont la qu’elle les informations qui sont remplit par l’enseignant, ne permet pas de prendre une décision pour l’étudier.

II.1.3. Proposition pré-retenu

L’ensemble des unités d’enseignement soumit, dont les propositions qui sont pré- retenu afin d’être étudier de plus.

II.1.4. Toutes les propositions

L’ensemble des unités d’enseignement soumis : dont on trouve toutes les propositions quelques soit des nouvelles, des incomplets, des pré-retenus et aussi les propositions annulées ou rejeté qui ont été envoyé à la corbeille.

II.1.5. Evaluation

L’ensemble des unités d’enseignement soumis qui est accepté par l’administrateur va être étudié et évalué selon leur continu et sa démarche pédagogique.

Cette phase consiste à faire suivre et traiter des données concernant les unités d’enseignement déjà validées pour passer à l’évaluation scientifique.

Dans cette phase l’administrateur peut effectuer, sur la base des unités d’enseignement validé pour évaluation scientifique, des manipulations à savoir :

Afficher les informations sur les soumissions en utilisant une interface de recherches avancées Remplir la fiche de l’évaluateur : consiste à choisir par l’intermédiaire d’un comité d’évaluation (une personne portant garant de l’évaluateur choisi) un évaluateur du contenu scientifique de l’UE et remplir sa fiche.

Remplir la fiche d’évaluation : contiendra les dates des opérations et leurs mouvements.

Modifier l’état des unités d’enseignement (UE) : Permettra à l’administrateur de prendre la décision de faire passer l’UE à la production numérique ou de la faire retirer de la liste des propositions soumises à l’évaluation scientifique.

(25)

25

II.1.6. Production numérique

L’ensemble des unités d’enseignement soumis, accepté et évalué et qui sont envoyé a l’unité technique de production numérique.

II.1.7. Propositions non retenues

L’administrateur de l’application a le choix entre deux états qui sont :

Envoyer la proposition à la corbeille : une proposition qui ne respecte pas la charte et la demande de l’UVT est rejetée à la corbeille.

Rejeter après évaluation : si la proposition a été évaluée négativement l’administrateur décide de retirer la soumission de la liste des soumissions en cours d’évaluation.

Un mail semi-automatique sera envoyé à l’enseignant pour l’informer que son unité d’enseignement est rejetée avec la motivation du rejet.

II.1.8. Boite Email

La gestion des emails consiste à éditer des emails types qui seront, après, envoyés à l’enseignant afin de les informer d’état d’évolution de leur cours soumis

L’édition des emails doit être faite par un éditeur évolué en signalant l’endroit d’affichage des informations dynamiques dans le texte.

Les emails envoyés doit être affichés dans un tableau avec l’email de destinataire et l’état d’envoi, le système doit permettre de transmettre l’email au utilisateur.

II.1.9. Déconnexion

La sortie de la session ou l’application de soumission de cours.

II.1.10. Gestion de contrat

C’est le contrat professionnel entre l’administrateur de la soumission de cours et l’enseignant après l’acceptation de son cours qui est déjà reçu par l’Université Virtuelle de Tunis.

La gestion de contrat peut contenir les règles suivantes : - Choix d'une action

Indiquez si vous voulez modifier un contrat existant ou en créer un nouveau.

- Numéro de contrat

Tapez le numéro de référence qui a été attribué lors de la création du contrat.

- Type de contrat

Sélectionnez le type de contrat qui a été attribué lors de la création du contrat.

- Date de début

Tapez la date de début du contrat attribuée lors de la création de celui-ci.

- Date d'expiration

Tapez la date de fin du contrat attribuée lors de la création de celui-ci.

(26)

26

- Statut du contrat

Sélectionnez le statut qui a été attribué au contrat lors de la création de celui-ci.

III. Besoins non fonctionnel

Notre application doit respecter les besoins non fonctionnels suivants :

 Faciliter la manipulation de l’application.

 Organiser les interfaces de l’application de point de vue graphique : le choix des couleurs, et des styles.

 Accélérer la manipulation de l’application

IV. Conclusion

La spécification des besoins procure une version plus claire du sujet et une compréhension plus profonde des tâches à réaliser. Elle mène également à prévoir les problèmes à rencontrer et chercher les solutions permettant de les éviter. Par conséquent, nous devons spécifier et chercher les moyens possibles pour mettre en place ces solutions et choisir les outils nécessaires pour développer l’application.

Dans le chapitre suivant, nous présenterons les déférentes phases pour analyser les existants de notre projet.

(27)

Chapitre V. Analyse d’existant

(28)

Analyse d’existant

28

I. Introduction

L’application de soumission de cours déjà élaboré à l’UVT par l’équipe de développements a été bien jugée dans le contexte fonctionnel basic. Afin d’améliorer l’architecture technique et prévoir l’évolution au niveau code et fonctionnalité et pour avoir une interactivité vis-à-vis l’administrateur de soumission de cours plus riche.

L’équipe de développement ont prévu le redéveloppement du système.

II. Système logistique déjà existant

II.1. Page authentification

Fenêtre 1 Interface authentification

Cette fenêtre permet à l’utilisateur d’accéder à l’application. Après la saisie de tous les champs, le fait de cliquer sur le bouton « Connexion » permet de se connecter à la base de données pour vérifier si le login et le code d’accès sont corrects ou non.

(29)

29

II.1. Page de recherche

Fenêtre 2 Page de recherche, Toutes les propositions

Après la saisie des données, le fait de cliquer sur le bouton « Rechercher » permet de se connecter à la base de données pour rechercher les unités d’enseignement selon les critères de recherche et les affichées dans un tableau.

II.2.Page d’affichage de résultat de recherche

Résultat de la recherche

Décision à cocher par l’administrateur Il y a 1 soumission trouvée

Date de

soumission UE Diplôme Enseignant

responsable Université Etab Equipe Afficher toutes

les infos Projet Observations

11/01/2008 statistiqu e

Licence fondamenta le

Ali ben Tunis ISG 1 Afficher

tout

modifier modifier

0 Rejeter la proposition

0 Mettre en Instance

0 Valider pour évaluation

Imprimer l’état enregistrer / Annuler

Fenêtre 3 Page d’affichage des résultats de recherche

Cette page contient les enregistrements des unités d’enseignement trouvées par notre application dans la base de données.

Rechercher les propositions d’UE soumises par les enseignants

! il y a 15 soumissions récemment ajoutées ! il y a 40 soumissions non encore traitées Date de soumission : du au Intitulé de l’UE :

Nature de l’UE : Type de diplôme : Parcours :

Enseignant responsable : Grade :

Université : Etablissement :

Membres de l’équipe participante :

Projet : Recherch

er

(30)

30

II.3. Page des nouvelles propositions

Dans cette interface on recherche les nouvelles soumissions soumit par les enseignants après le remplissage du formulaire que l’UVT a déjà mit en place suivant le lien http://pf- fc.uvt.rnu.tn/soumission/. Ces informations seront disponibles à l’administrateur dans un tableau pour qu’il lui permette de prendre des décisions et communiquer avec les personnes concernées.

II.4. Page des propositions incomplètes

Cette page contient des propositions incomplètes de l’unité d’enseignement dans notre application

Après la saisie des données, le fait de cliquer sur le bouton « Rechercher » permet de se connecter à la base de données pour l’affichage de l’enregistrement qui a été sauvegardé

II.5. Page des propositions pré-retenues

De même que la page des propositions incomplètes, cette page contient des propositions pré-retenues de l’unité d’enseignement dans notre application

Après la saisie des données, le fait de cliquer sur le bouton « Rechercher » permet de se connecter à la base de données pour l’affichage de l’enregistrement qui a été sauvegardé

II.6. Page d’Evaluateur

Cette phase consiste à faire suivre et traiter des données concernant les UE déjà validées pour passer à l’évaluation scientifique.

Dans cette phase l’administrateur peut effectuer, sur la base des UE validées pour évaluation scientifique, des manipulations à savoir : afficher les informations sur les soumissions, remplir la fiche de l’évaluateur, remplir la fiche d’évaluation et modifier l’état des UE

II.7. Page de la production numérique

Les soumissions validées et évaluées seront transmises à la production numérique, dans cette phase ils seront gérés dans l’application de gestion de production numérique. Le flux de données déjà présenté sera enrichi dans cette application.

(31)

31

II.8. Page de la proposition non retenues

L’administrateur de l’application a le choix entre deux états qui sont : II.8.1. Page d’Envoi la proposition à la corbeille :

L’application déjà développée gère les unités d’enseignement qui ne représente aucun intérêt scientifique et qui seront refusé par l’administrateur, ces cours ne seront pas supprimés mais simplement ils auront la décision d’administrateur de refus de la proposition, ils peuvent entre exploités ou consultés avec les mêmes interfaces déjà présentés au début de ce chapitre.

II.8.2. Page du rejet après évaluation

Cette page contient les enregistrements de la liste de l’unité d’enseignements rejetés après évaluation dans notre application dans la base de données.

 Un mail semi-automatique sera envoyé à l’enseignant pour l’informer que son unité d’enseignement est rejetée avec la motivation du rejet.

II.9. Page de la Boite Email

La gestion des emails contient deux composants qui sont définis par la configuration et liste des mails type.

II.9.1.1. Page de la configuration

La gestion de ma configuration des emails consiste a élaboré les emails type à envoyer qui seront après soit modifier ou supprimer dans la deuxième rubrique de gestion.

II.9.1.1.1. Edition des mails type

Fenêtre 4 : Page d’Edition des mails type

(32)

32

L’Edition des mails type c’est une zone de texte qui définit les données de configuration : unité d’enseignant, nom et prénom de l’enseignant et aussi une zone de saisie l’email.

II.9.1.1.2. Liste des mails type :

Liste des emails type contienne des liens des emails déjà défini Rejeter, Retirer de la liste, mise en instance, évaluation et production numérique et qui pourra être modifié dans cette rubrique.

III. Conclusion

Dans ce chapitre, nous avons estimé et analysé l’existant de l’ancienne version de notre projet. En outre, nous avons détaillé les différentes fenêtres qui vont être reproduites dans la nouvelle version avec des nouvelles technologies de développement.

Dans ce qui suit nous allons entamer la partie de la conception de tous les cas d’utilisation qui ont été analysés.

(33)

Chapitre VI. Conception

(34)

Conception

L’activité de conception consiste à façonner le système et à lui donner une forme et une architecture répondant à tous les besoins y compris les besoins non fonctionnels. Elle achève le travail déjà commencé au niveau de l’analyse et constitue une base et un point de départ aux activités d’implémentation et de test.

II. Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation est un diagramme UML utilisé pour donner une vision globale du comportement fonctionnel de notre application.

Ce diagramme représente une unité discrète d’interaction entre un utilisateur (homme ou machine) et un système.

Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d'utilisation (use cases).

II.1. Cas d’utilisation : Gestion de l’Administrateur

Figure 5:cas d’utilisation de gestion de l’Administrateur

 Authentifier

Information général : l’administrateur de l’UVT donne son identification et son mot de passe

(35)

Conception

35

Acteur principal : l’administrateur

Condition : l’administrateur de l’UVT veut gérer les soumissions de cours.

Scénario principal :

a.1 l’administrateur choisit notre application a.2 le système affiche le menue principal

a.3 l’administrateur insère ces informations nom utilisateur et mot de passe a.4 le système vérifie ces informations si ces dernières sont vraies alors il donne l’accès à l’administrateur si non il affiche un message de non validité de compte

a.5 le système affiche la page d’accueil si l’utilisateur est un administrateur a.6 le système enregistre tous les détails l’or de la connexion

Relation d’inclusion : gestion de soumission en attente, gestion de soumission pré- retenue, gestion de soumission incomplète, gestion de soumission en production, gestion de soumission en cours d’évaluation

 Gestion de soumission pré-retenue:

Information général : l’administrateur doit gérer la gestion de soumission pré- retenue

Acteur principal : administrateur

Condition : l’administrateur choisit la gestion de soumission pré-retenue Scénario principal :

a.1 l’administrateur s’authentifie à l’application a.2 l’application affiche le menu principal

a.3 l’administrateur choisit la fenêtre pré-retenue de la proposition de cours a.4 l’application affiche à l’utilisateur la fenêtre de proposition de cours

a.5 l’administrateur sélectionne son choix qui concerne de la proposition pré-retenue

a.6 L’application affiche le besoins de l’utilisateur qui concerne au soumission pré-retenue

Relation d’inclusion : s’authentifier et la recherche de soumission

 Gestion des soumissions en cours d’évaluation

(36)

Conception

36

Information général : l’administrateur doit gérer la gestion des soumissions en cours d’évaluation

Acteur principal : Administrateur

Condition : l’administrateur envoie le cours à l’évaluateur pour être évaluer

a.3 l’administrateur envoie le cours à l’évaluateur de soumission de cours a.4 l’application transmit les données pour être évaluer

 Gestion de soumission en production :

Information général : l’administrateur doit gérer la gestion de soumissions en production

Acteur principal : Administrateur

Condition : l’administrateur choisit la gestion de soumissions en production

a.3 l’administrateur choisit la fenêtre « proposition de cours »

a.4 l’application affiche à l’utilisateur la fenêtre de production numérique a.5 l’administrateur sélectionne son choix qui concerne la proposition en production

a.6 L’application renvoie les données ou l’enregistrement Relation d’inclusion : s’authentifier et la recherche de soumission

(37)

Conception

37

 Gestion de soumission en attente:

Information général : l’administrateur doit gérer la gestion de soumission en attente Acteur principal : administrateur

Condition : l’administrateur choisit la gestion de soumission en attente Scénario principal :

a.3 l’administrateur choisit la proposition de soumission en attente

a.4 l’application affiche à l’utilisateur des données après l’évaluation qui sont en état de soumission en attente

 Gestion de soumission incomplète :

Information général : l’administrateur doit gérer la gestion de soumission incomplète dont les informations sur le cours soumis ne sont pas suffisantes pour pendre une décision administrative à son propos

Acteur principal : administrateur

Condition : l’administrateur choisit la gestion de soumission incomplète Scénario principal :

a.3 l’administrateur choisit la fenêtre « proposition de cours »

a.4 l’application affiche à l’utilisateur la fenêtre « proposition de cours » a.5 l’administrateur sélectionne son choix qui concerne la proposition incomplète

a.6 L’application enregistre toutes les modifications ou la mise à jour Relation d’inclusion : s’authentifier et la recherche de soumission

(38)

Conception

38

II.2. Cas d’utilisation : l’enseignant

Figure 6: cas d’utilisation de l’Enseignent

 Ouvrir l’application :

Information général : l’Enseignant peut ouvrir l’application de soumission de cours Acteur principal : Enseignant

Condition : l’Enseignant choisit d’ouvrir l’application de soumission de cours Scénario principal :

a.1 l’Enseignant s’authentifie à l’application

a.2 l’application s’ouverte et affiche le menu principal

Relation d’inclusion : s’authentifier à l’application de soumission de cours

 L’inscrit dans l’application

Information général : Après l’ouverture l’Enseignant doit s’inscrire dans l’application de soumission de cours

Acteur principal : Enseignant

Condition : l’Enseignant choisit de s’inscrire dans l’application de soumission de cours

(39)

Conception

39

a.3 l’Enseignant insère ces informations nom utilisateur et mot de passe a.4 le système vérifie ces informations si ces dernières sont vraies alors il donne l’accès à l’administrateur si non il affiche un message d’interromption

a.5 le système enregistre tous les détails l’or de la connexion

Relation d’inclusion : s’authentifier à l’application de soumission de cours

 Consulter leur compte :

Information général : l’Enseignant doit consulter son compte de la soumission de cours

Condition : l’Enseignant choisit de consulter son compte de l’application de la soumission de cours

a.3 l’Enseignant insère ces informations nom utilisateur et mot de passe a.4 le système vérifie ces informations

a.5 l’Enseignant consulte son compte

Relation d’inclusion : s’authentifier à l’application de la soumission de cours

 Ajouter les informations de son cours :

Information général : l’Enseignant doit consulter son compte pour ajouter des informations dans l’application de la soumission de cours

Condition : l’Enseignant doit mette des informations sur son cours dans son compte de l’application de la soumission de cours

(40)

Conception

40

a.2 l’application s’ouverte et affiche le menu principal a.3 l’Enseignant ajoute les informations de son cours a.4 l’application enregistre ces informations

Relation d’inclusion : s’authentifier à l’application de la soumission de cours

II.3. Cas d’utilisation : Gestion d’évaluation de cours

Figure 7:cas d’utilisation d’évaluation de cours

(41)

Conception

41

II.3.1. Gestion de fichier d’évaluation

Figure 8: cas d’utilisation d’évaluation de cours : Gestion d’évaluation

Information général : l’Evaluateur doit gérer la gestion de fichier d’évaluation dont les informations sur le cours soumis

Acteur principal : Evaluateur

Condition : l’Evaluateur doit gérer le fichier ou le cours pour l’évaluation Scénario principal :

a.1 l’Evaluateur s’authentifie à l’application a.2 l’application affiche le menu principal

a.3 l’Evaluateur doit consulter la fiche d’évaluation a.4 l’application affiche à l’utilisateur la fiche a.5 l’Evaluateur doit ajouter une fiche d’évaluation

a.6 l’Evaluateur peut imprimer la fiche d’évaluation après la consultation

(42)

Conception

42

Relation d’inclusion : s’authentifier, consulter le fiche d’évaluation, ajouter une fiche d’évaluation

Relation d’extension : imprimer une fiche d’évaluation II.3.2. Décision

Figure 9:cas d’utilisation d’évaluation de cours : Décision

Information général : l’Evaluateur doit indiquer l’état des informations qui concernent le cours soit de rejeter après évaluer, soit envoyer la proposition à la corbeille soit sauvegarder la fiche

Condition : l’Evaluateur doit indiquer l’état de l’information de celui de cours d’enseignant

a.1 l’Evaluateur s’authentifie à l’application a.2 l’application affiche le menu principal a.3 l’Evaluateur doit gérer son décision

a.4 l’application affiche à l’évaluateur tout les décisions : proposition pré- retenue, proposition numérique ou rejeter.

(43)

Conception

43

a.5 l’Evaluateur doit choisir l’état de sa décision qui concerne le cours

Relation d’inclusion : s’authentifier, proposition pré-retenue, proposition numérique et rejet AE

II.3.3. Gestion d’Envoi des E-mails

Information général : Après l’évaluation, l’Evaluateur doit envoyer un e-mail à l’enseignant pour informer l’état de son cours

Condition : l’Evaluateur doit indiquer l’état de cours et envoyer à l’enseignant un E-mail

a.1 l’Evaluateur s’authentifie à l’application a.2 l’application affiche le menu principal

a.3 l’Evaluateur doit envoyer un E-mail à l’enseignant

a.4 l’application doit avoir une trace de cet E-mail sur la boite Relation d’inclusion : s’authentifier