République Tunisienne

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université de Gabes
Ecole Nationale d’Ingénieurs de Gabes

Rapport de Stage Ingénieur

Création d’une application de demande de

prêt ʺALKIMIA Prêtʺ

Effectué par :Hattab Najeh

Encadré par :M.Elhattab Fathi

À:

2018/2019

1
République Tunisienne
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de Gabes
Ecole Nationale d’Ingénieurs de Gabes

Remerciements

Je tiens à remercier toutes les personnes qui ont contribué au succès de mon stage et qui
m’ont aidé à la rédaction de ce rapport.

Je tiens à remercier vivement mon encadrant Monsieur Elhattab Fathi pour son accueil,
le temps passé ensemble et le partage de son expertise au quotidien. Grâce aussi à sa
confiance j’ai pu accomplir totalement dans mes missions avec son aide précieuse dans les
moments les plus délicats.

Je remercie également toute l'équipe informatique pour leur accueil, leur esprit d'équipe et
en particulier, Monsieur Ridha Lasouad, Monsieur Abdelhamid Chamakh et Monsieur Chadi
Baccar qui m’ont beaucoup aidé.

Enfin, je tiens à remercier toutes les personnes qui m’ont aidé à la rédaction de ce rapport de
stage.

2
Application de demande de prêt

HATTAB
Najeh

17 août 2018
Table des matières

Introduction Générale 4

1 Présentation de l’entreprise 5
1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Identification de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 le service informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Présentation de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Objectif de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Analyse et spécification des besoins 8

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Identification des acteurs . . . . . . . . . . . . .. . . . . . . . . 8
2.2.2 Besoin fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Vue globale du système . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Diagrammes de cas d’utilisations raffinés . . . . . . . .. . . . . . . . 11
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Architecture et conception 14
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 WPF . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 14

1
 3.2.2 Entity Framwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Digramme de séquence . . . . . . . . . . . . . . . .. . . . . . . . . . 18
3.3.3 Diagramme d’activité . . . . . . . . . . . . . . . . . … . . . . . . . . 20
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 22

4 Réalisation 23
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 23
4.2 Environnement de travail . . . . . . . . . . . . . . . . … . . . . . . . . . . . 23
4.2.1 Environnement matériel . . . . . . . . . . . . …. . . . . . . . . . . . 23
4.2.2 Environnement logiciel . . . . . . . . . . . . . . ... . . . . . . . . . . 23
4.3 Travail réalisé et scénarios d’exécution . . . . . . . . . ... . . . . . . . . . . 25
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 34

Conclusion Générale 35

2
Table des figures

1.1 Modèle du cycle de vie en cascade . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Diagramme de cas d’utilisation global . . . . . . . . . . .. . . . . . . . . . . 11

2.2 Diagramme de cas d’utilisation d’administrateur de prêt . . . . …. . . . . . 12
2.3 Diagramme de cas d’utilisation d’administrateur d’autorisation . . …. . . . . 13

3.1 Architecture MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 16

3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Diagramme de séquence de l’Authentification . . . . . . . . . . . . . . … . . 19
3.4 Diagramme de séquence de l’acceptation d’une demande de prêt . . . . . . …. 20
3.5 Diagramme d’activité « Authentification » . . . . . . . . . . . . . . . . . . 21
3.6 Diagramme d’activité « Demander Un Prêt » . . . . . . . . . . . . . . . . 22

4.1 Visual studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Le langage de programmation C# . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Sql Server Management Studio . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 Interface d’identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5 Interface d’accueil d’employé . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6 Interface de demande de prêt . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7 Interface d’accueil d’Administrateur De Prêt . . . . . . . . . . . . . . . . . 29
4.8 Interface de liste des demandes . . . . . . . . . . . . . . . . . . . . . . . . 30
4.9 Interface de détaille 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.10 Interface de détaille 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.11 Interface Accepter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.12 Interface de consultation des demandes . . . . . . . . . . . . . . . . . . . . 34

3
Introduction Générale

La deuxième année informatique s’achève par un stage ingénieur en une entreprise. Ce stage
est nécessaire afin de valider l’obtention du diplôme. Il a pour objectif de préparer l’étudiant à
son insertion dans la vie professionnelle. Il permet d’exploiter et d’approfondir les connaissances
apprises tout au long de la formation. Mon stage est effectué à la société chimique ”ALKIMIA
GABES”. Je me suis assignée au service informatique de l’usine, qui est chargé d’assurer la
gestion et la sécurité du parc informatique de l’usine et cherche des solutions dans le but
d’améliorer le réseau. Monsieur Elhattab Fathi est mon maître de stage. L’équipe souhaite
pouvoir créer une application de demande de prêt afin de faciliter l’envoie de demande de prêt
pour les employé d’ALKIMIA. Mon travail durant la période de stage consiste donc à créer une
application de demande de prêt intitulé ALKIMIA PRET.
En premier lieu, le rapport s’ouvrira sur une présentation détaillée de l’entreprise d’accueil ainsi
que le sujet de stage. Une partie du rapport portera ensuite une spécification des besoins
fonctionnels et non fonctionnels de notre projet suivie par la partie conception de notre
application ou` nous présenterons l’architecture globale et détaillée de notre projet. Et enfin, nous
nous concentrons dans le dernier chapitre sur la phase de la réalisation, cette dernière sera
illustrée par quelques interfaces présentant l’enchaînement de quelques scénarios d’exécution.

4
Chapitre 1

Présentation de l’entreprise

1.1 introduction
Avant de commencer la partie liée au développement de l’application, nous allons
consacrer le présent chapitre à la présentation de la société chimique ALKIMIA ainsi le cadre de
la solution que nous proposons.

1.2 Identification de l’entreprise

La société chimique ALKIMIA est une société anonyme crée le 26 septembre 1972 par la
famille DOGHRI et entrée en production en 1976. Elle est exonérée de la TVA et des droits de
consommation, pour acheter de matières premières et de produits assimilés, et ce en raison de
son activité exportatrice régie par la loi 93-120 du 27 septembre 1993. Cette société industrielle
est spécialisée dans la production et le vente du triplyphosphate de sodium(STPP) de formule
chimique Na5P3010 qui est le résultat de la purification de l’acide phosphorique et sa
neutralisation par la lessive de soude et/ou par du carbonate de sodium.
Le STPP est utilisé dans plusieurs domaines de la société, principalement dans la fabri- cation
des détergents, dans le traitement des eaux et dans le domaine de la céramique. D’une autre
coté, la société ALKIMIA est certifiée selon la norme internationale ISO 9002 depuis l’année
1998 et ISO 9001 depuis 2002.
En réalité cette certification est une reconnaissance des performances et de la capacité de la
société a` s’imposer par la qualité de son produit dans un marché mondiale marqué par une
concurrence très aigue. La société chimique ALKIMIA accorde une grande impor- tance
à son personnel dans le cadre de la GRH au sein de service administratif, celui-ci

5
veille à appliquer les normes de qualité et celle concerne l’environnement afin de fidéliser ses
clients et leur donner la confiance au produit.

1.3 le service informatique

Le service informatique constitue l’épine dorsale de toute action informatique menée par la
société ALKIMIA. Les taches de ce service peuvent être récapitulées dans ce qui suit : Participer
dans les actions de choix, d’acquisition ainsi qu’au suivi des équipements informatiques en tenant
compte de leurs composants matériels et logiciel.
Elaborer des applications informatiques afin d’automatiser les procédures de gestion. Assister
tous les divers services dans l’exploitation des applications informatiques ins- tallées.

1.4 Présentation de projet

Dans le cadre de projet de stage ingénieur, j’ai réalisé une application intitulée ’AL- KIMIA
PRET’ dont l’objectif est de donner aux employés d’ALKIMIA une plateforme de demande
de prêt.

1.4.1 Objectif de projet

Le travail que nous devons réaliser se divise en deux parties, établir la conception et
l’architecture de l’application puis la mettre en scène en développant une application in-
formatique réunissant les employées et leurs superviseurs. Cette application, d’une part, permet
à n’importe quelle employées de ALKIMIA ayant un compte d’envoyer une de- mande
de prêt contenant une description de la demande en question et les informations nécessaires ,
d’autre part, donne la chance aux super agent de parcourir la liste de de- mande et en
consultant les données de demandeur de prêt de décider soit d’accepté ou refusé la
demande.

1.4.2 Solution proposée

La solution que nous proposons dans ce projet, est de concevoir et réaliser une ap-
plication bureautique de travail indépendant. Cette plateforme réunit trois acteurs : un
administrateur d’autorisation, un administrateur de prêt et un employé.

6
1.5 Méthodologie de travail
Pour assurer le bon fonctionnement de notre projet et le meilleur résultat au niveau de qualité
et la production, nous devons choisir un processus de travail adéquat à suivre pendant le
déroulement de notre projet. Parmi les modèle de développement logiciel exis- tantes, nous
trouvons que le modèle du cycle de vie en cascade(1.1)est le mieux en terme de satisfaction de
nos besoins puisqu’il assure la bonne organisation de travail.

Fig. 1.1 – Modèle du cycle de vie en cascade

1.6 Conclusion
Dans cette partie du rapport, on a présenté la société chimique ALKIMIA et leur
service informatique et on a essayé de décrire le contexte général de notre projet, de
préciser son cadre et ses objectifs. Finalement on a parlé de la démarche du travail qu’on a adopté
durant la réalisation de ce projet. Dans le chapitre qui suit, la spécification des besoins
fonctionnels et non fonctionnels sera abordée.

7
Chapitre 2

Analyse et spécification des besoins

2.1 Introduction
Après la présentation de l’entreprise d’accueil et du contexte général de notre solution, dans
le chapitre précédent, nous allons, à présent, analyser et spécifier les besoins de notre
application. Nous commencerons d’abord par énoncer les acteurs qui agissent dans notre
application, par la suite, nous décrirons les besoins fonctionnels et non fonctionnels de notre
application et finalement, nous spécifierons, à travers les diagrammes de cas d’utilisation
d’UML, nos besoins.

2.2 Analyse des besoins

Cette partie est consacrée à l’analyse de la situation actuelle afin de tenir compte des
contraintes et des éléments pertinents afin de réaliser un produit qui répond parfaitement
à nos besoins.

2.2.1 Identification des acteurs

Les acteurs représentent les personnes autorisées à accéder aux données de l’appli-
cation. Un accès authentifié et sécurisé est réservé aux employés et un administrateur
d’autorisation et des administrateurs de prêt.

Administrateur d’autorisation : il crée des comptes aux employées, consulte les

résultats de ses demandes de prêt, et envoie une demande de prêt.

8
Administrateur de prêt : il consulte la liste des demandes de prêt, consulte des données
sur le demandeur de prêt, accepte ou refuse une demande de prêt, envoie une demande
de prêt et consulte les résultats de ses demandes de prêt.

Employé : il envoie une demande et consulte les résultats de ses demandes de prêt.

2.2.2 Besoin fonctionnel

Notre projet est une application bureautique et destiné aux employés d’ALKIMIA.
L’application doit donner à tous les utilisateurs un accès authentifié et sécurisé.

Administrateur d’autorisation :

-Un Administrateur d’autorisation est caractérisé par son matricule, son nom et son prénom,
son qualification, son date de naissance, son date d’embauche, son service et son situation
stationnaire.
- Un Administrateur d’autorisation peut créer des comptes aux utilisateurs.
- Un Administrateur d’autorisation peut modifier le mot de passe de son compte.
- Un Administrateur d’autorisation peut consulter les résultats des ses demandes.
- Un Administrateur d’autorisation peut envoyer une demande de prêt.
- Un Administrateur d’autorisation peut ajouter des autorisations aux utilisateurs.

Administrateur de prêt :

-Un Administrateur de prêt est caractérisé par son matricule, son nom et son prénom, son
qualification, son date de naissance, son date d’embauche, son service et son situation
stationnaire.
- Un Administrateur de prêt peut modifier le mot de passe de son compte.
- Un Administrateur de prêt peut consulter les résultats des ses demandes.
- Un Administrateur de prêt peut envoyer une demande de prêt.
- Un Administrateur de prêt peut consulter la liste de demande de prêt.
- Un Administrateur de prêt peut accepter une demande de prêt.
- Un Administrateur de prêt peut refuser une demande de prêt.

Un Employé :

9
-Un Employé de prêt est caractérisé par son matricule, son nom et son prénom, son
qualification, son date de naissance, son date d’embauche, son service et son situation
stationnaire.
- Un Employé peut modifier le mot de passe de son compte.
- Un Employé peut consulter les résultats des ses demandes.
- Un Employé peut envoyer une demande de prêt.

2.2.3 Besoins non fonctionnels

Pour mener à bien notre application, Il y a quelques exigences techniques à respecter,
notamment :

- Ergonomie : L’interface de l’application doit être présente d’une manière simple pour
qu’elle soit exploitée par tous les utilisateurs. C’est pour cela que la nôtre doit être facilement
exploitable pour faciliter la communication homme machine, en outre, cette interface doit
être conviviale et ergonomique.

Sécurité : l’accès à la plate-forme requiert une authentification sécurisée.

Rapidité : L’accès rapide et transparent aux données doit être garanti par l’application.

2.3 Spécification des besoins

Nous utiliserons dans cette partie, pour spécifier les besoins fonctionnels de notre
application, les diagrammes UML de cas d’utilisation.

2.3.1 Vue globale du système

Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour donner une
vision globale du behaviorisme fonctionnel d’un système logiciel. Ils sont utiles pour des
présentations auprès de la direction ou des acteurs d’un projet. Un cas d’utilisation dessine une
unité discrète d’interaction entre l’utilisateur et le système. Il est une unité significative de travail.
Dans un diagramme de cas d’utilisation, les utilisateurs sont ap- pelés acteurs, ils interagissent
avec les cas d’utilisation.

10
Nous présentons, à travers la figure ci-dessous (2.1), le diagramme de cas d’utilisations de notre
application.

Fig. 2.1 – Diagramme de cas d’utilisation global

2.3.2 Diagrammes de cas d’utilisations raffinés

Dans cette partie, nous allons spécifier pour chaque administrateur le diagramme de cas
d’utilisation correspondant.

Diagramme de cas d’utilisation d’administrateur de prêt

La figure (2.2) représente le diagramme de cas d’utilisation d’administrateur de prêt.

11
 Fig. 2.2 – Diagramme de cas d’utilisation d’administrateur de prêt

Diagramme de cas d’utilisation d’administrateur d’autorisation

Nous présentons, à travers la figure ci-dessous (2.3), le diagramme de cas d’utilisations

relatifs aux administrateurs d’autorisation.

12
 Fig. 2.3 – Diagramme de cas d’utilisation d’administrateur d’autorisation

2.4 Conclusion
Ce chapitre a visé la partie d’analyse et de spécification des besoins, chose qui nous a permis
de comprendre les objectifs de notre projet et de déterminer les fonctionnalités fondamentales du
système. Cette vision constitue alors le pilier de base de la conception que nous abordons dans le
suivant chapitre.

13
Chapitre 3

Architecture et conception

3.1 Introduction
La conception est une étape phare dans le processus de développement d’un logiciel. En fait,
il s’agit de déterminer la méthode et l’architecture à adopter afin de pouvoir réaliser une solution
qui répond aux besoins spécifiés dans le chapitre précédent. Dans ce chapitre, nous allons
présenter la conception architecturale et détaillée de notre application.

3.2 Architecture
L’architecture de notre application est définit principalement de :

3.2.1 WPF
Windows Forms est une technologie ” ancienne ”, elle a l’avantage d’être facile à
apprendre et rapidement performante. Malheureusement, il arrive souvent lorsque l’on
cherche à construire des formulaires complexes d’être ” limité ”.
Microsoft a introduit Windows Presentation Foundation (WPF) avec la version 3.0 du
Framework, c’est une technologie très récente et présente la nouvelle génération de Micro- soft
pour concevoir des applications qui offrent une expérience très riche pour l’utilisateur. WPF
combine la gestion des interfaces, graphiques en 2D, 3D, les documents, les mul- timédias...
tous ces éléments dans un seul package. Le moteur de performance de WPF est
à base vectorielle, il utilise l’accélération matérielle des cartes graphiques des machines, ceci
rend l’interface plus rapide, évolutive et indépendante de la résolution.
WPF sépare l’interface de son comportement (le code behind) : l’interface est écrite en

14
xaml (eXtensible Application Markup Language) tandis que le code est en c # (ou bien en
langage vb). Cette séparation offre :
- Un couplage faible entre l’interface et son comportement.
- Séparation du travail des designers et des codeurs.
- Personnalisation à l’extrême du rendu de chaque élément graphique.
Le langage xaml est issu du XML, c’est un langage à balises, structurellement proche du
HTML.

3.2.2 Entity Framwork

Entity Framework est un outil permettant de créer une couche d’accès aux données
(DAL pour Data Access Layer) liée à une base de données relationnelle. Il propose la
création d’un schéma conceptuel composé d’entités qui permettent la manipulation d’une source
de données, sans écrire une seule ligne de SQL. Ceci est par ’l’intermédiaire d’un modèle appelé
EDM (Entity Data Model).

3.2.3 MVVM
Le pattern M-V-VM (Model-View-ViewModel) est une avancée méthodologique essen-
tielle pour la mise en œuvre de logiciels modernes écrits sous WPF et Silverlight. MVVM,
acronyme de ” Model, View, View-Model ”, est une approche pour structurer le code vi- sant à
minimiser le plus possible la forte dépendance entre les données (le model) et leur représentation
(les vues). Ce découplage se fait par un intermédiaire appelé ” View-Model
” en exploitant les mécanismes de liaison DataBinding et DataContext (3.1).

15
 Fig. 3.1 – Architecture MVVM

Le Modèle Le Modèle est l’ensemble des données. Il est complètement indépendant de l’IHM
(interface homme machine). Le Modèle est écrit en code ou peut même n’être que de simples
données dans une base de données relationnelles voire même un simple fichier XML.

La vue La vue définit le visuel, elle est constituée principalement d’un fichier Xaml
et se présente sous la forme d’un UserControl dont le fichier de code-behind est vide (ou presque).
Le DataContext de la vue est initialisé pour pointer une instance d’un Modèle de Vue.
Dans la version la plus simple, la Vue est liée directement au Modèle. Mais en réalité
seules des applications très simples peuvent se contenter d’un tel raccourci.

16
Le ViewModel Il arrive souvent que les données du Modèle ne puissent pas être liées
directement à la Vue, (malgré la présence des convertisseurs sous Xaml). L’IHM peut aussi avoir
besoin d’effectuer des traitements spéciaux sur les données ce qui, raisonnablement, ne peut être
placé ni dans la Vue ni dans les données : Il faut faire intervenir un troisième bloc : le ViewModel
(Modèle de Vue).
Le ViewModel peut être compris comme une abstraction de la Vue, mais il peut aussi être vu
comme une spécialisation du Modèle que la Vue peut utiliser pour son DataBinding.
→ Le ” binding ” consiste à lier la propriété d’un objet à celle d’un autre objet de fa¸con
déclarative dans Xaml.

3.3 Conception
Dans cette section,nous présentons la conception de notre application. Nous utiliserons le
langage UML comme langage de modélisation des différents modules qui composent notre
système.

3.3.1 Diagramme de classes

Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les
classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce
diagramme fait partie de la partie statique d’UML car il fait abstraction des aspects tem- porels
et dynamiques. Une classe décrit les responsabilités, le comportement et le type d’un
ensemble d’objets. Il admet un ensemble des fonctions et des données qui sont liées ensemble
par un champ sémantique. Les classes peuvent être liées entre elles grace au mécanisme
d’héritage qui permet de mettre en évidence des relations de parent. D’autres relations sont
possibles entre des classes, chacune de ces relations est représentée par un arc spécifique dans
le diagramme de classes. La figure(3.2) ci-dessous représente le dia- gramme de classe de
notre application.

17
 Fig. 3.2 – Diagramme de classe

3.3.2 Digramme de séquence

Un diagramme de séquence est un diagramme UML qui représente la séquence de mes- sages
entre les objets au cours d’une interaction. Un diagramme de séquence comprend un groupe
d’objets, représentés par des lignes de vie, et les messages que ces objets échangent lors de
l’interaction. Les diagrammes de séquence peuvent également représenter les struc- tures de
controle entre des objets.
Nous représentons, maintenant, quelques scénarios d’exécution à travers les diagrammes de
séquences UML pour décrire la manière avec laquelle l’utilisateur interagit avec le système.

18
Diagramme de séquence « Authentification »

L’authentification à l’application suit les étapes présentées ci-dessous (3.3).

Fig. 3.3 – Diagramme de séquence de l’Authentification

Diagramme de séquence « Accepter Une Demande »

La figure (3.4) représente le diagramme séquence d’acceptation d’une demande de prêt.

19
 Fig. 3.4 – Diagramme de séquence de l’acceptation d’une demande de prêt

3.3.3 Diagramme d’activité

Le diagramme d’activité permet de représenter le déroulement d’un évènement en
évoluant les états intermédiaires, la séquence d’actions et les conditions d’exécutions.

Diagramme d’activité ” Authentification ”

La figure (3.5) décrit l’enchainement des traitements à faire pour pouvoir s’authenti ?er
à notre plateforme. d’acceptation d’une demande de prêt.

20
 Fig. 3.5 – Diagramme d’activité « Authentification »

Diagramme d’activité ” Demander Un Prêt ”

La figure (3.6) décrit l’enchainement des traitements à faire un administrateur de prêt

à ALKIMIA pour pouvoir accepter ou refuser une demande de prêt.

21
 Fig. 3.6 – Diagramme d’activité « Demander Un Prêt »

3.4 Conclusion
Nous avons traité dans ce chapitre l’étude conceptuelle de notre solution. Nous avons
présenté l’architecture générale que nous avons détaillée par la suite à travers nos déférents
diagrammes UML. Nous entamons à présent la partie relative à la réalisation de notre
système.

22
Chapitre 4

Réalisation

4.1 Introduction
Après l’affectation de la partie de conception de notre l’application, on va commencer la
partie de la réalisation et implémentation dans laquelle on s’assure que le système est prêt pour
être utilisé par les utilisateurs ordinaire.

4.2 Environnement de travail

Pour la réalisation de ce travail, nous avons eu recours aux Environnements suivants :

4.2.1 Environnement matériel

Nous avons créé cette application avec un ordinateur de caractéristiques suivantes :
-Processeur : Intel Core i3
-Capacité de stockage principal : 487GO
-Mémoire vivre : 4GO

4.2.2 Environnement logiciel

Visual studio 2015

Un seul environnement de développement qui regroupe tous les outils nécessaires pour
concevoir, implémenter, exécuter, tester et déployer une variété de types d’applications
sous différents langages. Il assure :
La conception des composants graphiques pour des interfaces complexes

23
-L’accès aux serveurs, bases de données
-La Création, la modification, la conception des bases de données
-L’option ”Complete word” :auto-écriture du reste du nom d’une variable , méthode. . .
-L’option ”Quick info” : Affichage de la déclaration complète de n’importe quel identifi- cateur
dans le code (juste en pointant la souris sur le texte pour afficher le popup d’infos) Visual studio
(4.1) est un :
-Outils efficaces de débogage (points d’arrêts, pile d’appels)
-Outils de structuration de code, recherche, l’optimisation.

Fig. 4.1 – Visual studio

Le langage de programmation C#

Le C# (4.2) est un langage de programmation orienté objet à typage fort, créé par la
société Microsoft, et notamment un de ses employés, Anders Hejlsberg, le créateur du langage
Delphi.
Il a été créé afin que la plate-forme Microsoft .NET soit dotée d’un langage permettant d’utiliser
toutes ses capacités. Il est très proche du Java dont il reprend la syntaxe générale ainsi que les
concepts (la syntaxe reste cependant relativement semblable à celles de lan- gages tels que le
C++ et le C). Un ajout notable à Java est la possibilité de surcharge des opérateurs,
inspirée du C++. Toutefois, l’implémentation de la redéfinition est plus proche de celle du Pascal
Objet [1].

24
 Fig. 4.2 – Le langage de programmation C#

Sql Server Management Studio 2017

SQL Server Management Studio (4.3) est un outil fourni avec Microsoft SQL Server
2005 et versions ultérieures pour la configuration, la gestion et l’administration de tous
les composants de Microsoft SQL Server. L’outil comprend à la fois des éditeurs de script et des
outils graphiques qui fonctionnent avec les objets et les fonctionnalités du serveur. Une fonction
centrale de SQL Server Management Studio est l’Explorateur d’objets, qui permet à l’utilisateur
de parcourir, sélectionner et agir sur l’un des objets du serveur [2].

Fig. 4.3 – Sql Server Management Studio

4.3 Travail réalisé et scénarios d’exécution

Afin d’utiliser notre application, l’utilisateur doit passer par la phase d’authentifica- tion
durant laquelle il doit remplir les champs de Login et Password associé (4.4).

25
 Fig. 4.4 – Interface d’identification

Après avoir été authentifié entant que ”Employé”, l’utilisateur aura alors accès à ses
données en lui offrant le choix entre consulter ses demandes, demander un prêt ou modi- fier son
mot de passe(4.5).

26
 Fig. 4.5 – Interface d’accueil d’employé

Si l’employé choisie le bouton de ” Demander Un Prêt ”, un formulaire à remplir va lui

s’afficher qui contient les informations nécessaires pour assurer l’unicité de la demande comme
la montre la figure (4.6).

27
 Fig. 4.6 – Interface de demande de prêt

Si l’utilisateur est authentifié en tant que ”Administrateur De Prêt ”, sa page d’accueil sera alors
afficher qui lui offre l’opportunité de consulter la liste de demande de prêt comme la
montre la figure ci-dessous(4.7).

28
 Fig. 4.7 – Interface d’accueil d’Administrateur De Prêt

Après le choix d’un demande de prêt (4.8) et si Administrateur De Prêt a cliqué sur le
bouton ”Plus” cette page va être affichée (4.9)(4.10).

29
Fig. 4.8 – Interface de liste des demandes

30
Fig. 4.9 – Interface de détaille 1

31
 Fig. 4.10 – Interface de détaille 2

Si ”Administrateur De Prêt ” a choisi d’accepter la demande et après avoir cliqué sur

le bouton ”Accepter ” cette page va être affichée (4.11).

32
 Fig. 4.11 – Interface Accepter

Et dans ce cas l’employé peut donc consulter le résultat de la demande en cliquant sur
”Consulter Mes Demandes”(4.12).

33
 Fig. 4.12 – Interface de consultation des demandes

4.4 Conclusion
Nous avons consacré ce dernier chapitre à présenter l’environnement matériel et logiciel du
développement de notre application et à la partie réalisation à travers un ensemble
d’interfaces.

34
Conclusion Générale

Le stage ingénieur est une occasion primordiale pour améliorer l’insertion de l’étudiant
dans la vie professionnelle.
De ma part, j’ai eu l’occasion d’être parmi les agents de la société chimique ALKIMIA, ce qui
m’a permis d’avoir une idée générale sur le processus de travail de la société.
Tout au long de la période de réalisation de ce projet, j’ai développé une application de demande
de prêt. Ce qui aura pour objectif de faciliter l’envoie de demande de prêt pour les employés
d’ALKIMIA.
Au cours de ce rapport, j’ai commencé par la présentation de la société chimique ALKI- MIA
ainsi que le cadre générale de projet, à savoir la méthodologie adoptée. Par la suite, j’ai spécifié
les besoins et les attentes du projet, ceci par l’analyse, la spécification et la détermination des
différents intervenants dans mon application. Chose qui m’a mené à aboutir à la phase de
conception de l’application et dans laquelle j’ai présenté l’architec- ture globale et détaillée de
l’application. Enfin, j’ai précisé mon choix matériels et logiciel que j’ai considéré les plus
adaptés à mes besoins pendant la réalisation du projet Ceci afin de mener a` bien mon travail.
Malgré sa courte duré, ce stage m’a permit de découvrir des nouvelles notions qui ont
certainement enrichi ma formation.
La société chimique ALKIMIA regorge des thèmes d’études et des domaines d’appren- tissage
efficaces dont ce stage m’a permis d’en toucher quelques-uns. Peut être d’autre stage
prochainement pourra être l’occasion de m’intéresser à d’autre facettes et d’autres technique au
sein de cette société exemplaire.

35
Bibliographie

[1] http ://dictionnaire.sensagent.leparisien.fr/C%20sharp/fr-fr/

[2] http ://dictionnaire.sensagent.leparisien.fr/SQL%20Server%20Management%20Studio/en- en/

36