Krimi Final

Introduction générale ISAEG 2020
Table des matières

Introduction Générale............................................................................................................................1
Chapitre 1 : Contexte Général................................................................................................................4
Introduction...........................................................................................................................................5
1. Présentation de l’entreprise.......................................................................................................5
1.1 Historique..................................................................................................................................5
1.2 Ressource de l’institut...............................................................................................................6
1.3 Organigramme de l’institut........................................................................................................6
2. Contexte du projet.....................................................................................................................7
3. Description de l’existant.............................................................................................................8
4. Critique de l’existant...................................................................................................................8
5. Solution proposée......................................................................................................................9
6. Critères d’acceptabilité du produit.............................................................................................9
Conclusion :..........................................................................................................................................10
Chapitre 2 : Expression des besoins et contraintes..............................................................................11
Introduction.........................................................................................................................................12
1. Les acteurs du système.............................................................................................................12
2. Spécification des besoins..........................................................................................................12
2.1 Besoins fonctionnels................................................................................................................12
2.2 Besoins non fonctionnels.........................................................................................................12
3. Les contraintes.........................................................................................................................13
3.1 Les contraintes ergonomiques.................................................................................................13
3.2 Les contraintes techniques......................................................................................................13
3.3 Les contraintes matérielles......................................................................................................13
4. Cas d’utilisation de projet.........................................................................................................14
4.1 Identification des cas d’utilisation...........................................................................................14
4.2 Spécification et raffinement des cas d’utilisation....................................................................14
5. Raffinement des cas d’utilisation..............................................................................................14
5.1 Raffinement du cas « S’authentifier »......................................................................................14
5.2 Raffinement du cas « Gérer SMS »..........................................................................................15
5.3 Raffinement du cas « Gérer contact»......................................................................................17
5.4 Raffinement du cas « Gérer filière »........................................................................................19
5.5 Raffinement du cas « Gérer groupe».......................................................................................20
5.6 Raffinement du cas « Gérer Profil personnel».........................................................................22
i
Chapitre III : Etude Conceptuelle..........................................................................................................24

Introduction.........................................................................................................................................25
1. Le Short Message System (SMS)...............................................................................................25
2. La reconnaissance optique de caractère..................................................................................25
2.1 Définition.................................................................................................................................25
2.2 Domaines d’application...........................................................................................................25
2.3 Types.......................................................................................................................................26
2.4 Techniques...............................................................................................................................26
3. RPC RESTful..............................................................................................................................26
3.1 RPC..........................................................................................................................................26
3.2 REST.........................................................................................................................................27
4. JSON.........................................................................................................................................27
5. Architecture envisagée.............................................................................................................28
6. La modélisation des données...................................................................................................28
6.1 Présentation............................................................................................................................28
6.2 Langage de modélisation des données....................................................................................29
7. Conception des cas d’utilisation...............................................................................................31
7.1 conception du cas « S’authentifier ».......................................................................................31
7.2 Conception du cas « Gérer SMS »...........................................................................................34
7.3 conception du cas « Gérer contact».......................................................................................38
7.4 conception du cas « Gérer filière ».........................................................................................43
7.5 Conception du cas « Gérer groupe»........................................................................................48
7.6 conception du cas « Gérer profil»...........................................................................................52
Chapitre 4 : Réalisation et Outils..........................................................................................................56
Introduction.........................................................................................................................................57
Conclusion............................................................................................................................................57
Conclusion Générale et Perspectives...................................................................................................58
ii
Table des figures
Figure 1: Organigramme de l’Institut Supérieur d’Administration des Entreprises de Gafsa.......6

Figure 2:Diagramme de cas d’utilisation général...............................................................................14
Figure 3:Diagramme de cas d’utilisation « S’authentifier»....................................................................15
Figure 4:Diagramme de cas d’utilisation «Gérer SMS ».......................................................................16
Figure 5:Diagramme de cas d’utilisation « Gérer contact»....................................................................19
Figure 6 :Diagramme de cas d’utilisation « Gérer groupe»...................................................................20
Figure 7 :.................................................................................................................................................27
Figure 8:Traçabilité MCU/MC du cas d’utilisation « S’authentifier »..................................................31
Figure 9:Diagramme de classe du cas « S’authentifier»........................................................................32
Figure 10: Diagramme de séquence du cas « S’authentifier»................................................................34
Figure 11:Traçabilité MCU/MU du cas d’utilisation « Gérer SMS »....................................................35
Figure 12:Diagramme de classe du cas « Gérer SMS»..........................................................................35
Figure 13: Traçabilité MCU/MU du cas d’utilisation « Gérer contact».................................................38
Figure 14: Diagramme de classe du cas « Gérer contact»......................................................................39
Figure 15: Traçabilité MCU/MU du cas d’utilisation « Gérer filière »..................................................43
Figure 16: Diagramme de classe du cas « Gérer filière»........................................................................44
Figure 17: Traçabilité MCU/MU du cas d’utilisation « Gérer groupe».................................................48
Figure 18: Diagramme de classe du cas « Gérer groupe»......................................................................48
Figure 19: Traçabilité MCU/MU du cas d’utilisation « Gérer profil»...................................................52
Figure 20: Diagramme de classe du cas « Gérer profil ».......................................................................53
iii
Table des tableaux
Tableau 1: Description des acteurs...........................................................................................12

Tableau 2. :Description textuelle du cas d’utilisation « s’authentifier »..................................15
Tableau 3: Scénario de cas d’utilisation « Envoi simple ».......................................................16
Tableau 4: Scénario de cas d’utilisation « Envoi massif ».......................................................17
Tableau 5: Scénario de cas d’utilisation « Envoi à partir du document».................................17
Tableau 6: Scénario de cas d’utilisation « Ajouter contact»....................................................18
Tableau 7: Scénario de cas d’utilisation « Modifier contact ».................................................18
Tableau 8: Scénario de cas d’utilisation « Supprimer Contact »..............................................19
Tableau 9: Scénario de cas d’utilisation « Ajouter filière ».....................................................19
Tableau 10: Scénario de cas d’utilisation « Modifier filière»..................................................20
Tableau 11: Scénario de cas d’utilisation « Supprimer filière»................................................20
Tableau 12: Scénario de cas d’utilisation « Ajouter groupe »..................................................21
Tableau 13: Scénario de cas d’utilisation « Modifier groupe».................................................21
Tableau 14: Scénario de cas d’utilisation « Supprimer groupe»..............................................22
Tableau 15: Scénario de cas d’utilisation « Modifier profil personnel»..................................22
Introduction Générale
1
Les appareils mobiles et l'émergence des technologies sans fil sont devenus aujourd'hui un
élément important de la société. Les entreprises ont adopté des appareils mobiles et des
technologies sans fil pour soutenir et améliorer les performances de leur entreprise.
Aujourd'hui, même les petits appareils mobiles peuvent accéder à Internet. De ce fait, les
problèmes de mobilité sont devenus des intérêts de recherche techniques et économiques
importants.
Le téléphone mobile a réformé notre vie, des moyens que nous communiquons aux moyens
que nous exerçons, la mobilité du téléphone mobile permet à l'utilisateur de passer un appel
presque partout et à tout moment. En Tunisie, le nombre des abonnés au service téléphonique
grimpé de 120 milles en 2000 à plus de 14,7 millions d’abonnés en 2008 selon le site
statista.com.
La fonction des téléphones a été étendue des simples appareils de communication vocale
uniquement à la navigation sur Internet et au transfert de données, les gens ont développé
l'attachement au téléphone mobile et le gardent comme compagnon de la vie quotidienne.
L’institut supérieur d’administration des entreprises de Gafsa en tant qu'institut

d'enseignement supérieur, tient et organise de nombreux événements tout au long de l'année
académique. Ces événements peuvent être de plus simple ; comme un affichage de note, de
rattrapage, l’invocation des enseignants à une délibération des résultats ou une réunion ; au
plus compliqué (un colloque ou séminaire par exemple).
La procédure actuelle suivie par l’institut consiste à envoyer des e-mails ou publier une
affiche papier au personnel sélectionné ou étudiants pour l'informer de l'événement ou de la
fonction auquel il est censé participer. La notification comprendra des détails sur cet
événement, comme la fonction et la date et le lieu de cette fonction. Ce type de notification
n’est pas idéale vu qu’il exige une connexion internet et une consultation quotidienne d’email
ou une présence hebdomadaire pour le cas des affiches
Pour cela nous cherchons à créer une application qui assure l’envoi des notes, des
évènements, l’invocation des enseignants à une délibération des résultats, etc. et ce à tous les
personnels de l’institut par notification SMS.
Dans le présent rapport nous présentons en détail les étapes que nous avons suivi pour réaliser
notre application. Ce rapport comporte quatre chapitre organisés comme suit :
2
Dans le premier chapitre nous commençons par la présentation du contexte de l’étude.

Ensuite, nous passons à l’analyse de l’existent en décrivant les éventuels projets
précédemment réalisés et qui ont des objectifs similaires à notre application. Enfin, nous
présentons l’architecture de notre application.
Le deuxième chapitre sera consacré à l’expression des besoins et contraintes puis en

présentons les acteurs et les cas d’utilisations.
Le troisième chapitre se focalise sur l’étude conceptuelle et l’analyse de différentes

fonctionnalités de l’application à travers des diagrammes UML.
Le quatrième chapitre sera consacré à la présentation des outils utilisés pour réaliser le travail
requis. De plus, nous détaillons les différentes interfaces de notre application.
3
Chapitre 1 : Contexte
Général
4
Chapitre 1 : Contexte général ISAEG 2020
Introduction
Dans ce chapitre nous mettons notre travail dans son contexte général, tout d’abord, nous
décrivant l’environnement du stage à travers une brève présentation de l’entreprise. Ensuite
nous présentons le cadre général de notre projet.
1. Présentation de l’entreprise
1.1 Historique
Fondée 04 aout 2003 selon le décret 1663, l’institut Supérieur d’Administration des
Entreprises de Gafsa (ISAEG) accueille aujourd’hui plus de 1290 étudiants et décerne deux
diplômes de licence : licence fondamentale et licence appliquée et deux diplômes en mastère :
Monnaie fiance développement et Finance sont deux mastères de recherche, et CMPME,
CCA et Data sciences, des mastères professionnelles. L’institut délivre un enseignement
scientifique et technique de haut niveau qui se décline harmonieusement entre les différentes
spécialités d’économie, de gestion et d’informatique.
L’institut s’est donné pour mission d’apporter sa contribution à la formation de ses étudiants
qui, en fin d’étude, auront les compétences nécessaires pour s’insérée et s’intégrer
efficacement et rapidement dans la vie professionnelle et y exercer des responsabilités de plus
en plus diversifiées et individualisées.
Grace à une formation intensive et multidimensionnelle reçue, notre établissement contribue à

la modernisation de la gestion de l’entreprise tunisienne, notamment les établissements
financiers tels que les banques et les assurances.
Dans l’institut les études se déroule sur trois ans et se termines par l’obtention d’un diplôme
de licence et deux ans de plus pour l’obtention d’un mastère dans les spécialités suivantes :
 Licence fondamentale en économie (Monnaie, finance et banque)

 Licence fondamentale en gestion (Finance, comptabilité, Administration des affaires)
 Licence applique en gestion (TMR, GC, Fi Islamique)
 Licence fondamentale en informatique de gestion,
 Mastère recherche Finance,
 Mastère recherche monnaie, Finance et développement
 Mastère professionnelle CMPME,
5
 Mastère professionnelle CCA,

 Mastère professionnelle Data Sciences,
1.2 Ressource de l’institut
L’ISAEG est dotée d’un grand nombre d’installation de qualité permettant aux enseignants et
aux étudiants de travailler dans un cadre agréable. On y compte, en particulier :
 03 amphithéâtres de 150 places.

 14 salles de cours et de TD
 05 salles informatiques avec à peu près 50 ordinateurs et un réseau WI-FI sur tout le
l’établissement.
 Une bibliothèque bien fournie en ouvrage et revues scientifiques
 Une buvette interne.
 Une grande salle de lecture.
1.3 Organigramme de l’institut
Scolarité Service Service Service Service 3ème Bibliothèque Magasin

Financier Personnel informatique cycle
Figure 1: Organigramme de l’Institut Supérieur d’Administration des Entreprises de Gafsa
6
Ce diagramme représente l’architecture de l’institut qui se compose de la direction qui assure

le conseil scientifique, puis les deux importantes divisions qui sont la direction des études et
le secrétariat général.
Les directions des études se composent de trois départements :
 Département sciences de gestion et finance

 Département comptabilité, sciences juridiques et fiscales
 Département sciences économie, méthodes quantifies et informatique
Le secrétariat général s’occupe de tout ce qui est administratif. Un ensemble de services sont
sous la direction du secrétaire général. Nous citons :
 Le service scolarité : qui représente le plus important service dans l’institut, il

s’intéresse à tout ce qui concerne les étudiants, l’inscription, le déroulement du cours,
des examens, les stages, les résultats, etc.…
 Service financier : qui s’occupe de tout ce qui monétaire, ainsi que l’enregistrement
et le règlement de toutes les opérations financières
 Service personnel : ses fonctions sont essentiellement de garder et suivre les fichiers
des personnels de l’institut que ce soit administratifs ou bien les enseignants.
 Le magasin : son rôle principal est de fournir aux personnels de l’institut leurs
besoins de matériels, équipement et outils selon les recettes d’alimentation internes, et
de s’occuper de tout ce qui matériels et marchandises.
 Service troisième : cycle s’intéresse à tout ce qui concerne les mastères
professionnels ou de recherche
 La bibliothèque : regroupe l’emprunte des livres, les supports numériques, les types
des examens, les anciens modèles de rapports des stages ou de fin d’étude.
 Service informatique : qui s’intéresse aux matériels, logiciels et réseaux, ce service
est le plus intéressant pour nous puisque c’est le lieu d’élaboration de notre projet, et
l’amélioration du travail au sein de ce service se fait par l’élaboration d’une
application de la gestion du service informatique.
2. Contexte du projet
Ce projet s’inscrit dans le contexte d’un projet de fin d’étude du programme informatique
appliqué a la gestion de l’Institut Supérieur d’Administration des Entreprises de Gafsa
7
(ISAEG). Ceci dans le but de nous permettre d’appliquer les connaissance acquises en
langage Java dans un projet réel.
Le sujet qui nous le plus attiré est le « développement d’un outil d’envoi des SMS » le
choix de ce projet vient du constat fait que le besoin d’envoyer des messages à temp réel se
fait de plus en plus agrandissent surtout avec l’avènement des nouvelles technologies .
3. Description de l’existant
Pour apprendre une idée sur l’existant, on peut prendre premièrement le cas d’affichage les
notes et les résultats, si on veut afficher des notes ou des résultats un administrateur imprime
Les feuilles des notes en trois copies et l’un des deux prenez-le et l’affiche sur le tableau.
Dans un autre cas s’il y a une réunion ou délibération des résultats l’administrateur envoi des
e-mails aux enseignants ou les appelle pour les inviter à participer.
Lorsque l’université organise des événements elle utilise la mémé manière d’affichage que les
notes et les résultats.
Parfois la direction de l’institut utilise le réseau social « Facebook » pour communiquer ces
informations aux étudiants.
4. Critique de l’existant
Les méthodes adoptées actuellement ont certains problèmes, parmi lesquelles :
- prend plus de temps et gaspille beaucoup des papiers,
- Parfois les affiches se perdre, parfois aussi les documents qui ont affichées sur les tableaux
contenant des informations non claires à cause de mauvaise impression,
- un étudiant peut déchirer le papier par conséquent chers collègues ne peuvent pas voient
leurs notes ou résultat.
Nous avons constaté au niveau de l’étudiant et l’enseignant qu’il y a des problèmes

notamment l’absence de l’information pour les personnes qui vivent loin de l’établissement.
D’autre part le réseau social « Facebook » n’est pas une manière efficace et professionnelle
utilisé par un institut universitaire pour fournir n’importe quelle information à leur étudiants.
8
Au plus part du temps les mails n’ont pas ouvert par les professeurs, dans cette cas
l’information n’arrivant comme il se doit à l’enseignant et par suite il ne vient pas à
l’établissement.
5. Solution proposée
Le principal objectif du présent travail réside principalement de trouver une solution optimale
et facile à utiliser spécialement pour automatiser le système d’information de l’institut. Il offre
de gros avantages par rapport au système papier.
Dans ce contexte, notre application permet d’envoyer une SMS aux étudiants et enseignants
existant dans une base de données pour informez-les de leurs informations.
C’est un service basé sur l’outil de communication sur réseau.
6. Critères d’acceptabilité du produit

A la fois mémorisable, rapide et rentable, le SMS professionnelle est un moyen qui offre une
bonne communication. Dans la mesure où le message délivré et court , il capte facilement
l’attention du destinataire qui obtiendra une information concise et précise. Il est en outre
plus efficace que l’emailing professionnel. Le SMS est un moyen percutant susceptible
d'attirer l'attention plus qu'un email.
Le choix du Short Message Service (SMS) ne résulte pas du hasard. En fait, il suffit de voir
les statistiques pour savoir qu’aujourd’hui le SMS est un outil performant pour dérouler un
système d’information automatisé
Voici quelques raisons qui font de SMS un canal judicieux pour offrir une meilleure
communication :
-La facilité d’utilisation : Parce que le SMS est un canal déjà utilisé par un très grand
nombre de personnes, il constitue un choix naturel pour contacter les étudiants et les
enseignants. Smart Insights montre que plus de 80% des internautes possèdent un smartphone.
-La personnalisation de l’expérience : Le SMS est un mode de communication très

personnel, dans la mesure où il rend possible des interactions naturelles et en temps réel.
-L’efficacité : Le SMS fait gagner du temps aux clients, car les messages peuvent être
envoyés rapidement et en temps réel.
9
-Les SMS ont un cout très peu élevé : Le SMS est un canal de communication très peu
couteux, les envois groupés de SMS sont beaucoup plus économiques que les prospectus
papier.
- Un SMS est lu instantanément et a un impact immédiat : Les derniers étude selon

l’INSEE (L’Institut National de la Statistique et des Etudes Economiques) montre que le taux
d’ouverture d’un SMS est de 98% alors que le taux d’ouverture d’un mail d’à peine 20%,
quant aux notification de Facebook elles n’ont un taux d’ouverture que de 12% . Le contenu
d’un SMS est mémorisé à 60% beaucoup plus rapidement que le contenu d’un mail ou d’un
prospectus papier.
Cette application sera très utile pour l’établissement puisqu’il permettre de fournir une
communication plus rapide, plus fiable et plus économique et aussi officiel.
Conclusion :
Dans ce chapitre nous représente le cadre général de l’institut supérieur d’administration d’entreprise
de Gafsa, puis on a essayé de trouver les problèmes liés au système d’information au sein de l’institut
et nous proposons la solution. Le chapitre suivant sera consacré pour l’analyse et la spécification des
besoins de notre application.
10
Chapitre 2 : Expression des
besoins et contraintes
11
Introduction
Dans ce chapitre on va présenter les acteurs du système, les besoins fonctionnels ainsi que les
besoins non fonctionnels. Par la suite, on va présenter les diagrammes des cas d’utilisation
détaillées.
1. Les acteurs du système

Dans notre application puisqu’il est administratif on a un seul acteur qui est l’administrateur.
Le tableau ci-dessous présente une spécification du rôle pour l’acteur administrateur :
Acteur Rôle
-Gérer les SMSs ,
-Gérer les contacts,
Administrateur -Gérer les filières ,
-Gérer les groupes,
-Gérer le profil personnel.
-Gérer les enseignants et les étudiants .

Tableau 1: Description des acteurs
2. Spécification des besoins

2.1 Besoins fonctionnels
Les besoins fonctionnels ou besoin métiers représentent les actions que le système doit
exécuter, il ne devient opérationnel que s’il les satisfait. Le système doit permettre de :
-Envoyer des SMS à une liste de personne préenregistré dans une base de données.
-Afficher les informations concernant les SMS envoyés.
-Gérer les personnels en permettant la : ajout d’un personne, suppression d’un personne,
modification des coordonnées d’un personne ou recherche d’un personne.
2.2 Besoins non fonctionnels
12
Les besoins non fonctionnels décrivent les objectifs liés aux performances du système. Ses
exigences techniques sont souvent exprimées sous forme d’objectifs spécifiques que doit
atteindre le système. L’application doit vérifier implicitement ces critères :
-Sécurité :Toute utilisation de l’application implique l’authentification de l’administrateur
-La fiabilité : l’application doit garantir l’envoi du message à tous les enseignants et les
étudiants.
- L’ergonomie : La facilité de l’utilisation de l’application via son interface.
- La maintenabilité : Le code doit être clair pour permettre des futures évolutions ou
améliorations.
-Les champs de saisie doivent être contrôlés
-La rapidité d’envoi de l’SMS.
3. Les contraintes
3.1 Les contraintes ergonomiques
Les contraintes ergonomiques sont les contraintes liées à l'adaptation entre les fonctionnalités
de l'application, leurs interfaces et leur utilisation.
Pour notre application, nous devons obéir aux contraintes ergonomiques suivantes :
- Permettre un accès rapide de l'information.
- Interface simple et compréhensible.
- L'organisation des rubriques, des onglets, etc.
3.2 Les contraintes techniques

- Il faut que toute interface de l'application soit homogène, en effet, les différentes pages
doivent suivre le même modèle de représentation (couleurs, images, textes défilants, etc.).
- Le code doit être extensible et maintenable pour faciliter toute opération d'amélioration ou
d'optimisation
3.3 Les contraintes matérielles

L'application sera installée sur un ordinateur à système d’exploitation Windows.
13
4. Cas d’utilisation de projet

4.1 Identification des cas d’utilisation
Un cas d’utilisation est un service rendu à un acteur : c’est une fonctionnalité de son point de
vue.
L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences

fonctionnelles du système. Chaque cas d’utilisation correspond donc à une
fonction métier du système, selon le point de vue d’un de ses acteurs.
Un cas d'utilisation (Use Case) est décrit par un ensemble de séquence d’actions
réalisées par le système et produisant un résultat observable et intéressant pour un acteur.
Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système.
4.2 Spécification et raffinement des cas d’utilisation

4.2.1 Spécification des cas d’utilisation général
La figure 2.1 représente le diagramme de cas d’utilisation général de cette application.
Avant d’effectuer n’importe quelle activité l’administrateur obligatoirement s’authentifier par

la saisie de login et mot de passe.
Figure 2:Diagramme de cas d’utilisation général
5. Raffinement des cas d’utilisation

5.1 Raffinement du cas « S’authentifier »
14
5.1.1 cas d’utilisation «S’authentifier »
Figure 3:Diagramme de cas d’utilisation « S’authentifier»

5.1.2 Description du cas d’utilisation « S’authentifier »
CU : S’authentifier
Objet : Saisie de login et de mot de passe
Acteurs : Administrateur
Précondition : Interface d’authentification affichée
Post-Condition : Administrateur authentifié
Scénario nominal :
Description du scénario nominal
« DEBUT »
1 :L’ Administrateur saisit login et mot de passe
2 :Le système vérifie les paramètres d’authentification(login et mot de passe)
3 :Le système renvoie la page d’accueil
« FIN »
Scénario alternatif :
L’ Administrateur saisit les paramètres erronés
 Le système affiche un message d’erreur et reprend au point 1 du scénario nominal
 L’utilisateur ressaisit les informations de connexion
Tableau 2. :Description textuelle du cas d’utilisation « s’authentifier »

5.2 Raffinement du cas « Gérer SMS »
5.2.1 Cas d’utilisation « Gérer SMS »
15
Figure 4:Diagramme de cas d’utilisation «Gérer SMS »

5.2.2 Description du cas d’utilisation « Gérer SMS »
 Envoyer SMS simple
Précondition : Interface de gestion SMS
Post-Condition : SMS envoyé
Scénario nominal :
« DEBUT »
1 :L’administrateur demande d’envoyer SMS personnalisé
2 :Le système affiche l’interface d’envoi SMS personnalisé
3 :l’administrateur remplir les champs et clique sur le bouton « Envoyer »
4 : SMS envoyé
« FIN »
L’administrateur saisit les paramètres erronés
Tableau 3: Scénario de cas d’utilisation « Envoi simple »
 Envoyer SMS massif
Scénario nominal :
« DEBUT »
1 :L’administrateur demande d’envoyer SMS groupé
2 :Le système affiche l’interface d’envoi SMS groupé
3 :l’administrateur remplir le formulaire et clique sur le bouton « Envoyer »
4 : SMS envoyé
« FIN »
16
Tableau 4: Scénario de cas d’utilisation « Envoi massif »

 Envoyer à partir du document
Scénario nominal :
« DEBUT »
1 :L’administrateur demande d’envoyer SMS groupé
2 :Le système affiche l’interface d’envoi SMS groupé
3 :l’administrateur remplir le formulaire et clique sur le bouton « Envoyer »
4 : SMS envoyé
« FIN »
Tableau 5: Scénario de cas d’utilisation « Envoi à partir du document»

 Consulter
5.3 Raffinement du cas « Gérer contact»
5.3.1 Cas d’utilisation « Gérer contact »
5.3.2 Description du cas d’utilisation « Gérer contact »

 Ajouter
Précondition : Interface de gestion contact
Post-Condition : contact ajouté
Scénario nominal :
« DEBUT »
1 :L’administrateur demande de gérer groupe
17
2 :Le système affiche l’interface de gérer groupe

3 :l’administrateur remplir le formulaire et clique sur le bouton « ajouter »
3 :groupe est ajouté
« FIN »
Tableau 6: Scénario de cas d’utilisation « Ajouter contact»
 Modifier
Post-Condition : contact modifié
Scénario nominal :
« DEBUT »
2 :Le système affiche l’interface de gérer groupe
3 :l’administrateur sélectionne un groupe puis saisir les modifications et clique sur le
bouton « modifier »
4 :groupe est modifié
« FIN »
Tableau 7: Scénario de cas d’utilisation « Modifier contact »
 Supprimer
Post-Condition : contact supprimé
Scénario nominal :
« DEBUT »
2 :Le système affiche l’interface de « gérer groupe »
3 :l’administrateur sélectionne un groupe et clique sur le bouton « Supprimer »
4 :groupe est supprimé
« FIN »
18
Tableau 8: Scénario de cas d’utilisation « Supprimer Contact »

 Consulter
5.4 Raffinement du cas « Gérer filière »
5.4.1 Cas d’utilisation «Gérer filière»
Figure 5:Diagramme de cas d’utilisation « Gérer contact»

5.4.2 Description du cas d’utilisation « Gérer filière »
 Ajouter
Précondition : Interface de gestion filière
Post-Condition : filière ajouté
Scénario nominal :
« DEBUT »
1 :L’administrateur demande l’interface de gérer un contact
2 :Le système affiche l’interface de gérer contact
3 : filière est ajouté
« FIN »
Tableau 9: Scénario de cas d’utilisation « Ajouter filière »
 Modifier
Post-Condition : filière modifié
Scénario nominal :
« DEBUT »
19
1 :L’administrateur demande l’interface de gestion un contact

2 :Le système affiche l’interface de gestion un contact
3 :l’administrateur sélectionne un contact puis saisir les modifications et clique sur le
4 : filière est modifié
« FIN »
Tableau 10: Scénario de cas d’utilisation « Modifier filière»
 Supprimer
Post-Condition : filière supprimé
Scénario nominal :
« DEBUT »
1 :L’administrateur demande de gérer un contact
3 :l’administrateur sélectionne un contact et clique sur le bouton « Supprimer »
4 : filière est supprimé
« FIN »
Tableau 11: Scénario de cas d’utilisation « Supprimer filière»

 Consulter
5.5 Raffinement du cas « Gérer groupe»
5.5.1 cas d’utilisation «Gérer groupe»
Figure 6 :Diagramme de cas d’utilisation « Gérer groupe»

5.5.2 Description du cas d’utilisation « Gérer groupe»
20
 Ajouter
Précondition : Interface de gestion groupe
Post-Condition : groupe ajouté
Scénario nominal :
« DEBUT »
1 :L’administrateur demande l’interface de gérer un contact
2 :Le système affiche l’interface de gérer contact
3 :groupe est ajouté
« FIN »
Tableau 12: Scénario de cas d’utilisation « Ajouter groupe »
 Modifier
Post-Condition : groupe modifié
Scénario nominal :
« DEBUT »
4 : groupe est modifié
« FIN »
Tableau 13: Scénario de cas d’utilisation « Modifier groupe»
 Supprimer
Post-Condition : groupe supprimé
Scénario nominal :
« DEBUT »
21
1 :L’administrateur demande de gérer un contact

3 :l’administrateur sélectionne un contact et clique sur le bouton « Supprimer »
4 : groupe est supprimé
« FIN »
Tableau 14: Scénario de cas d’utilisation « Supprimer groupe»
 Consulter
5.6 Raffinement du cas « Gérer Profil personnel»
5.6.1 cas d’utilisation «Gérer profil personnel»
5.6.2 Description du cas d’utilisation « Gérer profil personnel»

 Modifier
Précondition : Interface de gestion profil personnel
Post-Condition : profil personnel modifié
Scénario nominal :
« DEBUT »
4 : profil personnel est modifié
« FIN »
Tableau 15: Scénario de cas d’utilisation « Modifier profil personnel»

 Consulter
Conclusion
22
A la fin de ce chapitre, nous décrivons les acteurs, puis on a bien étudié les besoins du client ;
on a présente l’ensemble des fonctionnalités du futur portail de manière organisée dans les
différents cycles de l’application soit fonctionnel ou non fonctionnel, puis nous spécifions les
cas d’utilisations tout en présentant le diagramme de cas d’utilisation. Cette présentation nous
facilite l’étude de troisième chapitre dans lequel nous détaillons l’étude conceptuelle
concernant l’application.
23
Chapitre III : Etude
Conceptuelle
24
Introduction
Dans ce chapitre, on va analyser et modéliser les besoins du l’institut avec le langage UML.
L’activité d’analyse et de conception permet de traduire les besoins fonctionnels, les
contraintes et de la spécification des exigences dans un langage plus professionnel et
compréhensible par tous les individus intervenants dans la réalisation et l’utilisation de
l’application.
1. Le Short Message System (SMS)

Le service de messagerie SMS, plus connu sous le sigle de SMS (pour « Short Message
Service ») ou les noms de « texto » ou de « minimessage », permet de transmettre de courts
messages textuels. C'est l'un des services de la téléphonie mobile (il a été introduit par la
norme GSM).
2. La reconnaissance optique de caractère

2.1 Définition
La reconnaissance optique de caractères (ROC), en anglais Optical character

recognition (OCR), ou océrisation, désigne les procédés informatiques pour la traduction
d'images ou de textes imprimés en fichiers de texte.
Un ordinateur réclame pour l'exécution de cette tâche un logiciel d'OCR. Celui-ci permet de
récupérer le texte dans l'image d'un texte imprimé et de le sauvegarder dans un fichier
pouvant être exploité dans un traitement de texte pour enrichissement, et stocké dans une base
de données ou sur un autre support exploitable par un système informatique.
2.2 Domaines d’application
Un problème particulièrement ardu pour les ordinateurs et les humains est celui des anciens
registres religieux des baptêmes et des mariages, qui contiennent surtout des noms, où les
pages peuvent être endommagées par le temps, l'eau ou le feu, et les noms peuvent être
obsolètes ou écrits selon d'anciennes graphies. Les techniques informatiques de traitement de
l'image peuvent aider les humains dans la lecture de textes extrêmement difficiles, comme le
palimpseste d’Archimède. Des approches coopératives où les ordinateurs assistent les
humains et vice-versa constituent un domaine de recherche intéressant.
25
La reconnaissance de caractère est un domaine actif de recherche pour la science informatique
depuis la fin des années 1950. Au début, on pensait qu'il s'agissait d'un problème facile, mais
il apparut qu'il s'agissait d'un sujet beaucoup plus intéressant. Il faudra encore de nombreuses
décennies aux ordinateurs, s'ils y parviennent un jour, pour lire tous les documents avec la
même précision que les êtres humains.
2.3 Types
 Reconnaissance optique de caractères (OCR) : cible le texte dactylographié, un glyphe ou

un caractère à la fois.
 Reconnaissance optique des mots : cible le texte dactylographié, un mot à la fois (pour les
langues qui utilisent un espace comme séparateur de mots). (Habituellement simplement
appelé "OCR".)
 Reconnaissance intelligente des caractères (ICR) : cible également le texte manuscrit

imprimé ou cursif un glyphe ou un caractère à la fois, impliquant généralement
l'apprentissage automatique.
 Reconnaissance intelligente des mots (IWR) : cible également les textes manuscrits
imprimés ou cursifs, un mot à la fois. Ceci est particulièrement utile pour les langues où les
glyphes ne sont pas séparés dans un script cursif.
2.4 Techniques
Avant toute chose, le programme analyse la structure de l’image du document, dont il divise
la page en éléments distincts tels que les textes, les tableaux, les images... Les lignes sont
définies en mots, puis en caractères. Une fois que le caractère aura été isolé, le programme les
compare avec un groupe de modèles d’images grâce auxquels des hypothèses sont avancées
sur ce que représente le caractère. C’est sur cette base d’hypothèses que le programme analyse
les différentes variantes des courbures des lignes en mots et de mots en caractères. Après
avoir passé en revue toutes ces hypothèses, le programme prend la décision de vous livrer un
texte qu’il pense être conforme à l’image reconnue.
De manière générale, ces systèmes reposent sur les trois principes fondamentaux intégrité,
définition des objectifs et adaptabilité.
26
3. RPC RESTful
3.1 RPC
En informatique et en télécommunication, RPC (remote procedure call) est un protocole

réseau permettant de faire des appels de procédures sur un ordinateur distant à l'aide
d'un serveur d’applications. Ce protocole est utilisé dans le modèle client-serveur pour assurer
la communication entre le client, le serveur et d’éventuels intermédiaires.
Ce système est également utilisé pour la conception des micro-noyaux.
3.2 REST
REST (representational state transfer) est un style d'architecture logicielle définissant un

ensemble de contraintes à utiliser pour créer des services web. Les services web conformes au
style d'architecture REST, aussi appelés services web RESTful, établissent une
interopérabilité entre les ordinateurs sur internet. Les services web REST permettent aux
systèmes effectuant des requêtes de manipuler des ressources web via leurs représentations
textuelles à travers un ensemble d'opérations uniformes et prédéfinies sans état. D'autres types
de services web tels que les services web SOAP exposent leurs propres ensembles
d'opérations arbitraires.
Figure 7 :
4. JSON
JavaScript Object Notation (JSON) est un format de données textuelles dérivé de la notation
des objets du langage JavaScript. Il permet de représenter de l’information structurée comme
27
le permet XML par exemple. Créé par Douglas Crockford entre 2002 et 2005, la première
norme du JSON est ECMA-404 qui a été publiée en octobre 2003, il est actuellement décrit
par les deux normes en concurrence : RFC 8259 de l’IETF et ECMA-404 de l'ECMA.
5. Architecture envisagée
Modèle-vue-contrôleur ou MVC est un motif d'architecture logicielle destiné aux interfaces
graphiques lancé en 1978 et très populaire pour les applications web. Le motif est composé
de trois types de modules ayant trois responsabilités différentes : les modèles, les vues et les
contrôleurs.
 Un modèle (Model) contient les données à afficher.
Une vue (View) contient la présentation de l'interface graphique.
Un contrôleur (Controller) contient la logique concernant les actions effectuées par

l'utilisateur.
Modèle : Élément qui contient les données ainsi que de la logique en rapport avec les données
: validation, lecture et enregistrement. Il peut, dans sa forme la plus simple, contenir
uniquement une simple valeur, ou une structure de données plus complexe. Le modèle
représente l'univers dans lequel s'inscrit l'application. Par exemple pour une application de
banque, le modèle représente des comptes, des clients, ainsi que les opérations telles que
dépôt et retraits, et vérifie que les retraits ne dépassent pas la limite de crédit.
Vue : Partie visible d'une interface graphique. La vue se sert du modèle, et peut être un
diagramme, un formulaire, des boutons, etc. Une vue contient des éléments visuels ainsi que
la logique nécessaire pour afficher les données provenant du modèle. Dans une application de
bureau classique, la vue obtient les données nécessaires à la présentation du modèle en posant
des questions. Elle peut également mettre à jour le modèle en envoyant des messages
appropriés. Dans une application web une vue contient des balises HTML.
Contrôleur :Module qui traite les actions de l'utilisateur, modifie les données du modèle et de
la vue.
6. La modélisation des données

6.1 Présentation
28
La modélisation de données fait référence à la formalisation et à la documentation de
processus et d'événements qui se produisent au cours de la conception et du développement
des applications. Les techniques et les outils de modélisation de données recueillent les
conceptions de systèmes complexes et les traduisent en représentations simplifiées des
processus et des flux de données de façon à créer un modèle pour la construction et la
réingénierie.
Un modèle de données peut être comparé à un diagramme ou à un diagramme de flux qui

illustre les relations entre les données. Les modélisateurs utilisent souvent plusieurs modèles
pour représenter les mêmes données et s'assurer que la totalité des processus, entités, relations
et flux de données a été identifiée.
6.2 Langage de modélisation des données
Un langage de modélisation est un langage artificiel qui peut être utilisé pour exprimer de
l'information ou de la connaissance ou des systèmes dans une structure qui est définie par un
ensemble cohérent de règles. Les langages de modélisations peuvent être graphique ou
textuels.
Les langages de modélisation graphiques utilisent des techniques de diagrammes alors que les
langages de modélisation textuels utilisent typiquement des mots-clés standardisés
accompagnés de paramètres pour rendre les expressions interprétables par les ordinateurs
Nous optons, dans notre projet, un langage de modélisation graphique. Parmi les langage de
modélisation graphique nous trouvons notamment UML
Unified Modeling Langage
L’UML (Unified Modeling Language) est un langage de modélisation graphique orientée

objet. Elle est développée dans le but de :
 Fournir aux concepteurs de systèmes, ingénieurs logiciels et développeurs de logiciels des

outils pour l'analyse, la conception et la mise en œuvre de systèmes logiciels, ainsi que
pour la modélisation de processus métier et d'autres processus similaires.
29
 Faire progresser l'industrie en permettant l'interopérabilité des outils de modélisation
visuelle orientés objet. Toutefois, pour permettre un échange significatif d'informations de
modèles entre outils, il est nécessaire de trouver un accord sur la sémantique et la notation.
UML répond aux exigences suivantes :
 Fixer une définition formelle d'un métamodèle.
 Fournir une explication détaillée de la sémantique de chaque concept.
 Spécifier des éléments de notation lisibles par l'homme.
 Définir des moyens grâce auxquels les outils UML peuvent être mis en conformité avec
cette spécification
L'UML utilise des éléments et les associe de différentes manières pour former des
diagrammes. Ces diagrammes sont divisés en deux grandes catégories : structurels et
comportementaux. La version actuelle, (UML 2.5), propose 14 types de diagrammes dont 7
structurels et 3 comportementaux et 4 d'interaction ou dynamiques. À titre de comparaison,
UML 1.3 comportait 25 types de diagrammes.
Les sept diagrammes structurels, qui donnent de l'application une vue statique sont :
 Diagramme de classes,
 Diagramme d'objets,
 Diagramme de déploiement,
 Diagramme de composants ,
 Diagramme de paquets ,
 Diagramme de structure composite ,
 Diagramme de profils.
Les trois diagrammes comportementaux sont :
 Diagramme d'activités,
30
 Diagramme d'états-transition,
 Diagramme de cas d'utilisation.
Les quatre diagrammes d’interaction ou dynamique sont :
 Diagramme de séquence,
 Diagramme de communication,
 Diagramme global d'interaction,
 Digramme de temps.
Dans le cadre de notre projet notre choix se portera comme suit :
- Pour les diagrammes de type structurel : diagramme de classes.
- Pour les diagrammes de type comportemental : digramme de cas d’utilisation.
- Pour les diagrammes de type interaction : notre choix sera diagramme de séquence.
7. Conception des cas d’utilisation

Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une
vision globale du comportement fonctionnel d'un système logiciel.
L’étude de cas d’utilisation a pour objectif de déterminer ce que chaque utilisateur attend du
système. La détermination du besoin est base sur la représentation de l’interaction entre
l’acteur et le système.
7.1 conception du cas « S’authentifier »

7.1.1 Traçabilité MCU/MC du cas d’utilisation «S’authentifier »
31
Figure 8:Traçabilité MCU/MC du cas d’utilisation « S’authentifier »
7.1.2 Diagramme de classe du cas « S’authentifier »
Figure 9:Diagramme de classe du cas « S’authentifier»

7.1.3 Diagramme du séquence de cas « S’authentifier »
32
 Diagramme de séquence du «MotDePasseOublié »
33
Figure 10: Diagramme de séquence du cas « S’authentifier»
7.2 Conception du cas « Gérer SMS »
7.2.1 Traçabilité MCU/MC du cas d’utilisation «Gérer SMS»
34
Figure 11:Traçabilité MCU/MU du cas d’utilisation « Gérer SMS »
7.2.2 Diagramme de classe du cas « Gérer SMS »
Figure 12:Diagramme de classe du cas « Gérer SMS»

7.2.3 Diagramme de la séquence de cas « Gérer SMS »
 Envoi simple
35
 Envoi massif
36
 Envoi à partir document
……………………….
 Consulter
 Diagramme de séquence général du cas « Gérer SMS »
37
7.3 conception du cas « Gérer contact»
7.3.1 .Traçabilité MCU/MC du cas d’utilisation «Gérer contact»
Figure 13: Traçabilité MCU/MU du cas d’utilisation « Gérer contact»

7.3.2 Diagramme de classe du cas «Gérer contact»
38
Figure 14: Diagramme de classe du cas « Gérer contact»
7.3.3 Diagramme du séquence de cas « Gérer contact»
 Ajouter
39
 Modifier
40
 Supprimer
41
 Consulter
 Diagramme de séquence général du cas « Gérer contact »
42
7.4 conception du cas « Gérer filière »
7.4.1 Traçabilité MCU/MC du cas d’utilisation «Gérer filière»
Figure 15: Traçabilité MCU/MU du cas d’utilisation « Gérer filière »

7.4.2 Diagramme de classe du cas « Gérer filière »
43
Figure 16: Diagramme de classe du cas « Gérer filière»
7.4.3 Diagramme du séquence de cas « Gérer filière»
 Ajouter
44
 Modifier
45
 Supprimer
46
 Consulter
 Diagramme de séquence général du cas « Gérer filière »
47
7.5 Conception du cas « Gérer groupe»
7.5.1 Traçabilité MCU/MC du cas d’utilisation «Gérer groupe»
Figure 17: Traçabilité MCU/MU du cas d’utilisation « Gérer groupe»

7.5.2 Diagramme de classe du cas «Gérer groupe»
Figure 18: Diagramme de classe du cas « Gérer groupe»

7.5.3 Diagramme du séquence de cas « Gérer groupe»
 Ajouter
48
 Modifier
49
 Supprimer
50
 Consulter
 Diagramme de séquence général du cas « Gérer groupe »
51
7.6 conception du cas « Gérer profil»
7.6.1 Traçabilité MCU/MC du cas d’utilisation «Gérer profil»
Figure 19: Traçabilité MCU/MU du cas d’utilisation « Gérer profil»

7.6.2 Diagramme de classe du cas «Gérer profil »
52
Figure 20: Diagramme de classe du cas « Gérer profil »
7.6.3 Diagramme du séquence de cas « Gérer profil »
 Modifier
53
 Consulter
 Diagramme de séquence général du cas « Gérer profil »
54
55
Chapitre 4 : Réalisation et
Outils
56
Chapitre 4 : Réalisation et Outils ISAEG 2020
Introduction
qsd
Conclusion
Votre conclusion ici
57
Conclusion Générale et
Perspectives
58
Conclusion Générale et Perspective ISAEG 2020
Votre conclusion ici
59

Krimi Final

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Krimi Final

Transféré par

Droits d'auteur :

Formats disponibles

Introduction générale ISAEG 2020

Table des matières

Chapitre III : Etude Conceptuelle..........................................................................................................24

Table des figures

Figure 1: Organigramme de l’Institut Supérieur d’Administration des Entreprises de Gafsa.......6

Table des tableaux

Tableau 1: Description des acteurs...........................................................................................12

L’institut supérieur d’administration des entreprises de Gafsa en tant qu'institut

Dans le premier chapitre nous commençons par la présentation du contexte de l’étude.

Le deuxième chapitre sera consacré à l’expression des besoins et contraintes puis en

Le troisième chapitre se focalise sur l’étude conceptuelle et l’analyse de différentes

Grace à une formation intensive et multidimensionnelle reçue, notre établissement contribue à

 Licence fondamentale en économie (Monnaie, finance et banque)

 Mastère professionnelle CCA,

1.2 Ressource de l’institut

 03 amphithéâtres de 150 places.

Scolarité Service Service Service Service 3ème Bibliothèque Magasin

Figure 1: Organigramme de l’Institut Supérieur d’Administration des Entreprises de Gafsa

Ce diagramme représente l’architecture de l’institut qui se compose de la direction qui assure

Les directions des études se composent de trois départements :

 Département sciences de gestion et finance

 Le service scolarité : qui représente le plus important service dans l’institut, il

- prend plus de temps et gaspille beaucoup des papiers,

Nous avons constaté au niveau de l’étudiant et l’enseignant qu’il y a des problèmes

C’est un service basé sur l’outil de communication sur réseau.

6. Critères d’acceptabilité du produit

-La personnalisation de l’expérience : Le SMS est un mode de communication très

- Un SMS est lu instantanément et a un impact immédiat : Les derniers étude selon

1. Les acteurs du système

Le tableau ci-dessous présente une spécification du rôle pour l’acteur administrateur :

-Gérer les contacts,

Administrateur -Gérer les filières ,

-Gérer les groupes,

-Gérer le profil personnel.

-Gérer les enseignants et les étudiants .

2. Spécification des besoins

-Afficher les informations concernant les SMS envoyés.

2.2 Besoins non fonctionnels

-Sécurité :Toute utilisation de l’application implique l’authentification de l’administrateur

- L’ergonomie : La facilité de l’utilisation de l’application via son interface.

-Les champs de saisie doivent être contrôlés

-La rapidité d’envoi de l’SMS.

- Permettre un accès rapide de l'information.

- Interface simple et compréhensible.

- L'organisation des rubriques, des onglets, etc.

3.2 Les contraintes techniques

3.3 Les contraintes matérielles

4. Cas d’utilisation de projet

L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences

4.2 Spécification et raffinement des cas d’utilisation

La figure 2.1 représente le diagramme de cas d’utilisation général de cette application.

Avant d’effectuer n’importe quelle activité l’administrateur obligatoirement s’authentifier par

Figure 2:Diagramme de cas d’utilisation général

5. Raffinement des cas d’utilisation

5.1.1 cas d’utilisation «S’authentifier »

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

Tableau 2. :Description textuelle du cas d’utilisation « s’authentifier »

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

Tableau 3: Scénario de cas d’utilisation « Envoi simple »

 Envoyer SMS massif

Tableau 4: Scénario de cas d’utilisation « Envoi massif »

Tableau 5: Scénario de cas d’utilisation « Envoi à partir du document»

5.3.2 Description du cas d’utilisation « Gérer contact »

2 :Le système affiche l’interface de gérer groupe