RAPPORT

Conception et Développement d’une Application

Web pour la Gestion des demandes d’achats

Réalisé par : MAHDARI Yassine

Encadrant : Mr. BALOUKI Youssef
Licence Génie Informatique 2015/2016
 Dédicaces
A nos parents,
En mémoire du dévouement inconditionné et de la générosité que vous avez toujours montré à
notre égard
En mémoire de tous les moments de joie et d’espoir que nous avons passé ensemble …
En ce jour nous espérons de réaliser l’un de vos rêves…
Que DIEU accorde la santé et la longue vie à mon père…

…‫َّآمين‬،‫الجنة‬
َ ‫ِينَّفازواَّ ِب‬ ََّ ‫آللّهُمََّّارْ َح َّْمَّأُمِّيَّواجْ َع ْلهاَّم‬
ََّ ‫ِنَّالذ‬
Nous vous remercions pour votre soutien, votre amour, vos prières, et vos encouragements…

A toute la famille,
Nous vous remercions pour votre soutien, votre amour et présence à nos côtés dans les
moments de joie, de dépression et de stress, nous vous aimons si fort.

A tous nos cousins et cousines,

A tous nos amis,
A tous nos professeurs,
A tous ceux qui nous aiment,
A tous ceux que nous aimons
A toutes personnes qui nous ont aidés à arriver à ce stade par tous les
gestes.
Même le strict d’encouragement.
Ce projet leur est dédié

MAHDARI Yassine

2
Remerciements
Nous tenons à remercier premièrement le bon DIEU qui nous a donné la force pour travailler
et de mener à bien ce travail.

Nous remercions de suite l’entreprise Upline Group qui nous a permis de faire le stage au sein
de leur établissement.

Nos remerciements s’adressent aussi à notre encadrant à Upline Group, en la personne de Mr.
MOAWYA Omar à qui nous sommes très reconnaissant pour les efforts qu’il n’a cessé de
déployer pour le bon déroulement de notre stage. C’est grâce à ses explications et son partage
de connaissance en développement web, nous remercions de même tout le personnel d’Upline
Group.

Nos remerciements s’adressent aussi à notre encadrant à la FST de Settat, en la personne de

BALOUKI Youssef, professeur au département de Mathématiques et Informatique à qui nous
sommes très reconnaissant pour ses conseils, son encadrement, son temps qu’il a donné en notre
faveur.

Nous tenons à remercier aussi tout le corps professoral de la FST de Settat, pour leur
mobilisation, la formation qu’ils nous ont donnée durant notre parcours et pour l’élaboration du
présent rapport.

Ainsi, qu’à tous les membres du jury pour leur présence, remarques et leur conseil. Nous
n’oublions pas de remercier nos amis pour leur amabilité et leurs aides durant toute la période
du Projet de Fin d’Etudes.

Que tous ceux qui ont contribué, de près ou de loin, pour mener à bien ce stade trouvent ici
l’expression de notre parfaite considérations de nos remerciements chaleureux.

3
 Résumé
Notre projet consiste dans l’étude, la conception et la réalisation d’une application pour la

gestion et le suivi de processus d’une demande d’achat pour la société Upline Group, qui permet

l’amélioration de la communication et l’échange de l’information et de la documentation entre

les filiales d’Upline Group. Les objectifs majeurs de cette application sont la gestion, le suivi

et le contrôle de processus d’une demande d’achat. Pour atteindre cet objectif, nous avons eu

recours à créer une plateforme web basé sur une architecture 3 tiers dont MySQL comme

système de gestion de bases de données, une étude conceptuel réalisé par le langage de

modélisation UML et Eclipse comme IDE. Enfin, notre application sera exploitée par les

employés de la société Upline Group. Le présent rapport décrit les différentes étapes de

réalisation de ce projet.

4
 Table des matières
Remerciements ........................................................................................................................... 3
Résumé ....................................................................................................................................... 4
Table des matières ...................................................................................................................... 5
Liste des figures ......................................................................................................................... 7
Introduction générale .................................................................................................................. 8
CHAPITRE I
Introduction : ............................................................................................................................ 10
I. Organisme d’accueil :....................................................................................................... 10
1. Présentation d’Upline Group :....................................................................................... 10
2. Organigramme : ............................................................................................................. 11
3. Filiales d’Upline Group : ............................................................................................... 11
II. Contexte générale du projet : ........................................................................................... 12
1. Introduction : ................................................................................................................. 12
2. Problématique : ............................................................................................................. 13
3. Objectifs : ...................................................................................................................... 13
4. Diagramme de Gantt : ................................................................................................... 14
Conclusion ................................................................................................................................ 14

CHAPITRE II
Introduction : ............................................................................................................................ 16
I. Etude de l’existant et proposition : ................................................................................... 16
1. Processus d’une demande d’achat à Upline Group : ..................................................... 16
2. Critique : ........................................................................................................................ 17
3. Solution proposée : ........................................................................................................ 18
II. La Plate-forme Java EE : .................................................................................................. 18
1. Présentation et historique : ............................................................................................ 18
2. Composants et Architecture Java EE : .......................................................................... 19
3. Les conteneurs web : ..................................................................................................... 25
4. API et services Java EE : ............................................................................................... 27
III. Le modèle MVC : .......................................................................................................... 31
1. Le modèle MVC en théorie : ......................................................................................... 31
2. Le modèle MVC en pratique : ....................................................................................... 32
IV. Outils et environnement de développement : ................................................................ 34
1. Les outils : ..................................................................................................................... 34

5
 2. Téléchargement des outils ............................................................................................. 34
3. Installation des outils :................................................................................................... 34
4. Outils matériels : ........................................................................................................... 34

CHAPITRE III
I. Introduction : .................................................................................................................... 36
II. Analyse des besoins : ....................................................................................................... 36
1. Les besoins fonctionnels : ............................................................................................. 36
2. Les besoins non fonctionnels : ...................................................................................... 36
III. Conception : .................................................................................................................. 37
1. Diagramme de cas d’utilisation : ................................................................................... 37
2. Identification des acteurs :............................................................................................. 38
3. Les diagrammes de séquence : ...................................................................................... 38
4. Diagramme de classe : ................................................................................................... 48
Conclusion ................................................................................................................................ 48

CHAPITRE IV
I. Introduction : .................................................................................................................... 50
II. Environnement de travail : ............................................................................................... 50
1. Environnement logiciel : ............................................................................................... 50
III. Développement : ........................................................................................................... 52
1. Choix de la plateforme JEE :......................................................................................... 52
IV. Choix de développement : ............................................................................................. 52
1. Le modèle : .................................................................................................................... 53
2. La vue : .......................................................................................................................... 53
3. Le contrôleur : ............................................................................................................... 53
V. Phase de test : ................................................................................................................... 54
VI. Interface graphique : ...................................................................................................... 54
1. Interface authentification : ............................................................................................ 55
2. Interface administrative : ............................................................................................... 55
3. Interface création d’une demande d’achat : .................................................................. 56
4. Interface de consultation : ............................................................................................. 56
5. Interface suivi de bon de commande : ........................................................................... 57
Conclusion ................................................................................................................................ 57
Conclusion générale ................................................................................................................. 58

6
Liste des figures
Figure I.1: Organigramme d'upline Group ............................................................................... 11
Figure I.2 : Schéma d'Upline Group.......................................................................................... 11
Figure I.3 : FILIALE D’UPLINE ALTERNATIVE INVESTMENTS ..................................................... 12
Figure I.4 : Diagramme de Gantt .............................................................................................. 14
Figure II.1 : Processus d’une demande d’achat à Upline Group .............................................. 17
Figure II.2 : Architecture Java EE Standard .............................................................................. 20
Figure II.3 : Communication Java EE entre les différents tiers................................................. 22
Figure II.4 : Tiers web et Tiers métier Java EE .......................................................................... 23
Figure II.5 : Architecture évoluée Java EE ................................................................................ 24
Figure II.6 : Serveur Java EE et conteneur ................................................................................ 26
Figure II.7 : Modèle MVC .......................................................................................................... 32
Figure II.8 : MVC avec Java EE .................................................................................................. 33
Figure III.1 : Diagramme de cas d’utilisation ............................................................................ 37
Figure III.2 : Cas d’utilisation « Créer une demande d’achat » ................................................ 38
Figure III.3 : diagramme de séquence « Créer une demande d’achat » .................................. 39
Figure III.4 : Cas d’utilisation « Valider une demande d’achat ».............................................. 40
Figure III.5 : Diagramme de séquence « Valider une demande d’achat » ............................... 40
Figure III.6 : Cas d’utilisation « Suivre une demande d’achat » ............................................... 41
Figure III.7 : Diagramme de cas d’utilisation « Suivre une demande d’achat »....................... 41
Figure III.8 : Cas d’utilisation « Répondre à une demande d’achat » ...................................... 42
Figure III.9 : Diagramme de séquence « Répondre à une demande d’achat » ........................ 43
Figure III.10 : Cas d’utilisation « Gestion des utilisateurs » ..................................................... 43
Figure III.11 : Diagramme de séquence « Ajouter un utilisateur » .......................................... 45
Figure III.12 : cas d’utilisation « Consulter toutes les DA » ...................................................... 45
Figure III.13 : diagramme de séquence « Consulter toutes les DA » ....................................... 46
Figure III.14 : cas d’utilisation « Suivi de bon de commande » ................................................ 46
Figure III.15 : diagramme de séquence « suivi de bon de commande » ................................. 47
Figure III.16 : Diagramme de classe ......................................................................................... 48
Figure IV.1 : Modèle MVC ........................................................................................................ 53
Figure IV.2 : interface authentification .................................................................................... 55
Figure IV.3 : interface administrative ....................................................................................... 55
Figure IV.4 : interface création d’une demande d’achat ......................................................... 56
Figure IV.5 : interface consultation des demandes d’achats ................................................... 56

7
 Introduction générale
Aujourd'hui, Internet et les technologies de l'information et de la communication deviennent
indispensables dans la vie de l'entreprise, quelle que soit sa taille et quel que soit son secteur
d'activité. En effet, Internet tisse de nouveaux points de contacts avec sa clientèle en modifiant
les méthodes de travail au sein de l'entreprise : service-client, circulation plus rapide de
l'information, travail en réseau ou à distance, etc.

Le développement des réseaux informatiques, notamment avec l'apparition du World Wide

Web, a été un des éléments importants de cette évolution.

Avec la croissance du Web et l'arrivée de nouvelles technologies, les attentes de ses utilisateurs,
à l'égard des sites Web se sont développées énormément. Actuellement, on s'attend de plus en
plus à des sites complets, interactifs et mis à jour rapidement, utilisant des technologies de
pointe et offrant plus de fonctionnalités.

Dans ce contexte, la société Upline Group relève un besoin pour le suivi de processus des
demandes d’achats entre ses filiales.

Il s'agit donc d'une application Web permettant de gérer les demandes depuis leurs arrivées
jusqu'à la livraison, offrir aux employés la possibilité de créer et de consulter leurs appels à
distance.
Pour atteindre ces objectifs, il était nécessaire de subdiviser ce travail en quatre chapitres :

Chapitre 1 :«Présentation de l’organisme d’accueil et contexte général du projet » Présente

l'organisme d'accueil et le cahier des charges ainsi que le déroulement de stage.

Chapitre 2 : «Etude théorique» décrit la Plateforme JavaEE puis présente en détail ses
composantes et son architecture.

Chapitre 3 : « Analyse & Conception » ce dernier chapitre est réservé à l’analyse et

spécification des besoins et la conception de l’application.

Chapitre 4 : « Réalisation » présente les différentes étapes d’implémentation de l’application.

8
9
Introduction :
Dans ce chapitre nous présenterons les éléments permettant de mieux appréhender ce projet de
fin d’étude, commençant par l’organisme d’accueil, ainsi que son domaine d’activités, et
enchainant par l’aspect global du déroulement du projet en présentant son périmètre, le cahier
des charges exigé, le management du projet et les différentes circonstances caractérisant cette
période.

I. Organisme d’accueil :
1. Présentation d’Upline Group :
Fondée en 1992, Upline Group est considérer comme un acteur de référence dans les métiers
de la banque d’affaire.

Elle regroupe et développe les métiers d’investissements de la Banque Populaire Centrale et

répond aux besoins en services financiers d’un grand nombre d’investisseurs particuliers, de
clients institutionnels et d’entreprises.
Le groupe dispose ainsi d’un large réseau relationnel de clientèle privée et institutionnelle, aussi
bien au niveau national qu’international
Parmi ses activités nous citons :
 L’intermédiation boursière
 L’ingénierie financière
 La gestion d’actifs
 Le capital d’investissement

10
 2. Organigramme :

Figure I.1: Organigramme d'upline Group

3. Filiales d’Upline Group :
Upline Group dispose de plusieurs filiales :

Figure I.2 : Schéma d'Upline Group

11
 3.1. Upline Corporate Finance :
Elle a pour missions l’accompagnement des PME ou une grande entreprise dans leur croissance
et le conseil dans les matières de :
 Fusion et acquisition
 Levée de fonds
 Privatisation
 Conseil stratégique et étude de marché
 Conseil financier et évaluation d’entreprise

3.2. Upline Capital Management :

C’est l’entité qui se charge de la gestion d’actifs pour compte de tiers d’Upline group.
Actuellement, elle gère plus ce que 14 milliards de dirhams.

3.3. Upline Alternative Investment :

Upline alternative investment es spécialisé dans la gestion des fonds de private equaty.
Elle est organisé autour de 4 filiales métiers qui son schématisés ci-dessous :

Figure I.3 : FILIALE D’UPLINE ALTERNATIVE INVESTMENTS

3.4. Upline Securities et ICF ALWASSIT :

L’intermédiation boursière est représentée par deux sociétés de bourse, qui se distinguent par
leur spécialisation. Il s’agit d’Upline Securities et ICF ALWASSIT.

II. Contexte générale du projet :

1. Introduction :
Quelle que soit leur taille, leur secteur d’activités ou leur organisation, toutes les entreprises
sans exception, effectue des achats que ce soit à des fins commerciales ou tout simplement le
fonctionnement quotidien de l’activité.

12
Plusieurs études démontrent même que les achats dit « indirects », c’est-à-dire pas directement
liés à l’activité (les fournitures de bureau par exemple) représentent près d’un tiers des
dépenses. Bien souvent ce type d’achats sort du cadre de fonctionnement normal de l’entreprise,
et est gérer de manière plus ou moins formelle en fonction des sociétés.

D’ailleurs, même en ce qui concerne les achats récurrents, il est bien souvent difficile pour les
organisations de structurer et gérer leurs démarches « Achats ».

2. Problématique :
A l’entreprise Upline Group une demande d’achat est encore aussi un formulaire papier
circulant de services en services, est bien souvent le principal outil de formalisation des achats.
Liste des différents problèmes :

 Perte de documents
 Piles de demandes s’entassant dans les services d’achats
 Temps de traitement plus ou moins aléatoire
 Manque de traçabilité

3. Objectifs :
Lors de notre stage au sein de l’entreprise Upline Group, nous avons eu comme projet de fin
d’études la conception et la réalisation d’une application web pour la gestion et le suivi des
demandes d’achats qui résout les problèmes posés dans la partie problématique.

Le développement d’une application web qui permet aux demandeurs d’effectuer une demande
d’achat simplement et rapidement via une connexion à une interface web, saisie dans un
formulaire qui peut être pré-rempli en fonction des services, du profil de l’utilisateur.

La demande peut être suivi en ligne, plus besoin de demander par mail ou téléphone au service
achat ou en est la commande. En se connectant sur l’application le demandeur voit où en est sa
demande, si elle a été validée ou non.

Validation des demandes d’achats par un simple clic en se connectant sur l’application, après
la validation des demandes, celles-ci se transitent automatiquement entre services.

La génération automatique des bons de commande, permet des gains de temps. Permet des gains
de temps considérables permettant aux chargés d’achat de se concentrer sur des activités métiers
stratégiques. Chaque responsable d’action est clairement identifié.

13
 4. Diagramme de Gantt :

Figure I.4 : Diagramme de Gantt

Conclusion
Ce chapitre introductif a été dédié essentiellement à la présentation générale de notre stage y
compris l’environnement de stage, l’entité d’accueil Upline group. Il met aussi l’accent sur le
contexte général du projet ainsi que la méthodologie suivie pour son élaboration, et sa
planification tenant compte des délais à respecter.

Avant d’entamer les différentes phases qui nous ont permis de mener à bien le projet, il serait
judicieux de commencer tout d’abord par une étude théorique.

14
15
 Introduction :
Dans ce chapitre on va vous présenter le processus d’une demande d’achat à la société Upline,
et les problèmes dans ce processus et la solution proposée.

Ainsi dans ce chapitre une étude théorique sur la plateforme JEE, ses composants et son
architecture.

I. Etude de l’existant et proposition :

1. Processus d’une demande d’achat à Upline Group :
Chaque filiale d’Upline Group a un éditeur demande d’achat, après la création de la demande,
celle-ci est envoyée au président de directoire de la filiale pour faire la signature. Après la
signature la demande est reçue par le service de ressources humaines, ceci valide aussi la
demande. Puis le contrôleur du fond traite la demande d’achat et il peut donner soit une réponse
favorable ou défavorable sur la demande. Le service d’achat reçoit une demande d’achat validé
par tous ces services et il génère un bon de commande, ce bon de commande est envoyé par fax
aux fournisseurs. Ce processus est résumé par le diagramme suivant :

16
 Figure II.1 : Processus d’une demande d’achat à Upline Group

2. Critique :
Comme on a cité dans la partie problématique, le processus d’une demande d’achat se fait
encore à partir d’un formulaire papier circulant entre les services, l’éditeur de la demande
d’achat a besoin de demander par mail ou téléphone au service d’achat pour suivre l’état de sa
demande, manque de traçabilité, une demande d’achat n’est pas identifié par un référence, perte
de document, le temps de traitement plus ou moins aléatoire, etc.

17
 3. Solution proposée :
La société Upline Group relève un besoin pour l’automatisation de la gestion des demandes
d’achats. Il s’agit donc d’une application web permettant de gérer les demandes d’achats depuis
la création jusqu’à la livraison.

II. La Plate-forme Java EE :

1. Présentation et historique :
Dans le monde actuel de l'informatique et des technologies Internet, les applications sont de
plus en plus conséquentes, rapides et doivent être réalisées en un minimum de temps et de coût.
Le triptyque de gestion de projets Délais-Moyens-Objectifs est toujours d'actualité et demande
aux sociétés informatiques de créer des applications dans un temps donné avec les ressources
adaptées dans un souci de productivité. Sun Microsystems, désormais Oracle Corporation,
propose pour cela la plate-forme Java Enterprise Edition ou Java EE, véritable référence pour
le développement d'applications d'envergure et supportant en standard la programmation, la
persistance des données, les transactions, la sécurité ou encore le déploiement de projets sur
serveur applicatif.

La plate-forme Java EE (Enterprise Edition, anciennement J2EE) propose un développement

simplifié, rapide et robuste reposant désormais sur la configuration par annotations, directement
dans les fichiers source. La sortie de Java EE version 6 en 2009 correspond à l'anniversaire des
dix ans de la plate-forme. La première version standard J2EE 1.2 a été développée par Sun en
1999 et contenait 10 spécifications ou Java Spécification Requests (JSR). Les Entreprises
JavaBeans (EJB) permettaient de gérer la couche métier d'accès aux données alors que les
Servlets et JavaServer Pages (JSP) permettaient de développer les applications serveur. La
version J2EE 1.3 sortie en 2001 n'apportait pas de nouveautés essentielles mais plutôt des
améliorations de la plate-forme à la suite des demandes utilisateur, comme la configuration par
fichier XML.

La version J2EE 1.4 proposait 20 spécifications lors de sa sortie fin 2003. Cette version
apportait le support des services Web et des EJB version 2.1. Mais cette version conséquente
était difficile à utiliser, tester et déployer.

Les développements par couches, de type Modèle Vue Contrôleur (MVC), ne facilitent pas la
compréhension de l'ensemble, et les technologies Servlet et JSP ne sont pas adaptées pour un
développement rapide. En réponse à cela, quelques Frameworks ou outils spécialisés voyaient
le jour, comme Struts et Spring pour la partie développement serveur, et Hibernate ou TopLink
pour la persistance.

La version Java EE 5 sortie en 2006 proposait 23 spécifications et apportait une réponse à cela
en proposant désormais un outil de développement côté serveur adapté au design pattern MVC,
nommé JavaServer Faces. Cette nouvelle version était une étape majeure pour la plate-forme

18
Java EE qui s'orientait vers la simplicité, en proposant les EJB 3 associés à JPA (Java
Persistance API) pour la persistance des données, JAX-WS (Java API for XML based Web
Services) 2.0 pour les services Web en lieu et place de JAX-RPC (Java API for XML based
RPC) et surtout le principe des annotations Java 5 pour la configuration des applications
(configuration du déploiement, persistance, EJB ou autres) en remplacement des nombreux
fichiers XML.

Désormais, la version Java EE 6 sortie en 2009 propose 28 spécifications et se concentre

essentiellement sur la facilité d'utilisation de la plate-forme pour le développement, les tests et
le déploiement. Cette nouvelle mouture propose une simplification des EJB avec la version 3.1,
l'utilisation abondante des annotations pour faciliter le développement et la sortie de JAX-RS
(Java API for RESTful Web Services) 1.1 pour le développement de services Web.

Désormais, la version Java EE 6 sortie en 2009 propose 28 spécifications et se concentre

essentiellement sur la facilité d'utilisation de la plate-forme pour le développement, les tests et
le déploiement. Cette nouvelle mouture propose une simplification des EJB avec la version 3.1,
l'utilisation abondante des annotations pour faciliter le développement et la sortie de JAX-RS
(Java API for RESTful Web Services) 1.1 pour le développement de services Web.
Cette dernière mouture de la plate-forme Java EE version 6 propose les principales nouveautés :

 L'API JAX-RS.
 L'injection de dépendances et de ressources avec Contexts and Dependency Injection
(CDI).
 L'interface d'authentification pour le conteneur.
 Les nouveaux composants EJB 3.1 qui facilitent encore leur utilisation.
 La nouvelle version des Servlets (3.0) et des JavaServer Pages (2.2).
 Une nouvelle API JavaServer Faces (2.0) (JSF) pour la couche ou tiers Web.

2. Composants et Architecture Java EE :

Les développements Java EE reposent sur un découpage en couches ou tiers, nous parlons alors
d'applications multi-tiers. Trois grands tiers sont représentés :

 La couche présentation (tiers web).

 La couche métier (tiers métier ou tiers Business).
 La couche stockage des informations (tiers Entreprise Information System).

Les applications sont découpées en plusieurs composants réalisant des fonctionnalités

spécifiques et installés sur une machine serveur ou sur plusieurs tiers distribués. Les composants
Java EE sont des unités autonomes assemblées dans une application Java EE composée de
classes Java et de fichiers, et communiquant avec d'autres composants. De même, le code métier
écrit est indépendant de la couche de présentation, ce qui est utile pour changer cette dernière
ou pour l'afficher sur divers supports (Internet, Téléphonie...).
D'après le schéma ci-après, la spécification Java EE définit les composants suivants :

19
  Les composants Clients ou tiers Client sont des applications clientes (logiciel installé en
local ou navigateur Web ou Applets) s'exécutant sur la machine des utilisateurs.
 Les composants Web ou tiers Web sont les technologies Servlets, JavaServer Pages et
Java- Server Faces.
 Les composants métier ou tiers Métier sont des composants Entreprises JavaBeans
(EJB) représentant la logique métier, s'exécutant sur le serveur Java EE et dialoguant
avec la couche de stockage (EIS : Enterprise Information System).

Figure II.2 : Architecture Java EE Standard

Une application Java EE multi-tiers correspond à un ensemble de couches. Souvent considérée

comme étant une architecture trois tiers, celle-ci est distribuée de manière physique sur trois
machines :

 La machine des clients.

 Le serveur d’applications Java EE.
 Le serveur de base de données ou de stockage.

20
 2.1. Les composants clients ou tiers clients :
La plate-forme Java EE propose trois types de clients : les clients Web, les Applets et les
applications clientes riches type Java SE.

a) Les clients web :

Un client Web consiste en des pages Web de différents types (HTML, XHTML, XML,
JavaScript ou autres) générées à partir de composants exécutés côté serveur dans un conteneur
Web et capables de répondre aux requêtes HTTP en provenance du navigateur Internet. Ces
programmes côté serveur sont représentés en Java EE par les Servlets, pages JSP et JSF. Ces
programmes serveur ne réalisent en général pas directement les accès aux bases de données
mais s'occupent de la logique applicative.

b) Les clients applets :

Les Applets sont des interfaces graphiques Java SE exécutées dans un navigateur Web. Ces
applications utilisent une interface graphique évoluée de type SWING et sont exécutées dans
une machine virtuelle Java installée dans le navigateur. Cependant cette technique est plus
contraignante à maintenir, requiert des accès et des droits pour la sécurité et nécessite un plug-
in pour les navigateurs. Les clients Web sont donc préférables pour la création du tiers Client.

c) Les applications clientes :

Une application de type client est un logiciel riche, qui s'exécute sur la machine du client et
fournit un ensemble de services aux utilisateurs par l'intermédiaire d'une interface graphique
évoluée encore appelée Graphical User Interface (GUI).

Les clients et le serveur dialoguent ensemble par l'intermédiaire d'un composant standardisé
nommé JavaBean ou classe Plain Old Java Object (POJO). Un composant JavaBean peut être
vu comme la plus petite unité de communication entre les couches ou tiers Java EE. Les
composants JavaBeans sont des objets, instances de classes POJO, composés de propriétés et
de leurs accesseurs associés pour accéder aux données. Les JavaBeans s'exécutent sur le serveur
Java EE et dialoguent avec les clients ou avec la base de données (tiers EIS).
Ces applications riches sont développées avec les composants SWING en général, exécutées
avec Java Web Start ou Application Client Container (ACC) et déployées dans le projet
Enterprise ARchive (EAR).

21
 Figure II.3 : Communication Java EE entre les différents tiers

La figure ci-dessus montre les différents types de clients utilisés dans une plate-forme Java EE.
Les clients riches de type application communiquent directement avec le tiers Métier alors que
les clients de type navigateur Internet communiquent à travers le tiers Web par l'intermédiaire
de pages exécutées sur le serveur et générées par des Servlets, JSP ou JSF.

2.2. Les composants web ou tiers web :

Les composants Web Java EE sont des Servlets et/ou des pages JavaServer Pages et/ou des
JavaServer Faces. Les Servlets sont des classes Java, capables d'intercepter et de gérer les
requêtes du protocole HTTP. Les pages JSP sont des documents textuels exécutés comme des
Servlets apportant une solution simplifiée pour la programmation de pages Web. La technologie
JavaServer Faces est construite à partir de Servlets et fournit un Framework de développement
pour accélérer la création d'applications Web.

2.3. Les composants métier ou tiers métier :

Les composants métier ou tiers Métier représentent la couche business, avec les données du
système, et sont de deux types :

22
  Les entités beans (entity bean ou bean entity) peuvent être exécutées par un conteneur
léger (pas forcément un serveur Java EE) et permettent de réaliser la persistance des
données à partir des JavaBeans et de Java Persistance API (JPA).
 Les Enterprise JavaBeans offrent des possibilités plus riches comme la gestion des
transactions, les accès directs par clients riches ou encore la gestion automatique des
sessions utilisateur, mais sont exécutés sur un conteneur lourd, c'est-à-dire compatible
Java EE.

Figure II.4 : Tiers web et Tiers métier Java EE

La figure ci-dessus présente le découpage du tiers Métier avec les entités beans et les Enterprise
JavaBeans. Les informations sont reçues par un client léger au travers du tiers Web et des pages
Internet, ou directement depuis un client lourd. Ces informations sont ensuite envoyées sous la
forme de JavaBeans, images des informations en provenance des clients et à destination du tiers
Métier pour stockage. Dans le sens inverse, les Enterprise JavaBeans (EJB) lisent les données
en provenance du système de stockage, réalisent des opérations si nécessaire, et sont envoyés
au client.

La partie stockage des données, nommée tiers Enterprise Information System (EIS) est
directement liée au tiers Métier et correspond dans la majorité des cas, aux systèmes de gestion
de bases de données (Derby, MySQL, PostgreSQL, Oracle ou autres) ou à un entreprise
ressource planning (ERP), un gros système transactionnel ou n'importe quel système de
stockage évolué.

23
 Figure II.5 : Architecture évoluée Java EE

La figure précédente représente une architecture optimisée d'une application Java EE. Trois
types de clients sont représentés (client Web, client Applet et client Application), le serveur
Web utilisé en frontal est le serveur Internet de référence : Apache. Ce serveur renvoie
indirectement les résultats des pages dynamiques exécutées par le serveur d'applications Java
EE, et directement les contenus statiques de type images, CSS, JavaScript ou autres.

La partie contrôleur contient la logique de traitement. Cette couche dialogue avec les différents
types d'Enterprise JavaBeans (Stateless Bean, Stateful Bean et Message Driven Beans). La
couche métier est gérée par le standard JPA, permettant de paramétrer les classes ainsi que
l'outil de persistance EclipseLink, le tout configuré par le fichier persistence.xml.

24
 3. Les conteneurs web :
Les serveurs Java EE proposent plusieurs types de conteneurs (containers) pour chaque type de
composant. Chaque conteneur a un rôle bien défini et offre un ensemble de services pour les
développeurs :

 L'annuaire de nommage d'accès aux ressources : Java Naming and Directory Interface
(JNDI) est une interface unifiée de gestion de nommage pour les services et l'accès à
ceux-ci par des applications.
 L'injection dynamique de ressources.
 La gestion des accès aux bases de données.
 Le modèle de gestion de la sécurité.
 Le paramétrage des transactions.

Les exécutions et développements sont donc directement liés au conteneur utilisé et une
application Java EE côté tiers Web ne sera pas programmée comme une application côté tiers
EJB, par exemple. Les accès aux ressources nommées, les accès aux bases de données ou encore
l'injection dynamique de ressources seront différents. Pour résumer, un conteneur permet de
gérer le cycle de vie et la gestion des ressources.

Une application Java EE de type Web nécessite un conteneur Web pour son exécution alors
qu'une application utilisant les EJB nécessite un conteneur EJB pour son exécution. Chaque
conteneur propose un ensemble de services avec ses avantages et ses contraintes.

25
 Figure II.6 : Serveur Java EE et conteneur

L'architecture Java EE présentée dans la figure ci-dessus est découpée selon plusieurs domaines
ou services, appelés des conteneurs ou containers. D'après les précédents schémas, il existe en
Java EE cinq types de conteneurs :

 Java EE serveur, logiciel fournisseur du conteneur Web et EJB.

 Web Container ou conteneur Web, capable d'exécuter des pages JSP, Servlets et
programmes JSF (implémentation JSF nécessaire). Ces composants s'exécutent avec le
conteneur serveur Java EE. Ce conteneur supporte les protocoles HTTP et HTTPS et
dialogue avec différents types de clients (navigateur, application).
 EJB Container ou conteneur EJB, responsable de la couche métier et de l'exécution
des EJB. Ce conteneur fournit le mécanisme de gestion des EJB, la gestion de leur cycle
de vie, les transactions, le service de nommage JNDI et la possibilité des
déclenchements asynchrones.
 Applet Container ou conteneur Applet, responsable de l'environnement d'exécution
des Applets Java. Ce type d'application consiste en un navigateur Web et le plug-in Java,

26
 lancés en même temps sur le poste client. Ces programmes sont lancés dans un « bac à
sable » aussi nommé « sandbox » afin de gérer la sécurité des accès sur le poste client.
 Application Client Container (ACC) ou conteneur des applications clientes, permet
l'exécution d'applications Java SE. L'application de type client et son conteneur sont
lancés sur le client en simultané. Le conteneur d'applications client (ACC) propose une
bibliothèque de classes, un système de gestion de sécurité et le service de nommage
JNDI pour les applications Java SE. La communication directe entre le conteneur client
et le conteneur EJB est réalisée avec les technologies RMI-IIOP, alors que la
communication avec le conteneur Web est réalisée avec le protocole HTTP pour les
services Web, par exemple.

4. API et services Java EE :

La plate-forme Java EE est la plus importante proposée par Oracle et regroupe les services de
la plate-forme Java SE. Les services et API Java EE sont donc associés à une plate-forme et un
ou plusieurs conteneurs. Les conteneurs étudiés précédemment proposent plusieurs services
pour le développement d'applications. En tant que développeur, nous pouvons utiliser la totalité
des services ou bien au contraire sélectionner uniquement les techniques nécessaires à la
réalisation du projet. Chaque service s'exécute dans un des cinq conteneurs étudiés
précédemment et offre d'autres méthodes en fonction de ce conteneur.

4.1. Java Servlet (Technologie Java EE – Conteneur web)

Ce service Java EE s'exécute dans le conteneur Web et propose un ensemble de classes de
gestion des échanges HTTP de type requête-réponse. Avec la nouvelle version de Java EE, la
technologie Servlet 3.0 facilite la configuration et supporte les annotations ou encore les
traitements asynchrones.

4.2. JavaServer Page (JSP) (Technologie Java EE – conteneur

web)
La technologie JavaServer Pages (JSP) s'exécute dans le conteneur Web et utilise le mécanisme
de génération de Servlets à partir de documents textuels. Les JSP 2.2 contiennent des données
statiques de type HTML, XHTML, JavaScript ou autres, et des balises ou tags JSP nommés
JSTL correspondant à du code Java.

4.3. JavaServer Pages Standard Tag Library (JSTL)

La technologie JavaServer Pages Tag Library (JSTL) est encapsulée dans des pages JSP et
propose une librairie de balises XHTML standardisées. Ces balises proposent de gérer les
conditions et itérations, l'internationalisation, les affichages HTML ou encore l'accès aux bases
de données.

27
 4.4. JavaServer Faces (JSF)
La technologie JavaServer Faces s'exécute dans le conteneur Web et correspond à la réponse
du consortium Java EE en matière de Framework de développement côté serveur. JSF 2.0 est
un Framework de développement de projets Web proposant la construction rapide de code
serveur, la validation des entrées, la gestion des modèles objets, la configuration de la
navigation, les conversions de données, l'utilisation d'annotations, les balises et technologies
d'affichages de données pour la partie Vue, le support de la technologie Ajax en natif et bien
d'autres fonctionnalités. JSF est orienté composant et repose sur un cycle de vie proche du
développement d'applications Java SE (écouteurs, évènements...).

4.5. Java Database Connectivity (JDBC) :

La technologie Java DataBase Connectivity (JDBC) permet de gérer les commandes SQL et les
dialogues avec les différents SGBD relationnels. JDBC est utilisée lorsque nous devons accéder
à une base de données dans une Servlet, page JSP, page JSF ou autres. L'API JDBC propose un
ensemble de classes et interfaces pour se connecter aux différents SGBD du marché mais
également les paquetages de manipulation des données. JDBC est une technologie sous-jacente
à JPA.

4.6. Java Persistance API (JPA) :

Java Persistance API (JPA) est un standard Java utilisé pour la persistance des données. Ce
mécanisme de persistance utilise le principe de mapping objet/relationnel et relationnel/objet
afin de permettre de stocker les objets dans la base de données et inversement de pouvoir lire
les données relationnelles et les transformer en objets.
L'API Java Persistance 2.0 propose les services suivants :

 La gestion de la persistance.
 Un langage de requêtage évolué : Java Persistance Query Langage (JPQL).
 Un mécanisme de mapping objet/relationnel ORM à partir de métadonnées (fichiers
XML ou annotations).
 Une API à typage fort pour le requêtage.

4.7. Java Transaction API (JTA) (Technologie Java EE –

Conteneur web, conteneur EJB) :
Java Transaction API (JTA) fournit un standard de gestion des transactions pour une
architecture Java EE et propose par défaut le mode autocommit pour la gestion des transactions,
mais offre également les mécanismes de commit et rollback pour une optimisation des
transactions. Cependant, cette API est rarement utilisée directement par le développeur, mais
plutôt en association avec d'autres API.

28
 4.8. Entreprise JavaBeans (EJB) (Technologie Java EE –
Conteneur EJB) :
Les composants Enterprise JavaBeans s'exécutent dans le conteneur dédié EJB et correspondent
à la couche ou tiers Métier de l'application. Ces EJB 3.X sont des classes composées de champs
et de méthodes d'accès. Java EE propose deux familles d'EJB : les session beans et message-
Driven beans.

Les session beans représentent les conversations entre le client et le serveur, qu'elles soient avec
ou sans état. Un Message-Driven Bean (MDB) mélange un session bean et un écouteur de
message permettant ainsi la réception asynchrone de messages. Ces services utilisent Java
Message Service (JMS) pour leur fonctionnement. La nouvelle version de Java EE offre la
possibilité d'empaqueter les EJB directement dans des archives WAR (Web ARchive),
l'utilisation du Design Pattern Singleton dans les sessions beans et la possibilité d'utiliser des
EJB légers avec un serveur Java ne proposant pas le conteneur EJB.

4.9. Java Message Service API (JMS) (Technologie Java EE –

Conteneur web, Conteneur EJB, et Conteneur d’application) :
Java Message Service API (JMS) est le standard permettant aux applications Java EE de créer,
d'envoyer, de recevoir et de traiter les messages asynchrones en mode point à point ou multi
destinations.

4.10.JavaMail :
Les applications Java EE utilisent l'API JavaMail pour l'envoi d'e-mails. L'API JavaMail fournit
pour cela un ensemble de classes de gestion.

4.11.Java Authorization Service Provider Contract for

Containers (JACC):
La sécurité des services est regroupée sous le terme Java Authentification and Authorization
Service (JAAS) et permet de gérer l'authentification et les accès clients. L'API Java
Authorization Service Provider Contract for Containers (JACC) définit un contrat entre une
application Java EE et un fournisseur de services. La spécification Java ACC définit les classes
du paquetage java.security.Permission pour la gestion des autorisations.

4.12.Java Authentication Service Provider Interface for

Containers (JASPIC) :
L'API Java Authentication Service Provider Interface for Containers (JASPIC) propose une
interface de service d'authentification pour les dialogues entre le client et le serveur.

29
 4.13.Java Authentication and Authorization Service (JAAS):
La technologie Java Authentication and Authorization Service (JAAS) fournit les mécanismes
d'authentification et d'autorisation pour un groupe ou utilisateur spécifique lançant l'application.
JAAS est une version du standard Pluggable Authentication Module (PAM).

4.14.Java API for XML Registries (JAXR):

Java API for XML Registries (JAXR) permet un accès au tiers Métier à travers le Web.

4.15.Java API for XML Processing (JAXP):

La plate-forme Java permet l'utilisation de configuration à base de fichiers au format XML. Les
services de la bibliothèque Java API for XML Processing (JAXP) permettent le support des
documents XML en utilisant une bibliothèque pour le parsage XML : Document Object Model
(DOM) et Simple API for XML (SAX) ainsi qu'un mécanisme de feuilles de style : Extensible
Stylesheet Language Transformations (XSLT). JAXP permet aux différentes applications Java
de manipuler des documents XML, pour la description et le déploiement des applications,
indépendamment du processeur XML utilisé.

4.16.Java Architecture for XML Binding (JAXB):

L'API Java Architecture for XML Binding (JAXB) fournit un mécanisme simple de
transformation d'objet en document XML et inversement, pour une utilisation en Java. JAXB
peut également être utilisée avec JAX-WS ou JAX-RS et permet l'échange de messages avec
l'utilisation des services Web.

4.17.Java API for XML Web Services (JAX-WS):

L'API Java API for XML Web Services (JAX-WS) fournit un support des services Web et
utilise pour cela l'API JAXB (pour la transformation Objet/XML et XML/Objet) et l'API SOAP
with Attachments API pour Java (SAA). La bibliothèque JAX-WS remplace Java API for
XML-based RPC (JAX-RPC) et propose un support des services Web en utilisant le protocole
SOAP. Les messages supportent les accès JNDI des composants et le principe de sérialisation/
désérialisation.

4.18.Java API for RESTful Web Services (JAX-RS):

L'API Java for RESTful Web Services (JAX-RS) permet le développement Web de services
utilisant l'architecture REpresentational State Transfer (REST). Une application JAX-RS est
une application Web composée de classes empaquetées dans une archive WAR fournissant un
ensemble de services. JAX-RS permet d'exposer des classes POJO sous forme de ressources
REST manipulables via le protocole HTTP.

30
 4.19.Java Naming and Directory Interface (JNDI):
L'API Java Naming and Directory Interface (JNDI) fournit un mécanisme de nommage de type
annuaire pour l'accès aux ressources. Ces ressources peuvent être de différents types mais le
but est d'associer les objets à un nom (bind) et de retrouver ces objets (lookup) dans un annuaire
de nommage semblable à LDAP, DNS ou NIS. Nous pouvons ainsi nommer une source de
données de type base de données, un Enterprise JavaBean, une session JavaMail ou autres.
JNDI permet une utilisation et un accès depuis une application de type client, un EJB ou un
composant Web.

4.20.JavaBeans Activation Framework :

JavaBeans Activation Framework (JAF) est utilisé par l'API JavaMail pour la gestion des types
MIME. JAF permet de déterminer le type d'un ensemble de données encapsulées dans l'e-mail.
L'API permet de déterminer le type et de créer un JavaBean adapté en fonction de celui-ci.
La plate-forme Java EE propose également un outil de gestion (management) Java Management
Extensions (JMX) pour le contrôle des conteneurs et du serveur. Elle propose enfin un outil de
gestion du déploiement afin de standardiser le mécanisme de déploiement entre les produits
Java EE et les applications.

III. Le modèle MVC :

1. Le modèle MVC en théorie :
 Qu'est-ce qu'un modèle de conception ?
En anglais design pattern, un modèle de conception (ou encore patron de conception) est une
simple bonne pratique, qui répond à un problème de conception d'une application. C'est en
quelque sorte une ligne de conduite qui permet de décrire les grandes lignes d'une solution. De
tels modèles sont issus de l'expérience des concepteurs et développeurs d'applications : c'est en
effet uniquement après une certaine période d'utilisation que peuvent être mises en évidence
des pratiques plus efficaces que d'autres, pratiques qui sont alors structurées en modèles et
considérées comme standard.
Maintenant que nous sommes au point sur ce qu'est un modèle, la seconde question à se poser
concerne bien évidemment le Java EE.

 Que recommandent les développeurs Java EE expérimentés ?

Il faut bien vous rendre compte qu'à l'origine, Java EE permet plus ou moins de coder son
application comme on le souhaite : en d'autres termes, on peut coder n'importe comment ! Or
on sait que dans Java EE, il y a « Entreprise », et que ça n'est pas là pour faire joli ! Le
développement en entreprise implique entre autres :

31
  que l'on puisse être amené à travailler à plusieurs contributeurs sur un même projet
ou une même application (travail en équipe).
 que l'on puisse être amené à maintenir et corriger une application que l'on n'a pas
créée soi-même.
 que l'on puisse être amené à faire évoluer une application que l'on n'a pas créée soi-
même.

Pour toutes ces raisons, il est nécessaire d'adopter une architecture plus ou moins standard, que
tout développeur peut reconnaître, c'est-à-dire dans laquelle tout développeur sait se repérer.

Il a été très vite remarqué qu'un modèle permettait de répondre à ces besoins, et qu'il s'appliquait
particulièrement bien à la conception d'applications Java EE : le modèle MVC (Modèle-Vue-
Contrôleur). Il découpe littéralement l'application en couches distinctes, et de ce fait impacte
très fortement l'organisation du code ! Voici dans les grandes lignes ce qu'impose MVC :

 tout ce qui concerne le traitement, le stockage et la mise à jour des données de

l'application doit être contenu dans la couche nommée "Modèle" (le M de MVC).
 tout ce qui concerne l'interaction avec l'utilisateur et la présentation des données
(mise en forme, affichage) doit être contenu dans la couche nommée "Vue" (le V
de MVC).
 tout ce qui concerne le contrôle des actions de l'utilisateur et des données doit être
contenu dans la couche nommée "Contrôle" (le C de MVC).

Ce modèle peut être représenté par la figure suivante :

Figure II.7 : Modèle MVC

2. Le modèle MVC en pratique :

Modèle : des traitements et des données
Dans le modèle, on trouve à la fois les données et les traitements à appliquer à ces données. Ce
bloc contient donc des objets Java d'une part, qui peuvent contenir des attributs (données) et

32
des méthodes (traitements) qui leur sont propres, et un système capable de stocker des données
d'autre part. Rien de bien transcendant ici, la complexité du code dépendra bien évidemment de
la complexité des traitements à effectuer par votre application.

Vue : des pages JSP

Une page JSP est destinée à la vue. Elle est exécutée côté serveur et permet l'écriture de gabarits
(pages en langage "client" comme HTML, CSS, JavaScript, XML, etc.). Elle permet au
concepteur de la page d'appeler de manière transparente des portions de code Java, via des
balises et expressions ressemblant fortement aux balises de présentation HTML.

Contrôleur : les Servlets

Une servlet est un objet qui permet d'intercepter les requêtes faites par un client, et qui peut
personnaliser une réponse en conséquence. Il fournit pour cela des méthodes permettant de
scruter les requêtes HTTP. Cet objet n'agit jamais directement sur les données, il faut le voir
comme un simple aiguilleur : il intercepte une requête issue d'un client, appelle éventuellement
des traitements effectués par le modèle, et ordonne en retour à la vue d'afficher le résultat au
client.

Figure II.8 : MVC avec Java EE

 Un serveur d'applications est constitué d'un serveur HTTP et d'un conteneur web.
 Le modèle de conception MVC impose une répartition stricte des tâches au sein d'une
application :
 la couche Modèle se charge des traitements à effectuer sur les données et de leur
stockage.
 la couche Vue se charge de la présentation des données pour l'utilisateur et de
l'interaction.
 la couche Contrôle se charge d'aiguiller les requêtes entrantes vers les
traitements et vues correspondants.
 Un Framework est une boîte à outils mise à disposition du développeur pour lui alléger
certaines tâches.
 Dans une application Java EE sans Framework :
 la couche Modèle est constituée d'objets Java.

33
  la couche Vue est constituée de pages JSP.
 la couche Contrôle est constituée de servlets.

IV. Outils et environnement de développement :

La création d’une application web avec Java EE s’effectue généralement à l’aide d’un
environnement de développement intégré, très souvent raccourci en anglaise à l’IDE. C’est un
logiciel destiné à faciliter grandement le développement dans son ensemble.

1. Les outils :

1.1. L’IDE Eclipse :

J’ai utilisé IDE Eclipse tout au long de développement, ce n’est pas le seul existant, c’est
simplement celui que je maîtrise. Massivement utilisé en entreprise, c’est un outil puissant,
gratuit, libre et multiplateforme.

1.2. Apache Tomcat :

Pour faire fonctionner une application web nous avons besoin de mettre en place un serveur
d’application. Il en existe beaucoup, j’ai choisi d’utiliser Tomcat, car c’est serveur léger, gratuit,
libre, multiplateforme et assez complet.

2. Téléchargement des outils

Nous avons commencé par télécharger les outils nécessaires pour le développement Java EE

 Eclipse Java EE pour le développement web : Mars.2 Release (4.5.2)

 Apache Tomcat 8.0
 JDK 8

3. Installation des outils :

 Nous avons installé JDK 8
 Nous avons dé zipper le contenu du fichier zip Tomcat sous le chemin
C:\programmes\Tomcat.
 Nous avons dé zippé la version Eclipse sous le chemin C:\eclipse\.

4. Outils matériels :
La programmation a été effectuée sur un ordinateur de capacité suivante :

 Marque : Sony VAIO.

 Microprocesseur : Intel Core 2 duo.
 Mémoire vive : 4 Go.
 Disque dur : 600 Go.

34
35
I. Introduction :
La phase d’analyse et de spécification, est la première étape du processus de développement
que nous avons adopté. En effet, elle formalise et détaille ce qui a été ébauché au cours de
l'étude préliminaire, et permet de dégager l'étude fonctionnelle du système. Elle permet ainsi
d'obtenir une idée sur ce que va réaliser le système en termes de métier (comportement du
système).

Tout au long de ce chapitre, nous commencerons par définir les besoins fonctionnels et non
fonctionnels de la solution que nous allons proposer, et présenter le diagramme général de cas
d’utilisation.

II. Analyse des besoins :

Cette partie va servir à poser les bases du recueil des besoins du système à réaliser. Pour pouvoir
clarifier les besoins des utilisateurs de notre application, nous allons présenter les besoins
fonctionnels ainsi que les besoins non fonctionnels.

1. Les besoins fonctionnels :

Il s’agit des fonctionnalités du système. Ce sont des besoins spécifiant un comportement

d’entrée / sortie du système.
Le système à concevoir doit permettre à l’utilisateur d’effectuer les opérations suivantes :

 Gestion des utilisateurs : Il s’agit d’un outil permettant d’effectuer les opérations de
gestion telles que l’ajout, la suppression, la modification, et la consultation des
informations caractérisant chacun des utilisateurs.
 Gestion des demandes d’achat : l’application doit permet
o La saisie d’une demande d’achat.
o La validation des demandes d’achats.
o Le suivi d’une demande d’achat.
 Gestion de bon de commande : l’application doit permet
o Générer un bon de commande.
o Consultation des bons de commandes.

2. Les besoins non fonctionnels :

Les besoins non fonctionnels concernent les contraintes à prendre en considération pour mettre
en place une solution adéquate aux attentes des concepteurs des architectures dynamiques.

Notre application doit nécessairement assuré ces besoins :

36
  La sécurité : l’application devra être hautement sécurisée, les informations ne devront
pas être accessibles à tout le monde, c’est-à-dire que le site web est accessible par un
identifiant et un mot de passe attribué à une personne physique.
 L’interface : avoir une application qui respecte les principes des interfaces
Homme/Machine tels que l’ergonomie et la fiabilité.
 La performance : l’application devra être performante c’est-à-dire que le système doit
réagir dans un délai précis, quelque soit l’action de l’utilisateur.
 La convivialité : l’application doit être simple et facile à manipuler même par des non
experts.

III. Conception :
1. Diagramme de cas d’utilisation :

Le diagramme de cas d’utilisation décrit les utilisations requises d’un système, ou ce qu’un
système est supposé faire. Les principaux concepts de ce diagramme sont les acteurs, cas
d’utilisation et sujets. Un sujet représente un système avec lequel les acteurs et autres sujets
interagissent.

Figure III.1 : Diagramme de cas d’utilisation

37
 2. Identification des acteurs :

 Administrateur : l’administrateur a le droit de créer un nouvel utilisateur et de définir

les rôles et les privilèges des utilisateurs du système.
 Editeur demande d’achat : il a pour rôle de saisir une demande d’achat, ainsi que le
suivi l’état d’une demande d’achat. La demande créer se transite automatiquement vers
le président de directoire concerné.
 Président de directoire : plus les rôles d’éditeur, il a le rôle de valider des demandes
d’achats.
 Service ressources humaines : son rôle consiste à valider une demande d’achat après
la validation de celle-ci par le président directoire.
 Contrôleur du fond : il répond à une demande d’achat, sa réponse peut être favorable
ou défavorable, ça dépond du budget. Il peut aussi consulter toutes les demandes
d’achats.
 Responsable d’achat : il valide aussi une demande d’achat validé par tous les services
concernés, et il génère un bon de commande.

3. Les diagrammes de séquence :

Un diagramme de séquence est un document graphique qui montre pour des scénarios de cas
d'utilisation précis, les événements générés et les interactions entre objets en se basant sur des
messages ordonnés. Chaque message transitant sur un lien est symbolisé par une flèche porteuse
d'une expression. La lecture se fait de haut en bas, et l'ordre chronologique doit respecter ce
sens.

3.1. Cas d’utilisation « Créer une demande d’achat »

Figure III.2 : Cas d’utilisation « Créer une demande d’achat »

 But : Ce cas d’utilisation permet à un éditeur de créer une demande d’achat.

 Les acteurs : Editeur demande d’achat.
 Description textuelle : En cas de besoin de fourniture soit de type investissement ou
fonctionnement, l’éditeur demande au système de créer une demande d’achat, ce dernier
lui demande les informations nécessaires (désignation, fournisseur, libelle d’articles,
quantité…). Lors de la saisie des informations, le système effectuera les contrôles qu’il

38
 faut, et après la confirmation de ces informations, le système enregistre ces
informations.
 Les scénarios
1. L’éditeur demande de créer une demande d’achat.
2. Le système demande de choisir le type de la demande d’achat à créer.
3. L’éditeur effectue son choix.
4. Le système affiche une fiche de création d’une demande d’achat selon le type
choisi.
5. L’éditeur remplit les champs du formulaire (désignation, fournisseur, articles,
quantité…).
6. Le système vérifie les champs introduits, sauvegarde les informations saisies, et
affiche un message correspondant à la réussite de l’opération.

Figure III.3 : diagramme de séquence « Créer une demande d’achat »

39
 3.2. Cas d’utilisation « Valider une demande d’achat »

Figure III.4 : Cas d’utilisation « Valider une demande d’achat »

 But : Ce cas d’utilisation permet à ses acteurs de valider une demande d’achat reçu.
 Les acteurs : Président de directoire, service RH, Responsable d’achat.
 Description textuelle : le validateur demande au système de consulter les demandes
d’achats en cours de traitement pour la validation. Et il valide la demande pour qu’il
transite à l’étape suivante.
 Les scénarios :
1. Le validateur demande la liste de DAs non validées.
2. Le système affiche la liste des demandes d’achats en attente de validation.
3. Le validateur valide la demande d’achat.
4. Message de réussite.

Figure III.5 : Diagramme de séquence « Valider une demande d’achat »

40
 3.3. Cas d’utilisation « Suivre une demande d’achat »

Figure III.6 : Cas d’utilisation « Suivre une demande d’achat »

 But : ce cas d’utilisation permet à ses acteurs de suivre l’état d’une demande d’achat
s’elle est validée ou non.
 Les acteurs : Editeur demande d’achat.
 Description textuelle : l’éditeur demande au système de consulter la liste des demandes
d’achats en cours de traitement pour voir l’état de ses demandes.
 Les scénarios
1. L’éditeur demande la liste des demandes d’achats en cours de traitement.
2. Le système envoi la liste des DAs en cours de traitement.
3. L’éditeur visualise l’état de ses demandes en cours.

Figure III.7 : Diagramme de cas d’utilisation « Suivre une demande d’achat »

41
 3.4. Cas d’utilisation « répondre à une demande d’achat »

Figure III.8 : Cas d’utilisation « Répondre à une demande d’achat »

 But : ce cas d’utilisation permet au contrôleur du fond de répondre à une demande, la

réponse peur être soit Accepter ou Refuser.
 Las acteurs : Contrôleur du fond.
 Description textuelle : le contrôleur du fond demande au système de visualiser la liste
des demande d’achat en attentes d’une réponse, et il répond à ces demandes d’achats, la
réponse donnée peut être soit Accepter ou refuser.
 Les scénarios
1. Le contrôleur du fond demande au système de visualiser la liste des DAs en
attente.
2. Le système envoie la liste des DAs en attente d’une réponse.
3. Le contrôleur du fond sélectionne une DA et il donne sa réponse, si la réponse
est Acceptée le système envoie la DA au responsable d’achat, sinon le processus
de la DA se termine.

42
Figure III.9 : Diagramme de séquence « Répondre à une demande d’achat »

3.5. Cas d’utilisation « Gestion des utilisateurs »

Figure III.10 : Cas d’utilisation « Gestion des utilisateurs »

43
 But : Ce cas d’utilisation permet à l’administrateur du système d’ajouter, modifier ou
supprimer un utilisateur, permet aussi d’affecter un rôle à un utilisateur (lors de la
création du compte, l’administrateur spécifie le login et le mot de passe de l’utilisateur).
 Les acteurs : Administrateur
 Description textuelle : l’administrateur a le droit d’ajouter, modifier ou supprimer un
utilisateur, le système demande les informations nécessaires pour l’action effectuer.
 Les scénarios
 Ajouter un utilisateur : permet d’ajouter un utilisateur à la liste des utilisateurs
selon l’enchainement suivant
1. L’administrateur du système demande d’ajouter un utilisateur.
2. Le système affiche un formulaire à remplir par l’administrateur pour
ajouter un utilisateur.
3. L’administrateur saisit les informations nécessaires et valide la création.
4. Le système créer un compte pour le nouvel utilisateur, le sauvegarde, et
retourne un avis d’enregistrement.
 Modifier un utilisateur : permet de modifier un utilisateur donné selon
l’enchainement suivant :
1. L’administrateur demande la liste des utilisateurs.
2. Le système retourne la liste des utilisateurs.
3. L’administrateur sélectionne l’utilisateur qui lui convient.
4. Le système retourne la description complète de l’utilisateur (nom,
prénom, login…).
5. l’administrateur modifie tout ou une partie des informations concernant
l’utilisateur, et valide la modification.
6. Le système confirme la modification.
 Supprimer un utilisateur : permet de supprimer un utilisateur selon
l’enchainement suivant
1. l’administrateur du système demande la liste des utilisateurs.
2. le système retourne la liste des utilisateurs.
3. l’administrateur du système sélectionne l’utilisateur à supprimer.
4. le système retourne la description complète de l’utilisateur (nom,
prénom, login...).
5. l’administrateur valide la suppression.
6. le système avertit l’administrateur, en lui affichant une confirmation de
suppression.
7. l’utilisateur sera supprimé dans le cas de confirmation.

44
 Figure III.11 : Diagramme de séquence « Ajouter un utilisateur »

3.6. Cas d’utilisation « Consulter toutes les DA »

Figure III.12 : cas d’utilisation « Consulter toutes les DA »

 But : ce cas d’utilisation permet au contrôleur du fond de consulter l’historique

de toutes les demandes d’achat effectuées.
 Les acteurs : Contrôleur du fond.
 Description textuelle : pour le faire le contrôle, le contrôleur du fond au système
de consulter l’historique des demandes d’achat effectuées.
 Scénario :
1. Le contrôleur du fond demande au système l’historique des demandes
d’achats.

45
 2. Le système retourne l’historique des demandes d’achat effectuées par
tous les filiales.

Figure III.13 : diagramme de séquence « Consulter toutes les DA »

3.7. Cas d’utilisation « suivi de bon de commande »

Figure III.14 : cas d’utilisation « Suivi de bon de commande »

 But : ce ces d’utilisation permet au responsable d’achat de consulter tous les bon de
commande.
 Les acteurs : Responsable d’achat.
 Description textuelle : après la validation d’une demande d’achat par le responsable
d’achat le système génère un bon de commande à partir de la demande d’achat. Le
responsable d’achat consulte tous les bons de commande et il a la possibilité de
l’imprimer.

46
 Scénario
1. Le responsable d’achat demande au système la liste des bons de commande.
2. Le système retourne la liste des bons de commande.
3. Le responsable d’achat sélectionne un bon de bon de commande
4. Le système affiche les détails.

Figure III.15 : diagramme de séquence « suivi de bon de commande »

47
 4. Diagramme de classe :

Figure III.16 : Diagramme de classe

Conclusion
Dans ce chapitre, nous avons présenté le langage UML. Aussi nous avons fait la description des
diagrammes des cas d’utilisation, de classe et de séquence, et de contexte afin de délimiter le
cadre de notre travail et de préparer un terrain favorable pour la prochaine étape.

Maintenant, notre application est prête à être codée. Dans le chapitre suivant, nous allons nous
intéresser à l’implémentation de notre système en se basant sur la conception détaillée de ce
chapitre.

48
49
I. Introduction :
Dans chapitre précédent nous avons présenté les étapes de conception de l’application, ainsi
que les différents diagrammes des cas d’utilisation, par la suite nous avons détaillé cette phase
en établissant les diagrammes des classes ainsi que les diagrammes de séquences.

Dans ce chapitre nous traitons les différentes étapes d’implémentation de l’application, et au

fur et à mesure nous avons établi un ensemble de tests : ce sont les étapes de la phase de
réalisation.

II. Environnement de travail :

1. Environnement logiciel :
Nous avons énuméré au cours de cette partie les différents outils utilisés tout au long de ce
projet pour l’étude et la mise en place de notre application.

1.1. Système d’exploitation :

Nous avons utilisé comme système d’exploitation :
 Microsoft Windows 7 Entreprise.

1.2. Outils de modélisation UML :

 StarUML :
Nous avons exploité pour la modélisation UML de l’application l’outil StarUML, complet et
puissant, conçu pour les plateformes Windows. C’est un outil de création de modèles dont le
langage est UML.

1.3. Environnement de développement intégré :

 Eclipse :
Eclipse est un projet, décliné et organisé en un ensemble de sous-projets de développements
logiciels, de la fondation Eclipse visant à développer un environnement de production de
logiciels libre qui soit extensible, universel et polyvalent, en s'appuyant principalement sur Java.

1.4. Serveur d’application « Apache Tomcat » :

Pour faire fonctionner une application web nous avons besoin de mettre en place un serveur
d’application. Il en existe beaucoup, j’ai choisi d’utiliser Tomcat, car c’est serveur léger, gratuit,
libre, multiplateforme et assez complet.7

50
 1.5. Outils d’administration base de données :
 MySQL Workbench :
Nous avons appliqué MySQL Workbench comme un logiciel de gestion et d'administration de
bases de données MySQL, il possède une interface graphique intuitive, il permet, entre autres,
de créer, modifier ou supprimer des tables, des comptes utilisateurs, et d'effectuer toutes les
opérations inhérentes à la gestion d'une base de données. Pour ce faire, il doit être connecté à
un serveur MySQL.

1.6. Langage de programmation :

 Java
L’application a été développée en JAVA pour lequel nous avons opté car il est de plus en plus
utilisé dans le monde de la recherche scientifique ainsi que dans l'industrie. En effet, ce langage
de programmation présente un large avantage car les programmes peuvent être exécutés sur
différents systèmes d'exploitation et architectures matérielles. De plus, il permet de créer
facilement des interfaces graphiques conviviales.

 HTML
HTML (Hyper Text Markup Language / langage hypertexte) est le langage dans lequel sont
écrites les pages du web. Un site web est constitué d’un ou plusieurs documents HTML,
appelées aussi pages. Pour se déplacer d’une page à l’autre dans nos modules on passe par
l’intermédiaire d'hyperliens. Pour ajouter des objets graphiques on utilise le HTML d’autre part
pour tester des pages web html en local, il suffit d'ouvrir le fichier dans un navigateur. Le HTML
n’est pas un langage de programmation comme le C++. Les langages dynamiques comme PHP
et Javascript vont d' ailleurs générer des pages HTML statiques.

 JavaScript
JavaScript est un langage de programmation de scripts principalement utilisé pour les pages
web interactives comme les pages HTML. JavaScript est exécuté sur l'ordinateur de l'internaute
par le navigateur lui-même. C'est une extension du langage HTML qui est incluse dans le code.
Ce langage est un langage de programmation qui permet d'apporter des améliorations au
langage HTML en permettant d'exécuter des commandes. Ce code est directement écrit dans la
page HTML, c'est un langage peu évolué qui ne permet aucune confidentialité au niveau des
codes.

 CSS
Les CSS, Cascading Style Sheets (feuilles de styles en cascade), servent à mettre en forme des
documents web, type page HTML ou XML. Par l'intermédiaire de propriétés d'apparence
(couleurs, bordures, polices, etc.) et de placement (largeur, hauteur, côte à côte, dessus, dessous,
etc.), le rendu d'une page web peut être intégralement modifié sans aucun code supplémentaire

51
 dans la page web. Les feuilles de styles ont d'ailleurs pour objectif principal de dissocier le
contenu de la page de son apparence visuelle.

III. Développement :
1. Choix de la plateforme JEE :
Pour le développement de l’application, nous avons utilisé la plateforme JEE (Java Edition
Entreprise).
Parmi les avantages de la plateforme JEE, on peut citer :

 Technologie sans frais : Java (sur le quel est basé JEE) est une technologie Open
Source, les outils de développement JEE sont disponibles gratuitement.
 Maintenabilité : Les applications JEE sont plus faciles à entretenir, dans la plupart
des cas, ils sont conçus en plusieurs couches. Il est facile d'ajouter de nouvelles
fonctionnalités tierces pour les applications JEE en raison de sa fonction d'évolutivité.
 Indépendance : Les applications développées avec JEE peuvent être déployées sur la
plupart des matériels disponibles. Elles offrent une flexibilité de matériel à l'utilisateur
final. Ainsi, l’utilisateur peut déployer et exécuter des applications JEE sur le système
d'exploitation et le matériel de son choix.

IV. Choix de développement :

Pour le développement, nous avons appliqué le modèle Model-View-Controller (MVC). Ce
paradigme divise l’IHM (Interface Homme Machine) en un modèle (M pour modèle de
données) une vue (V pour la présentation, l’interface utilisateur) et un contrôleur (C pour la
logique de contrôle, et la gestion des événements / synchronisation), chacun ayant un rôle précis
dans l'interface.

L'organisation globale d'une interface graphique est souvent délicate. L'architecture MVC ne
résout pas tous les problèmes. Elle fournit souvent une première approche qui peut ensuite être
adaptée. Elle offre aussi un cadre pour structurer une application.
Ce patron d'architecture impose la séparation entre les données, la présentation et les
traitements, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la
vue et le contrôleur.

52
 Figure IV.1 : Modèle MVC

1. Le modèle :

Le modèle représente le comportement de l'application : traitements des données, interactions

avec la base de données, etc. Il décrit ou contient les données manipulées par l'application. Il
assure la gestion de ces données et garantit leur intégrité. Dans le cas typique d'une base de
données, c'est le modèle qui la contient. Le modèle offre des méthodes pour mettre à jour ces
données (insertion, suppression, changement de valeur). Il offre aussi des méthodes pour
récupérer ces données. Les résultats renvoyés par le modèle sont dénués de toute présentation.

2. La vue :

La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est de
présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les actions
de l'utilisateur (clic de souris, sélection d'une entrée, boutons, etc.). Ces différents événements
sont envoyés au contrôleur. La vue n'effectue aucun traitement, elle se contente d'afficher les
résultats des traitements effectués par le modèle et d'interagir avec l'utilisateur.

3. Le contrôleur :

Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à jour
la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur et enclenche
les actions à effectuer. Si une action nécessite un changement des données, le contrôleur
demande la modification des données au modèle, et ce dernier notifie la vue que les données
ont changée pour qu'elle les mette à jour.

53
V. Phase de test :
En informatique, un test désigne une procédure de vérification partielle d'un système
informatique. Le but en est de trouver un nombre maximum de comportements problématiques
du logiciel, car il est impossible de prouver qu'un logiciel fonctionne bien dans tous les cas.
Plus on trouve d'erreurs, plus il y a de chances qu'il y ait d’avantage d'erreurs dans le composant
logiciel visé. Les tests de vérification ou de validation visent à s'assurer que ce système réagit
de la façon prévue par ses concepteurs (spécifications) ou est conforme aux attentes du client
l'ayant commandé (besoins), respectivement. Dans cette partie nous allons présenter une liste
des modules de test, scénario de test et le résultat obtenu à partir du tableau suivant :

Module Scénario du test

Connexion Entrer un login et un mot de passe correct Exécution correcte
à l’application Entrer un login et un mot de passe Exécution correcte
incorrect
Connexion à la base Sélectionner des données de la base des Exécution correcte
des données données
Gestion des données Insertion des données statiques Exécution correcte
statiques Consultation des données Exécution correcte
Gestion des interfaces Insertion des données alphabétiques à la Exécution correcte
graphiques place des numériques
Gestion des Insertion des données existantes Exécution correcte
exceptions Sélection des données inexistantes dans la Exécution correcte
BD
Transfert correcte des informations entre Exécution correcte
les interfaces
Mise à jour de BD à chaque modification Exécution correcte
Envoyer une requête au serveur Exécution correcte
Insertion au BD Exécution correcte

VI. Interface graphique :

L’interface graphique est une partie très importante pour la réalisation d’une application Web
convenable et conviviale offrant un certain plaisir à l’utilisateur lors de sa navigation. Ainsi ce
critère peut faire la différence entre une application et une autre bien qu’elles aient les mêmes
fonctionnalités.

Voici maintenant quelques captures d’écrans sur les principaux points d’entrées de
l’application :

54
 1. Interface authentification :

Lors du clic sur le bouton « Entrer » de l’interface home, une interface d’authentification est
affichée. L’utilisateur doit introduire son Login et son mot de passe dans les champs
correspondants pour pouvoir accéder aux différentes fonctionnalités de l’application.

Figure IV.2 : interface authentification

Une fois que le client a cliqué sur le bouton « Entrée », le système vérifie les données entrées.
En cas d’échec, il réaffiche la page d’authentification avec un message d’erreur. Si le Login et
le mot de passe sont valides, le système passe au menu principal.

2. Interface administrative :

Figure IV.3 : interface administrative

55
Cette interface permet les ajouts, les suppressions et les modifications des différents utilisateurs.
Ces tâches sont effectuées par l’administrateur.

3. Interface création d’une demande d’achat :

Figure IV.4 : interface création d’une demande d’achat

Cette interface permet aux éditeurs de créer des demandes d’achats, le système affiche une
formulaire pré-remplit.

4. Interface de consultation :

Figure IV.5 : interface consultation des demandes d’achats

56
Cette interface permet aux utilisateurs de visualiser la liste des demandes d’achats ainsi que le
suivi des demandes d’achat s’ils sont validés ou non.

5. Interface suivi de bon de commande :

Cette interface permet de consulter la liste de bon de commande, permet aussi d’imprimer un
bon de commande.

Conclusion
La dernière partie de ce projet était dédiée à la navigation dans notre application. Cette partie
constitue le dernier volet de ce rapport ; elle a pour objet de présenter l’environnement logiciel
et matériel de réalisation. Elle a été clôturée par l’exposition des imprimés écrans décrivant
quelques interfaces de notre outil.

57
 Conclusion générale
Tout au long de ce rapport, nous avons présenté les différentes étapes de réalisation de
l’application au sein de la société Upline Group. Pour le développement de ce projet la
technique UML a été utilisée, ce qui a permis de mener correctement la tâche d’analyse des
besoins à l’aide du diagramme de cas d’utilisation et la tâche de conception, ainsi les scénarios
sont aussi détaillés afin d’expliquer tous tâches faite Puisque nous travaillons avec le plateforme
J2EE.

Ce projet nous a donné l’opportunité de s’initier à la vie professionnelle dans un milieu réel et
avoir un début d’expérience significatif, et il nous a appris comment dès le matin on peut
prendre le parti de la gaieté, comment réussir de bonnes relations pour assurer un travail de
groupe, comment compter sur soi pour résoudre les problèmes au cas où ils se présentent,
comment être méticuleuses dans notre travail, comment être attentives aux indications de nos
supérieurs, comment être bien organisées pour accomplir dans les meilleurs délais, et meilleures
conditions les tâches qui nous sont confiées.

Au cours de la réalisation de notre projet, nous avons étaient astreints par quelques limites
notamment, la contrainte du temps qui était relativement un obstacle devant l’ajout de certaines
autres fonctionnalités. Cependant, il était une occasion pour mettre en évidence et déployer sur
le plan pratique nos connaissances en informatique.
Le projet peut être amélioré, et ce, en lui ajoutant quelques modules ou interfaces pour mieux
l’adopter aux besoins de l’utilisateur et pour qu’il soit toujours fiable et au niveau des progrès
atteint par la société.

58