SlideShare une entreprise Scribd logo
1  sur  82
Télécharger pour lire hors ligne
A.U. : 2019-2020
Université de Kairouan
Institut Supérieur d’Informatique et de Gestion de Kairouan
Département Informatique
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du diplôme
de licence fondamental
Option : Science Informatique
Conception et réalisation d’un site web dynamique
Préparé au sein de l’entreprise : Optans
Réalisé par :Khalfaoui Ichraf
Encadrant académique :Mr.Ourimi Ali
Encadrant professionnel : Ben Fradj Safwen
Dédicace
A mes très chers parents
Source de vie, d’amour et d’affection
A ma belle sœur
Source d’amour et d’encouragement
A mes chers frères
Source de joie et de bonheur
A toute ma famille
Source d’espoir et de motivation
A tous mes amis
A vous cher lecteur
1
Remerciement
Avant tout, nous tenons à remercier mon dieu. De nous avoir donné la santé, la volonté et
la patience pour mener à terme notre formation de licence et pouvoir réalise ce travail.
Nous tenons à exprimer nos profonds remerciements à notre encadreur pédagogique Mr
Ourimi Ali qui nous a fourni le sujet de ce rapport et nous a guidés de ses précieux
conseils et suggestions, et la confiance qu’il nous a témoignés tout ou long de ce travail.
Je tiens également à adresser mes remerciements et ma gratitude à mon encadreur
professionnelle Ben Fraj Safwen pour sa disponibilité, son soutien et son aide précieuse
tout au long de ce projet.
Nous tenons a gratifier aussi les membres de jury pour l’intérêt qu’ils ont porté a notre
projet en acceptant d’examiner notre travail.
J’adresse aussi nos remerciements à Mr kalboussi Anis chef de département de
l’Informatique et a tous les enseignants de la filière de science Informatique.
Enfin, on adresse nos sincères sentiment de gratitudes et de reconnaissances atout les
personnes qui ont participe de près ou de loin a réalisation de ce travail.
2
Table des matières
1 Cadre générale du projet 16
1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 17
1.2.1 Présentation générale de l’entreprise . . . . . . . . . . . . . . . . . . 17
1.2.2 les activités principales de l’entreprise . . . . . . . . . . . . . . . . . 17
1.2.3 Fiche de renseignements de l’organisme d’accueil . . . . . . . . . . . 17
1.2.4 Emplacement de l’entreprise . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Présentation du sujet Proposé . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.2 Les Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Méthodologie de Travail adoptée . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 Méthode de Modélisation (Modèle de cycle de vie) . . . . . . . . . . 19
1.4.1.1 Modèle de cycle de vie en CASCADE . . . . . . . . . . . 19
1.4.1.2 Modèle de cycle de vie en V . . . . . . . . . . . . . . . . . 21
1.4.1.3 Modèle de cycle de vie en SPIRALE . . . . . . . . . . . . 21
1.4.2 Langages De Modélisation . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.3 Langages de modélisation textuels . . . . . . . . . . . . . . . . . . . 22
3
Table des matières
1.4.3.1 La vue statique est caractérisée par : . . . . . . . . . . . . 22
1.4.3.2 La vue dynamique est caractérisée par : . . . . . . . . . . 22
1.4.3.3 Les Avantages de langage de modélisation UML : . . . . . 23
1.4.4 Méthode et Langage De Modélisation choisis . . . . . . . . . . . . . 23
1.5 Planning Prévisionnels (Calendrier prévisionnel De Travail) . . . . . . . . . 24
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Spécifications des besoins 25
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . . 27
2.3.2 Liste Des Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . 27
2.3.3 Diagramme de contexte dynamique . . . . . . . . . . . . . . . . . . 28
2.3.4 Description Des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 28
2.3.4.1 Les cas d’utilisation de l’acteur visiteur . . . . . . . . . . . 29
2.3.4.2 Raffinement du cas d’utilisation consulter membre d’équipe 29
2.3.4.3 Raffinement du cas d’utilisation consulter article . . . . . 30
2.3.4.4 Raffinement du cas d’utilisation consulter client . . . . . 31
2.3.4.5 Raffinement du cas d’utilisation consulter service . . . . . 31
2.3.4.6 Raffinement du cas d’utilisation consulter offre . . . . . . 32
2.3.4.7 Raffinement du cas d’utilisation contacter . . . . . . . . . 33
2.3.4.8 Les cas d’utilisation de l’acteur Membre . . . . . . . . . . 33
2.3.4.9 Raffinement du cas d’utilisation authentification membre . 34
4
Table des matières
2.3.4.10 Raffinement du cas d’utilisation gérer client . . . . . . . . 34
2.3.4.11 Raffinement du cas d’utilisation gérer service . . . . . . . 35
2.3.4.12 Raffinement du cas d’utilisation gérer article . . . . . . . . 36
2.3.4.13 Raffinement du cas d’utilisation consulter liste message . . 36
2.3.4.14 Les cas d’utilisation de l’acteur Administrateur . . . . . . 37
2.3.4.15 Raffinement du cas d’utilisation authentification adminis-
trateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.4.16 Raffinement du cas d’utilisation gérer membre . . . . . . . 38
2.3.4.17 Raffinement du cas d’utilisation gérer offre . . . . . . . . . 39
2.3.4.18 Raffinement du cas d’utilisation consulter demande . . . . 39
2.3.5 Diagramme de cas d’utilisation générale . . . . . . . . . . . . . . . 41
2.3.6 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3 Analyse 45
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Présentation de la démarche du modèle d’analyse . . . . . . . . . . . . . . 46
3.3 Analyse des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1 Analyse du cas d’utilisation S’authentification . . . . . . . . . . . . 47
3.3.1.1 Analyse du cas d’utilisation ”s’authentifier” de l’acteur ’ad-
ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1.2 Digramme de collaboration du cas ”s’authentifier” . . . . 47
3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur ’Visiteur’ 48
3.3.2.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Consulter article” et le modèle analyse . . . . . . . . 48
3.3.2.2 Digramme de collaboration du cas ”consulter article” . . . 48
5
Table des matières
3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur ’Visiteur’ 49
3.3.3.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Demander offre” et le modèle analyse . . . . . . . . 49
3.3.3.2 Digramme de collaboration du cas ”Demander Offre” . . . 49
3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur ’Visiteur’ 50
3.3.4.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Envoyer Message” et le modèle analyse . . . . . . . 50
3.3.4.2 Digramme de collaboration du cas ”Demander Offre” . . . 50
3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur ’Membre’ 51
3.3.5.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Ajouter Client” et le modèle analyse . . . . . . . . . 51
3.3.5.2 Digramme de collaboration du cas ”Ajouter Client” . . . . 51
3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur ’Membre’ 52
3.3.6.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Modifier Service” et le modèle analyse . . . . . . . . 52
3.3.6.2 Digramme de collaboration du cas ”Modifier Service” . . . 52
3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’acteur ’Ad-
ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.7.1 Diagramme de traçabilité entre le modèle de cas d’utilisa-
tion ”Supprimer Membre” et le modèle analyse . . . . . . 53
3.3.7.2 Digramme de collaboration du cas ”Supprimer Membre” . 53
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4 Conception 55
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Présentation de la démarche du modèle de conception . . . . . . . . . . . . 56
4.3 Conception des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 57
6
Table des matières
4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’acteur ’Admi-
nistrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.1.1 Diagramme de traçabilité du cas d’utilisation ”s’authenti-
fier” de l’acteur ’Administrateur’ entre le modèle d’analyse
et le modèle de conception . . . . . . . . . . . . . . . . . . 57
4.3.1.2 Diagramme de séquence relative au cas d’utilisation ”s’au-
thentifier” de l’acteur ’Administrateur’ . . . . . . . . . . . 58
4.3.2 Conception du cas d’utilisation ” Consulter article ” de l’acteur ’Vi-
siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.2.1 Diagramme de traçabilité du cas d’utilisation ”consulter
article” de l’acteur ’visiteur’ entre le modèle d’analyse et le
modèle de conception . . . . . . . . . . . . . . . . . . . . 58
4.3.2.2 Diagramme de séquence relative au cas d’utilisation ”Consul-
ter article” de l’acteur ’visiteur’ . . . . . . . . . . . . . . . 59
4.3.3 Conception du cas d’utilisation ” envoyer message” de l’acteur ’Vi-
siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.3.1 Diagramme de traçabilité du cas d’utilisation ”envoyer mes-
sage” de l’acteur ’Visiteur’ entre le modèle d’analyse et le
modèle de conception . . . . . . . . . . . . . . . . . . . . 59
4.3.3.2 Diagramme de séquence relative au cas d’utilisation ”en-
voyer message” de l’acteur ’visiteur’ . . . . . . . . . . . . 60
4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.4.1 Diagramme de traçabilité du cas d’utilisation ”ajouter client”
de l’acteur ’Membre’ entre le modèle d’analyse et le modèle
de conception . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.4.2 Diagramme de séquence relative au cas d’utilisation ”ajou-
ter client” de l’acteur ’Membre’ . . . . . . . . . . . . . . . 62
4.3.5 Conception du cas d’utilisation ” modifier service” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7
Table des matières
4.3.5.1 Diagramme de traçabilité du cas d’utilisation ”modifier ser-
vice” de l’acteur ’Membre’ entre le modèle d’analyse et le
modèle de conception . . . . . . . . . . . . . . . . . . . . 63
4.3.5.2 Diagramme de séquence relative au cas d’utilisation ”mo-
difier service” de l’acteur ’Membre’ . . . . . . . . . . . . . 64
4.3.5.3 Diagramme de traçabilité du cas d’utilisation ”supprimer
membre” de l’acteur ’Administrateur’ entre le modèle d’ana-
lyse et le modèle de conception . . . . . . . . . . . . . . . 65
4.3.5.4 Diagramme de séquence relative au cas d’utilisation ”sup-
primer membre” de l’acteur ’Administrateur’ . . . . . . . 65
4.3.5.5 Diagramme de traçabilité du cas d’utilisation ”demander
offre” de l’acteur ’Visiteur’ entre le modèle d’analyse et le
modèle de conception . . . . . . . . . . . . . . . . . . . . 66
4.3.5.6 Diagramme de séquence relative au cas d’utilisation ”de-
mander offre” de l’acteur ’Visiteur’ . . . . . . . . . . . . . 67
4.4 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.1 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Modèles de paquetages et de déploiement . . . . . . . . . . . . . . . . . . . 68
4.5.1 Modèles de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Implémentation 70
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.1 Environnement de développement . . . . . . . . . . . . . . . . . . . 71
5.2.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Description de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . . 72
8
Table des matières
5.3.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . . . 72
5.3.3 Présentation de l’interface ’contacter’ : . . . . . . . . . . . . . . . . 73
5.3.4 Présentation de l’interface ’liste membre’ : . . . . . . . . . . . . . . 73
5.3.5 Présentation de l’interface ’ajouter client’ : . . . . . . . . . . . . . . 74
5.3.6 Présentation de l’interface ’gérer client’ : . . . . . . . . . . . . . . . 74
5.3.7 Présentation de l’interface ’liste des messages’ : . . . . . . . . . . . 75
9
Table des figures
1.1 logo de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Emplacment de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Modèle de cycle de vie en CASCADE . . . . . . . . . . . . . . . . . . . . . 20
1.4 Modèle de cycle de vie en V . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5 Modèle de cycle de vie en SPIRALE . . . . . . . . . . . . . . . . . . . . . 22
1.6 logo de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Diagramme de contexte Dynamique . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Cas d’utilisateur de l’acteur visiteur . . . . . . . . . . . . . . . . . . . . . . 29
2.4 cas d’utilisation consulter membre d’équipe . . . . . . . . . . . . . . . . . . 29
2.5 cas d’utilisation consulter article . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6 cas d’utilisation consulter client . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 cas d’utilisation consulter service . . . . . . . . . . . . . . . . . . . . . . . 31
2.8 cas d’utilisation consulter offre . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.9 cas d’utilisation contacter . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.10 cas d’utilisation acteur membre . . . . . . . . . . . . . . . . . . . . . . . . 33
2.11 cas d’utilisation authentification membre . . . . . . . . . . . . . . . . . . . 34
10
Table des figures
2.12 cas d’utilisation consulter article . . . . . . . . . . . . . . . . . . . . . . . . 34
2.13 cas d’utilisation gérer service . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.14 cas d’utilisation gérer article . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.15 cas d’utilisation consulter liste message . . . . . . . . . . . . . . . . . . . . 36
2.16 cas d’utilisation acteur administrateur . . . . . . . . . . . . . . . . . . . . 37
2.17 cas d’utilisation authentification administrateur . . . . . . . . . . . . . . . 37
2.18 cas d’utilisation gérer membre . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.19 cas d’utilisation gérer offre . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.20 cas d’utilisation consulter demande . . . . . . . . . . . . . . . . . . . . . . 39
2.21 cas d’utilisation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1 diagramme de traçabilité entre le modèle de cas d’utilisation ”s’authentifier”
et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 digramme de collaboration du cas ”s’authentifier” . . . . . . . . . . . . . . 47
3.3 diagramme de traçabilité entre le modèle de cas d’utilisation ”Consulter
article” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 digramme de collaboration du cas ”consulter article” . . . . . . . . . . . . 48
3.5 diagramme de traçabilité entre le modèle de cas d’utilisation ”Demander
offre” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6 digramme de collaboration du cas ”Demander Offre” . . . . . . . . . . . . 49
3.7 diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer Mes-
sage” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8 digramme de collaboration du cas ”Envoyer Message” . . . . . . . . . . . . 50
3.9 diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter Client”
et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.10 digramme de collaboration du cas ”Ajouter Client” . . . . . . . . . . . . . 51
3.11 diagramme de traçabilité entre le modèle de cas d’utilisation ”Modifier Ser-
vice” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11
Table des figures
3.12 digramme de collaboration du cas ”Modifier Service” . . . . . . . . . . . . 52
3.13 diagramme de traçabilité entre le modèle de cas d’utilisation ”Supprimer
Membre” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.14 digramme de collaboration du cas ”Supprimer Membre” . . . . . . . . . . 53
4.1 Diagramme de traçabilité du cas d’utilisation ”s’authentifier” . . . . . . . 57
4.2 Diagramme de séquence relative au cas d’utilisation ”s’authentifier” . . . . 58
4.3 Diagramme de traçabilité du cas d’utilisation ”consulter article” . . . . . . 58
4.4 Diagramme de séquence relative au cas d’utilisation ”consulter article” . . 59
4.5 Diagramme de traçabilité du cas d’utilisation ”envoyer message” . . . . . 59
4.6 Diagramme de séquence relative au cas d’utilisation ”envoyer message” . . 60
4.7 Diagramme de traçabilité du cas d’utilisation ”ajouter client” . . . . . . . 61
4.8 Diagramme de séquence relative au cas d’utilisation ”ajouter client” . . . 62
4.9 Diagramme de traçabilité du cas d’utilisation ”modifier service” . . . . . . 63
4.10 Diagramme de séquence relative au cas d’utilisation ”modifier service” . . 64
4.11 Diagramme de traçabilité du cas d’utilisation ”supprimer membre” . . . . 65
4.12 Diagramme de séquence relative au cas d’utilisation ”supprimer membre” 65
4.13 Diagramme de traçabilité du cas d’utilisation ”demander offre” . . . . . . 66
4.14 Diagramme de séquence relative au cas d’utilisation ”demander offre” . . 67
4.15 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . . . . . . 72
5.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . . . . . . . 72
5.3 Présentation de l’interface ’contacter’ . . . . . . . . . . . . . . . . . . . . . 73
5.4 Présentation de l’interface ’liste membre’ . . . . . . . . . . . . . . . . . . . 73
5.5 Présentation de l’interface ’ajouter client’ . . . . . . . . . . . . . . . . . . . 74
5.6 Présentation de l’interface ’gérer client’ . . . . . . . . . . . . . . . . . . . . 74
12
Table des figures
5.7 Présentation de l’interface ’liste des messages’ . . . . . . . . . . . . . . . . 75
13
Liste des tableaux
2.1 Description textuelle du cas d’utilisation consulter membre . . . . . . . . 30
2.2 Description textuelle du cas d’utilisation consulter article . . . . . . . . . 30
2.3 Description textuelle du cas d’utilisation consulter client . . . . . . . . . . 31
2.4 Description textuelle du cas d’utilisation consulter service . . . . . . . . . . 32
2.5 Description textuelle du cas d’utilisation consulter offre . . . . . . . . . . . 32
2.6 Description textuelle du cas d’utilisation contacter . . . . . . . . . . . . . . 33
2.7 Description textuelle du cas d’utilisation authfication membre . . . . . . . 34
2.8 Description textuelle du cas d’utilisation gérer client . . . . . . . . . . . . . 35
2.9 Description textuelle du cas d’utilisation gérer service . . . . . . . . . . . . 35
2.10 Description textuelle du cas d’utilisation gérer article . . . . . . . . . . . . 36
2.11 Description textuelle du cas d’utilisation consulter liste message . . . . . . 37
2.12 Description textuelle du cas d’utilisation authentification administrateur . 38
2.13 Description textuelle du cas d’utilisation gérer membre . . . . . . . . . . . 38
2.14 Description textuelle du cas d’utilisation gérer offre . . . . . . . . . . . . . 39
2.15 Description textuelle du cas d’utilisation consulter demande . . . . . . . . 40
2.16 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
14
Liste des tableaux
Introduction générale
Tout le monde prétend aujourd’hui que l’informatique est une révolution fondamentale et
innovante qui a touché considérablement la vie humaine durant le dernier siècle. En réalité,
loin d’être un phénomène pétillant, ou une tendance passagère, l’informatique vient d’être
exploitée dans tous les aspects de la vie. Aucun domaine ne reste à l’abri de cette politique,
ce qui facilite les tâches de l’entreprise ainsi que celle des personnels.
Grâce a la généralisation et de la globalisation, les domaines de l’information et de la
communication ont évolué très rapidement avec l’amélioration des moyens de développement
et de programmation. Cela a conduit à une révolution dans la représentation, l’organisation
et le traitement des données. De nos jours, les sites Web sont devenus des moyens indispen-
sables pour tout type de service couvrant ainsi tous types de besoins. Une société de service
informatique est une entreprise qui énonce et vend des services informatiques. Elle joue le
rôle d’un médiateur entre les clients et les différents bénéficiaires de services présents sur
le marché de l’informatique. Elles sont considérées parmi les entreprises les plus fréquentes
sur le territoire tunisien. Dans ce cadre, se déroule notre projet de fin d’étude qui consiste
à développer un site web d’une société de service informatique. Notre solution vise à infor-
matiser la procédure traditionnelle et exhaustive de traitement des services, l’objectif est
d’organiser le secteur de travail en mettant à sa disposition un outil performant et fiable
permettant aux sociétés de mieux administrer les services et de faciliter l’accès pour leurs
clients. Le pressent rapport décrit notre projet. Il est structuré en cinq chapitres répartis
comme suit :
• Le premier chapitre présente le cadre général du projet dans lequel on va présenter
une description de l’organisme d’accueil en citant les différents problèmes et les
défauts que l’on remarque avec les solutions proposées. Il fournit aussi une étude
comparative entre quelques solutions existantes et quelques méthodologies de concep-
tion.
• Le deuxième chapitre sera consacré pour la spécification des besoins dans lequel on
va citer une étude de l’existant, ensuite on va présenter les besoins fonctionnels et
non fonctionnels.
• Dans le troisième chapitre, nous présentons la démarche du modèle analyse dont le
but d’examiner les différents cas d’utilisation.
• La démarche du modèle de conception ainsi que les différentes conceptions des cas
d’utilisations seront présentés dans le quatrième chapitre.
• Le dernier chapitre sera consacré pour l’implémentation. Tout d’abord on va présenter
l’environnement de développement matériel et logiciel utilisé pour l’application. En-
fin, nous présentons la description de cette dernière via quelques interfaces.
15
Chapitre 1
Cadre générale du projet
Sommaire
1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 17
1.2.1 Présentation générale de l’entreprise . . . . . . . . . . . . . . . . 17
1.2.2 les activités principales de l’entreprise . . . . . . . . . . . . . . . 17
1.2.3 Fiche de renseignements de l’organisme d’accueil . . . . . . . . . 17
1.2.4 Emplacement de l’entreprise . . . . . . . . . . . . . . . . . . . . . 18
1.3 Présentation du sujet Proposé . . . . . . . . . . . . . . . . . . . 18
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.2 Les Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Méthodologie de Travail adoptée . . . . . . . . . . . . . . . . . 19
1.4.1 Méthode de Modélisation (Modèle de cycle de vie) . . . . . . . . 19
1.4.2 Langages De Modélisation . . . . . . . . . . . . . . . . . . . . . . 22
1.4.3 Langages de modélisation textuels . . . . . . . . . . . . . . . . . 22
1.4.4 Méthode et Langage De Modélisation choisis . . . . . . . . . . . 23
1.5 Planning Prévisionnels (Calendrier prévisionnel De Travail) 24
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.1 introduction
Dans ce premier chapitre, nous présentons l’organisme d’accueil , nous décrivons brièvement
l’entreprise dans laquelle nous avons réalisé notre stage tout en citant l’ensemble de ses
16
Chapiter 1 : Cadre générale du projet
activités, par la suite nous avons dégagé les problèmes du système‘ actuel et les solutions
proposées..
1.2 Présentation de l’organisme d’accueil
1.2.1 Présentation générale de l’entreprise
Optans est une société du Technologies et services de l’information basée à Monastir,
elle possède des travailleurs spécialisés dans le développement des applications web et
des applications mobiles. avec un actionnariat et une direction de majorité belges, elle
combine l’exactitude européenne avec la qualité des ressources informatiques tunisiennes
pour donner la solution la plus performante à un coût extrêmement concurrentiel. Elle
applique évidemment les standards de qualité internationaux les plus élevés.
Figure 1.1: logo de l’entreprise
1.2.2 les activités principales de l’entreprise
• l’intégration des solutions open source.
• Développement des application mobiles.
• Des services de marketing internet.
• Développement web.
1.2.3 Fiche de renseignements de l’organisme d’accueil
• Nom de l’entreprise : Optans
• Secteur : Technologie et services de l’information
17
Chapiter 1 : Cadre générale du projet
• Taille de l’entreprise : 2-10 employés 4 sur LinkedIn
• Type :Société de personnes (associés)
• Spécialisations : intégration des solutions open source, Développement web, ap-
plication mobile et Marketing internet
• Date de fondation :2012
• Adresse :Immeuble jaafoura 5000, Monastir
• numéro de Téléphone :(+216) 73 46 32 87
1.2.4 Emplacement de l’entreprise
Figure 1.2: Emplacment de l’entreprise
1.3 Présentation du sujet Proposé
Pendant la période de notre stage de fin d’études dans cette entreprise, Nous avons
suggéré de développer une application web comme un projet dans le but de faciliter et
d’informatiser les tâches manuelles.
1.3.1 Problématique
Pendant la période de stage, nous avons découvert plusieurs problèmes :
• Absence d’accès direct à l’information.
• La présence physique des clients à l’entreprise était obligatoire pour toute consul-
tation ou contact.
• Risque de pertes des informations importantes et confidentielles.
18
Chapiter 1 : Cadre générale du projet
En outre, plusieurs taches sont réalisées manuellement, par exemple :
• Gestion des produits.
• Gestion des clients.
• Gestion des services.
• Gestion des articles .
• Gestion des membres.
• Gestion des offres.
1.3.2 Les Solutions proposées
Pour remédier à ces problèmes, nous avons proposé de développer un site web dyna-
mique qui représente plusieurs fonctionnalités :
• Résoudre le problème du temps perdu dans la gestion (rapidité).
• Les activités de notre entreprise seront bien présentées et organisés dans un site
web.
• Les clients seront capables de contacter et consulter l’entreprise en ligne.
• Éliminer les risques de chevauchement des informations importantes.
• Stocker les informations avec toute sécurité fiabilité.
• Faciliter la gestion.
Grâce à ces solutions le système de notre entreprise sera plus simple et facile.
1.4 Méthodologie de Travail adoptée
Le développement de tout projet informatique nécessite une démarche (méthodologie)
de travail que l’on choisit avant de commencer le projet. Ceci est assurée grâce à un modèle
de conception et des formalismes de notations.
1.4.1 Méthode de Modélisation (Modèle de cycle de vie)
1.4.1.1 Modèle de cycle de vie en CASCADE
Le modèle de cycle de vie en CASCADE a été élaboré en 1970. Le principe du modèle
CASCADE est de diviser le projet en sept phases distinctes sur le principe du non-retour.
Ce modèle est basé sur l’hypothèse : dès le début, nous pouvons définir ce que nous pouvons
réaliser pleinement (expressions des besoins). Dans ce modèle le principe est très simple :
19
Chapiter 1 : Cadre générale du projet
• L’étape peut commencer si son étape précédente est complètement terminée.
• Chaque étape se termine à une date précise avec la production de documents ou
programmes spécifiques.
• Les résultats sont déterminés sur la base des interactions entre les étapes, ils font
l’objet d’un examen approfondi et l’étape suivante n’est franchie que s’ils sont sa-
tisfaisants.
Figure 1.3: Modèle de cycle de vie en CASCADE
Avantages du modèle en cascade :
• C’est un modèle linéaire. Bien sûr, les modèles linéaires sont la méthode de mise en
œuvre la plus simple.
• L’un des grands avantages du modèle CASCADE est la production de documents
à chaque étape du développement du modèle, ce qui facilite la compréhension de la
conception du produit dans chaque procédure.
• Après chaque étape majeure de codage du programme, des tests sont effectués pour
vérifier que le code fonctionne correctement.
• Contrôle facile.
• Faciliter la planification des barrières et des routes.
• Accent sur la documentation et la structure.
• Idéal pour des projets logiciels stables.
Inconvénients du modèle en cascade :
• Mal adapté aux systèmes complexes (processus de développement rarement séquentiel).
• Les tests s’appliquent à l’application globale (pas de validation des besoins).
20
Chapiter 1 : Cadre générale du projet
• Difficile de définir toutes les exigences depuis le début du projet.
• Assez longtemps pour voir quelque chose.
1.4.1.2 Modèle de cycle de vie en V
Le modèle du cycle en V (par comparaison avec les méthodes dites agiles) est un modèle
conceptuel de gestion de projet imaginé à la suite du problème de réactivité du modèle
en cascade. Il permet en cas d’anomalie, de limiter un retour aux étapes précédentes. Les
phases de la partie montante doivent renvoyer de l’information sur les phases en vis-à-vis
lorsque des défauts sont détectes, afin d’améliorer le logiciel.[1]
Figure 1.4: Modèle de cycle de vie en V
1.4.1.3 Modèle de cycle de vie en SPIRALE
Le modèle en spirale a été défini par Barry Boehm en 1988 dans son article ”A Spiral
Model of Software Developpement and Enharnachement”. Le modèle en spirale est un
modèle pour le cours de développement logiciel qui prend les différentes étapes du cycle
V. En mettant en œuvre des versions successives, le cycle recommence en proposant un
produit complet et de plus en plus difficile. Le cycle en spirale met cependant plus l’accent
sur la gestion des risques que le cycle en V.
21
Chapiter 1 : Cadre générale du projet
Figure 1.5: Modèle de cycle de vie en SPIRALE
1.4.2 Langages De Modélisation
1.4.3 Langages de modélisation textuels
UML(Unified Modeling Langage) ou (langage de modélisation unifié) est le langage de
modélisation graphique permettant de réaliser un modèle d’une manière simple avec des
diagrammes. Ce langage définit par des vues et des diagrammes.
1.4.3.1 La vue statique est caractérisée par :
• le cas d’utilisation.
• Diagramme d’objet.
• Diagramme de classes.
• Diagramme de composants.
• Diagramme de déploiement.
1.4.3.2 La vue dynamique est caractérisée par :
• Diagramme de collaboration.
• Diagramme de séquence.
• Diagramme d’activités.
22
Chapiter 1 : Cadre générale du projet
• Diagramme d’état-transition.
1.4.3.3 Les Avantages de langage de modélisation UML :
• facilite les présentations exemplaire et complexes.
• Ce langage est un langage formel :
— Accepte l’utilisation d’outils.
— Assure la précision.
— Assure la stabilité.
• Ce langage peut servir de support pour tout langage de programmation orientée
objet.
Figure 1.6: logo de UML
1.4.4 Méthode et Langage De Modélisation choisis
Pour développer les étapes d’analyse, de conception et de mise en œuvre, nous avons
choisi une méthodologie qui comprend :
— La modèle de vie en CASCADE comme méthode de modélisation pour les raisons
suivantes :
— Les besoins fonctionnels et non fonctionnels de notre projet sont déterminés dès
le départ ...
— la démarche linéaire du modèle en CASCADE est simple à adopter et appliquer
dans les projets.
• Le langage de modélisation sélectionné est UML pour les raisons suivantes :
— UML permet de couvrir le cycle de vie dans CASCADE pour déterminer les
besoins.
— Activer l’encapsulation et le traitement des données.
23
Chapiter 1 : Cadre générale du projet
1.5 Planning Prévisionnels (Calendrier prévisionnel
De Travail)
La clé principale de la réussite d’un projet est un bon planning. En fait, la planification
permet de bien répartir le travail et sépare les tâches à effectuer, elle fournit la meilleure
estimation et la gestion du temps nécessaires pour chaque tâche. En outre, il donne un
aperçu de l’arrondi de la date d’achèvement de chaque tâche. L’élaboration du cahier
des charges, la conception et le développement d’un projet informatique nécessite une
organisation et un bon découpage des différentes étapes du projet.
1.6 Conclusion
Dans ce premier chapitre nous avons présenté le cadre général de notre projet avec
une description générale de l’entreprise ensuite nous avons proposé des solutions afin de
résoudre les différents problèmes.
24
Chapitre 2
Spécifications des besoins
Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . 27
2.3.2 Liste Des Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . 27
2.3.3 Diagramme de contexte dynamique . . . . . . . . . . . . . . . . . 28
2.3.4 Description Des cas d’utilisation . . . . . . . . . . . . . . . . . . 28
2.3.5 Diagramme de cas d’utilisation générale . . . . . . . . . . . . . . 41
2.3.6 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . 43
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.1 Introduction
Après avoir défini l’objectif dans le chapitre précédent, nous consacrons ce chapitre à
l’identification des besoins fonctionnels et non fonctionnels d’écriture d’acteurs sur notre
site. Nous fournirons une description détaillée des principaux cas d’utilisation sur la base
des résultats de l’analyse des besoins.
25
Chapiter 2 : Spécifications des besoins
2.2 Etude de l’existant
Avant d’identifier les besoins, il est important de mener une étude de l’existant, ce qui
est une étape majeure pour réaliser notre site web. Pour notre étude, deux tâches doivent
être abordées :
2.2.1 Présentation de l’existant
Le système d’information doit actuellement être automatisé pour poursuivre le développ-
ement technologique et améliorer la production de services. Dans notre cas, la communi-
cation entre les différents acteurs est un problème très important. Plusieurs problèmes
caractérisent la gestion actuelle de l’information et de la communication entre les acteurs.
Parmi ces problèmes, nous pouvons citer : L’absence d’une plate-forme numérique et in-
formatique qui s’adapte aux nouvelles technologies. De plus, les informations des clients
sont traitées manuellement, ce qui entraı̂ne une perte d’informations. En fait, cette société
est connue comme une entreprise avec de nombreuses ressources. Le stockage des données
devient chaque jour plus fragile et plus important.
2.2.2 Critiques de l’existant
La critique de l’existant fournit une étape nécessaire importante. Son objectif est d’ex-
primer une opinion pour développer tout défaut existant dans le système actuel afin de
proposer un système plus fiable que l’ancien. A partir des observations que nous avons vues
dans notre entreprise, nous avons distingué des problèmes suivants :
• Problème de réalisation des informations sur les services disponibles.
• L’utilisation de documents dans l’entreprise peut ralentir le travail et cela nous
donne un faible rendement.
• L’absence d’une application web ne peut pas mettre en valeur l’entreprise sur le
marché.
• Problème de connaı̂tre l’emplacement de l’agence.
• Perte de temps dans l’administration due à l’utilisation de documents.
26
Chapiter 2 : Spécifications des besoins
2.3 Besoins Fonctionnels
Dans cette partie, nous définissons les spécifications des exigences qui sont le point de
départ de notre projet, l’application fournit des services en fonction des profils d’utilisateurs
et des différents traitements nécessaires pour effectuer les tâches qui assureront les objectifs
de l’application.
2.3.1 Diagramme De contexte Statique
Figure 2.1: Diagramme De contexte Statique
2.3.2 Liste Des Besoins Fonctionnels
Visiteur :
• Consulter membre.
• Consulter .
• Consulter service.
• Consulter client.
• Consulter .
• Contacter.
Membre :
• S’authentifier.
27
Chapiter 2 : Spécifications des besoins
• Gérer client.
• Gérer service.
• Gérer article.
• Consulter liste des messages.
Administrateur :
• S’authentifier.
• Gérer les membres .
• Gérer offre.
• Consulter liste des demandes.
2.3.3 Diagramme de contexte dynamique
Figure 2.2: Diagramme de contexte Dynamique
2.3.4 Description Des cas d’utilisation
Les diagrammes de cas d’utilisation sont des diagrammes UML qui sont utilisés pour
donner un aperçu global des fonctionnalités du système logiciel. Le cas d’utilisation représente
une unité d’interaction distincte entre l’utilisateur (humain ou machine) et le système. Il
s’agit d’une unité de travail importante. Dans un diagramme de cas d’utilisation, les utili-
28
Chapiter 2 : Spécifications des besoins
sateurs sont appelés acteurs (en anglais actors )et interagissent avec les cas d’utilisation
(use cases).
2.3.4.1 Les cas d’utilisation de l’acteur visiteur
Figure 2.3: Cas d’utilisateur de l’acteur visiteur
2.3.4.2 Raffinement du cas d’utilisation consulter membre d’équipe
Figure 2.4: cas d’utilisation consulter membre d’équipe
29
Chapiter 2 : Spécifications des besoins
Cas d’utilisation
Consulter membre
Acteur Visiteur
Pré condition Connexion établie avec succés
Post condition — liste des membres est affiché
Description du
Scénario principal
— le visiteur clique sur le menu de la consultation des
membre
— Le système affiche l’interface des membres
— le visiteur consulte la liste des membre affichés
Exception Erreur d’affichage
Table 2.1: Description textuelle du cas d’utilisation consulter membre
2.3.4.3 Raffinement du cas d’utilisation consulter article
Figure 2.5: cas d’utilisation consulter article
Cas d’utilisation Consulter article
Acteur Visiteur
Pré condition Connexion établie avec succès
Post condition — liste des articles est affiché
Description du Scénario principal
— le visiteur clique sur le menu de la consultation des
articles
— Le système affiche l’interface des articles
— le visiteur consulte la liste des articles affichés
Exception Erreur d’affichage
Table 2.2: Description textuelle du cas d’utilisation consulter article
30
Chapiter 2 : Spécifications des besoins
2.3.4.4 Raffinement du cas d’utilisation consulter client
Figure 2.6: cas d’utilisation consulter client
Cas d’utilisation Consulter client
Acteur Visiteur
Pré condition Connexion établie avec succès
Post condition — liste des clients est affiché
Description du Scénario principal
— le visiteur clique sur le menu de la consultation des
Clients
— Le système affiche l’interface des Clients
— le visiteur consulte la liste des Clients affichés
Exception Erreur d’affichage
Table 2.3: Description textuelle du cas d’utilisation consulter client
2.3.4.5 Raffinement du cas d’utilisation consulter service
Figure 2.7: cas d’utilisation consulter service
31
Chapiter 2 : Spécifications des besoins
Cas d’utilisation Consulter service
Acteur Visiteur
Pré condition Connexion établie avec succès
Post condition — liste des services est affiché
Description du Scénario principal
— le visiteur clique sur le menu de la consultation des
services
— Le système affiche l’interface des services
— le visiteur consulte la liste des services affichés
Exception Erreur d’affichage
Table 2.4: Description textuelle du cas d’utilisation consulter service
2.3.4.6 Raffinement du cas d’utilisation consulter offre
Figure 2.8: cas d’utilisation consulter offre
Cas d’utilisation Consulter offre
Acteur Visiteur
Pré condition connexion établie avec succès
Post condition — l’opération demander et effectuée avec succès
Description du
Scénario principal
— le visiteur ouvre l’interface de l’offre
— Le système affiche l’interface des offres
— visiteur saisie les données
Exception Erreur de consulter l’offre
Table 2.5: Description textuelle du cas d’utilisation consulter offre
32
Chapiter 2 : Spécifications des besoins
2.3.4.7 Raffinement du cas d’utilisation contacter
Figure 2.9: cas d’utilisation contacter
Cas d’utilisation Contacter
Acteur Visiteur
Pré condition connexion établie avec succès
Post condition — l’opération demander et effectuée avec succès
Description du
Scénario principal
— le visiteur ouvre l’interface contacter
— Le système affiche l’interface
— visiteur saisie les données
Exception Erreur de contacter
Table 2.6: Description textuelle du cas d’utilisation contacter
2.3.4.8 Les cas d’utilisation de l’acteur Membre
Figure 2.10: cas d’utilisation acteur membre
33
Chapiter 2 : Spécifications des besoins
2.3.4.9 Raffinement du cas d’utilisation authentification membre
Figure 2.11: cas d’utilisation authentification membre
Cas d’utilisation S’authentifier
Acteur Membre
Pré condition
Login et mot de passe enregistre dans la base de Donné,
l’interface membre est affichée
Post condition authentification avec succès
Description du
Scénario principal
- membre doit saisir son login et son mot de passe
pour accéder autres Tâche
Exception Login ou mot de passe non trouvé
Table 2.7: Description textuelle du cas d’utilisation authfication membre
2.3.4.10 Raffinement du cas d’utilisation gérer client
Figure 2.12: cas d’utilisation consulter article
34
Chapiter 2 : Spécifications des besoins
Cas d’utilisation Gérer client
Acteur Membre
Pré condition Le membre doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de suppression
est effectuée avec succès
Description du
Scénario principal
— membre ouvre l’interface de gestion des clients
— membre choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des clients
Exception
— membre saisit des données erronées.
— membre ne valide pas la modification.
Table 2.8: Description textuelle du cas d’utilisation gérer client
2.3.4.11 Raffinement du cas d’utilisation gérer service
Figure 2.13: cas d’utilisation gérer service
Cas d’utilisation Gérer service
Acteur Membre
Pré condition Le membre doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de suppression
est effectuée avec succès
Description du
Scénario principal
— membre ouvre l’interface de gestion des services
— membre choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des services
Exception
— membre saisit des données erronées.
— membre ne valide pas la modification.
Table 2.9: Description textuelle du cas d’utilisation gérer service
35
Chapiter 2 : Spécifications des besoins
2.3.4.12 Raffinement du cas d’utilisation gérer article
Figure 2.14: cas d’utilisation gérer article
Cas d’utilisation Gérer article
Acteur Membre
Pré condition Le membre doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de suppression
est effectée avec succès
Description du
Scénario principal
— membre ouvre l’interface de gestion des articles
— membre choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des articles
Exception
— membre saisit des données erronées.
— membre ne valide pas la modification.
Table 2.10: Description textuelle du cas d’utilisation gérer article
2.3.4.13 Raffinement du cas d’utilisation consulter liste message
Figure 2.15: cas d’utilisation consulter liste message
36
Chapiter 2 : Spécifications des besoins
Cas d’utilisation Consulter liste message
Acteur Membre
Pré condition Le membre doit être authentifié
Post condition — liste des messages est affiché
Description du
Scénario principal
— le membre clique sur le menu de la consultation des
Message
— Le système affiche l’interface des messages
— membre consulte la liste des messages affichés
Exception Erreur d’affichage
Table 2.11: Description textuelle du cas d’utilisation consulter liste message
2.3.4.14 Les cas d’utilisation de l’acteur Administrateur
Figure 2.16: cas d’utilisation acteur administrateur
2.3.4.15 Raffinement du cas d’utilisation authentification administrateur
Figure 2.17: cas d’utilisation authentification administrateur
37
Chapiter 2 : Spécifications des besoins
Cas d’utilisation S’authentifier
Acteur Administrateur
Pré condition
Login et mot de passe enregistre dans la base de
Donné, l’interface administrateur est affichée
Post condition authentification avec succès
Description du
Scénario principal
- l’administrateur doit saisir son login et son mot de
passe pour accéder autres taches
Exception Login ou mot de passe non trouvés
Table 2.12: Description textuelle du cas d’utilisation authentification administrateur
2.3.4.16 Raffinement du cas d’utilisation gérer membre
Figure 2.18: cas d’utilisation gérer membre
Cas d’utilisation Gérer membre
Acteur Administrateur
Pré condition L’administrateur doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de
suppression est effectuée avec succès
Description du
Scénario principal
— L’administrateur ouvre l’interface de gestion des clients
— L’administrateur choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des membre
Exception
— L’administrateur saisit des données erronées.
— L’administrateur ne valide pas la modification.
Table 2.13: Description textuelle du cas d’utilisation gérer membre
38
Chapiter 2 : Spécifications des besoins
2.3.4.17 Raffinement du cas d’utilisation gérer offre
Figure 2.19: cas d’utilisation gérer offre
Cas d’utilisation Gérer offre
Acteur Administrateur
Pré condition L’administrateur doit être authentifié
Post condition
L’opération d’ajout ou de modification ou de
suppression est effectuer avec succès
Description du
Scénario principal
— L’administrateur ouvre l’interface de gestion des offres
— L’administrateur choisit l’opération (suppression, ajout,
modification) qu’il va effectuer
— Le système affiche l’interface de gestion des offres
Exception
— L’administrateur saisit des données erronées.
— L’administrateur ne valide pas la modification.
Table 2.14: Description textuelle du cas d’utilisation gérer offre
2.3.4.18 Raffinement du cas d’utilisation consulter demande
Figure 2.20: cas d’utilisation consulter demande
39
Chapiter 2 : Spécifications des besoins
Cas d’utilisation Consulter liste demande
Acteur Administrateur
Pré condition L’administrateur doit être authentifié
Post condition — liste des demandes est affiché
Description du
Scénario principal
— l’administrateur clique sur le menu de la
consultation des Demandes
— Le système affiche l’interface des demandes
— l’administrateur consulte la liste des demandes affichés
Exception Erreur d’affichage
Table 2.15: Description textuelle du cas d’utilisation consulter demande
40
Chapiter 2 : Spécifications des besoins
2.3.5 Diagramme de cas d’utilisation générale
Figure 2.21: cas d’utilisation générale
41
Chapiter 2 : Spécifications des besoins
2.3.6 tableau récapitulatif
Acteur Intitulé cas utilisation Description
Consulter membre
Le visiteur consulte la liste des membres pour qu’il
explore les informations concernant le membre
Consulter article
Le visiteur consulte la liste des articles pour qu’il
explore les informations concernant les articles
Visiteur Consulter client
Le visiteur consulte la liste des clients pour qu’il
explore les informations concernant les clients
Consulter service
Le visiteur consulte la liste des services pour qu’il
explore les informations concernant les services
Consulter offre
Le visiteur consulte la liste des offres pour qu’il
explore les informations concernant les offres et
envoyer une demande
Contacter
Le visiteur peut contacter l’entreprise en
remplissant un formulaire contenant son nom,
e-mail et un message ou consulter
les coordonnés.
Gérer Client
Le membre a le droit de gérer plusieurs clients en
effectuant des différentes opérations :
-Il est capable d’ajouter un ou plusieurs
clients.
Il est capable de modifier un ou plusieurs clients
de la liste.
-Il est capable de supprimer un ou
plusieurs clients de la liste.
Membre Gérer Service
Le membre a le droit de gérer plusieurs clients en
effectuant des différentes opérations :
-Il est capable d’ajouter un ou plusieurs clients.
Il est capable de modifier un ou plusieurs clients
de la liste.
-Il est capable de supprimer un ou plusieurs
clients de la liste.
42
Chapiter 2 : Spécifications des besoins
Gérer Article
Le membre a le droit de gérer plusieurs clients en
effectuant des différentes opérations :
-Il est capable d’ajouter un ou plusieurs clients.
Il est capable de modifier un ou plusieurs clients
de la liste.
-Il est capable de supprimer un ou plusieurs
clients de la liste.
Consulter liste mes-
sage
Le membre consulte les messages envoyés par
le visiteur et peut répondre par mail.
Gérer membre
L’administrateur a le droit de gérer
plusieurs membres en effectuant des différentes
opérations :
-Il est capable d’ajouter un ou plusieurs membres.
Il est capable de modifier un ou plusieurs
membres de la liste.
-Il est capable de supprimer un ou
plusieurs membres de la liste.
Administrateur Gérer offre
L’administrateur a le droit de gérer plusieurs
offres en effectuant des différentes opérations :
-Il est capable d’ajouter un ou plusieurs offres.
-Il est capable de modifier un ou plusieurs offres
de la liste.
-Il est capable de supprimer un ou plusieurs offres
de la liste.
Consulter demande
Il consulte la liste des demandes par le visiteur,
dans ce cas l’administrateur peut accepter ou
refuser une demande selon des conditions.
Table 2.16: tableau récapitulatif
2.4 Besoins non fonctionnels
Ces besoins ne sont pas spécifiquement liés au comportement du système mais définissent
plutôt les contraintes internes et externes du système. Les principaux besoins non fonc-
tionnels de l’application peuvent être résumés dans les points suivants :
• La rapidité de traitements :En effet, il est impératif que la durée des traitements
soit effectuée au plus près du temps réel. . .
43
Chapiter 2 : Spécifications des besoins
• La performance : L’application doit être performance, c’est-à-dire elle doit répondre
aux besoins de tous les utilisateurs de manière optimale grâce à ses fonctionnalités.
• La disponibilité : L’application doit être disponible à tout moment pour tout uti-
lisateur et doit être facilement accessible depuis n’importe quel ordinateur connecté
à Internet.
• La convivialité : L’application doit être facile à utiliser. Les interfaces utilisateur
doivent être conviviale, pratiques et s’adaptent aux attentes de l’utilisateur.
• La sécurité : Il est difficile de prétendre avoir une sécurité des logiciels informa-
tiques à 100
2.5 Conclusion
À partir de ce chapitre, nous avons présenté une étude de l’existant, puis nous avons
des descriptions détaillées des différents cas d’utilisation en fournissant des scénarios pour
les cas des différents acteurs. Le chapitre suivant traite de l’analyse de différents cas d’uti-
lisation.
44
Chapitre 3
Analyse
Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Présentation de la démarche du modèle d’analyse . . . . . . . 46
3.3 Analyse des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 47
3.3.1 Analyse du cas d’utilisation S’authentification . . . . . . . . . . 47
3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur ’Visi-
teur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur ’Visi-
teur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur ’Vi-
siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’acteur
’Administrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1 Introduction
Dans ce chapitre, nous présenterons une analyse à travers le diagramme de collabo-
ration, qui nous permet de décrire les interactions entre les objets impliqués dans la
45
Chapiter 3 : Analyse
réalisation du scénario d’un cas d’utilisation, et de représenter les interactions entre les
classes. Nous avons tenté d’analyser certains cas d’utilisation en déterminant la traçabilité
entre les différents cas d’utilisation et le modèle d’analyse. Nous avons également essayé
de déterminer les différents diagrammes de collaboration afin de mieux comprendre le flux
de chaque cas d’utilisation.
3.2 Présentation de la démarche du modèle d’analyse
Il existe trois classes d’analyse :
• Interface : La classe d’interface est les classes qui permettent à l’acteur d’interagir
avec le système.Ce sont les écrans proposés à l’utilisateur.
• Entité : La classe d’entité représente les informations et le comportement du champ
d’application.
• Contrôle : La classe de contrôle agit comme un connecteur entre les classes d’in-
terface et les classes d’entité.
Diagramme de traçabilité : Ce modèle représente les différentes interfaces,commandes
et entités impliques dans l’exécution d’un cas d’utilisation, il permet la transition du modèle
du cas d’utilisation au modèle d’analyse.
Diagramme de collaboration : c’est un diagramme d’interaction organisé entre les
rôles qui interagissent et les liens qui les assemblent. Il expose les relations entre les objets
jouant les différents rôles. Cependant, le diagramme de collaboration ne doit contenir aucun
concept du temps.
46
Chapiter 3 : Analyse
3.3 Analyse des cas d’utilisation
3.3.1 Analyse du cas d’utilisation S’authentification
3.3.1.1 Analyse du cas d’utilisation ”s’authentifier” de l’acteur ’administra-
teur’
Figure 3.1: diagramme de traçabilité entre le modèle de cas d’utilisation ”s’authentifier”
et le modèle analyse
3.3.1.2 Digramme de collaboration du cas ”s’authentifier”
Figure 3.2: digramme de collaboration du cas ”s’authentifier”
47
Chapiter 3 : Analyse
3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur
’Visiteur’
3.3.2.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Consul-
ter article” et le modèle analyse
Figure 3.3: diagramme de traçabilité entre le modèle de cas d’utilisation ”Consulter ar-
ticle” et le modèle analyse
3.3.2.2 Digramme de collaboration du cas ”consulter article”
Figure 3.4: digramme de collaboration du cas ”consulter article”
48
Chapiter 3 : Analyse
3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur
’Visiteur’
3.3.3.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”De-
mander offre” et le modèle analyse
Figure 3.5: diagramme de traçabilité entre le modèle de cas d’utilisation ”Demander offre”
et le modèle analyse
3.3.3.2 Digramme de collaboration du cas ”Demander Offre”
Figure 3.6: digramme de collaboration du cas ”Demander Offre”
49
Chapiter 3 : Analyse
3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur
’Visiteur’
3.3.4.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer
Message” et le modèle analyse
Figure 3.7: diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer Mes-
sage” et le modèle analyse
3.3.4.2 Digramme de collaboration du cas ”Demander Offre”
Figure 3.8: digramme de collaboration du cas ”Envoyer Message”
50
Chapiter 3 : Analyse
3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur
’Membre’
3.3.5.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter
Client” et le modèle analyse
Figure 3.9: diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter Client”
et le modèle analyse
3.3.5.2 Digramme de collaboration du cas ”Ajouter Client”
Figure 3.10: digramme de collaboration du cas ”Ajouter Client”
51
Chapiter 3 : Analyse
3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur
’Membre’
3.3.6.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Modi-
fier Service” et le modèle analyse
Figure 3.11: diagramme de traçabilité entre le modèle de cas d’utilisation ”Modifier Ser-
vice” et le modèle analyse
3.3.6.2 Digramme de collaboration du cas ”Modifier Service”
Figure 3.12: digramme de collaboration du cas ”Modifier Service”
52
Chapiter 3 : Analyse
3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’ac-
teur ’Administrateur’
3.3.7.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Sup-
primer Membre” et le modèle analyse
Figure 3.13: diagramme de traçabilité entre le modèle de cas d’utilisation ”Supprimer
Membre” et le modèle analyse
3.3.7.2 Digramme de collaboration du cas ”Supprimer Membre”
Figure 3.14: digramme de collaboration du cas ”Supprimer Membre”
53
Chapiter 3 : Analyse
3.4 Conclusion
Au cours de ce chapitre, Nous avons essayé d’analyser les Cas d’utilisation pour Déterminer
la traçabilité entre les cas d’utilisation et le modèle d’analyse. Nous avons aussi essayé de
définir des diagrammes de collaboration pour mieux comprendre le flux de chaque cas
d’utilisation. Nous pouvons maintenant passer au chapitre 4 pour fournir une conception
détaillée de ce projet.
54
Chapitre 4
Conception
Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Présentation de la démarche du modèle de conception . . . . 56
4.3 Conception des cas d’utilisation . . . . . . . . . . . . . . . . . . 57
4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’acteur ’Ad-
ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.2 Conception du cas d’utilisation ” Consulter article ” de l’acteur
’Visiteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.3 Conception du cas d’utilisation ” envoyer message” de l’acteur
’Visiteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’acteur ’Mem-
bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.5 Conception du cas d’utilisation ” modifier service” de l’acteur
’Membre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 Diagramme de classe général . . . . . . . . . . . . . . . . . . . 68
4.4.1 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . 68
4.5 Modèles de paquetages et de déploiement . . . . . . . . . . . . 68
4.5.1 Modèles de paquetages . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . 69
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
55
Chapiter 4 : Conception
4.1 Introduction
La conception est un élément important de la préparation de notre application. Nous
devons élaborer un plan qui examine diverses options de conception et de réalisation.
Dans ce chapitre, Nous fournissons une conception détaillée en utilisant le diagramme de
séquence et le diagramme de classe de conception.
4.2 Présentation de la démarche du modèle de concep-
tion
L’étude conceptuelle a besoin des moyens de déplacer le modèle sur lequel nous allons
travailler,
Les diagrammes de séquence : Les diagrammes de séquence sont utilisés pour
illustrer les cas d’utilisation.Ils laissent de montrer la séquence verticale des messages passés
entre objets au sein d’une interaction.
Diagramme de classe :Le diagramme de classes montrer la structure statique du
système en termes de classes et de relations entre ces classes. L’intérêt du diagramme de
classes est la modélisation des entités du système d’information. Le diagramme de classes
est utilisé pour représenter toutes les informations finales gérées par le domaine.
56
Chapiter 4 : Conception
4.3 Conception des cas d’utilisation
4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’ac-
teur ’Administrateur’
4.3.1.1 Diagramme de traçabilité du cas d’utilisation ”s’authentifier” de l’ac-
teur ’Administrateur’ entre le modèle d’analyse et le modèle de concep-
tion
Figure 4.1: Diagramme de traçabilité du cas d’utilisation ”s’authentifier”
57
Chapiter 4 : Conception
4.3.1.2 Diagramme de séquence relative au cas d’utilisation ”s’authentifier”
de l’acteur ’Administrateur’
Figure 4.2: Diagramme de séquence relative au cas d’utilisation ”s’authentifier”
4.3.2 Conception du cas d’utilisation ” Consulter article ” de
l’acteur ’Visiteur’
4.3.2.1 Diagramme de traçabilité du cas d’utilisation ”consulter article” de
l’acteur ’visiteur’ entre le modèle d’analyse et le modèle de conception
Figure 4.3: Diagramme de traçabilité du cas d’utilisation ”consulter article”
58
Chapiter 4 : Conception
4.3.2.2 Diagramme de séquence relative au cas d’utilisation ”Consulter ar-
ticle” de l’acteur ’visiteur’
Figure 4.4: Diagramme de séquence relative au cas d’utilisation ”consulter article”
4.3.3 Conception du cas d’utilisation ” envoyer message” de l’ac-
teur ’Visiteur’
4.3.3.1 Diagramme de traçabilité du cas d’utilisation ”envoyer message” de
l’acteur ’Visiteur’ entre le modèle d’analyse et le modèle de conception
Figure 4.5: Diagramme de traçabilité du cas d’utilisation ”envoyer message”
59
Chapiter 4 : Conception
4.3.3.2 Diagramme de séquence relative au cas d’utilisation ”envoyer mes-
sage” de l’acteur ’visiteur’
Figure 4.6: Diagramme de séquence relative au cas d’utilisation ”envoyer message”
60
Chapiter 4 : Conception
4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’ac-
teur ’Membre’
4.3.4.1 Diagramme de traçabilité du cas d’utilisation ”ajouter client” de l’ac-
teur ’Membre’ entre le modèle d’analyse et le modèle de conception
Figure 4.7: Diagramme de traçabilité du cas d’utilisation ”ajouter client”
61
Chapiter 4 : Conception
4.3.4.2 Diagramme de séquence relative au cas d’utilisation ”ajouter client”
de l’acteur ’Membre’
Figure 4.8: Diagramme de séquence relative au cas d’utilisation ”ajouter client”
62
Chapiter 4 : Conception
4.3.5 Conception du cas d’utilisation ” modifier service” de l’ac-
teur ’Membre’
4.3.5.1 Diagramme de traçabilité du cas d’utilisation ”modifier service” de
l’acteur ’Membre’ entre le modèle d’analyse et le modèle de conception
Figure 4.9: Diagramme de traçabilité du cas d’utilisation ”modifier service”
63
Chapiter 4 : Conception
4.3.5.2 Diagramme de séquence relative au cas d’utilisation ”modifier service”
de l’acteur ’Membre’
Figure 4.10: Diagramme de séquence relative au cas d’utilisation ”modifier service”
]Conception du cas d’utilisation ” supprimer membre” de l’acteur ’Administrateur’
64
Chapiter 4 : Conception
4.3.5.3 Diagramme de traçabilité du cas d’utilisation ”supprimer membre”
de l’acteur ’Administrateur’ entre le modèle d’analyse et le modèle de
conception
Figure 4.11: Diagramme de traçabilité du cas d’utilisation ”supprimer membre”
4.3.5.4 Diagramme de séquence relative au cas d’utilisation ”supprimer membre”
de l’acteur ’Administrateur’
Figure 4.12: Diagramme de séquence relative au cas d’utilisation ”supprimer membre”
65
Chapiter 4 : Conception
]Conception du cas d’utilisation ”demander offre” de l’acteur ’Visiteur’
4.3.5.5 Diagramme de traçabilité du cas d’utilisation ”demander offre” de
l’acteur ’Visiteur’ entre le modèle d’analyse et le modèle de conception
Figure 4.13: Diagramme de traçabilité du cas d’utilisation ”demander offre”
66
Chapiter 4 : Conception
4.3.5.6 Diagramme de séquence relative au cas d’utilisation ”demander offre”
de l’acteur ’Visiteur’
Figure 4.14: Diagramme de séquence relative au cas d’utilisation ”demander offre”
67
Chapiter 4 : Conception
4.4 Diagramme de classe général
4.4.1 Diagramme de classe général
Figure 4.15: Diagramme de classe général
4.5 Modèles de paquetages et de déploiement
4.5.1 Modèles de paquetages
Un paquetage est un regroupement de classes dont il règle les visibilités. Le contexte
d’un paquetage permet de définir des notions et des propriétés spécifiques du domaine
(noms, types, constantes, etc.). Les paquetages permettent de présenter une vue synthétique
68
Chapiter 4 : Conception
du modèle. De même qu’une classe est la représentation d’un concept, un paquetage est
la représentation d’un domaine. Un paquetage peut être considère comme la spécification
d’un domaine Particulier
4.5.2 Modèles de déploiement
Un diagramme de déploiement est un diagramme de classe ou un diagramme d’ob-
jet représentant les nœud ou les instances de nœud sur lequel le système s’exécute. Il
propose une vision statique de la topologie du matériel s’exécute le système. Diagramme
de déploiement montre les associations(connexion) existant ente nœud du système.Il ne
montre pas les interactions entre le nœud
4.6 Conclusion
Dons ce chapitre, Représente le processus de conception de notre application . D’abord
en commençant par une architecture globale pour atteindre une conception détaille, en
définir plusieurs diagrammes de conception. Le derniér chapitre sera concerné pour l’implémentation
du projet ou la réalisation
69
Chapitre 5
Implémentation
Sommaire
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Environnement de développement . . . . . . . . . . . . . . . . 71
5.2.1 Environnement de développement . . . . . . . . . . . . . . . . . 71
5.2.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Description de l’application . . . . . . . . . . . . . . . . . . . . 71
5.3.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . 72
5.3.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . 72
5.3.3 Présentation de l’interface ’contacter’ : . . . . . . . . . . . . . . . 73
5.3.4 Présentation de l’interface ’liste membre’ : . . . . . . . . . . . . . 73
5.3.5 Présentation de l’interface ’ajouter client’ : . . . . . . . . . . . . 74
5.3.6 Présentation de l’interface ’gérer client’ : . . . . . . . . . . . . . . 74
5.3.7 Présentation de l’interface ’liste des messages’ : . . . . . . . . . . 75
5.1 Introduction
Dans ce derniér chapitre nous présentons la phase de réalisation qui a pour objectif d’ex-
poser le travail achevé. Nous présentons tout d’abord l’environnement de développement on
va voir l’environnement logiciel et matière utilisée pour développer l’application demandée.
par la suite , Nous présentons des interfaces de l’application et scenario de réalisation.
70
Chapiter 5 : Implémentation
5.2 Environnement de développement
Pendant la phase de développement de notre application, nous avons utilisé un ensemble
d’outils et moyens techniques qui constituent l’environnement général de travail. Il peut
être diviser en deux types : un environnement matériel et un environnement logiciel. Ci-
dessous, nous allons écrire et séparer chacun d’eux.
5.2.1 Environnement de développement
5.2.2 Environnement matériel
L’application est développée sur un ordinateur portable avec les caractéristiques sui-
vantes :
Marque Asus
Processeur Intel(R) Core(TM)i3
RAM 8,00 Go
Carte Graphique Intel(R) HD Graphics 520
Disque Dur 1 TB
Système D’exploitation Windows 10 professionnelle64 bits
5.3 Description de l’application
Dans cette partie, nous allons présenter les interfaces les plus importantes de notre
application tout en en expliquant leurs utilités et leurs fonctionnements.
71
Chapiter 5 : Implémentation
5.3.1 Présentation de l’interface ’s’authentifier’ :
Figure 5.1: Présentation de l’interface ’s’authentifier’ :
5.3.2 Présentation de l’interface ’page d’accueil’
Figure 5.2: Présentation de l’interface ’page d’accueil’
72
Chapiter 5 : Implémentation
5.3.3 Présentation de l’interface ’contacter’ :
Figure 5.3: Présentation de l’interface ’contacter’
5.3.4 Présentation de l’interface ’liste membre’ :
Figure 5.4: Présentation de l’interface ’liste membre’
73
Chapiter 5 : Implémentation
5.3.5 Présentation de l’interface ’ajouter client’ :
Figure 5.5: Présentation de l’interface ’ajouter client’
5.3.6 Présentation de l’interface ’gérer client’ :
Figure 5.6: Présentation de l’interface ’gérer client’
74
Chapiter 5 : Implémentation
5.3.7 Présentation de l’interface ’liste des messages’ :
Figure 5.7: Présentation de l’interface ’liste des messages’
75
Conclusion générale et perspectives
A la fin de notre formation licence informatique, nous avons été capable de réaliser un
Projet de fin d’année. Notre travail est basé sur le développement d’une application web.
Cela nous a conduit à découvrir une nouvelle plateforme de développement. J’ai passé deux
mois dans les locaux du Optans ou j’ai participé aux différentes phases du projet, de la
détermination des exigences aux tests d’admission en utilisant la méthodologie Cascade.
Pendant la période du stage, Je me suis familiarisé avec la conception de systèmes d’in-
formation et le développement en utilisant les nouvelles technologies web. Finalement, Ce
travail peut être améliorér en effectuant certaines tâches supplémentaires que nous n’avons
pas pu terminer faute de temps.
76
Annexe 1
NodeJs :
NodeJS est une plateforme construite sur le moteur JavaScript V8 de Chrome qui permet
de développer des applications en utilisant du JavaScript. Il se distingue des autres
plateformes grâce à une approche non bloquante permettant d’effectuer des
entrées/sorties (I/O) de manière asynchrone. [2]
ExpressJs
ExpressJS est une librairie qui vous permettra de créer une application Web plus
simplement qu’avec l’objet http directement. Elle fournit un ensemble de méthode
permettant de traiter les requêtes HTTP et fournit un système de middleware pour
étendre ses fonctionnalités. [3]
MongoDB
MongoDB est base de données de documents, ce qui signifie qu’elle stocke les données au
format de documents JSON. Nous estimons qu’il s’agit de la façon la plus naturelle
d’envisager les données, bien plus efficace et expressive que le modèle traditionnel basé
sur des rangées et des colonnes. [4]
Handlebars.Js
Handlebars.js est un langage de Template populaire et très puissant, simple à utiliser et
dispose d’une grande communauté. Il est basé sur le langage de Template Moustache,
tout en ajoutant plusieurs améliorations importantes. Avec Handlebars, vous pouvez
séparer la génération de votre HTML du reste de votre code JavaScript ce qui permet
d’avoir un code plus propre. [5]
HTML5
Le HTML5 est un langage de base pour la création de site internet, il sert à structurer
vote document. D’autre langage peuvent s’ajouter lors de la conception, mais tous les
sites web contiennent du HTML. HTML5 désignant la version du langage HTML.[6]
CSS3
Le terme CSS est l’acronyme anglais de Cascading Style Sheets qui peut se traduire par
”feuilles de style en cascade”. Le CSS est un langage informatique utilisé sur l’internet
pour mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi appelé
les fichiers CSS, comprennent du code qui permet de gérer le design d’une page en
HTML. [7]
Bootstrap
Bootstrap est un framework développé par l’équipe du réseau social Twitter. Proposé en
open source (sous licence MIT), ce framework utilisant les langages HTML, CSS et
JavaScript fournit aux développeurs des outils pour créer un site facilement. Ce
framework est pensé pour développer des sites avec un design responsive, qui s’adapte à
tout type d’écran, et en priorité pour les smartphones. Il fournit des outils avec des styles
déjà en place pour des typographies, des boutons, des interfaces de navigation et bien
d’autres encore. On appelle ce type de framework un ”Front-End Framework”. [8]
Références
[1] https ://fr.wikipedia.org/wiki/CycleenV
[2] https ://www.grafikart.fr/tutoriels/nodejs-intro-792
[3] https ://www.grafikart.fr/tutoriels/express-798
[4] https ://www.mongodb.com/fr
[5] https ://www.supinfo.com/articles/single/2831-handlebars
[6] http ://41mag.fr/
[7] http ://glossaire.infowebmaster.fr/css/
[8] https ://www.journaldunet.com/web-tech/developpeur/1159810-bootstrap-definition-
tutoriels-astuces-pratiques
Résumé
Ce projet a été élaboré dans le cadre du projet de fin d’études en vue
de l’obtention du diplôme de la licence fondamentale en Sciences de
l’informatique. Il a été destiné à l’étude, la conception et la réalisation
d’une application Web au profit du Optans une société du Technolo-
gies et services de l’information . Ä Pour accomplir ce travail, nous
avons choisi comme langage de modélisation le formalisme UML. En
fait, notre choix est prouvé par rapport à sa clarté et sa perfor-
mance en matière de conception. Ä la réalisation de notre applica-
tion nécessite l’utilisation de ” MongoDb ” comme serveur de base de
données. De plus pour la conception des interfaces, nous avons choisi
les langages de programmation Html, Css, javascript

Contenu connexe

Tendances

Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Rim ENNOUR
 
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIRRapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIRAHMEDAKHACHKHOUCH
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Mohamed Boubaya
 
Soutenance de Mon PFE de Stage (DUT)
Soutenance de Mon PFE de Stage (DUT) Soutenance de Mon PFE de Stage (DUT)
Soutenance de Mon PFE de Stage (DUT) Mohammed JAITI
 
Rapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humainesRapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humainesHosni Mansour
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Ahmed Makni
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"étudesMohamed Boubaya
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIAAhmed BEN JEMIA
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD) Ben Ahmed Zohra
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti MohammedMohammed JAITI
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatiqueHicham Ben
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Nawres Farhat
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationALALSYSE
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiDonia Hammami
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMohamed Arar
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRouâa Ben Hammouda
 
Presentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesPresentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesTahani RIAHI
 

Tendances (20)

Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
 
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIRRapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIR
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
Soutenance de Mon PFE de Stage (DUT)
Soutenance de Mon PFE de Stage (DUT) Soutenance de Mon PFE de Stage (DUT)
Soutenance de Mon PFE de Stage (DUT)
 
Rapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humainesRapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humaines
 
MEMOIRE DE STAGE
MEMOIRE DE STAGEMEMOIRE DE STAGE
MEMOIRE DE STAGE
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIA
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Presentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesPresentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'Etudes
 

Similaire à Rapport de stage

Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifsSafaAballagh
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Houssem Eddine Jebri
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développementGlei Hadji
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITLina Meddeb
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfnesrine haloui
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Adem Amen Allah Thabti
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...mouafekmazia
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientTaieb Kristou
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...Mohamed Amine Mahmoudi
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testahmed oumezzine
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaIlef Ben Slima
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesHosni Mansour
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFEDonia Hammami
 
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesLe Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesGenève Lab
 
Cours base données
Cours base donnéesCours base données
Cours base donnéeskerosina
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Ilyas CHAOUA
 

Similaire à Rapport de stage (20)

Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
iRecruite
iRecruiteiRecruite
iRecruite
 
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesLe Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
 
Cours base données
Cours base donnéesCours base données
Cours base données
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 

Rapport de stage

  • 1. A.U. : 2019-2020 Université de Kairouan Institut Supérieur d’Informatique et de Gestion de Kairouan Département Informatique Rapport de Projet de Fin d’Études Présenté en vue de l’obtention du diplôme de licence fondamental Option : Science Informatique Conception et réalisation d’un site web dynamique Préparé au sein de l’entreprise : Optans Réalisé par :Khalfaoui Ichraf Encadrant académique :Mr.Ourimi Ali Encadrant professionnel : Ben Fradj Safwen
  • 2. Dédicace A mes très chers parents Source de vie, d’amour et d’affection A ma belle sœur Source d’amour et d’encouragement A mes chers frères Source de joie et de bonheur A toute ma famille Source d’espoir et de motivation A tous mes amis A vous cher lecteur 1
  • 3. Remerciement Avant tout, nous tenons à remercier mon dieu. De nous avoir donné la santé, la volonté et la patience pour mener à terme notre formation de licence et pouvoir réalise ce travail. Nous tenons à exprimer nos profonds remerciements à notre encadreur pédagogique Mr Ourimi Ali qui nous a fourni le sujet de ce rapport et nous a guidés de ses précieux conseils et suggestions, et la confiance qu’il nous a témoignés tout ou long de ce travail. Je tiens également à adresser mes remerciements et ma gratitude à mon encadreur professionnelle Ben Fraj Safwen pour sa disponibilité, son soutien et son aide précieuse tout au long de ce projet. Nous tenons a gratifier aussi les membres de jury pour l’intérêt qu’ils ont porté a notre projet en acceptant d’examiner notre travail. J’adresse aussi nos remerciements à Mr kalboussi Anis chef de département de l’Informatique et a tous les enseignants de la filière de science Informatique. Enfin, on adresse nos sincères sentiment de gratitudes et de reconnaissances atout les personnes qui ont participe de près ou de loin a réalisation de ce travail. 2
  • 4. Table des matières 1 Cadre générale du projet 16 1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 17 1.2.1 Présentation générale de l’entreprise . . . . . . . . . . . . . . . . . . 17 1.2.2 les activités principales de l’entreprise . . . . . . . . . . . . . . . . . 17 1.2.3 Fiche de renseignements de l’organisme d’accueil . . . . . . . . . . . 17 1.2.4 Emplacement de l’entreprise . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Présentation du sujet Proposé . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3.2 Les Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.4 Méthodologie de Travail adoptée . . . . . . . . . . . . . . . . . . . . . . . 19 1.4.1 Méthode de Modélisation (Modèle de cycle de vie) . . . . . . . . . . 19 1.4.1.1 Modèle de cycle de vie en CASCADE . . . . . . . . . . . 19 1.4.1.2 Modèle de cycle de vie en V . . . . . . . . . . . . . . . . . 21 1.4.1.3 Modèle de cycle de vie en SPIRALE . . . . . . . . . . . . 21 1.4.2 Langages De Modélisation . . . . . . . . . . . . . . . . . . . . . . . 22 1.4.3 Langages de modélisation textuels . . . . . . . . . . . . . . . . . . . 22 3
  • 5. Table des matières 1.4.3.1 La vue statique est caractérisée par : . . . . . . . . . . . . 22 1.4.3.2 La vue dynamique est caractérisée par : . . . . . . . . . . 22 1.4.3.3 Les Avantages de langage de modélisation UML : . . . . . 23 1.4.4 Méthode et Langage De Modélisation choisis . . . . . . . . . . . . . 23 1.5 Planning Prévisionnels (Calendrier prévisionnel De Travail) . . . . . . . . . 24 1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2 Spécifications des besoins 25 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3 Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . . 27 2.3.2 Liste Des Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . 27 2.3.3 Diagramme de contexte dynamique . . . . . . . . . . . . . . . . . . 28 2.3.4 Description Des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 28 2.3.4.1 Les cas d’utilisation de l’acteur visiteur . . . . . . . . . . . 29 2.3.4.2 Raffinement du cas d’utilisation consulter membre d’équipe 29 2.3.4.3 Raffinement du cas d’utilisation consulter article . . . . . 30 2.3.4.4 Raffinement du cas d’utilisation consulter client . . . . . 31 2.3.4.5 Raffinement du cas d’utilisation consulter service . . . . . 31 2.3.4.6 Raffinement du cas d’utilisation consulter offre . . . . . . 32 2.3.4.7 Raffinement du cas d’utilisation contacter . . . . . . . . . 33 2.3.4.8 Les cas d’utilisation de l’acteur Membre . . . . . . . . . . 33 2.3.4.9 Raffinement du cas d’utilisation authentification membre . 34 4
  • 6. Table des matières 2.3.4.10 Raffinement du cas d’utilisation gérer client . . . . . . . . 34 2.3.4.11 Raffinement du cas d’utilisation gérer service . . . . . . . 35 2.3.4.12 Raffinement du cas d’utilisation gérer article . . . . . . . . 36 2.3.4.13 Raffinement du cas d’utilisation consulter liste message . . 36 2.3.4.14 Les cas d’utilisation de l’acteur Administrateur . . . . . . 37 2.3.4.15 Raffinement du cas d’utilisation authentification adminis- trateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3.4.16 Raffinement du cas d’utilisation gérer membre . . . . . . . 38 2.3.4.17 Raffinement du cas d’utilisation gérer offre . . . . . . . . . 39 2.3.4.18 Raffinement du cas d’utilisation consulter demande . . . . 39 2.3.5 Diagramme de cas d’utilisation générale . . . . . . . . . . . . . . . 41 2.3.6 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3 Analyse 45 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2 Présentation de la démarche du modèle d’analyse . . . . . . . . . . . . . . 46 3.3 Analyse des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.1 Analyse du cas d’utilisation S’authentification . . . . . . . . . . . . 47 3.3.1.1 Analyse du cas d’utilisation ”s’authentifier” de l’acteur ’ad- ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.1.2 Digramme de collaboration du cas ”s’authentifier” . . . . 47 3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur ’Visiteur’ 48 3.3.2.1 Diagramme de traçabilité entre le modèle de cas d’utilisa- tion ”Consulter article” et le modèle analyse . . . . . . . . 48 3.3.2.2 Digramme de collaboration du cas ”consulter article” . . . 48 5
  • 7. Table des matières 3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur ’Visiteur’ 49 3.3.3.1 Diagramme de traçabilité entre le modèle de cas d’utilisa- tion ”Demander offre” et le modèle analyse . . . . . . . . 49 3.3.3.2 Digramme de collaboration du cas ”Demander Offre” . . . 49 3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur ’Visiteur’ 50 3.3.4.1 Diagramme de traçabilité entre le modèle de cas d’utilisa- tion ”Envoyer Message” et le modèle analyse . . . . . . . 50 3.3.4.2 Digramme de collaboration du cas ”Demander Offre” . . . 50 3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur ’Membre’ 51 3.3.5.1 Diagramme de traçabilité entre le modèle de cas d’utilisa- tion ”Ajouter Client” et le modèle analyse . . . . . . . . . 51 3.3.5.2 Digramme de collaboration du cas ”Ajouter Client” . . . . 51 3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur ’Membre’ 52 3.3.6.1 Diagramme de traçabilité entre le modèle de cas d’utilisa- tion ”Modifier Service” et le modèle analyse . . . . . . . . 52 3.3.6.2 Digramme de collaboration du cas ”Modifier Service” . . . 52 3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’acteur ’Ad- ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.3.7.1 Diagramme de traçabilité entre le modèle de cas d’utilisa- tion ”Supprimer Membre” et le modèle analyse . . . . . . 53 3.3.7.2 Digramme de collaboration du cas ”Supprimer Membre” . 53 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4 Conception 55 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.2 Présentation de la démarche du modèle de conception . . . . . . . . . . . . 56 4.3 Conception des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 57 6
  • 8. Table des matières 4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’acteur ’Admi- nistrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.1.1 Diagramme de traçabilité du cas d’utilisation ”s’authenti- fier” de l’acteur ’Administrateur’ entre le modèle d’analyse et le modèle de conception . . . . . . . . . . . . . . . . . . 57 4.3.1.2 Diagramme de séquence relative au cas d’utilisation ”s’au- thentifier” de l’acteur ’Administrateur’ . . . . . . . . . . . 58 4.3.2 Conception du cas d’utilisation ” Consulter article ” de l’acteur ’Vi- siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.2.1 Diagramme de traçabilité du cas d’utilisation ”consulter article” de l’acteur ’visiteur’ entre le modèle d’analyse et le modèle de conception . . . . . . . . . . . . . . . . . . . . 58 4.3.2.2 Diagramme de séquence relative au cas d’utilisation ”Consul- ter article” de l’acteur ’visiteur’ . . . . . . . . . . . . . . . 59 4.3.3 Conception du cas d’utilisation ” envoyer message” de l’acteur ’Vi- siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.3.3.1 Diagramme de traçabilité du cas d’utilisation ”envoyer mes- sage” de l’acteur ’Visiteur’ entre le modèle d’analyse et le modèle de conception . . . . . . . . . . . . . . . . . . . . 59 4.3.3.2 Diagramme de séquence relative au cas d’utilisation ”en- voyer message” de l’acteur ’visiteur’ . . . . . . . . . . . . 60 4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’acteur ’Mem- bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3.4.1 Diagramme de traçabilité du cas d’utilisation ”ajouter client” de l’acteur ’Membre’ entre le modèle d’analyse et le modèle de conception . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3.4.2 Diagramme de séquence relative au cas d’utilisation ”ajou- ter client” de l’acteur ’Membre’ . . . . . . . . . . . . . . . 62 4.3.5 Conception du cas d’utilisation ” modifier service” de l’acteur ’Mem- bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7
  • 9. Table des matières 4.3.5.1 Diagramme de traçabilité du cas d’utilisation ”modifier ser- vice” de l’acteur ’Membre’ entre le modèle d’analyse et le modèle de conception . . . . . . . . . . . . . . . . . . . . 63 4.3.5.2 Diagramme de séquence relative au cas d’utilisation ”mo- difier service” de l’acteur ’Membre’ . . . . . . . . . . . . . 64 4.3.5.3 Diagramme de traçabilité du cas d’utilisation ”supprimer membre” de l’acteur ’Administrateur’ entre le modèle d’ana- lyse et le modèle de conception . . . . . . . . . . . . . . . 65 4.3.5.4 Diagramme de séquence relative au cas d’utilisation ”sup- primer membre” de l’acteur ’Administrateur’ . . . . . . . 65 4.3.5.5 Diagramme de traçabilité du cas d’utilisation ”demander offre” de l’acteur ’Visiteur’ entre le modèle d’analyse et le modèle de conception . . . . . . . . . . . . . . . . . . . . 66 4.3.5.6 Diagramme de séquence relative au cas d’utilisation ”de- mander offre” de l’acteur ’Visiteur’ . . . . . . . . . . . . . 67 4.4 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.4.1 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . 68 4.5 Modèles de paquetages et de déploiement . . . . . . . . . . . . . . . . . . . 68 4.5.1 Modèles de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.5.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 69 4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5 Implémentation 70 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 71 5.2.1 Environnement de développement . . . . . . . . . . . . . . . . . . . 71 5.2.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 71 5.3 Description de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.3.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . . 72 8
  • 10. Table des matières 5.3.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . . . 72 5.3.3 Présentation de l’interface ’contacter’ : . . . . . . . . . . . . . . . . 73 5.3.4 Présentation de l’interface ’liste membre’ : . . . . . . . . . . . . . . 73 5.3.5 Présentation de l’interface ’ajouter client’ : . . . . . . . . . . . . . . 74 5.3.6 Présentation de l’interface ’gérer client’ : . . . . . . . . . . . . . . . 74 5.3.7 Présentation de l’interface ’liste des messages’ : . . . . . . . . . . . 75 9
  • 11. Table des figures 1.1 logo de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Emplacment de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Modèle de cycle de vie en CASCADE . . . . . . . . . . . . . . . . . . . . . 20 1.4 Modèle de cycle de vie en V . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.5 Modèle de cycle de vie en SPIRALE . . . . . . . . . . . . . . . . . . . . . 22 1.6 logo de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . . . . . . 27 2.2 Diagramme de contexte Dynamique . . . . . . . . . . . . . . . . . . . . . . 28 2.3 Cas d’utilisateur de l’acteur visiteur . . . . . . . . . . . . . . . . . . . . . . 29 2.4 cas d’utilisation consulter membre d’équipe . . . . . . . . . . . . . . . . . . 29 2.5 cas d’utilisation consulter article . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6 cas d’utilisation consulter client . . . . . . . . . . . . . . . . . . . . . . . . 31 2.7 cas d’utilisation consulter service . . . . . . . . . . . . . . . . . . . . . . . 31 2.8 cas d’utilisation consulter offre . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.9 cas d’utilisation contacter . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.10 cas d’utilisation acteur membre . . . . . . . . . . . . . . . . . . . . . . . . 33 2.11 cas d’utilisation authentification membre . . . . . . . . . . . . . . . . . . . 34 10
  • 12. Table des figures 2.12 cas d’utilisation consulter article . . . . . . . . . . . . . . . . . . . . . . . . 34 2.13 cas d’utilisation gérer service . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.14 cas d’utilisation gérer article . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.15 cas d’utilisation consulter liste message . . . . . . . . . . . . . . . . . . . . 36 2.16 cas d’utilisation acteur administrateur . . . . . . . . . . . . . . . . . . . . 37 2.17 cas d’utilisation authentification administrateur . . . . . . . . . . . . . . . 37 2.18 cas d’utilisation gérer membre . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.19 cas d’utilisation gérer offre . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.20 cas d’utilisation consulter demande . . . . . . . . . . . . . . . . . . . . . . 39 2.21 cas d’utilisation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1 diagramme de traçabilité entre le modèle de cas d’utilisation ”s’authentifier” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2 digramme de collaboration du cas ”s’authentifier” . . . . . . . . . . . . . . 47 3.3 diagramme de traçabilité entre le modèle de cas d’utilisation ”Consulter article” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4 digramme de collaboration du cas ”consulter article” . . . . . . . . . . . . 48 3.5 diagramme de traçabilité entre le modèle de cas d’utilisation ”Demander offre” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.6 digramme de collaboration du cas ”Demander Offre” . . . . . . . . . . . . 49 3.7 diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer Mes- sage” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.8 digramme de collaboration du cas ”Envoyer Message” . . . . . . . . . . . . 50 3.9 diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter Client” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.10 digramme de collaboration du cas ”Ajouter Client” . . . . . . . . . . . . . 51 3.11 diagramme de traçabilité entre le modèle de cas d’utilisation ”Modifier Ser- vice” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11
  • 13. Table des figures 3.12 digramme de collaboration du cas ”Modifier Service” . . . . . . . . . . . . 52 3.13 diagramme de traçabilité entre le modèle de cas d’utilisation ”Supprimer Membre” et le modèle analyse . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.14 digramme de collaboration du cas ”Supprimer Membre” . . . . . . . . . . 53 4.1 Diagramme de traçabilité du cas d’utilisation ”s’authentifier” . . . . . . . 57 4.2 Diagramme de séquence relative au cas d’utilisation ”s’authentifier” . . . . 58 4.3 Diagramme de traçabilité du cas d’utilisation ”consulter article” . . . . . . 58 4.4 Diagramme de séquence relative au cas d’utilisation ”consulter article” . . 59 4.5 Diagramme de traçabilité du cas d’utilisation ”envoyer message” . . . . . 59 4.6 Diagramme de séquence relative au cas d’utilisation ”envoyer message” . . 60 4.7 Diagramme de traçabilité du cas d’utilisation ”ajouter client” . . . . . . . 61 4.8 Diagramme de séquence relative au cas d’utilisation ”ajouter client” . . . 62 4.9 Diagramme de traçabilité du cas d’utilisation ”modifier service” . . . . . . 63 4.10 Diagramme de séquence relative au cas d’utilisation ”modifier service” . . 64 4.11 Diagramme de traçabilité du cas d’utilisation ”supprimer membre” . . . . 65 4.12 Diagramme de séquence relative au cas d’utilisation ”supprimer membre” 65 4.13 Diagramme de traçabilité du cas d’utilisation ”demander offre” . . . . . . 66 4.14 Diagramme de séquence relative au cas d’utilisation ”demander offre” . . 67 4.15 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . . . . . . 72 5.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . . . . . . . 72 5.3 Présentation de l’interface ’contacter’ . . . . . . . . . . . . . . . . . . . . . 73 5.4 Présentation de l’interface ’liste membre’ . . . . . . . . . . . . . . . . . . . 73 5.5 Présentation de l’interface ’ajouter client’ . . . . . . . . . . . . . . . . . . . 74 5.6 Présentation de l’interface ’gérer client’ . . . . . . . . . . . . . . . . . . . . 74 12
  • 14. Table des figures 5.7 Présentation de l’interface ’liste des messages’ . . . . . . . . . . . . . . . . 75 13
  • 15. Liste des tableaux 2.1 Description textuelle du cas d’utilisation consulter membre . . . . . . . . 30 2.2 Description textuelle du cas d’utilisation consulter article . . . . . . . . . 30 2.3 Description textuelle du cas d’utilisation consulter client . . . . . . . . . . 31 2.4 Description textuelle du cas d’utilisation consulter service . . . . . . . . . . 32 2.5 Description textuelle du cas d’utilisation consulter offre . . . . . . . . . . . 32 2.6 Description textuelle du cas d’utilisation contacter . . . . . . . . . . . . . . 33 2.7 Description textuelle du cas d’utilisation authfication membre . . . . . . . 34 2.8 Description textuelle du cas d’utilisation gérer client . . . . . . . . . . . . . 35 2.9 Description textuelle du cas d’utilisation gérer service . . . . . . . . . . . . 35 2.10 Description textuelle du cas d’utilisation gérer article . . . . . . . . . . . . 36 2.11 Description textuelle du cas d’utilisation consulter liste message . . . . . . 37 2.12 Description textuelle du cas d’utilisation authentification administrateur . 38 2.13 Description textuelle du cas d’utilisation gérer membre . . . . . . . . . . . 38 2.14 Description textuelle du cas d’utilisation gérer offre . . . . . . . . . . . . . 39 2.15 Description textuelle du cas d’utilisation consulter demande . . . . . . . . 40 2.16 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 14
  • 16. Liste des tableaux Introduction générale Tout le monde prétend aujourd’hui que l’informatique est une révolution fondamentale et innovante qui a touché considérablement la vie humaine durant le dernier siècle. En réalité, loin d’être un phénomène pétillant, ou une tendance passagère, l’informatique vient d’être exploitée dans tous les aspects de la vie. Aucun domaine ne reste à l’abri de cette politique, ce qui facilite les tâches de l’entreprise ainsi que celle des personnels. Grâce a la généralisation et de la globalisation, les domaines de l’information et de la communication ont évolué très rapidement avec l’amélioration des moyens de développement et de programmation. Cela a conduit à une révolution dans la représentation, l’organisation et le traitement des données. De nos jours, les sites Web sont devenus des moyens indispen- sables pour tout type de service couvrant ainsi tous types de besoins. Une société de service informatique est une entreprise qui énonce et vend des services informatiques. Elle joue le rôle d’un médiateur entre les clients et les différents bénéficiaires de services présents sur le marché de l’informatique. Elles sont considérées parmi les entreprises les plus fréquentes sur le territoire tunisien. Dans ce cadre, se déroule notre projet de fin d’étude qui consiste à développer un site web d’une société de service informatique. Notre solution vise à infor- matiser la procédure traditionnelle et exhaustive de traitement des services, l’objectif est d’organiser le secteur de travail en mettant à sa disposition un outil performant et fiable permettant aux sociétés de mieux administrer les services et de faciliter l’accès pour leurs clients. Le pressent rapport décrit notre projet. Il est structuré en cinq chapitres répartis comme suit : • Le premier chapitre présente le cadre général du projet dans lequel on va présenter une description de l’organisme d’accueil en citant les différents problèmes et les défauts que l’on remarque avec les solutions proposées. Il fournit aussi une étude comparative entre quelques solutions existantes et quelques méthodologies de concep- tion. • Le deuxième chapitre sera consacré pour la spécification des besoins dans lequel on va citer une étude de l’existant, ensuite on va présenter les besoins fonctionnels et non fonctionnels. • Dans le troisième chapitre, nous présentons la démarche du modèle analyse dont le but d’examiner les différents cas d’utilisation. • La démarche du modèle de conception ainsi que les différentes conceptions des cas d’utilisations seront présentés dans le quatrième chapitre. • Le dernier chapitre sera consacré pour l’implémentation. Tout d’abord on va présenter l’environnement de développement matériel et logiciel utilisé pour l’application. En- fin, nous présentons la description de cette dernière via quelques interfaces. 15
  • 17. Chapitre 1 Cadre générale du projet Sommaire 1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 17 1.2.1 Présentation générale de l’entreprise . . . . . . . . . . . . . . . . 17 1.2.2 les activités principales de l’entreprise . . . . . . . . . . . . . . . 17 1.2.3 Fiche de renseignements de l’organisme d’accueil . . . . . . . . . 17 1.2.4 Emplacement de l’entreprise . . . . . . . . . . . . . . . . . . . . . 18 1.3 Présentation du sujet Proposé . . . . . . . . . . . . . . . . . . . 18 1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3.2 Les Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . 19 1.4 Méthodologie de Travail adoptée . . . . . . . . . . . . . . . . . 19 1.4.1 Méthode de Modélisation (Modèle de cycle de vie) . . . . . . . . 19 1.4.2 Langages De Modélisation . . . . . . . . . . . . . . . . . . . . . . 22 1.4.3 Langages de modélisation textuels . . . . . . . . . . . . . . . . . 22 1.4.4 Méthode et Langage De Modélisation choisis . . . . . . . . . . . 23 1.5 Planning Prévisionnels (Calendrier prévisionnel De Travail) 24 1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.1 introduction Dans ce premier chapitre, nous présentons l’organisme d’accueil , nous décrivons brièvement l’entreprise dans laquelle nous avons réalisé notre stage tout en citant l’ensemble de ses 16
  • 18. Chapiter 1 : Cadre générale du projet activités, par la suite nous avons dégagé les problèmes du système‘ actuel et les solutions proposées.. 1.2 Présentation de l’organisme d’accueil 1.2.1 Présentation générale de l’entreprise Optans est une société du Technologies et services de l’information basée à Monastir, elle possède des travailleurs spécialisés dans le développement des applications web et des applications mobiles. avec un actionnariat et une direction de majorité belges, elle combine l’exactitude européenne avec la qualité des ressources informatiques tunisiennes pour donner la solution la plus performante à un coût extrêmement concurrentiel. Elle applique évidemment les standards de qualité internationaux les plus élevés. Figure 1.1: logo de l’entreprise 1.2.2 les activités principales de l’entreprise • l’intégration des solutions open source. • Développement des application mobiles. • Des services de marketing internet. • Développement web. 1.2.3 Fiche de renseignements de l’organisme d’accueil • Nom de l’entreprise : Optans • Secteur : Technologie et services de l’information 17
  • 19. Chapiter 1 : Cadre générale du projet • Taille de l’entreprise : 2-10 employés 4 sur LinkedIn • Type :Société de personnes (associés) • Spécialisations : intégration des solutions open source, Développement web, ap- plication mobile et Marketing internet • Date de fondation :2012 • Adresse :Immeuble jaafoura 5000, Monastir • numéro de Téléphone :(+216) 73 46 32 87 1.2.4 Emplacement de l’entreprise Figure 1.2: Emplacment de l’entreprise 1.3 Présentation du sujet Proposé Pendant la période de notre stage de fin d’études dans cette entreprise, Nous avons suggéré de développer une application web comme un projet dans le but de faciliter et d’informatiser les tâches manuelles. 1.3.1 Problématique Pendant la période de stage, nous avons découvert plusieurs problèmes : • Absence d’accès direct à l’information. • La présence physique des clients à l’entreprise était obligatoire pour toute consul- tation ou contact. • Risque de pertes des informations importantes et confidentielles. 18
  • 20. Chapiter 1 : Cadre générale du projet En outre, plusieurs taches sont réalisées manuellement, par exemple : • Gestion des produits. • Gestion des clients. • Gestion des services. • Gestion des articles . • Gestion des membres. • Gestion des offres. 1.3.2 Les Solutions proposées Pour remédier à ces problèmes, nous avons proposé de développer un site web dyna- mique qui représente plusieurs fonctionnalités : • Résoudre le problème du temps perdu dans la gestion (rapidité). • Les activités de notre entreprise seront bien présentées et organisés dans un site web. • Les clients seront capables de contacter et consulter l’entreprise en ligne. • Éliminer les risques de chevauchement des informations importantes. • Stocker les informations avec toute sécurité fiabilité. • Faciliter la gestion. Grâce à ces solutions le système de notre entreprise sera plus simple et facile. 1.4 Méthodologie de Travail adoptée Le développement de tout projet informatique nécessite une démarche (méthodologie) de travail que l’on choisit avant de commencer le projet. Ceci est assurée grâce à un modèle de conception et des formalismes de notations. 1.4.1 Méthode de Modélisation (Modèle de cycle de vie) 1.4.1.1 Modèle de cycle de vie en CASCADE Le modèle de cycle de vie en CASCADE a été élaboré en 1970. Le principe du modèle CASCADE est de diviser le projet en sept phases distinctes sur le principe du non-retour. Ce modèle est basé sur l’hypothèse : dès le début, nous pouvons définir ce que nous pouvons réaliser pleinement (expressions des besoins). Dans ce modèle le principe est très simple : 19
  • 21. Chapiter 1 : Cadre générale du projet • L’étape peut commencer si son étape précédente est complètement terminée. • Chaque étape se termine à une date précise avec la production de documents ou programmes spécifiques. • Les résultats sont déterminés sur la base des interactions entre les étapes, ils font l’objet d’un examen approfondi et l’étape suivante n’est franchie que s’ils sont sa- tisfaisants. Figure 1.3: Modèle de cycle de vie en CASCADE Avantages du modèle en cascade : • C’est un modèle linéaire. Bien sûr, les modèles linéaires sont la méthode de mise en œuvre la plus simple. • L’un des grands avantages du modèle CASCADE est la production de documents à chaque étape du développement du modèle, ce qui facilite la compréhension de la conception du produit dans chaque procédure. • Après chaque étape majeure de codage du programme, des tests sont effectués pour vérifier que le code fonctionne correctement. • Contrôle facile. • Faciliter la planification des barrières et des routes. • Accent sur la documentation et la structure. • Idéal pour des projets logiciels stables. Inconvénients du modèle en cascade : • Mal adapté aux systèmes complexes (processus de développement rarement séquentiel). • Les tests s’appliquent à l’application globale (pas de validation des besoins). 20
  • 22. Chapiter 1 : Cadre générale du projet • Difficile de définir toutes les exigences depuis le début du projet. • Assez longtemps pour voir quelque chose. 1.4.1.2 Modèle de cycle de vie en V Le modèle du cycle en V (par comparaison avec les méthodes dites agiles) est un modèle conceptuel de gestion de projet imaginé à la suite du problème de réactivité du modèle en cascade. Il permet en cas d’anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer de l’information sur les phases en vis-à-vis lorsque des défauts sont détectes, afin d’améliorer le logiciel.[1] Figure 1.4: Modèle de cycle de vie en V 1.4.1.3 Modèle de cycle de vie en SPIRALE Le modèle en spirale a été défini par Barry Boehm en 1988 dans son article ”A Spiral Model of Software Developpement and Enharnachement”. Le modèle en spirale est un modèle pour le cours de développement logiciel qui prend les différentes étapes du cycle V. En mettant en œuvre des versions successives, le cycle recommence en proposant un produit complet et de plus en plus difficile. Le cycle en spirale met cependant plus l’accent sur la gestion des risques que le cycle en V. 21
  • 23. Chapiter 1 : Cadre générale du projet Figure 1.5: Modèle de cycle de vie en SPIRALE 1.4.2 Langages De Modélisation 1.4.3 Langages de modélisation textuels UML(Unified Modeling Langage) ou (langage de modélisation unifié) est le langage de modélisation graphique permettant de réaliser un modèle d’une manière simple avec des diagrammes. Ce langage définit par des vues et des diagrammes. 1.4.3.1 La vue statique est caractérisée par : • le cas d’utilisation. • Diagramme d’objet. • Diagramme de classes. • Diagramme de composants. • Diagramme de déploiement. 1.4.3.2 La vue dynamique est caractérisée par : • Diagramme de collaboration. • Diagramme de séquence. • Diagramme d’activités. 22
  • 24. Chapiter 1 : Cadre générale du projet • Diagramme d’état-transition. 1.4.3.3 Les Avantages de langage de modélisation UML : • facilite les présentations exemplaire et complexes. • Ce langage est un langage formel : — Accepte l’utilisation d’outils. — Assure la précision. — Assure la stabilité. • Ce langage peut servir de support pour tout langage de programmation orientée objet. Figure 1.6: logo de UML 1.4.4 Méthode et Langage De Modélisation choisis Pour développer les étapes d’analyse, de conception et de mise en œuvre, nous avons choisi une méthodologie qui comprend : — La modèle de vie en CASCADE comme méthode de modélisation pour les raisons suivantes : — Les besoins fonctionnels et non fonctionnels de notre projet sont déterminés dès le départ ... — la démarche linéaire du modèle en CASCADE est simple à adopter et appliquer dans les projets. • Le langage de modélisation sélectionné est UML pour les raisons suivantes : — UML permet de couvrir le cycle de vie dans CASCADE pour déterminer les besoins. — Activer l’encapsulation et le traitement des données. 23
  • 25. Chapiter 1 : Cadre générale du projet 1.5 Planning Prévisionnels (Calendrier prévisionnel De Travail) La clé principale de la réussite d’un projet est un bon planning. En fait, la planification permet de bien répartir le travail et sépare les tâches à effectuer, elle fournit la meilleure estimation et la gestion du temps nécessaires pour chaque tâche. En outre, il donne un aperçu de l’arrondi de la date d’achèvement de chaque tâche. L’élaboration du cahier des charges, la conception et le développement d’un projet informatique nécessite une organisation et un bon découpage des différentes étapes du projet. 1.6 Conclusion Dans ce premier chapitre nous avons présenté le cadre général de notre projet avec une description générale de l’entreprise ensuite nous avons proposé des solutions afin de résoudre les différents problèmes. 24
  • 26. Chapitre 2 Spécifications des besoins Sommaire 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . . 26 2.2.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3 Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.1 Diagramme De contexte Statique . . . . . . . . . . . . . . . . . . 27 2.3.2 Liste Des Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . 27 2.3.3 Diagramme de contexte dynamique . . . . . . . . . . . . . . . . . 28 2.3.4 Description Des cas d’utilisation . . . . . . . . . . . . . . . . . . 28 2.3.5 Diagramme de cas d’utilisation générale . . . . . . . . . . . . . . 41 2.3.6 tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . 43 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.1 Introduction Après avoir défini l’objectif dans le chapitre précédent, nous consacrons ce chapitre à l’identification des besoins fonctionnels et non fonctionnels d’écriture d’acteurs sur notre site. Nous fournirons une description détaillée des principaux cas d’utilisation sur la base des résultats de l’analyse des besoins. 25
  • 27. Chapiter 2 : Spécifications des besoins 2.2 Etude de l’existant Avant d’identifier les besoins, il est important de mener une étude de l’existant, ce qui est une étape majeure pour réaliser notre site web. Pour notre étude, deux tâches doivent être abordées : 2.2.1 Présentation de l’existant Le système d’information doit actuellement être automatisé pour poursuivre le développ- ement technologique et améliorer la production de services. Dans notre cas, la communi- cation entre les différents acteurs est un problème très important. Plusieurs problèmes caractérisent la gestion actuelle de l’information et de la communication entre les acteurs. Parmi ces problèmes, nous pouvons citer : L’absence d’une plate-forme numérique et in- formatique qui s’adapte aux nouvelles technologies. De plus, les informations des clients sont traitées manuellement, ce qui entraı̂ne une perte d’informations. En fait, cette société est connue comme une entreprise avec de nombreuses ressources. Le stockage des données devient chaque jour plus fragile et plus important. 2.2.2 Critiques de l’existant La critique de l’existant fournit une étape nécessaire importante. Son objectif est d’ex- primer une opinion pour développer tout défaut existant dans le système actuel afin de proposer un système plus fiable que l’ancien. A partir des observations que nous avons vues dans notre entreprise, nous avons distingué des problèmes suivants : • Problème de réalisation des informations sur les services disponibles. • L’utilisation de documents dans l’entreprise peut ralentir le travail et cela nous donne un faible rendement. • L’absence d’une application web ne peut pas mettre en valeur l’entreprise sur le marché. • Problème de connaı̂tre l’emplacement de l’agence. • Perte de temps dans l’administration due à l’utilisation de documents. 26
  • 28. Chapiter 2 : Spécifications des besoins 2.3 Besoins Fonctionnels Dans cette partie, nous définissons les spécifications des exigences qui sont le point de départ de notre projet, l’application fournit des services en fonction des profils d’utilisateurs et des différents traitements nécessaires pour effectuer les tâches qui assureront les objectifs de l’application. 2.3.1 Diagramme De contexte Statique Figure 2.1: Diagramme De contexte Statique 2.3.2 Liste Des Besoins Fonctionnels Visiteur : • Consulter membre. • Consulter . • Consulter service. • Consulter client. • Consulter . • Contacter. Membre : • S’authentifier. 27
  • 29. Chapiter 2 : Spécifications des besoins • Gérer client. • Gérer service. • Gérer article. • Consulter liste des messages. Administrateur : • S’authentifier. • Gérer les membres . • Gérer offre. • Consulter liste des demandes. 2.3.3 Diagramme de contexte dynamique Figure 2.2: Diagramme de contexte Dynamique 2.3.4 Description Des cas d’utilisation Les diagrammes de cas d’utilisation sont des diagrammes UML qui sont utilisés pour donner un aperçu global des fonctionnalités du système logiciel. Le cas d’utilisation représente une unité d’interaction distincte entre l’utilisateur (humain ou machine) et le système. Il s’agit d’une unité de travail importante. Dans un diagramme de cas d’utilisation, les utili- 28
  • 30. Chapiter 2 : Spécifications des besoins sateurs sont appelés acteurs (en anglais actors )et interagissent avec les cas d’utilisation (use cases). 2.3.4.1 Les cas d’utilisation de l’acteur visiteur Figure 2.3: Cas d’utilisateur de l’acteur visiteur 2.3.4.2 Raffinement du cas d’utilisation consulter membre d’équipe Figure 2.4: cas d’utilisation consulter membre d’équipe 29
  • 31. Chapiter 2 : Spécifications des besoins Cas d’utilisation Consulter membre Acteur Visiteur Pré condition Connexion établie avec succés Post condition — liste des membres est affiché Description du Scénario principal — le visiteur clique sur le menu de la consultation des membre — Le système affiche l’interface des membres — le visiteur consulte la liste des membre affichés Exception Erreur d’affichage Table 2.1: Description textuelle du cas d’utilisation consulter membre 2.3.4.3 Raffinement du cas d’utilisation consulter article Figure 2.5: cas d’utilisation consulter article Cas d’utilisation Consulter article Acteur Visiteur Pré condition Connexion établie avec succès Post condition — liste des articles est affiché Description du Scénario principal — le visiteur clique sur le menu de la consultation des articles — Le système affiche l’interface des articles — le visiteur consulte la liste des articles affichés Exception Erreur d’affichage Table 2.2: Description textuelle du cas d’utilisation consulter article 30
  • 32. Chapiter 2 : Spécifications des besoins 2.3.4.4 Raffinement du cas d’utilisation consulter client Figure 2.6: cas d’utilisation consulter client Cas d’utilisation Consulter client Acteur Visiteur Pré condition Connexion établie avec succès Post condition — liste des clients est affiché Description du Scénario principal — le visiteur clique sur le menu de la consultation des Clients — Le système affiche l’interface des Clients — le visiteur consulte la liste des Clients affichés Exception Erreur d’affichage Table 2.3: Description textuelle du cas d’utilisation consulter client 2.3.4.5 Raffinement du cas d’utilisation consulter service Figure 2.7: cas d’utilisation consulter service 31
  • 33. Chapiter 2 : Spécifications des besoins Cas d’utilisation Consulter service Acteur Visiteur Pré condition Connexion établie avec succès Post condition — liste des services est affiché Description du Scénario principal — le visiteur clique sur le menu de la consultation des services — Le système affiche l’interface des services — le visiteur consulte la liste des services affichés Exception Erreur d’affichage Table 2.4: Description textuelle du cas d’utilisation consulter service 2.3.4.6 Raffinement du cas d’utilisation consulter offre Figure 2.8: cas d’utilisation consulter offre Cas d’utilisation Consulter offre Acteur Visiteur Pré condition connexion établie avec succès Post condition — l’opération demander et effectuée avec succès Description du Scénario principal — le visiteur ouvre l’interface de l’offre — Le système affiche l’interface des offres — visiteur saisie les données Exception Erreur de consulter l’offre Table 2.5: Description textuelle du cas d’utilisation consulter offre 32
  • 34. Chapiter 2 : Spécifications des besoins 2.3.4.7 Raffinement du cas d’utilisation contacter Figure 2.9: cas d’utilisation contacter Cas d’utilisation Contacter Acteur Visiteur Pré condition connexion établie avec succès Post condition — l’opération demander et effectuée avec succès Description du Scénario principal — le visiteur ouvre l’interface contacter — Le système affiche l’interface — visiteur saisie les données Exception Erreur de contacter Table 2.6: Description textuelle du cas d’utilisation contacter 2.3.4.8 Les cas d’utilisation de l’acteur Membre Figure 2.10: cas d’utilisation acteur membre 33
  • 35. Chapiter 2 : Spécifications des besoins 2.3.4.9 Raffinement du cas d’utilisation authentification membre Figure 2.11: cas d’utilisation authentification membre Cas d’utilisation S’authentifier Acteur Membre Pré condition Login et mot de passe enregistre dans la base de Donné, l’interface membre est affichée Post condition authentification avec succès Description du Scénario principal - membre doit saisir son login et son mot de passe pour accéder autres Tâche Exception Login ou mot de passe non trouvé Table 2.7: Description textuelle du cas d’utilisation authfication membre 2.3.4.10 Raffinement du cas d’utilisation gérer client Figure 2.12: cas d’utilisation consulter article 34
  • 36. Chapiter 2 : Spécifications des besoins Cas d’utilisation Gérer client Acteur Membre Pré condition Le membre doit être authentifié Post condition L’opération d’ajout ou de modification ou de suppression est effectuée avec succès Description du Scénario principal — membre ouvre l’interface de gestion des clients — membre choisit l’opération (suppression, ajout, modification) qu’il va effectuer — Le système affiche l’interface de gestion des clients Exception — membre saisit des données erronées. — membre ne valide pas la modification. Table 2.8: Description textuelle du cas d’utilisation gérer client 2.3.4.11 Raffinement du cas d’utilisation gérer service Figure 2.13: cas d’utilisation gérer service Cas d’utilisation Gérer service Acteur Membre Pré condition Le membre doit être authentifié Post condition L’opération d’ajout ou de modification ou de suppression est effectuée avec succès Description du Scénario principal — membre ouvre l’interface de gestion des services — membre choisit l’opération (suppression, ajout, modification) qu’il va effectuer — Le système affiche l’interface de gestion des services Exception — membre saisit des données erronées. — membre ne valide pas la modification. Table 2.9: Description textuelle du cas d’utilisation gérer service 35
  • 37. Chapiter 2 : Spécifications des besoins 2.3.4.12 Raffinement du cas d’utilisation gérer article Figure 2.14: cas d’utilisation gérer article Cas d’utilisation Gérer article Acteur Membre Pré condition Le membre doit être authentifié Post condition L’opération d’ajout ou de modification ou de suppression est effectée avec succès Description du Scénario principal — membre ouvre l’interface de gestion des articles — membre choisit l’opération (suppression, ajout, modification) qu’il va effectuer — Le système affiche l’interface de gestion des articles Exception — membre saisit des données erronées. — membre ne valide pas la modification. Table 2.10: Description textuelle du cas d’utilisation gérer article 2.3.4.13 Raffinement du cas d’utilisation consulter liste message Figure 2.15: cas d’utilisation consulter liste message 36
  • 38. Chapiter 2 : Spécifications des besoins Cas d’utilisation Consulter liste message Acteur Membre Pré condition Le membre doit être authentifié Post condition — liste des messages est affiché Description du Scénario principal — le membre clique sur le menu de la consultation des Message — Le système affiche l’interface des messages — membre consulte la liste des messages affichés Exception Erreur d’affichage Table 2.11: Description textuelle du cas d’utilisation consulter liste message 2.3.4.14 Les cas d’utilisation de l’acteur Administrateur Figure 2.16: cas d’utilisation acteur administrateur 2.3.4.15 Raffinement du cas d’utilisation authentification administrateur Figure 2.17: cas d’utilisation authentification administrateur 37
  • 39. Chapiter 2 : Spécifications des besoins Cas d’utilisation S’authentifier Acteur Administrateur Pré condition Login et mot de passe enregistre dans la base de Donné, l’interface administrateur est affichée Post condition authentification avec succès Description du Scénario principal - l’administrateur doit saisir son login et son mot de passe pour accéder autres taches Exception Login ou mot de passe non trouvés Table 2.12: Description textuelle du cas d’utilisation authentification administrateur 2.3.4.16 Raffinement du cas d’utilisation gérer membre Figure 2.18: cas d’utilisation gérer membre Cas d’utilisation Gérer membre Acteur Administrateur Pré condition L’administrateur doit être authentifié Post condition L’opération d’ajout ou de modification ou de suppression est effectuée avec succès Description du Scénario principal — L’administrateur ouvre l’interface de gestion des clients — L’administrateur choisit l’opération (suppression, ajout, modification) qu’il va effectuer — Le système affiche l’interface de gestion des membre Exception — L’administrateur saisit des données erronées. — L’administrateur ne valide pas la modification. Table 2.13: Description textuelle du cas d’utilisation gérer membre 38
  • 40. Chapiter 2 : Spécifications des besoins 2.3.4.17 Raffinement du cas d’utilisation gérer offre Figure 2.19: cas d’utilisation gérer offre Cas d’utilisation Gérer offre Acteur Administrateur Pré condition L’administrateur doit être authentifié Post condition L’opération d’ajout ou de modification ou de suppression est effectuer avec succès Description du Scénario principal — L’administrateur ouvre l’interface de gestion des offres — L’administrateur choisit l’opération (suppression, ajout, modification) qu’il va effectuer — Le système affiche l’interface de gestion des offres Exception — L’administrateur saisit des données erronées. — L’administrateur ne valide pas la modification. Table 2.14: Description textuelle du cas d’utilisation gérer offre 2.3.4.18 Raffinement du cas d’utilisation consulter demande Figure 2.20: cas d’utilisation consulter demande 39
  • 41. Chapiter 2 : Spécifications des besoins Cas d’utilisation Consulter liste demande Acteur Administrateur Pré condition L’administrateur doit être authentifié Post condition — liste des demandes est affiché Description du Scénario principal — l’administrateur clique sur le menu de la consultation des Demandes — Le système affiche l’interface des demandes — l’administrateur consulte la liste des demandes affichés Exception Erreur d’affichage Table 2.15: Description textuelle du cas d’utilisation consulter demande 40
  • 42. Chapiter 2 : Spécifications des besoins 2.3.5 Diagramme de cas d’utilisation générale Figure 2.21: cas d’utilisation générale 41
  • 43. Chapiter 2 : Spécifications des besoins 2.3.6 tableau récapitulatif Acteur Intitulé cas utilisation Description Consulter membre Le visiteur consulte la liste des membres pour qu’il explore les informations concernant le membre Consulter article Le visiteur consulte la liste des articles pour qu’il explore les informations concernant les articles Visiteur Consulter client Le visiteur consulte la liste des clients pour qu’il explore les informations concernant les clients Consulter service Le visiteur consulte la liste des services pour qu’il explore les informations concernant les services Consulter offre Le visiteur consulte la liste des offres pour qu’il explore les informations concernant les offres et envoyer une demande Contacter Le visiteur peut contacter l’entreprise en remplissant un formulaire contenant son nom, e-mail et un message ou consulter les coordonnés. Gérer Client Le membre a le droit de gérer plusieurs clients en effectuant des différentes opérations : -Il est capable d’ajouter un ou plusieurs clients. Il est capable de modifier un ou plusieurs clients de la liste. -Il est capable de supprimer un ou plusieurs clients de la liste. Membre Gérer Service Le membre a le droit de gérer plusieurs clients en effectuant des différentes opérations : -Il est capable d’ajouter un ou plusieurs clients. Il est capable de modifier un ou plusieurs clients de la liste. -Il est capable de supprimer un ou plusieurs clients de la liste. 42
  • 44. Chapiter 2 : Spécifications des besoins Gérer Article Le membre a le droit de gérer plusieurs clients en effectuant des différentes opérations : -Il est capable d’ajouter un ou plusieurs clients. Il est capable de modifier un ou plusieurs clients de la liste. -Il est capable de supprimer un ou plusieurs clients de la liste. Consulter liste mes- sage Le membre consulte les messages envoyés par le visiteur et peut répondre par mail. Gérer membre L’administrateur a le droit de gérer plusieurs membres en effectuant des différentes opérations : -Il est capable d’ajouter un ou plusieurs membres. Il est capable de modifier un ou plusieurs membres de la liste. -Il est capable de supprimer un ou plusieurs membres de la liste. Administrateur Gérer offre L’administrateur a le droit de gérer plusieurs offres en effectuant des différentes opérations : -Il est capable d’ajouter un ou plusieurs offres. -Il est capable de modifier un ou plusieurs offres de la liste. -Il est capable de supprimer un ou plusieurs offres de la liste. Consulter demande Il consulte la liste des demandes par le visiteur, dans ce cas l’administrateur peut accepter ou refuser une demande selon des conditions. Table 2.16: tableau récapitulatif 2.4 Besoins non fonctionnels Ces besoins ne sont pas spécifiquement liés au comportement du système mais définissent plutôt les contraintes internes et externes du système. Les principaux besoins non fonc- tionnels de l’application peuvent être résumés dans les points suivants : • La rapidité de traitements :En effet, il est impératif que la durée des traitements soit effectuée au plus près du temps réel. . . 43
  • 45. Chapiter 2 : Spécifications des besoins • La performance : L’application doit être performance, c’est-à-dire elle doit répondre aux besoins de tous les utilisateurs de manière optimale grâce à ses fonctionnalités. • La disponibilité : L’application doit être disponible à tout moment pour tout uti- lisateur et doit être facilement accessible depuis n’importe quel ordinateur connecté à Internet. • La convivialité : L’application doit être facile à utiliser. Les interfaces utilisateur doivent être conviviale, pratiques et s’adaptent aux attentes de l’utilisateur. • La sécurité : Il est difficile de prétendre avoir une sécurité des logiciels informa- tiques à 100 2.5 Conclusion À partir de ce chapitre, nous avons présenté une étude de l’existant, puis nous avons des descriptions détaillées des différents cas d’utilisation en fournissant des scénarios pour les cas des différents acteurs. Le chapitre suivant traite de l’analyse de différents cas d’uti- lisation. 44
  • 46. Chapitre 3 Analyse Sommaire 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2 Présentation de la démarche du modèle d’analyse . . . . . . . 46 3.3 Analyse des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 47 3.3.1 Analyse du cas d’utilisation S’authentification . . . . . . . . . . 47 3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur ’Visi- teur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur ’Visi- teur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur ’Vi- siteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur ’Mem- bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur ’Mem- bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’acteur ’Administrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.1 Introduction Dans ce chapitre, nous présenterons une analyse à travers le diagramme de collabo- ration, qui nous permet de décrire les interactions entre les objets impliqués dans la 45
  • 47. Chapiter 3 : Analyse réalisation du scénario d’un cas d’utilisation, et de représenter les interactions entre les classes. Nous avons tenté d’analyser certains cas d’utilisation en déterminant la traçabilité entre les différents cas d’utilisation et le modèle d’analyse. Nous avons également essayé de déterminer les différents diagrammes de collaboration afin de mieux comprendre le flux de chaque cas d’utilisation. 3.2 Présentation de la démarche du modèle d’analyse Il existe trois classes d’analyse : • Interface : La classe d’interface est les classes qui permettent à l’acteur d’interagir avec le système.Ce sont les écrans proposés à l’utilisateur. • Entité : La classe d’entité représente les informations et le comportement du champ d’application. • Contrôle : La classe de contrôle agit comme un connecteur entre les classes d’in- terface et les classes d’entité. Diagramme de traçabilité : Ce modèle représente les différentes interfaces,commandes et entités impliques dans l’exécution d’un cas d’utilisation, il permet la transition du modèle du cas d’utilisation au modèle d’analyse. Diagramme de collaboration : c’est un diagramme d’interaction organisé entre les rôles qui interagissent et les liens qui les assemblent. Il expose les relations entre les objets jouant les différents rôles. Cependant, le diagramme de collaboration ne doit contenir aucun concept du temps. 46
  • 48. Chapiter 3 : Analyse 3.3 Analyse des cas d’utilisation 3.3.1 Analyse du cas d’utilisation S’authentification 3.3.1.1 Analyse du cas d’utilisation ”s’authentifier” de l’acteur ’administra- teur’ Figure 3.1: diagramme de traçabilité entre le modèle de cas d’utilisation ”s’authentifier” et le modèle analyse 3.3.1.2 Digramme de collaboration du cas ”s’authentifier” Figure 3.2: digramme de collaboration du cas ”s’authentifier” 47
  • 49. Chapiter 3 : Analyse 3.3.2 Analyse du cas d’utilisation ”Consulter article”de l’acteur ’Visiteur’ 3.3.2.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Consul- ter article” et le modèle analyse Figure 3.3: diagramme de traçabilité entre le modèle de cas d’utilisation ”Consulter ar- ticle” et le modèle analyse 3.3.2.2 Digramme de collaboration du cas ”consulter article” Figure 3.4: digramme de collaboration du cas ”consulter article” 48
  • 50. Chapiter 3 : Analyse 3.3.3 Analyse du cas d’utilisation ”Demander offre” de l’acteur ’Visiteur’ 3.3.3.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”De- mander offre” et le modèle analyse Figure 3.5: diagramme de traçabilité entre le modèle de cas d’utilisation ”Demander offre” et le modèle analyse 3.3.3.2 Digramme de collaboration du cas ”Demander Offre” Figure 3.6: digramme de collaboration du cas ”Demander Offre” 49
  • 51. Chapiter 3 : Analyse 3.3.4 Analyse du cas d’utilisation ”Envoyer Message”de l’acteur ’Visiteur’ 3.3.4.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer Message” et le modèle analyse Figure 3.7: diagramme de traçabilité entre le modèle de cas d’utilisation ”Envoyer Mes- sage” et le modèle analyse 3.3.4.2 Digramme de collaboration du cas ”Demander Offre” Figure 3.8: digramme de collaboration du cas ”Envoyer Message” 50
  • 52. Chapiter 3 : Analyse 3.3.5 Analyse du cas d’utilisation ”Ajouter Client” de l’acteur ’Membre’ 3.3.5.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter Client” et le modèle analyse Figure 3.9: diagramme de traçabilité entre le modèle de cas d’utilisation ”Ajouter Client” et le modèle analyse 3.3.5.2 Digramme de collaboration du cas ”Ajouter Client” Figure 3.10: digramme de collaboration du cas ”Ajouter Client” 51
  • 53. Chapiter 3 : Analyse 3.3.6 Analyse du cas d’utilisation ”Modifier Service” de l’acteur ’Membre’ 3.3.6.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Modi- fier Service” et le modèle analyse Figure 3.11: diagramme de traçabilité entre le modèle de cas d’utilisation ”Modifier Ser- vice” et le modèle analyse 3.3.6.2 Digramme de collaboration du cas ”Modifier Service” Figure 3.12: digramme de collaboration du cas ”Modifier Service” 52
  • 54. Chapiter 3 : Analyse 3.3.7 Analyse du cas d’utilisation ”Supprimer Membre” de l’ac- teur ’Administrateur’ 3.3.7.1 Diagramme de traçabilité entre le modèle de cas d’utilisation ”Sup- primer Membre” et le modèle analyse Figure 3.13: diagramme de traçabilité entre le modèle de cas d’utilisation ”Supprimer Membre” et le modèle analyse 3.3.7.2 Digramme de collaboration du cas ”Supprimer Membre” Figure 3.14: digramme de collaboration du cas ”Supprimer Membre” 53
  • 55. Chapiter 3 : Analyse 3.4 Conclusion Au cours de ce chapitre, Nous avons essayé d’analyser les Cas d’utilisation pour Déterminer la traçabilité entre les cas d’utilisation et le modèle d’analyse. Nous avons aussi essayé de définir des diagrammes de collaboration pour mieux comprendre le flux de chaque cas d’utilisation. Nous pouvons maintenant passer au chapitre 4 pour fournir une conception détaillée de ce projet. 54
  • 56. Chapitre 4 Conception Sommaire 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.2 Présentation de la démarche du modèle de conception . . . . 56 4.3 Conception des cas d’utilisation . . . . . . . . . . . . . . . . . . 57 4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’acteur ’Ad- ministrateur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.2 Conception du cas d’utilisation ” Consulter article ” de l’acteur ’Visiteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.3 Conception du cas d’utilisation ” envoyer message” de l’acteur ’Visiteur’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’acteur ’Mem- bre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3.5 Conception du cas d’utilisation ” modifier service” de l’acteur ’Membre’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4 Diagramme de classe général . . . . . . . . . . . . . . . . . . . 68 4.4.1 Diagramme de classe général . . . . . . . . . . . . . . . . . . . . 68 4.5 Modèles de paquetages et de déploiement . . . . . . . . . . . . 68 4.5.1 Modèles de paquetages . . . . . . . . . . . . . . . . . . . . . . . . 68 4.5.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . 69 4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 55
  • 57. Chapiter 4 : Conception 4.1 Introduction La conception est un élément important de la préparation de notre application. Nous devons élaborer un plan qui examine diverses options de conception et de réalisation. Dans ce chapitre, Nous fournissons une conception détaillée en utilisant le diagramme de séquence et le diagramme de classe de conception. 4.2 Présentation de la démarche du modèle de concep- tion L’étude conceptuelle a besoin des moyens de déplacer le modèle sur lequel nous allons travailler, Les diagrammes de séquence : Les diagrammes de séquence sont utilisés pour illustrer les cas d’utilisation.Ils laissent de montrer la séquence verticale des messages passés entre objets au sein d’une interaction. Diagramme de classe :Le diagramme de classes montrer la structure statique du système en termes de classes et de relations entre ces classes. L’intérêt du diagramme de classes est la modélisation des entités du système d’information. Le diagramme de classes est utilisé pour représenter toutes les informations finales gérées par le domaine. 56
  • 58. Chapiter 4 : Conception 4.3 Conception des cas d’utilisation 4.3.1 Conception du cas d’utilisation ” s’authentifier ” de l’ac- teur ’Administrateur’ 4.3.1.1 Diagramme de traçabilité du cas d’utilisation ”s’authentifier” de l’ac- teur ’Administrateur’ entre le modèle d’analyse et le modèle de concep- tion Figure 4.1: Diagramme de traçabilité du cas d’utilisation ”s’authentifier” 57
  • 59. Chapiter 4 : Conception 4.3.1.2 Diagramme de séquence relative au cas d’utilisation ”s’authentifier” de l’acteur ’Administrateur’ Figure 4.2: Diagramme de séquence relative au cas d’utilisation ”s’authentifier” 4.3.2 Conception du cas d’utilisation ” Consulter article ” de l’acteur ’Visiteur’ 4.3.2.1 Diagramme de traçabilité du cas d’utilisation ”consulter article” de l’acteur ’visiteur’ entre le modèle d’analyse et le modèle de conception Figure 4.3: Diagramme de traçabilité du cas d’utilisation ”consulter article” 58
  • 60. Chapiter 4 : Conception 4.3.2.2 Diagramme de séquence relative au cas d’utilisation ”Consulter ar- ticle” de l’acteur ’visiteur’ Figure 4.4: Diagramme de séquence relative au cas d’utilisation ”consulter article” 4.3.3 Conception du cas d’utilisation ” envoyer message” de l’ac- teur ’Visiteur’ 4.3.3.1 Diagramme de traçabilité du cas d’utilisation ”envoyer message” de l’acteur ’Visiteur’ entre le modèle d’analyse et le modèle de conception Figure 4.5: Diagramme de traçabilité du cas d’utilisation ”envoyer message” 59
  • 61. Chapiter 4 : Conception 4.3.3.2 Diagramme de séquence relative au cas d’utilisation ”envoyer mes- sage” de l’acteur ’visiteur’ Figure 4.6: Diagramme de séquence relative au cas d’utilisation ”envoyer message” 60
  • 62. Chapiter 4 : Conception 4.3.4 Conception du cas d’utilisation ” Ajouter client” de l’ac- teur ’Membre’ 4.3.4.1 Diagramme de traçabilité du cas d’utilisation ”ajouter client” de l’ac- teur ’Membre’ entre le modèle d’analyse et le modèle de conception Figure 4.7: Diagramme de traçabilité du cas d’utilisation ”ajouter client” 61
  • 63. Chapiter 4 : Conception 4.3.4.2 Diagramme de séquence relative au cas d’utilisation ”ajouter client” de l’acteur ’Membre’ Figure 4.8: Diagramme de séquence relative au cas d’utilisation ”ajouter client” 62
  • 64. Chapiter 4 : Conception 4.3.5 Conception du cas d’utilisation ” modifier service” de l’ac- teur ’Membre’ 4.3.5.1 Diagramme de traçabilité du cas d’utilisation ”modifier service” de l’acteur ’Membre’ entre le modèle d’analyse et le modèle de conception Figure 4.9: Diagramme de traçabilité du cas d’utilisation ”modifier service” 63
  • 65. Chapiter 4 : Conception 4.3.5.2 Diagramme de séquence relative au cas d’utilisation ”modifier service” de l’acteur ’Membre’ Figure 4.10: Diagramme de séquence relative au cas d’utilisation ”modifier service” ]Conception du cas d’utilisation ” supprimer membre” de l’acteur ’Administrateur’ 64
  • 66. Chapiter 4 : Conception 4.3.5.3 Diagramme de traçabilité du cas d’utilisation ”supprimer membre” de l’acteur ’Administrateur’ entre le modèle d’analyse et le modèle de conception Figure 4.11: Diagramme de traçabilité du cas d’utilisation ”supprimer membre” 4.3.5.4 Diagramme de séquence relative au cas d’utilisation ”supprimer membre” de l’acteur ’Administrateur’ Figure 4.12: Diagramme de séquence relative au cas d’utilisation ”supprimer membre” 65
  • 67. Chapiter 4 : Conception ]Conception du cas d’utilisation ”demander offre” de l’acteur ’Visiteur’ 4.3.5.5 Diagramme de traçabilité du cas d’utilisation ”demander offre” de l’acteur ’Visiteur’ entre le modèle d’analyse et le modèle de conception Figure 4.13: Diagramme de traçabilité du cas d’utilisation ”demander offre” 66
  • 68. Chapiter 4 : Conception 4.3.5.6 Diagramme de séquence relative au cas d’utilisation ”demander offre” de l’acteur ’Visiteur’ Figure 4.14: Diagramme de séquence relative au cas d’utilisation ”demander offre” 67
  • 69. Chapiter 4 : Conception 4.4 Diagramme de classe général 4.4.1 Diagramme de classe général Figure 4.15: Diagramme de classe général 4.5 Modèles de paquetages et de déploiement 4.5.1 Modèles de paquetages Un paquetage est un regroupement de classes dont il règle les visibilités. Le contexte d’un paquetage permet de définir des notions et des propriétés spécifiques du domaine (noms, types, constantes, etc.). Les paquetages permettent de présenter une vue synthétique 68
  • 70. Chapiter 4 : Conception du modèle. De même qu’une classe est la représentation d’un concept, un paquetage est la représentation d’un domaine. Un paquetage peut être considère comme la spécification d’un domaine Particulier 4.5.2 Modèles de déploiement Un diagramme de déploiement est un diagramme de classe ou un diagramme d’ob- jet représentant les nœud ou les instances de nœud sur lequel le système s’exécute. Il propose une vision statique de la topologie du matériel s’exécute le système. Diagramme de déploiement montre les associations(connexion) existant ente nœud du système.Il ne montre pas les interactions entre le nœud 4.6 Conclusion Dons ce chapitre, Représente le processus de conception de notre application . D’abord en commençant par une architecture globale pour atteindre une conception détaille, en définir plusieurs diagrammes de conception. Le derniér chapitre sera concerné pour l’implémentation du projet ou la réalisation 69
  • 71. Chapitre 5 Implémentation Sommaire 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.2 Environnement de développement . . . . . . . . . . . . . . . . 71 5.2.1 Environnement de développement . . . . . . . . . . . . . . . . . 71 5.2.2 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . 71 5.3 Description de l’application . . . . . . . . . . . . . . . . . . . . 71 5.3.1 Présentation de l’interface ’s’authentifier’ : . . . . . . . . . . . . . 72 5.3.2 Présentation de l’interface ’page d’accueil’ . . . . . . . . . . . . 72 5.3.3 Présentation de l’interface ’contacter’ : . . . . . . . . . . . . . . . 73 5.3.4 Présentation de l’interface ’liste membre’ : . . . . . . . . . . . . . 73 5.3.5 Présentation de l’interface ’ajouter client’ : . . . . . . . . . . . . 74 5.3.6 Présentation de l’interface ’gérer client’ : . . . . . . . . . . . . . . 74 5.3.7 Présentation de l’interface ’liste des messages’ : . . . . . . . . . . 75 5.1 Introduction Dans ce derniér chapitre nous présentons la phase de réalisation qui a pour objectif d’ex- poser le travail achevé. Nous présentons tout d’abord l’environnement de développement on va voir l’environnement logiciel et matière utilisée pour développer l’application demandée. par la suite , Nous présentons des interfaces de l’application et scenario de réalisation. 70
  • 72. Chapiter 5 : Implémentation 5.2 Environnement de développement Pendant la phase de développement de notre application, nous avons utilisé un ensemble d’outils et moyens techniques qui constituent l’environnement général de travail. Il peut être diviser en deux types : un environnement matériel et un environnement logiciel. Ci- dessous, nous allons écrire et séparer chacun d’eux. 5.2.1 Environnement de développement 5.2.2 Environnement matériel L’application est développée sur un ordinateur portable avec les caractéristiques sui- vantes : Marque Asus Processeur Intel(R) Core(TM)i3 RAM 8,00 Go Carte Graphique Intel(R) HD Graphics 520 Disque Dur 1 TB Système D’exploitation Windows 10 professionnelle64 bits 5.3 Description de l’application Dans cette partie, nous allons présenter les interfaces les plus importantes de notre application tout en en expliquant leurs utilités et leurs fonctionnements. 71
  • 73. Chapiter 5 : Implémentation 5.3.1 Présentation de l’interface ’s’authentifier’ : Figure 5.1: Présentation de l’interface ’s’authentifier’ : 5.3.2 Présentation de l’interface ’page d’accueil’ Figure 5.2: Présentation de l’interface ’page d’accueil’ 72
  • 74. Chapiter 5 : Implémentation 5.3.3 Présentation de l’interface ’contacter’ : Figure 5.3: Présentation de l’interface ’contacter’ 5.3.4 Présentation de l’interface ’liste membre’ : Figure 5.4: Présentation de l’interface ’liste membre’ 73
  • 75. Chapiter 5 : Implémentation 5.3.5 Présentation de l’interface ’ajouter client’ : Figure 5.5: Présentation de l’interface ’ajouter client’ 5.3.6 Présentation de l’interface ’gérer client’ : Figure 5.6: Présentation de l’interface ’gérer client’ 74
  • 76. Chapiter 5 : Implémentation 5.3.7 Présentation de l’interface ’liste des messages’ : Figure 5.7: Présentation de l’interface ’liste des messages’ 75
  • 77. Conclusion générale et perspectives A la fin de notre formation licence informatique, nous avons été capable de réaliser un Projet de fin d’année. Notre travail est basé sur le développement d’une application web. Cela nous a conduit à découvrir une nouvelle plateforme de développement. J’ai passé deux mois dans les locaux du Optans ou j’ai participé aux différentes phases du projet, de la détermination des exigences aux tests d’admission en utilisant la méthodologie Cascade. Pendant la période du stage, Je me suis familiarisé avec la conception de systèmes d’in- formation et le développement en utilisant les nouvelles technologies web. Finalement, Ce travail peut être améliorér en effectuant certaines tâches supplémentaires que nous n’avons pas pu terminer faute de temps. 76
  • 78. Annexe 1 NodeJs : NodeJS est une plateforme construite sur le moteur JavaScript V8 de Chrome qui permet de développer des applications en utilisant du JavaScript. Il se distingue des autres plateformes grâce à une approche non bloquante permettant d’effectuer des entrées/sorties (I/O) de manière asynchrone. [2] ExpressJs ExpressJS est une librairie qui vous permettra de créer une application Web plus simplement qu’avec l’objet http directement. Elle fournit un ensemble de méthode permettant de traiter les requêtes HTTP et fournit un système de middleware pour étendre ses fonctionnalités. [3] MongoDB MongoDB est base de données de documents, ce qui signifie qu’elle stocke les données au format de documents JSON. Nous estimons qu’il s’agit de la façon la plus naturelle d’envisager les données, bien plus efficace et expressive que le modèle traditionnel basé sur des rangées et des colonnes. [4]
  • 79. Handlebars.Js Handlebars.js est un langage de Template populaire et très puissant, simple à utiliser et dispose d’une grande communauté. Il est basé sur le langage de Template Moustache, tout en ajoutant plusieurs améliorations importantes. Avec Handlebars, vous pouvez séparer la génération de votre HTML du reste de votre code JavaScript ce qui permet d’avoir un code plus propre. [5] HTML5 Le HTML5 est un langage de base pour la création de site internet, il sert à structurer vote document. D’autre langage peuvent s’ajouter lors de la conception, mais tous les sites web contiennent du HTML. HTML5 désignant la version du langage HTML.[6] CSS3 Le terme CSS est l’acronyme anglais de Cascading Style Sheets qui peut se traduire par ”feuilles de style en cascade”. Le CSS est un langage informatique utilisé sur l’internet pour mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi appelé les fichiers CSS, comprennent du code qui permet de gérer le design d’une page en HTML. [7]
  • 80. Bootstrap Bootstrap est un framework développé par l’équipe du réseau social Twitter. Proposé en open source (sous licence MIT), ce framework utilisant les langages HTML, CSS et JavaScript fournit aux développeurs des outils pour créer un site facilement. Ce framework est pensé pour développer des sites avec un design responsive, qui s’adapte à tout type d’écran, et en priorité pour les smartphones. Il fournit des outils avec des styles déjà en place pour des typographies, des boutons, des interfaces de navigation et bien d’autres encore. On appelle ce type de framework un ”Front-End Framework”. [8]
  • 81. Références [1] https ://fr.wikipedia.org/wiki/CycleenV [2] https ://www.grafikart.fr/tutoriels/nodejs-intro-792 [3] https ://www.grafikart.fr/tutoriels/express-798 [4] https ://www.mongodb.com/fr [5] https ://www.supinfo.com/articles/single/2831-handlebars [6] http ://41mag.fr/ [7] http ://glossaire.infowebmaster.fr/css/ [8] https ://www.journaldunet.com/web-tech/developpeur/1159810-bootstrap-definition- tutoriels-astuces-pratiques
  • 82. Résumé Ce projet a été élaboré dans le cadre du projet de fin d’études en vue de l’obtention du diplôme de la licence fondamentale en Sciences de l’informatique. Il a été destiné à l’étude, la conception et la réalisation d’une application Web au profit du Optans une société du Technolo- gies et services de l’information . Ä Pour accomplir ce travail, nous avons choisi comme langage de modélisation le formalisme UML. En fait, notre choix est prouvé par rapport à sa clarté et sa perfor- mance en matière de conception. Ä la réalisation de notre applica- tion nécessite l’utilisation de ” MongoDb ” comme serveur de base de données. De plus pour la conception des interfaces, nous avons choisi les langages de programmation Html, Css, javascript