Réalisation d’une application de gestion du suivi des bons de livraison

Processus de développement

Le processus de développement constitue un facteur déterminant dans la réussite d’un projet, du fait qu’il orchestre ses différentes phases et trace les principaux traits de sa conduite. Pour cela, le choix d’une méthode de développement doit être élaboré au préalable afin d’obtenir un produit de qualité tout en respectant les délais et les exigences fixés. Pour ce faire, nous avons comparé 2 méthodes : RUP (Rational UnifedProcess) et 2TUP (2 TrackUnifiedProcess) qui sont des processus unifié itératif et incrémental. Cette comparaison nous a permis d’éliminer la méthode RUP puisqu’elle est lourde, coûteuse à personnaliser et destinée pour les projets mobilisant plus de 10 personnes. Ensuite, nous avons opté pour la méthode 2TUP puisqu’elle couvre toutes les phases sans être très exhaustive et lourde, et fait une large place à la technologie et convient à des projets de taille quelconque. Vu que nous ne disposions pas d’un cahier de charges précis et amplement détaillé, nous avons senti que la méthode 2TUP est plus appropriée puisqu’elle traite les projets selon deux axes différents : fonctionnel et technique, et donc nous permettra de répondre aux changements et aux spécifications de l’entreprise. De plus, la méthode 2TUP va augmenter le taux de succès du projet car elle permet d’anticiper et de limiter les risques.

Spécifications logicielles

Dans ce paragraphe, après une description de l’architecture physique conçue, nous allons dévoiler la plate-forme applicative, en l’occurrence, nous allons dresser la suite logicielle et l’ensemble des briques choisies pour le déploiement de l’application. Dans notre projet, nous avons adopté un modèle de conception Design Pattern qui décrit une meilleure pratique ou une solution prouvée qui permet de résoudre à toutes contraintes les difficultés qui lui sont attachées, en mettant l’accent sur le contexte et sur les conséquences et les impacts de la solution. Durant le cycle de développement de notre projet, nous avons choisi d’implémenter certains modèles de conception, notamment, le MVC 2 asynchrone du (Model, View, Controller2), l’inversion de contrôle IOC2, l’objet de transfert de données DTO3, et l’objet d’accès aux données DAO4. Cette partie détaille le principe de chacun de ces Design Patterns en rappelant ses concepts clés.

Inversion de contrôle

Le principe de l’inversion de contrôle est au moins aussi ancien que celui de la programmation événementielle. Il s’agit d’un principe générique utilisé par de nombreux frameworks apparus bien avant la notion de conteneur léger.L’inversion de contrôle est aussi appelée principe Hollywood en référence à la phrase mythique « ne nous appelez pas, nous vous appellerons ». Les conteneurs légers proposent une version spécialisée de l’inversion de contrôle. Ils se concentrent en fait sur le problème de la gestion des dépendances entre objets et leur instanciation, notamment dans le cadre d’une dissociation des interfaces et des implémentations.

Injection de dépendances L’injection vise à rendre l’inversion de contrôle de la gestion des dépendances la plus transparente possible vis-à-vis des classes concernées. Comme nous l’avons vu à la section précédente, la recherche de dépendances crée un lien explicite entre les classes et le conteneur léger en charge de la gestion de leurs dépendances.

Grâce à l’injection de dépendances, nous pourront transformer ce lien explicite en lien implicite. Pour procéder à l’injection des dépendances, le conteneur léger initialise directement les objets(à partir d’un référentiel), libérant ainsi l’application de cette charge. Au lieu d’utiliser l’opérateur new, le conteneur léger injecte dans l’application les instances dont elle a besoin, comme l’illustre [Figure 19 : Injection de dépendances]. Pour effectuer cette initialisation, le conteneur peut implémenter deux méthodes : l’injection de dépendances via le constructeur ou l’injection de dépendances via les modificateurs.

Design pattern DAO

Les DAO (Data Access Object), ou objets d’accès aux données, ont la tâche de créer, récupérer, mettre à jour et effacer des objets Java, d’où l’expression associée pattern CRUD (Create, Retrieve, Update, Delete). Cesont des classes utilitaires qui gèrent la persistance des objets métier. Nous séparons ainsi les données stockées dans des Java Beans, et le traitement de ces données. Un DAO est un objet threadsafe, c’est-à-dire qu’il est accessible en simultané par plusieurs threads. À l’inverse d’un Java Bean, qui contient des données spécifiques de l’action en cours, un DAO ne fait que du traitement. Il peut, par conséquent, être commun à plusieurs actions parallèles. Pour cette raison, les DAO peuvent être implémentés comme des singletons, avec une seule instance partagée par l’ensemble des objets de l’application.

Design pattern DTO

Dans la conception d’applications distribuées, et pour satisfaire une seule requête client, on se trouve souvent obligé d’émettre un nombre important d’appels vers une interface distante, ce qui accroît le temps de réponse au-delà de l’acceptable. L’objet de transfert de données, Data Transfer Object (DTO), dit aussi Value Object, est un modèle de conception qui tente de résoudre la problématique suivante : préserver la simplicité de la sémantique d’une interface d’appel de procédure sans être soumis aux problèmes de latence inhérents à la communication distante [6]. La solution consiste à créer un DTO qui contient toutes les données nécessaires à l’appel, et modifier la signature de la méthode distante pour qu’elle accepte le DTO en tant que paramètre unique et pour qu’elle renvoie un paramètre DTO unique au client. La meilleure solution est d’utiliser le modèle Assembler, dit aussi Data Transformer, qui crée des DTO à partir d’objets métier et vice versa.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1 : CONTEXTE GENERAL DU PROJET
1.PRESENTATION DE L’ORGANISME D’ACCUEIL
1.1. DAMCO
1.2. Chiffres clés
1.2.1. Chiffre d’affaires global
1.2.2. Chiffre d’affaires Distribution
2.PRESENTATION DU SUJET
2.1. Problématique
2.2. Solution
3.CONDUITE DU PROJET
3.1. Processus de développement
3.2. Planification
CHAPITRE 2 : ANALYSE FONCTIONNELLE
1.METHODE DE DEVELOPPEMENT (2TUP)
1.1. Branche fonctionnel
1.2. Branche technique
1.3. Branche conception et réalisation
2.CAPTURE DES BESOINS FONCTIONNELS
2.1. Différents acteurs
2.2. Exigences fonctionnelles
2.2.1. Module Décision
2.2.2. Module Administration
3.ANALYSE DES SPECIFICATIONS FONCTIONNELLES
3.1. Diagrammes de cas d’utilisation
3.1.1. Utilisateur
3.1.1.1. Gestion des bons de livraison
3.1.1.2. Gestion des voyages des camions
3.1.2. Administrateur
3.1.3. Super Administrateur
CHAPITRE 3 : ANALYSE TECHNIQUE
1.RECENSEMENT DES BESOINS TECHNIQUES
2.ARCHITECTURE PHYSIQUE
3.SPECIFICATIONS LOGICIELLES
3.1. Modèle Vue Contrôleur
3.2. Conteneur léger
3.2.1. Inversion de contrôle
3.2.2. Injection de dépendances
3.3. Design pattern DAO
3.4. Design pattern DTO
3.5. Architecture logique
3.5.1. Architecture logique générale
3.5.2. Architecture applicative
CHAPITRE 4 : CONCEPTION
1.DIAGRAMME DE CLASSES
1.1. Module Administration
1.2. Module décision
1.3. Module Bon de livraison
1.4. Digramme de classe globale
2.DIAGRAMME D’ACTIVITE
2.1. Processus d’un bon de livraison
2.2. Processus d’ajout d’un voyage
CHAPITRE 5 : MISE EN OEUVRE
1.OUTILS DE DEVELOPPEMENT
1.1. Serveur d’application
1.1.1. Serveur Apache Tomcat
1.1.2. Serveur MySQL
1.2. Framework de développement
1.2.1. La plateforme JEE
1.2.2. Spring Framework
1.2.3. Spring Data
1.2.4. Spring Security
1.2.5. Spring MVC
1.2.6. Framework de persistance : Hibernate/JPA
1.2.7. JSR303 (Bean Validation)
1.3. Environnement de développement
1.3.1. IntelliJ IDEA
1.3.2. Maven
1.3.3. Git/Bitbucket
2.REALISATION DE LA PLATE-FORME
2.1. Structure du projet
2.2. Optimisation des performances
3.INTERFACES GRAPHIQUES
3.1. Formulaire d’authentification
3.2. Le gestion des comptes
3.3. Les types de camion
3.4. Les villes
CONCLUSION GENERALE
ANNEXE