Table des matières

Introduction générale.............................................................................................................................4
CHAPITRE 1 :...........................................................................................................................................6
CONTEXE GENERAL.................................................................................................................................6
1.1. Introduction............................................................................................................................6
1.2. Présentation de l’entreprise...................................................................................................6
1.3. Etude préalable de projet.......................................................................................................7
1.3.1. Description de l’existant.................................................................................................7
1.3.2. Solutions proposées........................................................................................................7
CHAPITRE 2 :...........................................................................................................................................8
ANALYSE ET SPECIFICATION DE BESOIN.................................................................................................8
2.1. Introduction............................................................................................................................8
2.2. Identification des acteurs.......................................................................................................8
2.3. Spécification des besoins........................................................................................................9
2.3.1. Les besoins fonctionnels.................................................................................................9
2.3.2. Les besoins non fonctionnels........................................................................................10
2.4. Méthodologie de conception :..............................................................................................10
2.5. Diagramme de Cas d’utilisation............................................................................................12
2.5.1. Définition......................................................................................................................12
2.6. Conclusion :..........................................................................................................................18
CHAPITRE 3 :.........................................................................................................................................18
CONCEPTION........................................................................................................................................18
3.1. Introduction..........................................................................................................................19
3.2. Conception de système........................................................................................................19
3.2.1. Vue statique : diagramme de classes............................................................................19
3.2.2. Vue dynamique : diagramme de séquence...................................................................20
3.3. Conclusion :..........................................................................................................................26
CHAPITRE 4 :.........................................................................................................................................27
IMPLEMENTATION...............................................................................................................................27
4.1. Introduction :........................................................................................................................27
4.2. Environnement de travail et architecture utilisé :................................................................27
4.2.1. Le logiciel de base :.......................................................................................................27
4.2.2. Choix technologique...................................................................................................29
4.2.3. Choix du langage TypeScript.....................................................................................30

1
 4.2.4. Architecture utilisée.....................................................................................................30
4.2.5. Notion de service web..................................................................................................31
4.3. Quelques interfaces..............................................................................................................33
4.3.1. Partie Public..................................................................................................................33
4.4. Conclusion............................................................................................................................36

2
 Liste des figures

Figure 1: faculté des sciences de Monastir.............................................................................................7

Figure 2: UML.......................................................................................................................................11
Figure 3: Diagramme de cas d’utilisation générale...............................................................................14
Figure 4: Diagramme de cas d’utilisation « Gérer site ».......................................................................15
Figure 5: Diagramme de cas d’utilisation« S’authentifier admin»........................................................16
Figure 6: Diagramme de cas d’utilisation « Gérer admin »...................................................................17
Figure 7: Diagramme de cas d’utilisation « Gérer Profil »....................................................................18
Figure 8: cas d’utilisation « Gestion S-utilisateur»................................................................................19
Figure 9: Principaux diagramme étudiés..............................................................................................20
Figure 10: Diagramme de classes statique...........................................................................................21
Figure 11: Diagramme de séquence « Inscription ».............................................................................22
Figure 12: Diagramme de séquence « S'authentifier ».........................................................................23
Figure 13: Diagramme de séquence « Ajouter S-utilisateur »..............................................................25
Figure 14: Diagramme de séquence « Supprimer un S-utilisateur ».....................................................26
Figure 15: PowerAMC...........................................................................................................................28
Figure 16: WebStorm...........................................................................................................................29
Figure 17: WampServer........................................................................................................................29
Figure 18: Bootstrap 4..........................................................................................................................30
Figure 19: Angular 9.............................................................................................................................30
Figure 20: NodeJS.................................................................................................................................31
Figure 21: Notion de service web.........................................................................................................32
Figure 22: Interface « accueil »............................................................................................................34
Figure 23: : Interface « accueil »...........................................................................................................35
Figure 24: Interface « S’authentifier admin ».......................................................................................36
Figure 25: Interface « Ajouter actualité ».............................................................................................37

3
 Introduction générale

Au cours de ces dernières années, les nouvelles technologies de l'information et de la

communication ont connu un bouleversement marqué par l'apparition de l'Internet et par sa
croissance exponentielle.

Face à l’évolution d’internet et ses services, l’université tunisienne fait face à de nouveaux
défis auxquels il lui appartient de répondre. Le site web universitaire devient le principal canal
de communication à travers lequel on pourra la juger et ceci via le contenu des sites. De nos
jours, la qualité des études et les diplômes ne sont pas les seuls moyens pour bien placer
l’université mais aussi le coté communication (site web, réseaux sociaux …) et surtout offrir
une formation pour les étudiants qui soit bien étudiée afin de répondre aux exigences du
marché de l’emploi. Vu que le coté communication est manquante, la tâche qui m’a été
confiée pour le projet de mastère est la création d’un nouveau site web pour la faculté des
sciences de Monastir (FSM) destinés pour ceux qui sont inscrit au Master et Les Doctorants
de ce département. Outre son rôle de présentation du département, ce site offrira un ensemble
de services à la communauté universitaire dont :

+ L'accès au différents servies de site web.

+ Le téléchargement des documents.

+ La consultation des plannings.

+ La consultation des nouvelles actualités.

+La consultation des nouvelles manifestations.

+ L'accès au service de la scolarité pour consulter les notes ou demander un papier

+ L'accès au forum.

+La communication avec les différents membres de site.

Ce présent rapport sera structuré en 6 chapitres :

4
Dans le premier chapitre : Cadre Général on présente le cadre du stage de PFA à savoir
l’organisme de la faculté des sciences de Monastir ainsi que le sujet sur lequel portera le PFA
et la méthodologie de travail adoptée.

Le seconde chapitre : Analyse et spécification des besoins sert à identifier et définir les
acteurs, les besoins fonctionnels et non fonctionnels ainsi que les différents cas d'utilisations
développés.
Le troisième chapitre : Conception est consacré à la conception du projet du point de vue
statique et dynamique permet de faire d’une maniéré détaillée des cas d’utilisation, les
diagrammes de séquence, ainsi que le diagramme de classe complet.
Le dernier chapitre : Réalisation décrit la mise en œuvre du site en décrivant les différents
services.
Ce rapport est clôturé avec une conclusion générale qui résume tout le travail effectué durant
ce stage et présente les perspectives envisagées.

5
 CHAPITRE 1 :
CONTEXE GENERAL

1.1. Introduction
Introduction Aujourd'hui, l'informatique a atteint une prodigieuse évolution technologique
dans différents domaines (réseaux informatiques, bases de données, Web, etc.). Cette
évolution est nécessaire pour remédier aux problèmes rencontrés dans la vie actuelle. Le but
de notre projet est d’avoir passé stage de fin d’année, nous étions accueillis par la faculté des
sciences des Monastir « FSM » qui nous a proposé de créer une plateforme web pour le
partage des données entre les enseignants et étudiants.

1.2. Présentation de l’entreprise

La faculté des sciences de Monastir ou FSM, relevant de l'Université de Monastir (Tunisie),
est fondée en vertu de la loi no 77-81 du 31 décembre 1977.

La FSM offre un cursus universitaire complet et de haut niveau avec un encadrement

disposant d'équipements pédagogiques de pointe. Ses enseignants et chercheurs placent le
développement de la recherche au cœur du processus de rénovation des enseignements et la
formation des futurs universitaires.

Figure 1: faculté des sciences de Monastir

6
1.3. Etude préalable de projet
1.3.1. Description de l’existant
Cette partie est le socle pour bien comprendre le système actuel utilisé au sein de la faculté
des sciences de Monastir et préciser ses objectifs. Cette faculté utilise actuellement un site
web de gestion des étudiants inscrit au sein de cette faculté affichage de leurs notes,
affichage des actualités, espace intranet dédié aux étudiants, ainsi l’affichage des
manifestations, aussi des détails à propos la faculté et la formations en s’appuyant sur les
différents départements. Le problème ici c’est le manque de communication entre les
différents membres de site web et le manque de partage des informations entre eux.

1.3.2. Solutions proposées

L’intégration d’un logiciel informatique dans la plateforme de partage des données entre
les enseignants et les étudiants fut le point tournant : l’élaboration des bases de données et
l’utilisation croissante des systèmes informatisés (logiciels de gestion) ont facilite le
partage ou bien la communication entre les étudiants spécialement inscrit dans le
département informatique et mathématique et leurs enseignants. D’où la nécessité de
l’utilisation d’une application spéciale pour la gestion de ce problème permettant
d’atteindre le point culminant de flexibilité de gestion idéale était souhaitée.

7
 CHAPITRE 2 :
ANALYSE ET SPECIFICATION DE BESOIN

2.1. Introduction
Dans ce chapitre, nous nous intéressons aux fonctionnalités des utilisateurs du site web dans
le but de spécifier clairement les besoins à satisfaire. Nous identifions, dans un premier
temps, les acteurs de notre projet, ensuite nous présentons les besoins fonctionnels ainsi que
les besoins non fonctionnels auxquels doit répondre notre projet.

Nous présentons par la suite les diagrammes de cas d'utilisation nécessaires pour représenter
les besoins d'une manière formelle.

2.2. Identification des acteurs

Les acteurs de notre site sont classés en trois catégories principales :

Admin S-utilisateur Super Admin

L’admin : C'est une personne qui a un accès à toutes les fonctions de ce site web. Il a le
droit d’accepter un s-utilisateur de partager une publication, accepter une publication avant
qu’elle soit afficher sur le site, aussi d’ajouter des manifestations, des actualités, des mises à
jour et des albums photo. Il a aussi un profil personnel, des informations, aussi il peut
contacter les différents membres de site web.
S-utilisateur : c'est une personne qui peut être soit un étudiant soit un enseignant. Il
possède un profil d’utilisateur avec des informations personnelles, il peut gérer son profil
aussi il peut consulter les manifestations les actualités, comme il peut contacter les membres
et les admins et il peut partager des publications.
Super Admin : c'est la personne qui a tous les privilèges il a l’autorité d’ajouter,
supprimer les admins aussi les S-utilisateurs inscrits, supprimer les publications. Cette

8
gestion est assurée à l'aide d'une interface en back office, qui n'est accessible que pour le
super admin.

2.3. Spécification des besoins

Dans cette partie nous nous proposons de lister les différents besoins fonctionnels et non
fonctionnels, auxquels doivent répondre notre application.

1.1.1. Les besoins fonctionnels

Les besoins fonctionnels sont les exigences des différents acteurs et utilisateurs du système.
On peut classer ces besoins fonctionnels selon les acteurs.

S-utilisateur est la première catégorie d'acteurs pour notre système, cet acteur peut :

S’inscrire au site.

Se connecter pour accéder aux différents services via un compte utilisateur.

Visualiser les différents services de site web.
Compléter son profil en renseignant toutes ses informations.
Afficher son profil avec toutes les informations.
Modifier son profil.
Partager une publication.
Consulter le détail d'une annonce d’emploi.
Contacter les membres et les admins.
Accéder aux différents services de ces sites.

L’admin est la deuxième catégorie des acteurs. Ce dernier peut :

S’inscrire au site via un compte admin.

Se connecter pour accéder à son profil.
Compléter son profil en renseignant toutes ses informations.
Gérer son profil.
Déposer une publication.
Consulter les différents services de ce site.
Contacter les membres et les autres admins.
Accepter un S-utilisateur.
Modifier un S-utilisateur.

9
 Ajouter des manifestations.
Ajouter des actualités.
Ajouter des mises à jour.
Ajouter un album photo.

Le super administrateur du plateforme web est la troisième catégorie des acteurs. Cet
utilisateur peut :

Se connecter en tant qu'administrateur.

Gérer les utilisateurs (admins, S-utilisateur) : ajouter, supprimer, modifier et
consulter le profil d’un utilisateur.
Gérer les différents services dans le site : supprimer, consulter, partager.

2.3.1. Les besoins non fonctionnels

Notre système, comme tout autre système d'information doit vérifier des besoins non
fonctionnels, parmi lesquels on peut mentionner :

Sécurité : L'application doit garantir la sécurité et la confidentialité des

informations et les annonces d’emploi des utilisateurs inscrits au site. Ce besoin
doit inclure l'authentification des utilisateurs avec une adresse email valide, un
mot de passe personnel.
Fiabilité : La fiabilité d'un système informatique peut être définie par la
probabilité du fonctionnement sans tomber en panne pendant un certain
intervalle de temps et dans des conditions d'utilisation prédéfinies. Pour notre
application il s'agit d'assurer un fonctionnement sûr et fiable pour les utilisateurs
lors de la navigation.
Aptitude à la maintenance : Notre application doit vérifier la maintenabilité et
la portabilité du code source pour des raisons de réutilisation.
Ergonomie : L'application doit garantir la clarté de l'interface ainsi que la facilité
de manipulation, la simplicité d'utilisation et la navigation intuitive elle doit être
convivial.

10
 2.4. Méthodologie de conception :
Pour notre projet nous avons choisi UML comme outil de conception (Unified Modeling
Langage). Ce langage de modélisation des systèmes, qui utilise des diagrammes pour
représenter chaque aspect d'un système : statique, dynamique en s'appuyant sur la notion
d'orienté objet qui est un véritable atout pour ce langage [1].

Notion d’UML  :

Figure 2: UML

UML se propose de créer un langage de modélisation utilisable à la fois par les

humais (forme graphique) et les machines (syntaxe précise).

L’utilisation des modèles « UML » sert à :

Décomposer le processus de développement.

Mettre en relation les experts des métiers et les analystes.

Coordonner les équipes d’analyse de la réalisation.

Séparer l’analyse de la réalisation.

Prendre en compte l’évolution de l’analyse et du développement.

Migrer facilement vers une architecture objet d’un point de vue

statique.

Les points forts d’UML :

UML est un langage formel et normalisé

Gain de précision

11
 Encourage l’utilisation d’outils

Gage de stabilité

UML est un support de communication performant

Il cadre l’analyse
Il facilite la compréhension de représentations abstraites complexes

Son caractère polyvalent et sa souplesse en font un langage universel

UML a pour objectif de spécifier, construire, visualiser et documenter les

systèmes à base de logiciel
UML n’est pas une méthode mais une notation qui laisse la liberté de conception.
UML est un langage graphique qui permet de modéliser tous les types
de systèmes informatiques mais, qui nécessite toute fois une
méthodologie de conception (UP, RUP, ..).

Les points faibles d'UML

La mise en pratique d'UML nécessite un apprentissage et passe par une

période d'adaptation.

UML n’est pas à l'origine des concepts objets, mais en constitue une étape majeure,

car il unifie les différentes approches et en donne une définition plus formelle.

Le processus (non couvert par UML) est une autre clé de la réussite d'un projet. Or,
l'intégration d'UML dans un processus n'est pas triviale et améliorer un processus est une
tâche complexe et longue.

2.5. Diagramme de Cas d’utilisation

1.1.1. Définition

Ce diagramme est destiné à représenter les besoins des utilisateurs par

rapport au système.
Il constitue un de diagrammes le plus structurants dans l’analyse d’un système.

Acteur : représente un rôle joué par une personne qui interagit

12
directement avec le système étudié.

Cas d’utilisation (use case) : représente un ensemble des 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.

L’utilisation d’un diagramme de cas d’utilisation s’avère indispensables pour

décrire les besoins fonctionnels. Ces diagrammes permettent de décrire
l’interaction entre l’acteur et le système.
C’est l’image d’une fonctionnalité de système déclenchée en réponse à la
stimulation d’un acteur externe.

Diagramme de cas d’utilisation initial

Le modèle de cas d’utilisation générale est représenté dans la figure qui va suivre :

13
 Consulter site

Accepter
<<include>>
publication.
<<include>>

Gérer s
utlisateur <<include>> S'authentifier
Admin
<<include>>

Gérer site
Utilisateur

Admin
Contacter
S admin S'authentifier
<<include>>

Partager
publication.

<<include>>
Gérer <<include>> S'authetifier S-
admins utilisateur
<<include>>

Controler S'authentifier Gérer profil

<<include>>
accés S-admin
S admin S-Utlisateur
<<include>>
Contacter
<<include>> admin

Supprimer
S-utilisateur
Contacter
<<include>> membre

S'inscrire

Figure 3: Diagramme de cas d’utilisation générale

Ce diagramme représente les différentes activités par les différents acteurs de

notre site web afin de pouvoir gérer et contrôler les différents cas

d’utilisation présent dans notre plateforme.

Raffinement de cas d’utilisation « Gérer site »

14
 Modifier Mise
Modifier Ajouter Mise à jour
Supprimer <<extend>> actualité à jour
actualité

Supprimer Mise
<<extend>> à jour
Ajouter <<extend>>
actualité <<extend>>
<<extend>>

<<extend>>

Consulter Consulter Mise à

actualité jour

<<extend>>
<<extend>>
<<include>>
S'authenfier
admin

<<extend>> <<include>>
Gérer site Consulter
manifistation
Admin
<<extend>> <<extend>>
<<extend>>
<<extend>>

Ajouter Supprimer Modifier

manifistation manifistation manifestation

Consulter album
<<extend>> <<include>>
<<extend>>

<<extend>>

Supprimer
Ajouter photo Modifier
photo
photo

Figure 4: Diagramme de cas d’utilisation « Gérer site »

Le diagramme de cas d'utilisation gérer site est représenté par la figure 2.2. Ce diagramme
représente un raffinement du cas d'utilisation gérer site.

L’admin de site web qui a le droit de faire les actions suivantes :

Ajouter, modifier ou supprimer une manifestation.

Ajouter, modifier ou supprimer une actualité.
Ajouter, modifier ou supprimer une mise à jour.
Ajouter, modifier ou supprimer un album photo.

Toutes ses fonctions nécessitent une authentification à l’espace admin.

15
 Raffinement de cas d’utilisation « S’authentifier admin » :

Saisir mot de
<<include>> passe

S'authentifier
Admin

Admin

Saisir email
<<include>>

Figure 5: Diagramme de cas d’utilisation« S’authentifier admin»

Ce cas d’utilisation est nécessaire pour chaque utilisateur de notre

application.

Ce dernier commence par saisir son nom d’utilisateur et mot de passe, le système

vérifie la validité des informations saisies en entrée :

Si les informations saisies sont correctes alors l’admin va rédiger vers la

page d’accueil didié pour l’admin (selon la nature d’acteur).

Si une information est erronée, un message d’erreur s’affichera.

16
 Raffinement de cas d’utilisation « Gérer les admin » :

Ajouter <<include>>
<<extend>> admin

Modifier
admin

<<extend>> <<include>> S'authentifer S

<<extend>> Consulter liste admin
Gérer admin
Supprimer
<<extend>> admin <<include>>
S-Admin

<<extend>>
<<extend>>
Mettre à jours
<<include>>

Contacter
admin
<<include>>

Figure 6: Diagramme de cas d’utilisation « Gérer admin »

Raffinement de cas d’utilisation « Gérer admin» :

Le diagramme de cas d'utilisation gérer admin est représenté par la figure 2.4. Ce diagramme
représente un raffinement du cas d'utilisation gérer admin.

L’admin de site web qui a le droit de faire les actions suivantes :

Ajouter admin.
Supprimer admin.
Modifier admin.
Contacter admin.
Raffinement de cas d’utilisation « Gérer profil » :

17
 <<include>>
Ajouter
<<extend>> informations

Supprimer
informations <<include>>

S'authentifier S
<<extend>> utlisateur

Gérer profil <<extend>> Modifier profil <<include>>

S utlisateur

<<extend>>

Consulter profil
<<include>>

Figure 7: Diagramme de cas d’utilisation « Gérer Profil »

Le diagramme de cas d'utilisation gérer profil est représenté par la figure 2.5. Ce diagramme
représente un raffinement du cas d'utilisation gérer admin.

Le S-utilisateur de site web qui a le droit de faire les actions suivantes :

Ajouter information.
Supprimer information.
Modifier information.

18
 Raffinement de cas d’utilisation « Gestion S-utilisateur» :

Contacter S <<include>>
<<extend>>
utlisateur

<<extend>> Ajouter S -
utlisateur <<include>>

<<extend>> S'authentifier
Gérer S <<extend>>
Consulter liste <<include>> admin
utlisateur
Modifier S-
Admin utilisateur
<<extend>>

<<extend>>
Consulter <<include>>
profil

Mettre à jours

<<include>>

Figure 8: cas d’utilisation « Gestion S-utilisateur»

2.6. Conclusion :
Dans ce chapitre nous avons modélisé notre système en Diagramme de classe général
illustre toutes les fonctionnalités possibles faites par les différents acteurs de notre site afin
de raffiner les cas d’utilisation pour clarifier les fonctions et spécifier de façon détaillée
les aspects fonctionnels de notre système et prendre une réflexion sur les mécanismes
internes de notre système.

CHAPITRE 3 :
CONCEPTION

19
 3.1. Introduction
La conception est une phase primordiale pour développer tout système d'informations.
Cette phase nécessite des méthodes permettant de mettre en place un modèle sur lequel
s'appuie la phase de réalisation.

3.2. Conception de système

Figure 9: Principaux diagramme étudiés

3.2.1. Vue statique : diagramme de classes

Le diagramme de classes est défini par une collection d'éléments de modélisation

statiques, qui décrit la structure statique d'un système [2]. Pour notre plateforme ce
diagramme est constitué des différentes classes, avec les différents attributs et méthodes
associés.

Un Super admin peut être un admin.

Un admin gère des S-utilisateur.
Un admin peut déposer une ou plusieurs publications.
Un admin peut déposer une ou plusieurs manifestations.
Un admin peut déposer une ou plusieurs actualités.
Un admin peut déposer une ou plusieurs albums photo.
Un admin peut déposer une ou plusieurs mises à jour.
Un album photo peut posséder une ou plusieurs photos.
Une publication peut posséder un ou plusieurs commentaires.

20
 Un S-utilisateur peut aussi déposer une ou plusieurs publications.
Un S-utilisateur peut contacter les autres membres et l’admin par un message
contact.
Un admin peut contacter les autres membres et admin par un message contact.

Le diagramme ci-dessous est le diagramme de classes statique :

Album Publication
- id : int - id : int Commentaire
- titre : String - titre : String 1..1 - id : int
1..1 - path : String - image : String
0..* - date : Date
- fichier : String
- description : String
- date : Date
1..* - nbJaime : int
0..*
Photo 0..*
- id : int 0..*
- path : int

1..1

S-Admin 1..1 Admin

1..1 S-utlisateur
- cin : int - id : int
- Logo : String - email : String - id : int
- password : String 1..1 - grades : String
- nom : String - nom : String
1..*
- prénom : String - prénom : String
1..1 - cin : int
- établissement : String
1..1 - université : String
0..* 1..1 1..1 - email : String
- password : String
Manifestation - activate : boolean

- id : int
- titre : String
- date : Date 1..1
- description : String
- image : String 0..*

Message_contact
0..*
- id : int
0..* 0..* - date_création : Date
- sujet : String
Actualité Mise à jour - contenu_msg : String
- id : int - id : int
- titre : String - titre : String
- date : Date - date : Date
- description : String - description : String
- image : String - image : String

Figure 10: Diagramme de classes statique

3.2.1. Vue dynamique : diagramme de séquence

Le diagramme de séquence présente les interactions à mettre en œuvre entre les classes pour réaliser
un résultat, tel qu'un cas d'utilisation. Les communications entre les classes sont reconnues comme

21
des messages. Le diagramme de séquence énumère des objets horizontalement, et le temps
verticalement. Il modélise l'exécution des différents messages en fonction du temps [3].
Inscription

:Interface :Controller :S-utilisateur

S utlisateur

1:Remplir formulaire

2:Vérifier saisie
3:Valider

4:Verifier email

alt Valide 5:Retourner inscription valide

Erreur

6:Afficher un msg d'erreur

Figure 11: Diagramme de séquence « Inscription ».

Pour s’inscrire, l’utilisateur (étudiant, enseignant) doit saisir son E-mail et son mot de passe, le
système vérifie l’email si l’utilisateur est déjà inscrit, s’il n’est pas inscrit il lui affiche son interface
de travail, si non un message d’erreur est affiché.

Pré condition :

Opération demandée par l’utilisateur.

Scénario normale :

1. L’utilisateur doit remplir le formulaire de l’interface inscription.

2. le système contrôle les champs saisis.

3. l’utilisateur valide la saisie.

4. le système vérifie l’existence de l’utilisateur.

5. S’il toutes est valide et l’utilisateur n’existe pas,une
inscription va retourner.

22
 6.Sinon un message d’erreur s’affichera.

3.2.1.1. Diagramme de séquence du cas

d’utilisation « Authentification »
Le diagramme de séquence « S’authentifier » est représenté dans la figure 3.3.

Figure 12: Diagramme de séquence « S'authentifier ».

Pour s’authentifier, l’acteur (admin, étudiant, enseignant) doit être déjà inscrit sur notre plateforme, le
système vérifie le saisie puis il doit vérifier l’exitance de son email, si oui il lui affiche son interface
de travail, si non un message d’erreur est affiché.

Post condition :

L’utilisateur est inscrit.

Pré condition :

23
L’opération d’authentification doit être affichée.
Scénario normale :

1 : L’utilisateur demande page de connexion.

2 : Demander de page d’authentification(Controller).

3 : Retourner page d’authenfication.

4 : Retourner page de connexion.

5 : Remplir le formulaire d’authentification avec le saisie

(email,mot de passe).

6 :Controler la gestion de saisie

Si les informations sont valide :

Si la vérification d’email est valide :

7 :Envoyer les informations vers le controller.

8 :Envoyer les informations vers la base de donné pour

verfier l’existance de email.

9 :Verfier l’email.

SI la verification est valide :

10 :Retourner profil vers le controller.

11 :Retourner profil vers l’interface.

12 :Retourner profil vers l’utilisateur.

Sinon :

13 :verfier l’email.

14 : Retourner email ou mot de passe érroné vers

controller.

24
 15 : Retourner email ou mot de passe érroné vers l
’interface.

16 : Retourner email ou mot de passe érroné vers

l’utilisateur.

Si les informations ne sont pas valide :

17 :Afficher un msg d’erreur.

3.2.1.2. Diagramme de séquence du cas

d’utilisation « Ajouter S-utilisateur »

Le diagramme de séquence « Ajouter S-utilisateur » est représenté dans la figure 3.4.

Ajouter S-utilisateur

:Liste S utlisateur :Ajouter S utlisateur :S utlisateur

Admin

loop [Vérification de saisie et d'existance]

1:Remplir formulaire

2:Vérifier saisie

3:Validation
4:Vérification de l'existance

5:Réessayer remplir

6:Ajouter S-utilisateur

25
Figure 13: Diagramme de séquence « Ajouter S-utilisateur ».
Une fois le l’admin est authentifié et il choisit d’ajouter ou bien d’accepter les utilisateur inscrit dans
la plateforme. L’admin remplit le formulaire, le système vérifie si les informations sont validées, si
oui l'enregistrer pour l’ajouter dans la liste des S-utilisateur.

Post condition :

L’admin doit être authentifié dans son espace.

Pré condition :

Opération demandée par l’admin.

Scénario normale :

1. : L’admin doit remplir le formulaire de l’interface ajouter utilisateur.

2. : le système contrôle les champs saisis.

3 : l’admin valide les information.

4. : le système vérifie l’existence de l’utilisateur.

5 : S’il y a une erreur une demande de réeassayer le
formulaire est envoyer vers l’admin.
6 : Sinon un utilisateur sera ajouté dans l’interface liste des S-
utilisateur.

26
 3.2.1.3. Diagramme de séquence du cas
d’utilisation « Supprimer un S-utilisateur »

Supprimer S utlisateur

:Liste S utlisateur :BD S utlisateur

S admin

1:Choisir S utlisateur à supprimer 2:Supprimer S utlisateur

3:Requête de suppression
4:S utlisateur supprimé

5:Mise à jour

Figure 14: Diagramme de séquence « Supprimer un S-utilisateur »

Cette tâche est accessible seulement par le S-admin et non pas par tous les admins. Le S-admin choisit
le S-utilisateur à supprimer, le système de bd gère une requête de suppression afin de supprimer le S-
utilisateur, une mise à jour sera déclenchée au niveau d’interface liste S-utilisateur.

Post condition :

Le S-admin doit être authentifié dans son espace.

Pré condition :

Opération demandée par le super admin.

.Scénario normale :

1. : Le S-admin doit choisir le S-utilisateur à supprimer.

2. : le cotroller evoie une demande de suppression vers la bd.

27
 3 : Une rêquete de suppression est gèré par la bd.

4. : le système vérifie l’existence de l’utilisateur.

5. : le S-utilisateur est supprimé

6 : Une mise à jour est déclenchée au niveau du l’interface.

3.3. Conclusion :
Dans ce chapitre nous avons présenté la phase de conception de notre
plateforme. Nous avons modélisé notre projet en utilisant la méthode UML en
élaborant le diagramme de classes statique et les diagrammes de séquences.
Toutes ces taches vont être traduites sur des

interfaces qu’on va représenter dans le chapitre suivant.

CHAPITRE 4 :
IMPLEMENTATION

4.1. Introduction :
Après avoir spécifié les traitements ainsi que les données, nous présentons au niveau de ce chapitre
des aspects relatifs à l’implémentation de la solution proposée. Dans ce cadre, nous justifions notre
choix du langage de programmation et les outils de développement. Ensuite, nous proposons quelques
interfaces graphiques de notre projet.

28
 4.2. Environnement de travail et architecture utilisé :
1.1.1. Le logiciel de base :
4.2.1.1. Environnement de conception
Nous avons utilisé comme outil de conception et de modélisation UML le logiciel Sybase Power qui
nous permet de modéliser tous les diagrammes de notre projet.

Power AMC

Figure 15: PowerAMC

Power AMC est un logiciel de conception créé par la société SDP, qui permet de modéliser les
traitements informatiques et leurs bases de données associées. Créé par SDP sous le nom
AMC*Designer, racheté par Power soft, ce logiciel est produit par Sybase depuis le rachat par cet
éditeur en 1995. Hors de France, la version internationale est commercialisée par Sybase sous la
marque Power Designer. [4].

4.2.1.1. Environnement de développement

WebStorm :

WebStorm est un IDE pour les langages Web

(HTML, CSS et JavaScript), développé par l'entreprise JetBrains et
basé sur la plateforme IntelliJ IDEA.

Figure 16: WebStorm

29
 4.2.1.2. Système de gestion de base de données
WampServer :

Wampserver est un paquetage WAMP, une

plateforme de développement web, permettant de
faire fonctionner localement (sans se connecter à un
server externe) des scripts PHP. Wampserver n’est
pas en soi un logiciel, mais n environnement
comprenant deux servers (un server WAMPSERVER
Figure 17: WampServer
web Apache et un serveur de base de données
MYSQL), un interpréteur de script PHP, ainsi
qu’une administration SQL PhpMyAdmin. Il dispose d’interface d’administration
permettent de gérer les alias (dossier virtuels disponible sous Apache), et le démarrage
/arrêt des serveurs. Il permet donc d’installer en une seule fois tous.

4.2.1.3. Les outils de développement

Langage HTML

Nous avons utilisé le langage de balise HTML pour la création des interfaces graphiques.

Langage CSS

CSS est un langage déclaratif simple pour mettre en forme des pages HTML, Il permet de préciser les
caractéristiques visuelles et sonores de présentation d'une page Web : les polices de caractères, les
marges et bordures, les couleurs, le positionnement des différents éléments, etc.

Langage JavaScript

JavaScript est un langage informatique utilisé sur les pages web. Ce langage à la particularité de
s'activer sur le poste client, en d'autres mots c'est votre ordinateur qui va recevoir le code et qui devra
l'exécuter. C'est en opposition à d'autres langages qui sont activé côté serveur.

Bootstrap4

Bootstrap est une collection d'outils utiles à la création du design de

sites et d'applications web. C'est un ensemble qui contient des codes

HTML et CSS, des formulaires, boutons, outils de navigation et autres

éléments interactifs, ainsi que des extensions JavaScript en option.

Figure 18: Bootstrap 4

30
 4.2.2. Choix technologique
4.2.2.1. Frontend :
Angular

Angular (communément appelé "Angular 2+" ou "Angular v2

et plus") est un cadriciel (framework) côté client, open source,
basé sur Type Script, et co-dirigé par l'équipe du projet
« Angular » à Google et par une communauté de particuliers et
de sociétés. Angular est une réécriture complète de AngularJS,
cadriciel construit par la même équipe.

Figure 19: Angular 9

4.2.2.2. Backend :
Nodejs :

Figure 20: NodeJS

Node.js est une plateforme logicielle libre en JavaScript orientée vers les

applications réseau événementielles hautement concurrentes qui doivent pouvoir monter en
charge.

31
Elle utilise la machine virtuelle V8, la librairie libuv pour sa boucle d'évènements, et
implémente sous licence MIT les spécifications CommonJS.

Parmi les modules natifs de Node.js, on retrouve http qui permet le développement de serveur
HTTP. Il est donc possible de se passer de serveurs web tels que Nginx ou Apache lors du
déploiement de sites et d'applications web développés avec Node.js.

Concrètement, Node.js est un environnement bas niveau permettant l’exécution

de JavaScript côté serveur.

4.2.3. Choix du langage TypeScript

TypeScript est un langage de programmation libre et open source développée par MiT
crosoft qui a pour but d’améliorer et de sécuriser la production de code JavaScript. C’est un
sur-ensemble de JavaScript (c’est-à-dire que tout code JavaScript correct peut être utiu lisé
avec TypeScript). Le code TypeScript est transcompilé en JavaScript, pouvant ainsi être
interprété par n’importe quel navigateur web ou moteur JavaScript. Il a été cocréé par
Anders Hejlsberg, principal inventeur de C#.

4.2.4. Architecture utilisée

Dans notre projet, nous utilisons le modèle MVC. C’est un modèle 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 [8].

Ce paradigme regroupe les fonctions nécessaires en trois catégories :

Un modèle : Le modèle représente le cœur (algorithmique) de l'application : traitements des

données, interactions avec la base de données, etc. Il décrit les données manipulées par
l'application. Il regroupe la gestion de ces données et est responsable de leur intégrité. La base de
données sera l'un de ses composants. Le modèle comporte des méthodes standards pour mettre à
jour ces données (insertion, suppression, changement de valeur).
Une vue : Ce avec quoi l'utilisateur interagit se nomme précisément la vue. Sa première tâche est
de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toute action de
l'utilisateur (hover, clic de souris, sélection d'un bouton radio, cochage d'une case, entrée de texte,
de mouvements, de voix, etc.). Ces différents événements sont envoyés au contrôleur. La vue
n'effectue pas de traitement, elle se contente d'afficher les résultats des traitements effectués par
le modèle et d'interagir avec l'utilisateur.

32
 Un contrôleur : Le contrôleur prend en charge la gestion des événements de synchronisation
pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de la vue
et enclenche les actions à effectuer. Si une action nécessite un changement des données, le
contrôleur demande la modification des données au modèle afin que les données affichées se
mettent à jour.

4.2.5. Notion de service web

Figure 21: Notion de service web

Un service web (ou service de la toile1) est un protocole d'interface informatique de la

famille des technologies web permettant la communication et l'échange de données entre
applications et systèmes hétérogènes dans des environnements distribués. Il s'agit donc d'un
ensemble de fonctionnalités exposées sur internet ou sur un intranet, par et pour des
applications ou machines, sans intervention humaine, de manière synchrone ou asynchrone.
Le protocole de communication est défini dans le cadre de la norme SOAP dans
la signature du service exposé (WSDL). Actuellement, le protocole de transport est
essentiellement HTTP. Le concept a été précisé et mis en œuvre dans le cadre de Web
Services Activity2, au W3C, particulièrement avec le protocole SOAP. Associé avec
les échanges de données informatisés (EDI), le consortium ebXML l'a utilisé pour automatiser
des échanges entre entreprises. Cependant le concept s'enrichit avec l'approfondissement des
notions de ressource et d'état, dans le cadre du modèle REST, et l'approfondissement de la
notion de service, avec le modèle SOA.

33
4.3. Quelques interfaces
1.1.1. Partie Public

Interface « accueil »

34
 Figure 22: Interface « accueil ».

Lors de lancement de notre plateforme web, une interface s’affiche qui contient l’espace personnel
,les derniers mise à jour , les actualités et les manifestations.

Interface « inscription Admin »

La figure suivante présente l’interface « inscription » :

Figure 23: : Interface « accueil ».

Tous acteur peut faire une inscription dans notre plateforme web afin d’être accepté par le super
admin ou l’admin , une interface s’affiche qui contient quelques renseignements a remplir.

35
 Interface « S’authentifier Admin »
La figure suivante présente l’interface « S’authentifier Admin » :

Figure 24: Interface « S’authentifier admin ».

Une interface s’authentifier admin s’affiche dés qu’un admin déjà ajouté par le S-admin veut
s’authentifier, en saisie son email et son password.

36
 Interface «Ajouter actualité »

Figure 25: Interface « Ajouter actualité ».

Une parmi les tâches d’un admin est d’ajouter une actualité. Cette interface a pour objectif de définir
une actualité à ajouter.

37
 4.4. Conclusion
Dans ce chapitre nous avons exposé les différents outils de développement de notre application ainsi
que quelques interfaces qui permettent de visualiser les fonctionnalités de notre plateforme web et
nous avons également réalisé la phase de test de notre projet en utilisant des données réelles.

Conclusion

Le but principal pour ce projet de fin d'année est de concevoir et de réaliser une plateforme pour
partager des données entre les enseignants et leurs étudiants, qui met en contact toutes intervenants de
la plateforme, ce projet inclut une plateforme web pour les étudiants et les enseignants de la faculté
des sciences de Monastir., des manifestations et des actualités et des mise à jour et la consultation des
différents évènements. Pour la réalisation de ce projet nous avons utilisé comme Framework de
développement frontend Angular 9 et pour le backend nodejs. Notre base de données est réalisée avec
le SGBD MySQL. Ce rapport est composé de quatre chapitres : le premier chapitre est une
présentation du cadre du projet : l'entreprise au sein de laquelle ont été réalisé ce stage, la
problématique et la présentation du projet. Le second chapitre est consacré à l'analyse et la
spécification des besoins des utilisateurs, et l'étude des cas d'utilisation. Dans le troisième chapitre
nous avons présenté la conception dynamique et statique du projet. La phase de réalisation est décrite
dans le dernier chapitre qui renferme l'environnement de travail, et enfin la mise en place du projet et
les interfaces finales. Au cours de l’évolution du domaine informatique qui rajoute toujours les
solutions rapide pour tous les problèmes au cours du temps ce qui va nous pousser à améliorer cette
plateforme de point de vue contenue (augmenter le nombre des départements connecter actuelle) pour
38
inclure tous les domaines et les départements et pour quoi pas ajouter d’autre fonctionnalités aident à
faciliter la communication et le partage des données entre toutes les facultés au niveau de même
région ou même pays .

39
40