¡dure d9—™h—tFPFSIS
•—™h—t •—™h—t
Projet de conception et de développement 2014-2015
Université de la Mannouba
Ecole Natio...
Remerciements
Il nous est indispensable de remercier avec gratitude Mme. GUERMAZI HOUDA aussi bien pour sa collaboration
a...
Table des matières
Introduction générale 2
1 Présentation générale 3
1.1 Evolution des ERPs . . . . . . . . . . . . . . . ...
TABLE DES MATIÈRES
3.3.2 Description des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Réalisati...
Table des figures
2.1 Diagramme des cas d’utilisation à l’administrateur . . . . . . . . . . . . . . . . . . 11
2.2 Diagram...
TABLE DES FIGURES
4.11 Interface de la validation de réception . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.12 I...
Liste des tableaux
3.1 Table article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3....
Introduction Générale
DE nos jours, toute entreprise est prête à investir des sommes considérables dans l’im-
plantation d...
Introduction Générale
Le deuxième chapitre comportera l’analyse et la spécification des besoins fonctionnels et des
besoins...
Chapitre 1
Présentation générale
Introduction
NOus commençons dans ce premier chapitre par une étude de l’évolution des ER...
CHAPITRE 1. PRÉSENTATION GÉNÉRALE
entrepôts et les centres de distribution.
Bien que les implémentations de MRP n’étaient ...
CHAPITRE 1. PRÉSENTATION GÉNÉRALE
ainsi que pour optimiser la productivité et la rentabilité de l’organisation[10,11,12].
...
CHAPITRE 1. PRÉSENTATION GÉNÉRALE
chaque unité d’affaire[2].
1.4 Présentation du travail demandé
Dans notre approche, nous...
Chapitre 2
Analyse et spécification des besoins
Introduction
L
’analyse et la spécification des besoins représentent la prem...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
2.2 Spécification des besoins
Au cours de cette partie, nous allons définir...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
– Supprimer un fournisseur.
– Modifier un fournisseur.
– Ajouter un articl...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
L’application doit fonctionner de façon cohérente sans erreurs et doit êt...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
FIGURE 2.1 – Diagramme des cas d’utilisation à l’administrateur
Cas d’uti...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
FIGURE 2.2 – Diagramme des cas d’utilisation relatif au responsable d’ach...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
FIGURE 2.3 – Diagramme des cas d’utilisation relatif au responsable du st...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
FIGURE 2.4 – Diagramme des cas d’utilisation relatif au responsable
2.3.2...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
Diagramme de séquence d’une procédure d’achat
La procédure d’achat est l’...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
Diagramme de séquence de consultation de stock
Ce diagramme concerne la c...
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
FIGURE 2.7 – Diagramme de séquence d’ajout d’un groupe
17
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
Diagramme de séquence de consultation des articles
La figure 2.8 nous rens...
Chapitre 3
Conception
Introduction
APrès avoir identifié les différentes fonctionnalités que doit accomplir notre applicati...
CHAPITRE 3. CONCEPTION
Il s’agit en général d’un ou plusieurs objets Java. Ces objets s’apparentent généralement
à ce qu’o...
CHAPITRE 3. CONCEPTION
– Une indépendance des données, de l’affichage et des actions (ce qui donne plus de sou-
plesse pour...
CHAPITRE 3. CONCEPTION
FIGURE 3.3 – Diagramme de classes
3.2.2 Conception détaillée du package traitement
La figure ci-dess...
CHAPITRE 3. CONCEPTION
FIGURE 3.4 – Diagramme de traitement
Dans la figure 3.4, nous montrons que :
– L’utilisateur consult...
CHAPITRE 3. CONCEPTION
3.3 Conception de la base de données
Cette partie est consacrée à la conception de la base de donné...
CHAPITRE 3. CONCEPTION
3.3.2 Description des tables
Champ Commentaire
idA identifiant article
T taux annuel de consommation...
CHAPITRE 3. CONCEPTION
Champ Commentaire
idC identifiant catalogue
coeff_delai importance du respect du délai
coeff_qualite...
CHAPITRE 3. CONCEPTION
Champ Commentaire
idU identifiant utilisateur
idG identifiant du groupe de associé à l’utilisateur
TA...
CHAPITRE 3. CONCEPTION
Conclusion
T
Out au long de ce chapitre, nous avons décrit les différents aspects conceptuels de no...
Chapitre 4
Réalisation
Introduction
A
Près avoir achevé l’étape de conception de l’application, nous entamons dans ce chap...
CHAPITRE 4. RÉALISATION
4.2 Les technologiques utilisées
Dans cette partie, nous allons présenter les raisons pour lesquel...
CHAPITRE 4. RÉALISATION
exécute un bytecode écrit dans un langage intermédiaire (Microsoft Intermediate Lan-
guage)
– C# :...
CHAPITRE 4. RÉALISATION
4.2.1.2 J2EE
4.2.1.2.1 Présentation J2EE est logiquement destiné aux gros systèmes d’entreprise. L...
CHAPITRE 4. RÉALISATION
croitre la productivité des développeurs dans le développement des interfaces utilisateur
tout en ...
CHAPITRE 4. RÉALISATION
définit une vaste infrastructure d’exécution pour l’hébergement des composants coté ser-
veur.
– Le...
CHAPITRE 4. RÉALISATION
FIGURE 4.2 – Architecture d’HIbernate
4.2.1.2.3 Les avantages de J2EE L’approche multi niveaux ado...
CHAPITRE 4. RÉALISATION
composants pour développer les applications requises.
– L’équipe de développement peut sélectionne...
CHAPITRE 4. RÉALISATION
– Les classes : une classe correspond à un ensemble d’objets possédant un identificateur
unique.
– ...
CHAPITRE 4. RÉALISATION
un moteur d’exécution pour les servlets et les pages JSP. Il prend en charge la partie dynamique
d...
CHAPITRE 4. RÉALISATION
FIGURE 4.5 – Interface de l’espace du responsable d’achat
FIGURE 4.6 – Interface de l’espace du re...
CHAPITRE 4. RÉALISATION
FIGURE 4.7 – Interface de l’espace du responsable
FIGURE 4.8 – Interface de l’espace de l’utilisat...
CHAPITRE 4. RÉALISATION
FIGURE 4.9 – Interface de la demande d’achat
FIGURE 4.10 – Interface de la commande d’achat
41
CHAPITRE 4. RÉALISATION
FIGURE 4.11 – Interface de la validation de réception
FIGURE 4.12 – Interface de la gestion des fo...
CHAPITRE 4. RÉALISATION
FIGURE 4.13 – Interface de la gestion des catalogues
FIGURE 4.14 – Interface de la gestion des art...
CHAPITRE 4. RÉALISATION
FIGURE 4.15 – Interface de la gestion des sorties des articles
FIGURE 4.16 – Interface de la consu...
CHAPITRE 4. RÉALISATION
FIGURE 4.17 – Interface de l’administration des groupes
FIGURE 4.18 – Interface de l’administratio...
CHAPITRE 4. RÉALISATION
FIGURE 4.19 – Interface de la gestion des accès des groupes
FIGURE 4.20 – Interface de la consulta...
CHAPITRE 4. RÉALISATION
FIGURE 4.21 – Interface de la consultation des mouvements
FIGURE 4.22 – Interface de la gestion de...
CHAPITRE 4. RÉALISATION
FIGURE 4.23 – Interface de la consultation des articles par site
.
48
Conclusion Générale
LEs ERPs sont un produit d’avenir au moins en Tunisie car ils permettent l’automatisation
des tâches ,...
Bibliographie
[0] Al-Mashari M., Al-Mudimigh A., and Zairi M.. (2003). Enterprise resource planning : A
taxonomy of critic...
Netographie
[10] www.entreprise-erp.com, date de dernière consultation 05/03/2015.
[11] www.erp-logiciel-gestion.com, date...
Glossaire
A
API Application Programmable Interface.
ASP Active Server Pages.
C
CLR Common Language Runtime.
E
EJB Entrepri...
Glossaire
JSP Java Server Pages.
M
MVC MODEL-VIEW-CONTROLLER.
P
PGI Progiciel de Gestion Integré.
PME Petites et Moyennes ...
Prochain SlideShare
Chargement dans…5
×

Projet de conception et de développement

551 vues

Publié le

Conception et Développement d’un ERP(module d’achat, module de gestion de stock» dont
l’objectif est de concevoir une application dédiée aux entreprises, permettant à son propriétaire
la gestion des achats et du stock

Publié dans : Ingénierie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
551
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
35
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Projet de conception et de développement

  1. 1. ¡dure d9—™h—tFPFSIS •—™h—t •—™h—t Projet de conception et de développement 2014-2015 Université de la Mannouba Ecole Nationale des Sciences de l’Informatique Campus Universitaire de la Manouba Ecole Nationale des Sciences de L’Informatique Rapport : Projet de conception et de développement Sujet : Conception et développement d’un ERP(module d’achat,module de gestion de stock) Réalisé par : Themri Abdelkarim Hadji Glei Encadré par : Mme. Guermazi Houda
  2. 2. Remerciements Il nous est indispensable de remercier avec gratitude Mme. GUERMAZI HOUDA aussi bien pour sa collaboration ainsi que pour son assistance précieuse qui nous ont donné un coup d’aide pour réaliser notre projet convenablement. De même, nous tenons à exprimer nos gratitudes à ceux qui nous ont aidé de près ou de loin pour avancer dans nos développements et nos recherches. i
  3. 3. Table des matières Introduction générale 2 1 Présentation générale 3 1.1 Evolution des ERPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Avantages des ERPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Inconvénients des ERPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Présentation du travail demandé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 Analyse et spécification des besoins 7 2.1 Les acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2 Les scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 Conception 19 3.1 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1 Choix de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.2 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.1 Conception détaillée du package persistance . . . . . . . . . . . . . . . . . 21 3.2.2 Conception détaillée du package traitement . . . . . . . . . . . . . . . . . 22 3.3 Conception de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.1 Modèle Entités Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 ii
  4. 4. TABLE DES MATIÈRES 3.3.2 Description des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Réalisation 29 4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Les technologiques utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1 Technologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1.1 Microsoft .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1.2 J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.2 Gestion de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2.3 Choix retenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.4 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Conclusion générale 49 Bibliographie 50 Netographie 51 Glossaire 52 iii
  5. 5. Table des figures 2.1 Diagramme des cas d’utilisation à l’administrateur . . . . . . . . . . . . . . . . . . 11 2.2 Diagramme des cas d’utilisation relatif au responsable d’achat . . . . . . . . . . . 12 2.3 Diagramme des cas d’utilisation relatif au responsable du stock . . . . . . . . . . 13 2.4 Diagramme des cas d’utilisation relatif au responsable . . . . . . . . . . . . . . . 14 2.5 Diagramme de séquence d’une procédure d’achat . . . . . . . . . . . . . . . . . . 15 2.6 Diagramme de séquence de consultation de stock . . . . . . . . . . . . . . . . . . 16 2.7 Diagramme de séquence d’ajout d’un groupe . . . . . . . . . . . . . . . . . . . . . 17 2.8 Diagramme de séquence de consultation des articles . . . . . . . . . . . . . . . . . 18 3.1 L’architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4 Diagramme de traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.5 Le modèle entités associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1 Architecture de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Architecture d’HIbernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3 Interface d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4 Interface de l’espace de l’administrateur . . . . . . . . . . . . . . . . . . . . . . . . 38 4.5 Interface de l’espace du responsable d’achat . . . . . . . . . . . . . . . . . . . . . . 39 4.6 Interface de l’espace du responsable de stock . . . . . . . . . . . . . . . . . . . . . 39 4.7 Interface de l’espace du responsable . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.8 Interface de l’espace de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.9 Interface de la demande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.10 Interface de la commande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 iv
  6. 6. TABLE DES FIGURES 4.11 Interface de la validation de réception . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.12 Interface de la gestion des fournisseurs . . . . . . . . . . . . . . . . . . . . . . . . 42 4.13 Interface de la gestion des catalogues . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.14 Interface de la gestion des articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.15 Interface de la gestion des sorties des articles . . . . . . . . . . . . . . . . . . . . . 44 4.16 Interface de la consultation des articles . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.17 Interface de l’administration des groupes . . . . . . . . . . . . . . . . . . . . . . . 45 4.18 Interface de l’administration des utilisateurs . . . . . . . . . . . . . . . . . . . . . 45 4.19 Interface de la gestion des accès des groupes . . . . . . . . . . . . . . . . . . . . . 46 4.20 Interface de la consultation des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.21 Interface de la consultation des mouvements . . . . . . . . . . . . . . . . . . . . . 47 4.22 Interface de la gestion des sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.23 Interface de la consultation des articles par site . . . . . . . . . . . . . . . . . . . . 48 v
  7. 7. Liste des tableaux 3.1 Table article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 Table groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3 Table catalogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Table entete_achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5 Table fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6 Table ligne_achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.7 Table groupe_utlisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.8 Table mouvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.9 Table role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.10 Table site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.11 Table utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 vi
  8. 8. Introduction Générale DE nos jours, toute entreprise est prête à investir des sommes considérables dans l’im- plantation des technologies logicielles afin d’améliorer ses services, d’accroître son agilité et sa flexibilité , de réduire les coûts, d’augmenter la production et de faire face aux défis du marché. En effet,vu la croissance des activités au sein des entreprises, la tâche de gérer efficacement toutes ces fonctions s’avère de plus en plus complexe et difficile. Pour surpasser ces difficultés, une entreprise doit utiliser des outils optimisés et adaptés facilitant les tâches et offrant des fonctionnalités riches et utiles. Parmi ces outils nous trouvons les systèmes intégrés de gestion tels que les ERPs(Entreprise Ressources Planning). Les ERPs appelés aussi Progiciel de Gestion Intégré sont des systèmes dont le but est d’in- tégrer les données et les processus dans les organisations. Les données sont stockées dans une même base de données ce qui garantit l’unicité des informations qui circulent à l’intérieur des différents départements[0]. C’est dans ce cadre que s’inscrit notre projet de conception et de développement, intitulé «Conception et Développement d’un ERP(module d’achat, module de gestion de stock» dont l’objectif est de concevoir une application dédiée aux entreprises, permettant à son propriétaire la gestion des achats et du stock. Le présent rapport synthétise tout le travail que nous avons effectué dans cette perspective. Il s’articule autour de quatre parties : Le premier chapitre donne une présentation générale du projet : étude des avantages et des inconvénients des ERPs ainsi que les objectifs à atteindre. 1
  9. 9. Introduction Générale Le deuxième chapitre comportera l’analyse et la spécification des besoins fonctionnels et des besoins non fonctionnels qui décrivent les fonctionnalités attendues de l’ERP à proposer, ainsi que les exigences qui vont déterminer sa qualité. Dans le troisième chapitre, nous présenterons la conception de l’ERP à développer : nous com- mencerons d’abord par la description du système suivi de son architecture, ensuite nous dé- taillerons et modéliserons la conception globale. Finalement, l’implémentation et la réalisation de la solution seront abordées dans le dernier chapitre. 2
  10. 10. Chapitre 1 Présentation générale Introduction NOus commençons dans ce premier chapitre par une étude de l’évolution des ERPs, puis nous allons présenter les avantages et les inconvénients de ces progiciels pour finir par présen- ter notre travail. 1.1 Evolution des ERPs Au fil des années, les systèmes ERP ont évolué et avancé depuis l’émergence des systèmes "Material Requirements Planning" (MRP) et des "Manufacturing Resource Planning" (MRP2) . La première différence entre un système ERP et ses prédécesseurs est que ERP engendre toute la gestion de l’entreprise non seulement les opérations reliées à la production. Les systèmes ERPs ont été inventés dans les années 1960, Ces systèmes ont été évolués en systèmes MRPs durant les années 1970. Les systèmes MRPs ont été utilisés au sein des entreprises industriels dans le but de gérer la production et le stockage. Dans la décennie suivante, on a vu l’apparition des systèmes "Manufacturing Requirements Planning" (MRP2) qui présentent une version étendue des MRPs couvrant d’autres opérations et processus entrepreneuriales des entreprises industrielles[1]. Outre la planification de fabrication, l’extension a géré les processus de finance, de gestion d’ordre, de gestion de stock, de distribution et d’approvisionnement MRP2 peuvent aussi s’oc- cuper des processus d’affaires au sein et entre les entités des grandes entreprises comme les 3
  11. 11. CHAPITRE 1. PRÉSENTATION GÉNÉRALE entrepôts et les centres de distribution. Bien que les implémentations de MRP n’étaient pas triviales, cependant, MRP2 consommaient plus de temps et de ressources car ils étaient de plus large portée et avaient des impacts plus importants sur les processus d’affaires et les personnes. Dans les années 1990, les systèmes ERP ont été introduits comme extension de ses prédécesseurs pour couvrir toute l’activité de l’orga- nisation. LES ERPs mettent l’accent sur les processus de la fonction d’affaires et non seulement les opérations reliées à la production de plus, ils offrent un stockage central des données et une intégration entre les différents départements de l’organisation. 1.2 Avantages des ERPs Concrètement, les avantages de la mise en place d’un ERP sont les suivants : – L’intégrité et l’unicité du SI, c’est-à-dire qu’un ERP permet une logique et une ergonomie unique à travers sa base de données, elle l’est aussi unique au sens " logique ". Ceci se tra- duit par le fait qu’il peut exister plusieurs bases de données " physiques " mais celles-ci respectent la même structure. En bref, un ERP permet d’éviter la redondance d’informa- tion entre différents SI de l’entreprise ce qui rend l’entreprise fiable vis-à-vis des autres organisations. – L’utilisateur a la possibilité de récupérer des données de manière immédiate, ou encore de les enregistrer. Un avantage important , les mise à jour dans la base de données sont ef- fectuées en temps réel et propagées aux modules concernés ce qui garantit une traçabilité des flux de production permettent un tavail d’amélioration continue de l’organisation. – Un ERP est un outil multilingue et multidevise, il est donc adapté au marché mondial, en particulier aux multinationales. – Pas d’interface entre les modules, il y a une synchronisation des traitements et une opti- misation des processus de gestion. De même, la maintenance corrective est simplifiée car celle-ci est assurée directement par l’éditeur et non plus par le service informatique de l’entreprise .(Celui-ci garde néanmoins sous sa reponsabilité la maintenance évolutive : amélioration des fonctionnalités , évolution des règles de gestion , etc ...) – Un ERP permet de maîtriser les stocks et les flexibiliser, élément important pour la plu- part des entreprises car les stocks coûtent chers ce qui augmente la compétivité de l’en- treprise. – L’automatisation de la gestion de certains processus pour soulager les équipes en interne 4
  12. 12. CHAPITRE 1. PRÉSENTATION GÉNÉRALE ainsi que pour optimiser la productivité et la rentabilité de l’organisation[10,11,12]. 1.3 Inconvénients des ERPs Malgré la grande reconnaissance des systèmes ERPs au sein des organisations, certaines critiques ont été dirigées vers ces types de systèmes, que ce soit d’un point de vue technique ou d’un point de vue commercial[2]. La rigidité des systèmes ERPs est souvent soulignée comme étant un facteur limitant leur uti- lisation. D’un côté, les organisations qui adoptent ces types de systèmes finissent par avoir les processus conçus sous une forme standard, juste parce que le système mis en place l’exige[3,4,5,6]. Cependant, cela n’arrive que lorsque les organisations veulent une solution de système ERP moins chère et avec un délai de mise en œuvre plus court, donc moins paramétré[7]. Une des difficultés majeures dans la mise en œuvre des systèmes ERP est la longue période que tels systèmes nécessitent[3,4,8]. Dans les grandes organisations, une application peut durer de trois à cinq ans qui est jugée en tant qu’une très longue période dans un environnement d’af- faires en évolution constante. Une autre critique des systèmes ERP est l’utilisation d’une technologie dépassée, même si cer- tains efforts ont récemment été faits comme Business By Design (SAP) et les systèmes SaaS offrant des installations Web 2.0 (SAP, Oracle, ...). En fait, certains systèmes ERPs ne font pas des interfaces graphiques et modernes, que les utilisateurs aimeraient. Cependant, il n’existe pas d’alternatives viables à cette situation[2]. De plus, le fait que cette technologie est basée sur des utilisateurs individuels, forçant le paie- ment de licences individuelles pour l’utilisation de système ERP, il en résulte un coût élevé de l’utilisation du système, ce qui rend la mise à jour du système difficile pour la plupart des ver- sions[9]. Un autre inconvénient des systèmes ERP est sa rigidité hiérarchique et la centralisation de contrôle et de gestion. Les Systèmes ERPs supposent que l’information doit être gèrée de ma- nière centralisée et que les organisations ont bien défini les structures hiérarchiques. Certains détracteurs de ces types de systèmes prétendent que l’habilitation devrait être de plus en plus appliquée aux organisations et les employés devraient être perçus comme des agents indé- pendants. Pour surmonter ces faiblesses, certains auteurs comme Davenport, soutiennent que, d’une part, la grande majorité des organisations ont bien définis les structures hiérarchiques et d’autre part, lorsque cela n’est pas le cas, il est possible d’implémenter un système ERP pour 5
  13. 13. CHAPITRE 1. PRÉSENTATION GÉNÉRALE chaque unité d’affaire[2]. 1.4 Présentation du travail demandé Dans notre approche, nous nous intéressons à la conception de deux modules que nous jugeons très important pour les entreprises : l’achat et la gestion du stock. De plus, nous es- sayons de proposer un ERP simple qui ne dépasse pas les besoins des organisations qui sont les suivants : – Offrir à l’utilisateur la possibilité de consulter les articles. – Offrir à l’administrateur la possibilité de gérer les groupes, les utilisateurs et les rôles. – Gérer la procédure d’achat. – Permettre au responsable du stock la gestion du stock. Conclusion DAns ce chapitre, nous avons exposé théoriquement notre projet pour mieux comprendre le système implémenté. Le chapitre suivant sera consacré à l’étude des besoins fonctionnels et non fonctionnels auxquels doit répondre notre ERP. 6
  14. 14. Chapitre 2 Analyse et spécification des besoins Introduction L ’analyse et la spécification des besoins représentent la première phase du cycle de déve- loppement d’un logiciel et c’est au cours de laquelle que les besoins de l’utilisateur sont identifiés et précisés. Dans ce chapitre, nous étudions dans un premier temps les besoins fonctionnels et non fonc- tionnels de notre système, ensuite, une spécification formelle des besoins est présentée par des diagrammes de cas d’utilisation et de séquences suivant la modélisation UML. 2.1 Les acteurs Cette partie consiste à présenter les acteurs du système. L’utilisateur : il s’identifie et consulte les articles avec les quantités existantes. Le responsable d’un service : les responsables des différents départements peuvent exprimer leurs besoins à travers la rédaction d’une demande d’achat. Le responsable d’achat : il fait toute l’analyse stratégique et consulte le nouveau dossier d’achat qui lui est destiné afin de valider la demande et établir la commande. Le responsable du stock : il vérifie la conformité de la marchandise reçue avec le bon de com- mande puis il valide la réception et il gère le stock. L’administrateur : il gère les groupes, les utilisateurs et les accès. 7
  15. 15. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS 2.2 Spécification des besoins Au cours de cette partie, nous allons définir les besoins fonctionnels et non fonctionnels de notre application. 2.2.1 Les besoins fonctionnels Ces exigences répondent à la question à quoi sert notre système. Les services proposés par notre application se manifestent suivant les acteurs comme suit : L’utilisateur : – S’identifier en tant que simple utilisateur. – Consulter les articles avec les quantités existantes. L’administrateur : – S’identifier en tant qu’administrateur. – Ajouter un utilisateur. – Modifier un utilisateur. – Supprimer un utilisateur. – Ajouter un groupe. – Modifier un groupe. – Supprimer un groupe. – Consulter les rôles. Le responsable : – S’identifier en tant que responsable. – Envoyer une demande. – Consulter les articles avec les quantités existantes. Le responsable d’achat : – S’identifier en tant que responsable d’achat. – Envoyer une commande. – Ajouter un fournisseur. 8
  16. 16. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS – Supprimer un fournisseur. – Modifier un fournisseur. – Ajouter un article. – Modifier un article. – Supprimer un article. – Consulter les articles avec les quantités existantes. – Ajouter un catalogue. – Modifier un catalogue. – Supprimer un catalogue. Le responsable du stock : – S’identifier en tant que responsable du stock. – Valider la réception d’une commande. – Ajouter un mouvement. – S’informer de l’état du stock. – Ajouter un site. – Supprimer un site. – Modifier un site. 2.2.2 Les besoins non fonctionnels Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumis le sys- tème pour sa réalisation et son bon fonctionnement. Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système mais plutôt imposent des contraintes internes et externes du système. Les principaux besoins non fonctionnels de notre application se résument dans les points sui- vants : – BNF1. Ergonomie L’application doit être adaptée à l’utilisateur sans fournir aucun effort (utilisation claire et facile) de point de vue navigation entre les différentes pages, couleurs et mise en textes utilisés. – BNF2. Fiabilité 9
  17. 17. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS L’application doit fonctionner de façon cohérente sans erreurs et doit être satisfaisante. – BNF3. Robustesse Les ambiguités doivent être signalées par des messages d’erreurs bien organisés pour bien guider l’utilisateur et le familiariser avec notre application web. – BNF4. Maintenabilité Le système doit être conforme à une architecture standard et claire permettant sa mainte- nance. – BNF5. Sécurité Notre solution doit respecter la confidentialité des données personnelles des utilisateurs. 2.3 Analyse des besoins Dans cette partie, on s’intéresse à la modélisation des besoins fonctionnels et leur analyse. 2.3.1 Diagrammes des cas d’utilisation L’étude approfondie des spécifications permet de dégager plusieurs cas d’utilisation. Un cas d’utilisation décrit une utilisation du système par un acteur particulier. Ce qui revient à présenter les besoins fonctionnels de façon formelle. Cas d’utilisation d’un administrateur Dans la figure 2.1, on montre les différents fonctionnalités de l’administrateur parmi lesquelles on trouve la consultation des rôles qui lui permet de connaitre ce que peut faire chaque utilisa- teur. 10
  18. 18. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS FIGURE 2.1 – Diagramme des cas d’utilisation à l’administrateur Cas d’utilisation du responsable d’achat La figure 2.2 montre les fonctionnalités du responsable d’achat formellement. 11
  19. 19. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS FIGURE 2.2 – Diagramme des cas d’utilisation relatif au responsable d’achat Cas d’utilisation du responsable de stock Le responsable de stock gère les sites, ajoute les mouvements en cas de sortie ou retours du stock et valide la réception comme l’indique la figure 2.3. 12
  20. 20. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS FIGURE 2.3 – Diagramme des cas d’utilisation relatif au responsable du stock Cas d’utilisation d’un responsable Le responsable est celui qui passe les demandes de tous les employés de son département. 13
  21. 21. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS FIGURE 2.4 – Diagramme des cas d’utilisation relatif au responsable 2.3.2 Les scénarios Les diagrammes de séquences peuvent servir à illustrer un cas d’utilisation décrit précé- demment. C’est un moyen semi formel de capturer le comportement de tous les objets et ac- teurs impliqués dans un cas d’utilisation. Dans ce qui suit nous allons présenter quelques scé- narios de notre application. 14
  22. 22. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS Diagramme de séquence d’une procédure d’achat La procédure d’achat est l’une des tâches les plus importantes de notre système qu’on trouve son déroulement représenté dans la figure 2.5. FIGURE 2.5 – Diagramme de séquence d’une procédure d’achat 15
  23. 23. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS Diagramme de séquence de consultation de stock Ce diagramme concerne la consultation de l’état du stock par le responsable du stock. FIGURE 2.6 – Diagramme de séquence de consultation de stock Diagramme de séquence d’ajout d’un groupe Le diagramme de la figure 2.7 montre la méthode de l’ajout d’un groupe par l’administrateur. 16
  24. 24. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS FIGURE 2.7 – Diagramme de séquence d’ajout d’un groupe 17
  25. 25. CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS Diagramme de séquence de consultation des articles La figure 2.8 nous renseigne sur la fonctionnalité de base d’un utilisateur. FIGURE 2.8 – Diagramme de séquence de consultation des articles Conclusion D Ans ce chapitre, nous avons spécifié les fonctionnalités que doit assurer notre projet. Nous avons, ensuite, spécifié les besoins requis par l’application via le diagramme de cas d’utilisation qui applique la méthode de conception UML et les diagrammes de séquences associés. Ceci, nous a permis d’avoir une idée claire sur les services offerts par notre applica- tion. La conception et ses détails seront décrits dans le prochain chapitre. 18
  26. 26. Chapitre 3 Conception Introduction APrès avoir identifié les différentes fonctionnalités que doit accomplir notre application, nous allons réserver ce chapitre pour la phase de conception qui présente une étape primordiale dans le cycle de développement d’un projet. Nous allons présenter dans ce chapitre l’aspect architectural et l’aspect conceptuel de notre solution. 3.1 Conception globale Dans cette section, nous allons étudier certaines architectures afin d’assurer un choix adé- quat pour la réalisation de notre application. Ensuite, nous allons présenter le diagramme de paquetage. 3.1.1 Choix de l’architecture L’architecture MVC (modèle, vue et contrôleur) est une architecture à trois couches utilisée pour la programmation client/serveur et d’interface graphique. C’est un modèle architectural très puissant qui intervient dans la réalisation d’une application. Il tire sa puissance de son concept de base qui est la séparation des données (modèle), de l’affichage (vue) et des actions (contrôleur). C’est trois couches sont décrites comme suit : – Modèle 19
  27. 27. CHAPITRE 3. CONCEPTION Il s’agit en général d’un ou plusieurs objets Java. Ces objets s’apparentent généralement à ce qu’on appelle souvent « la couche métier » de l’application et effectuent des traitements absolument transparents pour l’utilisateur. – Vue Ne contenant que les informations liées à l’affichage, la vue se contente d’afficher le contenu qu’elle reçoit sans avoir connaissance des données. En bref, c’est l’interface homme machine de l’application. – Contrôleur Le contrôleur sert de base à récupérer les informations, de les traiter en fonction des para- mètres demandés par la vue (par l’utilisateur), puis de renvoyer à la vue les données afin d’être affichées. C’est donc l’élément qui va utiliser les données pour les envoyer à la vue. L’interaction entre ces trois couches est décrite à l’aide de la figure suivante. FIGURE 3.1 – L’architecture MVC Les avantages apportés par l’architecture MVC sont : – La séparation des données de la vue et du contrôleur (ce qui permet une conception claire et efficace de l’application). 20
  28. 28. CHAPITRE 3. CONCEPTION – Une indépendance des données, de l’affichage et des actions (ce qui donne plus de sou- plesse pour la maintenabilité et l’évolutivité du système). – Un gain de temps de maintenance et d’évolution de l’application. Pour toutes ces raisons nous avons opté pour l’architecture MVC. 3.1.2 Diagramme de paquetage Notre application se base sur l’architecture MVC. Elle se décompose à son tour en trois paquets qui sont persistance, traitement et présentation. FIGURE 3.2 – Diagramme de paquetage 3.2 Conception détaillée Dans cette section, nous allons décrire les trois parties de l’architecture MVC. 3.2.1 Conception détaillée du package persistance Le package persistance comporte les classes qui représentent les données sauvegardées dans la base. Il permet l’intégrité et la gestion des données. 21
  29. 29. CHAPITRE 3. CONCEPTION FIGURE 3.3 – Diagramme de classes 3.2.2 Conception détaillée du package traitement La figure ci-dessous présente les différentes classes du package traitement. 22
  30. 30. CHAPITRE 3. CONCEPTION FIGURE 3.4 – Diagramme de traitement Dans la figure 3.4, nous montrons que : – L’utilisateur consulte les articles. – Le responsable consulte les articles et passe des demandes. – Le responsable d’achat consulte les articles, demande et commande. De plus, il fait la gestion des fournisseurs, des articles et des catalogues. – Le responsable du stock envoie des demandes et fait toutes les opérations nécessaires concernant le stock. – L’administrateur gère les utilisateurs ainsi que les groupes et consulte les rôles pour bien s’informer des droits d’accès. 23
  31. 31. CHAPITRE 3. CONCEPTION 3.3 Conception de la base de données Cette partie est consacrée à la conception de la base de données. En tenant compte des diverses fonctionnalités que le site doit assurer et afin de garantir l’ex- tensibilité et l’adaptabilité de la base, nous avons conçu un modèle de la base de données rela- tionnelle que nous allons détailler dans ce qui suit. 3.3.1 Modèle Entités Associations Le modèle conceptuel ci-dessous permet d’écrire formellement les données qui seront uti- lisées par notre application. Il s’agit donc d’une représentation de données facilement compré- hensible, décrivant le système à l’aide des entités associations. FIGURE 3.5 – Le modèle entités associations 24
  32. 32. CHAPITRE 3. CONCEPTION 3.3.2 Description des tables Champ Commentaire idA identifiant article T taux annuel de consommation designation nom article delai_liv délai livraison description description article marge_delai nombre de jours si le délai non respecté note_delai aptitude du fournisseur à respecter le délai note_qualite qualité de l’article note_retour_stock facilité du retour du stock prix prix unitaire stock quantité existante idF identifiant fournisseur idC identifiant catalogue idS identifiant site TABLE 3.1 – Table article Champ Commentaire idG identifiant groupe nom nom groupe description description du groupe responsable responsable du groupe TABLE 3.2 – Table groupe 25
  33. 33. CHAPITRE 3. CONCEPTION Champ Commentaire idC identifiant catalogue coeff_delai importance du respect du délai coeff_qualite importance de la qualité coeff_retour_stock importance du retour du stock consommation la consommation journaliére marge_consommation la consommation à prévoir nom nom catalogue TABLE 3.3 – Table catalogue Champ Commentaire idE identifiant entête date_doc date création de la demande type_doc indique l’état de la demande idF identifiant fournisseur idU identifiant demandeur TABLE 3.4 – Table entete_achat Champ Commentaire idF identifiant fournisseur nom nom fournisseur tel numéro téléphone mail mail fournisseur adresse adresse fournisseur TABLE 3.5 – Table fournisseur Champ Commentaire idL identifiant ligne achat quantite quantité à demander unite l’unité de la demande idE identifiant de l’entête achat correspondante idA identifiant de l’article lié à la ligne TABLE 3.6 – Table ligne_achat 26
  34. 34. CHAPITRE 3. CONCEPTION Champ Commentaire idU identifiant utilisateur idG identifiant du groupe de associé à l’utilisateur TABLE 3.7 – Table groupe_utlisateur Champ Commentaire idM identifiant mouvement date_op date du mouvement type entrée ou sortie ou retour stock quantite la quantité du mouvement idA identifiant de l’article concerné TABLE 3.8 – Table mouvement Champ Commentaire idR identifiant rôle demande indique si l’utilisateur peut faire une demande commande indique si l’utilisateur peut faire une commande validation indique si l’utilisateur peut valider la réception TABLE 3.9 – Table role Champ Commentaire idS identifiant site nom nom du site localisation localisation du site TABLE 3.10 – Table site Champ Commentaire idU identifiant utilisateur nom nom utilisateur prenom prénom utilisateur mail mail utilisateur idR groupe correspondant TABLE 3.11 – Table utilisateur 27
  35. 35. CHAPITRE 3. CONCEPTION Conclusion T Out au long de ce chapitre, nous avons décrit les différents aspects conceptuels de notre travail. Nous avons commencé par la présentation de l’architecture globale de l’appli- cation. Ensuite nous avons illustré l’architecture détaillée. Nous entamons dans ce qui suit la partie réalisation. 28
  36. 36. Chapitre 4 Réalisation Introduction A Près avoir achevé l’étape de conception de l’application, nous entamons dans ce chapitre la phase de réalisation. Nous allons présenter, en premier lieu, l’environnement de tra- vail utilisé pour le développement de l’application. Ensuite, nous allons donner un aperçu sur le travail accompli à travers des captures d’écran. 4.1 Environnement matériel Afin de réaliser ce projet dans les conditions favorables, nous avons mis en notre disposition deux ordinateurs avec les configurations suivantes : Le premier : – Processeur : Intel Core i7-3537U – Disque dur : 1To – RAM : 4Go Le deuxième : – Processeur : Intel(R) Core(TM) i5-2400M CPU – Disque dur : 720Go – RAM : 6Go 29
  37. 37. CHAPITRE 4. RÉALISATION 4.2 Les technologiques utilisées Dans cette partie, nous allons présenter les raisons pour lesquelles nous avons fait nos choix de technologie. 4.2.1 Technologie de développement Dans le chapitre précédent, nous avons choisi l’architecture du système et nous avons fait une comparaison entre les deux technologies .NET et J2EE avoir une application robuste, por- table, complexe et sécurisée, d’autant plus elles traitent des données confidentielles, et font appels aux technologies les plus modernes. 4.2.1.1 Microsoft .NET 4.2.1.1.1 Présentation La plate-forme Microsoft .NET est une solution complète pour déve- lopper, déployer et exécuter des application de tous types, y compris des services web. Fondée sur des standards de l’industrie (HTTP, XML, SOAP, WDSL), la plate-forme .NET est un moyen simple et puissant pour implémenter la coopération des services logiciels entre eux, quelle que soit leur localisation, leur impléméntation technique, qu’ils soient internes ou externes, exis- tants ou à inventer. 4.2.1.1.2 Les composants .NET A travers les différentes annonces de Microsoft depuis son lancement, les composants de .NET semblent s’organiser de la manière suivante : Pour la couche présentation et logique de présentation : – ASP .NET : c’est une nouvelle version d’ASP (Active Server Pages) qui supporte une véritable compilation en IL, alors qu’ASP était interprété auparavant. On peut également écrire les pages ASP dans n’importe quel langage disposant d’un compilateur IL. – WinForms et WebForms : ils présentent un ensemble de composants graphiques acces- sibles dans Visual Studio .NET. Pour la couche logique métier et objets intermédiaires : – CLR (Common Language Runtime) : c’est un environnement d’exécution commun qui 30
  38. 38. CHAPITRE 4. RÉALISATION exécute un bytecode écrit dans un langage intermédiaire (Microsoft Intermediate Lan- guage) – C# : c’est un nouveau langage orienté objet destiné à faciliter la programmation dans .NET, notamment les composants, qui intègre des éléments de C, C++ et de Java en ap- portant quelques innovations comme les méta-données. – Langages quelconques qui peuvent être compilés en IL et exécutés par le CLR si un com- pilateur IL existe pour ce dernier. – Une grande bibliothèque de composants et d’objets de base accessibles par le CLR, qui fournissent les fondations pour écrire rapidement un programme (accès réseau, graphisme, accès aux données). – Visual Studio .NET : c’est une réfonte de l’environnement Visual Studio et de VisualIN- terDev permettant aussi bien le développement d’application et de composant classique. – Un support de terminaux mobiles avec une version compacte de l’environnement .NET. Pour la couche de données : ADO .NET : c’est une nouvelle génération de composants d’accès aux bases de données ADO qui utilise XML et SOAP pour l’échange de données. 4.2.1.1.3 Les avantages de .NET La plate-forme .NET comprend un mod¨le de programma- tion homogène et des outils de développement multi langages qui accèlèrent le développement et l’intégration de Services Web et de tout autre type d’application multi langages et intégrant les standards, la plate-forme .NET laisse au développeur toute liberté de choisir le langage de développement. D’autre part son support des standards et son approche moderne, la plate- forme .NET est parfaitement adaptée à la construction d’une architecture orientée services. La plate-forme .NET offre donc plusieurs avantages : – Un développement spécifique grace au moteur CLR. – Une structure multi langages et extensible. – Une exécution multi plate-forme. – Une productivité comparable à celle des environnements Client/Serveur comme Power- Builder ou Delphi. – Un modèle de programmation simple et cohérent. – Une installation automatisée des Web Services. 31
  39. 39. CHAPITRE 4. RÉALISATION 4.2.1.2 J2EE 4.2.1.2.1 Présentation J2EE est logiquement destiné aux gros systèmes d’entreprise. Les lo- giciels employés à ce niveau ne fonctionnent pas sur un simple PC mais requière une puissance beaucoup plus importante. Pour cette raison, les applications doivent être constituées de plu- sieurs composants pouvant être déployés sur des plate-formes multiples afin de disposer de la puissance de calcul nécessaire. C’est la raison d’être des applications distribuées. J2EE est une collection de composants, de conteneurs et de services permettant de créer et de déployer des applications distribuées au sein d’une architecture standardisée. 4.2.1.2.2 Les composants J2EE J2EE fournit une gamme d’outils et d’API afin de concevoir facilement les différentes couches. Pour la couche de présentation et logique de présentation : – Java Servlet :une servlet est un programme écrit en JAVA qui tourne sur la machine du serveur J2EE. Une servlet est chargée lorsque le serveur est mis en route ou lorsque le premier client fait appel aux services de la servlet. Le serveur Web reçoit une demande adressée à une servlet sous la forme d’une requete HTTP. Il transmet la requete à la servlet concernée, puis renvoie la réponse fournie par celle du client. La servlet reçoit également les paramètres de la requete envoyée par le client. Elle peut alors effectuer toutes les opérations nécessaires pour construire la réponse avant de renvoyer celle-ci sous forme de code HTML. Une fois chargée, une servlet reste active dans l’attente de nouvelles requetes. Une servlet doit soit implémenter l’interface javax.servlet.Servlet ou étendre soit la classe javax.servlet.GenericServlet soit javax.servlet.http.HttpServlet. – Java Server Pages (JSP) : cette extension permet de valoriser davantage les applications web avec la plate-forme J2EE en permettant le développement d’applications web basées sur ce modèle ; les JSP permettent grace au moteur de servlet de produire facilement des pages HTML. – Struts : Jakarta Struts est un projet d’Apache software foundation qui a pour but de four- nir un cadre standard de développement web en java respectant le modèle d’architecture MVC (Model-View-Controller). Il fournit le minimum de r¨gles pour construire des ap- plications web professionnelles. – Java Server Faces (JSF) : Java Server Faces est un framework d’interface utilisateur pour les applications web, basé sur les technologies JSP et Servlets. Le but de JSF est d’ac- 32
  40. 40. CHAPITRE 4. RÉALISATION croitre la productivité des développeurs dans le développement des interfaces utilisateur tout en facilitant leur maintenance. JSF permet de réconcilier deux points de vues diamé- tralement opposés en fournissant un framework basé sur une abstraction complète des mécanismes d’internet tout en garantissant une totale maîtrise du cycle de vie du traite- ment d’une requete. JSF permet : – Une séparation nette entre la couche de présentation et les autres couches. – Le mapping HTML/Objet. – Un mod¨le riche de composants graphiques réutilisables. – Une gestion de l’état de l’interface entre les différentes requetes. – Une liaison simple entre les actions coté client de l’utilisateur et le code Java correspon- dant coté serveur. – La création de composants customs grace à une API. – Le support de différents clients (HTML, WML, XML, ...) grace à la séparation des pro- blématiques de construction de l’interface et du rendu de cette interface. FIGURE 4.1 – Architecture de JSF – Spring : c’est un framework ayant pour but de rendre facile le développement des appli- cations web tout en augmentant la consistance et la productivité. Pour la couche métier et objets intermédiaires : – Les EJB : ce sont des composants Java pour des applications distribuées multi niveaux. Cette extension fournit un moyen standard pour définir les composants coté serveur et 33
  41. 41. CHAPITRE 4. RÉALISATION définit une vaste infrastructure d’exécution pour l’hébergement des composants coté ser- veur. – Les JavaBeans : selon la spécification des Javabeans, une Bean est un composant logiciel réutilisable pouvant etre manipulé visuellement dans un outil de construction (builder- tool). Pour la couche de données : – JDBC Connector : JDBC (l’acronyme de JAVA Data Base Connectivity) est une API JAVA permettant d’accéder à la base de données, de façon indépendante de la base utilisée, à partir d’une application JAVA. La procédure sera la meme quelle que soit la base de données choisie. JDBC définit une API de bas niveau désignée pour supporter les fonc- tionnalités basiques de SQL indépendemment de toute implémentation SQl spécifique. – Hibernate : c’est un framework qui donne une solution pour le mapping objet/relationnel et la gestion de la couche de persistance. Hibernate permet la gestion automatique de la structure de la base de données : création et mise à jour. IL utilise un langage simple pour l’interrogation de la base de données appelé HQL (Hibernate Query Language) et qui fournit une couche d’abstraction SQL. 34
  42. 42. CHAPITRE 4. RÉALISATION FIGURE 4.2 – Architecture d’HIbernate 4.2.1.2.3 Les avantages de J2EE L’approche multi niveaux adoptée par la plate-forme J2EE offre plusieurs avantages : – Elle réduit la compléxité du développement distribué avec une architecture simplifiée et le partage de la charge de travail. – C’est une solution hautement évolutive qui permet le développement des systèmes satis- faisant de nombreux besoins rapidement modifiables. – Les nouvelles applications peuvent s’intégrer correctement avec les systèmes d’informa- tions existants. – La sécurié est améliorée. – Les développeurs peuvent choisir parmi une diversité d’outils de développement et de 35
  43. 43. CHAPITRE 4. RÉALISATION composants pour développer les applications requises. – L’équipe de développement peut sélectionner les meilleurs solutions pour leurs besoins, sans etre verrouillée par l’offre du fournisseur unique. – Tous les composants sont gratuits. 4.2.2 Gestion de la base de données Oracle DataBase Oracle est un SGBDR édité par la société du meme nom Oracle Corpora- tion leader mondial en base de données. Oracle peut assurer entre autres fonctionnalités : – La d´finition et la manipulation des données. – La cohérence des données. – La confidentialité des données. – L’intégrité des données. MySQL MySQL a pour origine l’application mSQL. Cette application permettait de ce connec- ter à des tables en utilisant des routines bas niveau. Cependant, après quelques tests, les déve- loppeurs sont arrivés à la conclusion que mSQL n’était pas assez rapide et flexible pour leurs besoins. Le serveur de bases de données MySQL est très rapide, able et facile à utiliser. Il dis- pose aussi de fonctionnalités pratiques, développées en coopération avec les utilisateurs. Les principales fonctionnalités qu’offre MySQL sont : – Fonctionne sur de nombreuses plate-formes. – Dispose d’API pour C, C++, Eiffel, Java, Perl, PHP, Python, Ruby et Tcl. – Compl¨tement multi-threadé, grace aux threads du noyau. Cela signifie qu’on peut l’uti- liser facilement sur un serveur avec plusieurs processeurs. – Tables B-tree très rapide, avec compression d’index. – Système d’allocation mémoire très rapide, exploitant les threads. – Tables en mémoire, pour réaliser des tables temporaires. – Les fonctions SQL sont implémentées grace à une librairie de classes optimisées, qui sont aussi rapides que possible. PostegreSQL PostgreSQL est un SGBD relationnel objet Open Source implémenté par l’univer- sité de Ber-keley. Les fonctions clés du mod¨le objet de PostgreSQL sont les classes, l’héritage et la surcharge. PostgreSQL est un logiciel â modulaire â possédant un langage d’écriture de procédures similaire à celui d’Oracle mais également d’autres interfaces de programmation. Voici les fonctions clés du modèle orienté objet de PostgreSQL : 36
  44. 44. CHAPITRE 4. RÉALISATION – Les classes : une classe correspond à un ensemble d’objets possédant un identificateur unique. – L’héritage : la notion d’héritage correspond à une organisation hiérarchique des tables. Par exemple, si deux tables se trouvent dans une relation parent/enfant, les informations contenues dans la table parent sont également disponible dans la table enfant. – La surcharge : On parle de " surcharge de fonction " lorsqu’une fonction peut etre définie plusieurs fois avec des paramètres différents. 4.2.3 Choix retenus La clareté de l’architecture qu’elle propose ainsi que la multitude des IDE qui peuvent la supporter et sa gratitude, la technologie J2EE a été le choix Judicieux pour le développement de notre application. L’IDE sur lequel nous avons choisit de développer notre application est l’IDE Eclipse. Une base de donnée MySQL est celle qui va être implémentée pour gérer les données nécessaires à l’application. 4.2.4 Environnement logiciel Eclipse Eclipse est un environnement de développement intégré (Integrated Development Envi-ronment) dont le but est de fournir une plate-forme modulaire pour permettre de réaliser des développements informatiques. I.B.M. est à l’origine du développement d’Eclipse qui est d’ailleurs toujours le cœur de son outil Websphere Studio Workbench (WSW), lui même à la base de la famille des derniers outils de développement en Java d’I.B.M. Tout le code d’Eclipsea a été donné à la communauté par I.B.M afin de poursuivre son développement. Eclipse utilise énormément le concept de modules nommés " Plug-ins " dans son architecture. D’ailleurs, hormis le noyau de la plate-forme nommé " Runtime ", tout le reste de la plate- forme est développé sous la forme de Plug-ins. Ce concept permet de fournir un mécanisme pour l’extension de la plate-forme et ainsi fournir la possibilité aux tiers de développer des fonctionnalités qui ne sont pas fournies en standard par Eclipse. Tomcat Tomcat est un serveur d’application totalemet écrit en java. A partir de la version 5.0, il implémentait les spécifications 2.4 des JavaServlet et 2.0 des JSP. Tomcat a été développé en open source au sein du projet Apache Jakarta, dont le but est de fournir des solutions serveur basées sur la plate-forme Java, de qualité identique aux applications commerciales. Tomcat est 37
  45. 45. CHAPITRE 4. RÉALISATION un moteur d’exécution pour les servlets et les pages JSP. Il prend en charge la partie dynamique du site et laisse la partie statique au serveur web. 4.3 Travail réalisé A cette étape du rapport, nous donnons les captures d’écran relatives aux pages des princi- pales fonctions réalisées par l’application. FIGURE 4.3 – Interface d’acceuil FIGURE 4.4 – Interface de l’espace de l’administrateur 38
  46. 46. CHAPITRE 4. RÉALISATION FIGURE 4.5 – Interface de l’espace du responsable d’achat FIGURE 4.6 – Interface de l’espace du responsable de stock 39
  47. 47. CHAPITRE 4. RÉALISATION FIGURE 4.7 – Interface de l’espace du responsable FIGURE 4.8 – Interface de l’espace de l’utilisateur 40
  48. 48. CHAPITRE 4. RÉALISATION FIGURE 4.9 – Interface de la demande d’achat FIGURE 4.10 – Interface de la commande d’achat 41
  49. 49. CHAPITRE 4. RÉALISATION FIGURE 4.11 – Interface de la validation de réception FIGURE 4.12 – Interface de la gestion des fournisseurs 42
  50. 50. CHAPITRE 4. RÉALISATION FIGURE 4.13 – Interface de la gestion des catalogues FIGURE 4.14 – Interface de la gestion des articles 43
  51. 51. CHAPITRE 4. RÉALISATION FIGURE 4.15 – Interface de la gestion des sorties des articles FIGURE 4.16 – Interface de la consultation des articles 44
  52. 52. CHAPITRE 4. RÉALISATION FIGURE 4.17 – Interface de l’administration des groupes FIGURE 4.18 – Interface de l’administration des utilisateurs 45
  53. 53. CHAPITRE 4. RÉALISATION FIGURE 4.19 – Interface de la gestion des accès des groupes FIGURE 4.20 – Interface de la consultation des rôles 46
  54. 54. CHAPITRE 4. RÉALISATION FIGURE 4.21 – Interface de la consultation des mouvements FIGURE 4.22 – Interface de la gestion des sites 47
  55. 55. CHAPITRE 4. RÉALISATION FIGURE 4.23 – Interface de la consultation des articles par site . 48
  56. 56. Conclusion Générale LEs ERPs sont un produit d’avenir au moins en Tunisie car ils permettent l’automatisation des tâches ,une optimisation des gains et une bonne gestion des ressources. L’objectif de ce projet était de concevoir et de développer deux modules faisant parti d’un ERP destiné aux entreprises classées en tant que PME. Pour réaliser le travail nous avons utilisé le framework JSF pour le développement des applications web et MySQL pour la gestion des bases de données. Pour la programmation de cette applications Web, nous avons utilisé l’IDE Eclipse suivant l’architecture MVC ainsi qu’Hibernate pour la manipulation de la couche de persistance. En tant que perspective, nous pouvons proposé le développement d’autres modules de l’ERP tels que la production, la finance, les ressources humaines et la comptabilité afin de présen- ter un produit complet, pouvant automatiser plusieurs taches, aux petites et moyennes entre- prises. 49
  57. 57. Bibliographie [0] Al-Mashari M., Al-Mudimigh A., and Zairi M.. (2003). Enterprise resource planning : A taxonomy of critical factors. European Journal of Operational Research, 146(2), 352-364. [1] Robert Jacobs and Ted Weston Jr. (2007). Enterprise resource planning (ERP) - A brief history. Journal of Operations Management, 25(2), 357-363. [2] Davenport T.. (2000). Mission Critical : Realizing the Promise ok Enterprise Systems. Boston, Massachusetts : harvard Business School Press. [3] Alshawi S., Themistocleous M. and Almadani R.. (2004). Integrating diverse ERP Sys- tems : a case study. The Journal of Enterprise Information Management, 17 (6), pp. 454-462. [4] Themistocleous M., Irani Z. , O’Keefe R. and Paul R.. (2001). ERP Problems and Appli- cation Integration Issues. Proceedings of the 34th Hawaii International Conference on System Sciences : An Empirical Survey ( HICSS-34) , (9), pp. 1-10. [5] Soh C., Kien S. and Tay-Yap. (2000). Cultural Fits and Misfits : Is ERP a Universal solu- tion ? Communications of ACM , 43 (4), pp. 47-51. [6] Sumner M.. (1999). Critical Success Factors in Enterprise Wide Information Management Systems Projects. Proceedings of the 1999 ACM SIGCPR Conference on Computer Personnel Research , pp. 297-303. [7] Lee j., Siau K. and Hong S.. (2003). Enterprise Integration with ERP and EAI. Communi- cations of the ACM , 46 (2), pp. 54- 60. [8] Murphy K. and Simon S.. (2002). Intangible benefits valuation in ERP projects. Informa- tion Systems Journal , 12, 4, pp. 301- 320. [9] Markus M. L. and Tanis C.. (2000). The Enterprise System Experience-From Adoption to Success. In R. W. Zmud (Ed.), Framing the Domains of IT Management : Projecting the Future Through the Past (pp. 173-207). 50
  58. 58. Netographie [10] www.entreprise-erp.com, date de dernière consultation 05/03/2015. [11] www.erp-logiciel-gestion.com, date de dernière consultation 20/03/2015. [12] www.erp.comprendrechoisir.com, date de dernière consultation 04/04/2015. [13] www.microsft.com, date de dernière consultation 23/04/2015. 51
  59. 59. Glossaire A API Application Programmable Interface. ASP Active Server Pages. C CLR Common Language Runtime. E EJB Entreprise JavaBean. ERP Entreprise Ressource Planning. E HQL Hibernate Query Language. HTTP Hyper Text Transfer Protocol. I IDE Integrated Development Environment. J JDBC Java Data Base Connectivity. JSF Java Server Faces. 52
  60. 60. Glossaire JSP Java Server Pages. M MVC MODEL-VIEW-CONTROLLER. P PGI Progiciel de Gestion Integré. PME Petites et Moyennes Entreprises. S SI Syst¨me d’Information. SQL Structured Query Language. U UML Unified Modeling Language. 53

×