Conception Et Réalisation D'une Application Web de Gestion Des Achats E-Purchasing Basée Sur L'architecture JEE
Conception Et Réalisation D'une Application Web de Gestion Des Achats E-Purchasing Basée Sur L'architecture JEE
Conception Et Réalisation D'une Application Web de Gestion Des Achats E-Purchasing Basée Sur L'architecture JEE
No Réf :……………
Centre Universitaire
Abd Elhafid Boussouf Mila
Ainsi ,nous adressons nos vifs remerciements à Monsieur DJEMEL ET Ishak pour son
aide et ses précieux conseils.
Enfin, une pensée particulière à toute personne ayant de près ou de loin poussé à donner
le coup de rein final pour boucler ce mémoire et tourner cette page de notre vie…
Pour tout l'amour d’ont vous m'avez entouré, pour tout ce que vous avez fait
pour moi.
Je ferai de mon mieux pour rester un sujet de fierté à vos yeux avec
Que ce modeste travail, soit l'exaucement de vos veux tant formulés et de Vos
prier quotidiennes.
Vous occupez une place particulière dans mon cœur. Je vous dédie ce
BOUANANE ZINA
Dédicace
A mes très chers parents «Atika & Khalil»
passés ensemble.
SEDRATI SAMIRA
Table de matières
Titre Page
Introduction générale 2
CHAPITRE I : GENERALITES
1. Introduction 5
2. Le processus 2TUP 5
2.1. Définition 5
2.2. Schéma général de processus 2TUP 5
3. Les applications web 6
3.1. Définition d’une application web 6
3.2. Pourquoi créer une application Web ? 6
4. java EE 7
4.1. Définition 7
4.2. Les couches de base d’une architecture java EE 8
4.3. La plate-forme java EE 8
4.3.1. Les composants Web 9
4.3.2. Les composants métiers 10
4.3.3. Les services d’infrastructures et de communication 10
4.4. Les conteneurs 11
4.5. Modèle MVC pour java EE 11
4.5.1. Modèle MVC de type1 12
4.5.2. Modèle MVC de type2 13
4.6. Modèle DAO (Data Access Object) 14
5. Les Frameworks 15
5.1. Framework Spring 15
5.2. Framework Hibernate 16
6. Les avantages des applications java EE 17
7. Conclusion 17
CHAPITRE II : ETUDE PRELEMINAIRE
1. Introduction 19
2. Elaboration du cahier de charge 20
2.1. Présentation du projet 20
2.2. Grands choix techniques 20
2.3. Recueil des besoins fonctionnels 21
2.4. Recueil des besoins opérationnels 21
3. Description de contexte du système 21
3.1. Identification des acteurs 21
3.2. Identification des messages 23
3.3. Modélisation de contexte 24
4. Conclusion 26
CHAPITRE III: CAPTURE DES BESOINS FONCTIONNELS ET TECHNIQUE
1. Introduction 28
2. Capture des besoins fonctionnels 28
2.1. Déterminer les cas d’utilisations 29
2.2. Description détaillée des cas d’utilisation 33
2.2.1. Description textuelle des cas d’utilisation 33
2.2.2. Description graphique des cas d’utilisation 46
2.3. Identification des classes candidates 65
2.3.1. Définition 65
2.3.2. La liste des classes candidates 66
2.3.3. Responsabilités des classes 67
2.4. Diagramme de classes participantes 69
3. Capture des besoins techniques 80
PageI
3.1. Spécification techniques du point de vue matériel 81
3.2. Spécification d’architecture 82
3.2.1. Spécification d’organisation du modèle déploiement SGAE 83
3.3. Elaboration du modèle de spécification logicielle 83
3.3.1. Modèle de spécification logicielle 84
3.3.2. Description textuelle des cas d’utilisation technique 85
3.3.3. Organisation en couche du modèle de spécification 85
4. Conclusion 87
CHAPITRE IV : ANALYSE
1. Introduction 89
2. Découpage en catégorie 89
2.1. Répartition des classes candidates en catégories 90
2.2. Elaboration de diagramme de classe préliminaires pour chaque catégorie 91
2.3. Dépendance entre les catégories 92
3. Développement du modèle statique 92
3.1. Affiner les classes 93
3.2. Affiner les associations 93
3.3. Ajouter les attributs 93
3.4. Ajouter les opérations 93
3.5. Diagramme de classe détaillé pour chaque catégorie 94
4. Développement de modèle dynamique 95
4.1. Diagramme de séquence 95
5. Conclusion 110
CHAPITRE V : CONCEPTION
1. Introduction 112
2. Conception générique 112
2.1. Définition 112
2.2. Elaboration du modèle logique 113
2.2.1. Définition d’un Framework technique 113
2.2.2. Organisation des Frameworks techniques 113
3. Conception préliminaire 115
3.1. Définition 115
3.2. Développement du modèle de déploiement 115
4. Conception détaillé 116
4.1. Définition 116
4.1.1. Concevoir les attributs et les opérations 116
4.1.2. Le diagramme de classe 118
4.1.3. Concevoir les Associations 118
4.2. Les classes modifiées 121
4.3. Le Modèle de base de données 122
5. Conclusion 122
Chapitre VI : IMPLEMENTATION
1. Introduction 124
2. Langage de programmation et choix techniques 124
2.1. Java 124
2.2. Les API java EE 124
2.3. Les standards web 125
3. Outils et environnement de développement 126
4. Présentation de quelque interface de notre application 127
5. Conclusion 130
Conclusion générale 132
PageII
Liste des figures
CHAPITRE I : GENERALITES
Figure I-1 schhéma général de processus 2TUP 5
Figure I-2 L’architecture java EE 7
Figure I-3 Les composants de la plate-forme java EE 9
Figure I-4 le modèle MVC 12
Figure I-5 le modèle MVC I 13
Figure I-6 le modèle MVC II 14
Figure I-7 La couche DAO 14
CHAPITRE II : ETUDE PRELEMINAIRE
Figure II-1 La phase d'étude préliminaire 19
Figure II-2 Le résumé des activités et des produits de l'étude préliminaire 20
Figure II-3 Le diagramme de contexte dynamique du système SGAE 24
CHAPITRE III: CAPTURE DES BESOINS FONCTIONNELS ET TECHNIQUE
Figure III-1 L'étape de capture des besoins 28
Figure III-2 La démarche de capture des besoins fonctionnels 29
Figure III-3 Le diagramme de cas d’utilisation 32
Figure III-4 La démarche de capture des besoins techniques 81
Figure III-5 Configuration matérielle de système SGAE 82
Figure III-6 Architecture 3 tiers 83
Figure III-7 Modèle de spécification logicielle initial 84
Figure III-8 Organisation du modèle de spécification logicielle 86
CHAPITRE IV : L’ANALYSE
Figure IV-1 L’étape d’analyse 89
Figure IV-2 Découpage en catégories 90
Figure IV-3 Modèle structurel d’analyse 92
Figure IV-4 La démarche d’élaboration du modèle statique 92
Figure IV-5 La démarche d’élaboration du modèle dynamique 95
Figure IV-6 Les diagrammes de séquences du système SGAE 110
CHAPITRE V : CONCEPTION
Figure V-1 L’étape de la conception 112
Figure V-2 Organisation du modèle logique de SGAE 114
Figure V-3 Le modèle de déploiement du SGAE 115
Figure V-4 La conception des attributs et des opérations 117
Figure V-5 Le diagramme de classe 118
Figure V-6 La transformation des associations 120
Figure V-7 Les classes modifiées 121
CHAPITRE VI : IMPLEMENTATION
Figure VI-1 Fenêtre d’accueil 127
Figure VI-2 Fenêtre d’inscription 127
Figure VI-3 Fenêtre de panier 128
Figure VI-4 Fenêtre liste des commandes 128
Figure VI-5 Fenêtre d’authentification de l’administrateur 129
Figure VI-6 Fenêtre de gestion des articles 129
Figure VI-7 Fenêtre d’ajout d’un article 130
Figure VI-8 Fenêtre voir les statistiques 130
PageIII
Liste des tableaux
PageIV
Introduction
générale
INTRODUCTION GENERALE
Actuellement, le monde connaît une avance technologique considérable dans tous les
domaines, grâce à l'informatique qui s’est imposée d’une manière très impressionnante dans
les entreprises, cela est dû à son apport extraordinaire dans le développement du travail et le
domaine de la gestion des bases de données.
L'informatique est de plus en plus utilisée dans tous les domaines d'activité y compris
celui de la gestion des achats en ligne auquel nous rattacherons d'ailleurs notre étude du
master. L’achat en ligne est une solution informatique destinée à optimiser et à rationaliser les
fonctions d'achat, et cela pour des meilleurs services comme la gestion des commandes
d'achats et des fonctions administratives avancées aussi bien aux clients qu'aux vendeurs,
permettant ainsi d'améliorer l'efficacité des opérations et la réduction des coûts.
L’objectif de notre projet est la conception et la réalisation d'une application web pour
la gestion des achats en ligne, et en même temps l’adoption d’une architecture orientée
entreprise appelée JEE (Java Entreprise Edition).
Java EE est une architecture indépendante qui permet de développer, déployer et gérer
des applications d’entreprise multi tiers en ajoutant la possibilité de fournir une architecture
complète, stable, sécurisée et rapide. L’architecture JEE permet un découpage de
l’application et donc une séparation des rôles lors du développement, ainsi que la possibilité
de choisir les outils de développement et le ou les serveurs d'applications utilisés, afin de
permettre par la suite que le produit final puisse être évolutif et facilement maintenable.
Pour réaliser ce travail, nous allons utiliser le processus 2TUP basé sur la notation UML
comme méthode de conception. Pour l’implémentation, on utilise le langage JAVA. pour la
programmation Web (Jsp, Servlet, Java Beans, le modèle MVC 2), avec le SGBD MYSQL.
Page 2
INTRODUCTION GENERALE
cahier des charges. Après avoir identifié les acteurs qui interagiront avec le système, nous
développerons un premier modèle UML de niveau contexte, pour pouvoir établir précisément
les frontières fonctionnelles du système.
Le chapitre 03 : «Capture des besoins » Ce chapitre comporte deux étapes : la capture des
besoins fonctionnels et celle des besoins techniques. La phase de capture des besoins
fonctionnels formalise et détaille ce qui a été ébauché au cours de l’étude préliminaire, en
donnant une description textuelle et une autre graphique pour chaque cas d’utilisation. La
capture des besoins techniques couvre, par complémentarité avec celle des besoins
fonctionnels, toutes les contraintes qui ne traitent ni de la description du métier des
utilisateurs, ni de la description applicative.
Page 3
Chapitre I
Généralités
CHAPITRE I GENERALITES
1. Introduction
Dans le cadre de ce chapitre, nous allons définir quelques généralités portant sur les méthodes et les
techniques mettant en évidence la réalisation de notre projet. Nous allons commencer par présenter le
processus 2TUP (2 Track Unified Process) pour la modélisation unifiée UML (Unified Modeling
Language), définir les applications web et enfin nous allons présenter les principaux concepts de la
technologie java EE (Java Enterprise Edition).
2. Le processus 2TUP
2.1. Définition :
2TUP est un processus de développement logiciel qui implémente le processus unifié. Il propose un
cycle de développement en Y, qui dissocie les aspects techniques et les aspects fonctionnels. Il commence
par une étude préliminaire qui consiste essentiellement à identifier les acteurs qui vont interagir avec le
système à construire et les messages échangés entre les deux. Cette étape consiste aussi à modéliser le
contexte et de générer le cahier des charges. [W0]
Page 5
CHAPITRE I GENERALITES
utilisateurs veulent qu'ils soient pris en compte dans le système. Ces besoins sont capturés à
l’aide des diagrammes de cas d’utilisation.
Analyse : étude des besoins des utilisateurs et leur modélisation. On utilise essentiellement
les diagrammes de classes et le diagramme de séquence. [W01]
Branche technique (droite) :
Capture des besoins techniques : recensement des besoins à caractère technique non lié au
métier des utilisateurs. Ces besoins sont capturés à l’aide des diagrammes de composants et
de déploiement.
Conception générique : proposition de solution technique indépendante du métier. [W01]
Phase de réalisation :
Conception préliminaire : croisement de l'analyse et de l'architecture générique du système.
Conception détaillée : approfondissement de la conception (typage de données, détail des
algorithmes, etc.)
Codage et tests : création des bases de données, implémentation des programmes, dans des
environnements.
Recette : remise du système aux utilisateurs finaux. [W01]
Une application web est un logiciel hébergé sur un serveur, accessible depuis n’importe quel
navigateur web via un réseau informatique (internet, etc.) d’une façon de faciliter l’accomplissement d’une
tâche précise sur le Web.
L’accès est universel : à partir d’un navigateur web, tel que FireFox , Chrome, Internet Explorer.
Plus besoin donc d’assurer un développement et un déploiement sur de multiples systèmes
d’exploitation.
Il n'est plus nécessaire d'installer un logiciel sur chaque poste, ce qui diminue en grande partie les
frais de maintenance et élimine certaines incompatibilités.
Une application bien conçue peut être utilisée par différents types de terminaux (ordinateurs,
laptops, tablettes, smartphones, etc.).
Page 6
CHAPITRE I GENERALITES
Ces applications sont capables de gérer des données multimédias (textes, photos, vidéos, etc.).
Certaines parties de ces applications sont ouvertes aux clients et fournisseurs et facilitent ainsi les
échanges d'information entre les partenaires
Pour mettre à jour l'application, il suffit de modifier l'application sur le serveur et tous les postes
accèdent instantanément à la nouvelle version.
4. java EE
4.1. Définition :
Java EE est une norme élaborée par la société SUN plus particulièrement destinée aux applications
d’entreprise. Ces applications sont considérées dans une approche multi-niveau, basé sur des composants,
s’appuyant sur le langage JAVA.
La première version des spécifications de java EE fut publiée en 1999, la version 1.3 apparut en 2001,
puis la version 1.4 en 2003 et la version 1.5 (renommée Java EE 5) en 2007. Depuis septembre 2014, la
dernière version en cours est Java EE 8.
Java EE permet une grande flexibilité dans le choix de l'architecture de l'application en combinant les
différents composants. Les applications java EE possèdent une architecture où plusieurs composants
applicatifs interviennent, une telle application est organisée sous forme de plusieurs couches interconnectées
que l’on appelle « tiers ». L'architecture d'une application se découpe en au moins trois tiers. La partie
cliente, la partie métier et la partie de données.
Page 7
CHAPITRE I GENERALITES
Java EE est utilisé principalement dans le cadre du développement de grosses applications distribuées.
Ces applications sont développées dans une architecture de type client/serveur. L’application est structurée
en couches, chacune des couches correspondant à une fonctionnalité propre et étant implémentée sur l’un ou
l’autre des postes (client ou serveurs).
Ces services sont des extensions JAVA indépendants, permettant d’offrir en standard un certain
nombre de fonctionnalités. Sun fournit une implémentation minimale de ces API appelée java EE SDK
(J2EE Software Development Kit). Les différents services et/ou fonctionnalités associées à J2EE sont
classés comme suit :
Page 8
CHAPITRE I GENERALITES
Le serveur web d’une application java EE rend disponible la logique d’une application sur le web,
donc c’est le serveur web qui gère la communication avec les clients web et qui répond à leurs requêtes.
Les servlets :
La Servlet est écrit en langage Java, ce sont des programmes qui aident à la construction
d'application générant des pages Web dynamiques. Il conçut sous la forme d’une classe java et
utilise une API spécifique. Cependant, le développement doit toujours mixer le code Java et
HTML. De plus, la moindre modification oblige à recompiler la Servlet et à la recharger.
Les JSP viennent résoudre les problèmes de recompilation. Ici, c’est le code Java que l’on
incorpore dans la page HTML avec technique de Scripting. Le serveur compile
automatiquement la page en une Servlet et l’exécuter ensuite. Ces techniques limitent aussi la
réutilisation de code. Pour ce qui est du monde java, il a donc été proposé de faire collaborer
les servlets et les JSP dans les applications. Les Servlets sont utilisées par les développeurs
pour gérer les aspects programmation d’une application Web et JSP sont utilisées par les
infographistes pour effectuer l’affichage.
Page 9
CHAPITRE I GENERALITES
Les JavaBeans sont des composants écrits en Java(classe java) qui peuvent être employés
dans tous les tiers d’une application. Ils sont souvent considérés comme un complément des
servlets ou comme un composant des interfaces utilisateur. La spécification JavaBeans de Sun
Microsystems définit les composants du type JavaBeans comme des composants logiciels
réutilisables manipulables visuellement dans un outil de conception.
Les EJB sont des composants spéciaux, fonctionnant sur un serveur et utilisés pour construire
la logique applicative et permet d’accéder aux données des applications java EE.Ils possèdent
certaines caractéristiques comme la réutilisabilité, la possibilité de s'assembler pour construire
une application, etc.
Services d’infrastructure :
JDBC : (Java Data Base Connectivity), permet l’ accès aux bases de données.JDBC est
une API d’accès aux systèmes de gestion de bases de données relationnelles qui permet
d’exécuter des requêtes au sein d’un programme Java et de récupérer les résultats, ce qui
représente une alternative aux solutions propriétaires. C’est de plus une tentative de
standardiser l’accès aux bases de données car L’API est indépendant du SGBD choisi.
JTA/JTS : (Java Transaction API/ Java Transaction), est un API définissant des
interfaces standard avec un gestionnaire de transactions.
JCA : (java EE Connector Architecture), est un API de connexion au système
d'information de l'entreprise.
JMX :(Java Management Extension), fournit des extensions permettant de développer
des applications web de supervision d'application.
JNDI : (Java Naming and Directory Interface), API d’accès aux annuaires d’entreprises
Page 10
CHAPITRE I GENERALITES
Services de communication :
RMI : (Remote Méthode Invocation), qui permet la communication entre objets distants.
JavaMail : permettant l’envoi de courrier électronique.
JMS :(Java Message Service), fournit des fonctionnalités de communication asynchrone
(appelées MOM pour Middleware Object Message) entre applications. [W03]
Les conteneurs assurent la gestion du cycle de vie des composants qui s'exécutent entre eux, et
fournissent des services qui peuvent être utilisés par les applications lors de leur exécution.
Il existe plusieurs conteneurs définis par java EE:
conteneur web : pour exécuter les servlets et les JSP
conteneur client : pour exécuter des applications sur les postes qui utilisent des composants java EE.
Les serveurs d'applications peuvent fournir un conteneur web uniquement (exemple : Tomcat) ou un
conteneur d'EJB uniquement (exemple : JBoss, Jonas, etc.) ou les deux (exemple : Websphère, Weblogic,
etc.).[W04]
Le modèle : représente les données et les règles métiers. C'est dans ce composant que
s'effectuent les traitements liés au cœur du métier. Les données peuvent être liées à une base
de données. [W5]
La vue : correspond à l'IHM. Elle présente les données et interagit avec l'utilisateur. Dans le
Page 11
CHAPITRE I GENERALITES
cadre des applications Web, il s'agit d'une interface HTML/JSP, mais n'importe quel
composant graphique peut jouer ce rôle. [W5]
Le contrôleur : fait le lien entre la vue et le modèle et gère les interactions avec l’utilisateur il
va utiliser les données du modèle, les traiter en fonction de l’action de l’utilisateur, et les
envoyer à la vue afin qu’elle les affiche. .
Il est important de noter que les données sont indépendantes de la présentation. En d'autres termes, le
modèle ne réalise aucune mise en forme. Ces données pourront être affichées par plusieurs vues. De ce fait
le code du modèle est factorisé : il est écrit une seule et unique fois puis réutilisé par chaque vue. [W5]
Page 12
CHAPITRE I GENERALITES
Dans l'organisation logicielle MVC2, le Servlet est unique, en classe et en instance. Il garantit l'unicité
du point d'entrée de l'application. Il prend en charge une partie du contrôle de l'application.
Les contrôleurs MVC se retrouvent alors partiellement déportés dans l'entité « dynamique de
l'application » qui assure le contrôle du dynamisme de l'application et qui gère les relations entre les
objets métier et la présentation. Les contrôleurs deviennent essentiellement des contrôleurs du dialogue
entre l'utilisateur et les objets métiers. [W5]
Pour cela des Framework ont été développés, qui sont composés d’une seule Servlet. Les Framework
les plus connus, sont : (Struts, Spring, etc.).
Page 13
CHAPITRE I GENERALITES
Le modèle MCV II hérite des propriétés du modèle MVC. Son organisation cependant capitalise sur la
longue expérience acquise avec MVC et s'adapte au contexte des applications internet et de la plate-forme
J2EE.
Page 14
CHAPITRE I GENERALITES
5. Les Frameworks
Les frameworks sont des structures logicielles qui définissent des cadres dans lesquels viennent
s'insérer les objets et concepts spécifiques à une application. En pratique, un framework (traduction littérale:
squelette d'application) est un ensemble de classes et de mécanismes associés à une architecture logicielle
qui fournit un ou plusieurs services techniques ou métiers aux applications pour facilitant la création de tout
ou d'une partie d'un système logiciel. [W8]
Les principaux avantages de ces frameworks sont la réutilisation de leur code, la standardisation du
cycle de vie du logiciel (Spécification, développement, maintenance, évolution), ils permettent de formaliser
une architecture adaptée aux besoins de l'entreprise. Ils tirent parti de l'expérience des développements
antérieurs. Pour cela plusieurs Frameworks ont été développés comme : (Struts, Spring, Hibernate, etc.).
Pour notre projet on s’intéresse au Framework Spring et Hibernate.
Un conteneur léger implémentant le design pattern IoC (Injection of Control) pour la gestion des
objets et de leur dépendance en offrant des fonctionnalités avancées concernant la configuration et
l'injection automatique. Un de ces points forts est d'être non intrusif dans le code de l'application tout
en permettant l'assemblage d'objets faiblement couplés.
Une gestion des transactions par déclaration offrant une abstraction du gestionnaire de transactions
sous-jacentes.
Faciliter le développement des DAO de la couche de persistance en utilisant JDBC (Java Data Base
Connectivity), JPA(Java Percistence Api), ou une solution open source comme (Hibernate).
Page 15
CHAPITRE I GENERALITES
Une application typique utilisant Spring est généralement structurée en trois couches :
Il est très largement utilisé dans le monde Java, ce qui en fait un standard de facto et constitue
une certaine garantie sur la pérennité du framework.
Spring propose une très bonne intégration avec des frameworks open source (Struts, Hibernate,
etc.) ou des standards de Java (Servlets, JMS (Java Messaging Service)).
Toutes les fonctionnalités de Spring peuvent s'utiliser dans un serveur Java EE et pour la
plupart dans un simple conteneur web ou une application autonome.
Les fonctionnalités offertes par Spring sont très nombreuses et les sujets couverts ne cessent
pas d'augmenter au fur et mesure des nouvelles versions et des nouveaux projets ajoutés au
portfolio.
La documentation de Spring est complète et régulièrement mise à jour lors de la diffusion de
chaque nouvelle version. [W9]
Spring et JAVA EE :
Spring est né de l'idée de fournir une solution plus simple et plus légère que celle proposée par Java 2
EE. C'est pour cette raison que Spring a été initialement désigné comme un conteneur léger.L'idée
principale de Spring est de proposer un framework qui utilise une solution simple pour développer des
applications plutôt que d'utiliser des EJB complexes dans un conteneur. [W9]
Hibernate est une solution open source du type ORM (Object RelationalMapping) qui permet de
faciliter le développement de la couche persistance d'une application. Hibernate permet donc de
représenter une base de données en objets Java et vice versa.
Page 16
CHAPITRE I GENERALITES
Hibernate facilite la persistance et la recherche de données dans une base de données en réalisant lui-
même la création des objets et les traitements de remplissage de ceux-ci en accédant à la base de données.
La quantité de code ainsi épargnée est très importante d'autant que ce code est généralement fastidieux et
redondant, il est très populaire notamment à cause de ses bonnes performances et de son ouverture à de
nombreuses bases de données. (Oracle, MySQL).[W9]
Le fonctionnement d’Hibernate :
une classe de type javabean qui encapsule les données d'une occurrence d'une table.
un fichier de configuration qui assure la correspondance entre la classe et la table (mapping).
des propriétés de configuration notamment des informations concernant la connexion à la base de
données
Une fois ces éléments correctement définis, il est possible d'utiliser Hibernate dans le code des
traitements à réaliser. [W9]
7. Conclusion
Dans ce chapitre, nous avons introduit le processus 2TUP qui sera la base des chapitres suivants, nous
avons rappelé la notion des applications web avec ses avantages, et enfin nous avons également présenté la
technologie java EE qui est une bonne solution pour les applications d’entreprise.
Page 17
Chapitre II
Etude
Préliminaire
CHAPITRE II ETUDE PRELIMINAIRE
1. Introduction
Dans ce chapitre nous allons déterminer la phase d’étude préliminaire qui permet de recueillir les
informations initiales sur le système. Il s’agit dans cette phase de définir le contour du système, les différents
acteurs, ainsi que les messages d’interaction avec le système.
L’étude préliminaire est la toute première étape du processus 2TUP. Elle consiste à effectuer un
premier repérage des besoins fonctionnels et opérationnels, en utilisant principalement le texte, ou
diagrammes très simples. Elle prépare les activités plus formelles de capture des besoins fonctionnels et de
capture techniques.
Nous sommes
ici
Etude
préliminaire
Page 19
CHAPITRE II ETUDE PRELIMINAIRE
La figure suivante illustre le résumé des activités et les produits de l’étude préliminaire :
Page 20
CHAPITRE II ETUDE PRELIMINAIRE
Notre projet concentre sur la réalisation d’une application web pour les achats en ligne utilisant
l’architecture Java EE, pour garanti les fonctions suivantes.
La disponibilité des services : Les services et les informations doivent être accessibles aux
personnes autorisées quand elles en ont besoin.
Page 21
CHAPITRE II ETUDE PRELIMINAIRE
matériels ou autre système) qui interagit directement avec le système étudié. [Roques07]
En réponse à l'action d'un acteur, le système fournit un service qui correspond à son besoin. Les
acteurs du système sont :
Visiteur: est une personne qui est entrain de fouiller internet, cherchant un produit ou un service
pour l’acheter ou pour avoir une idée sur les catalogues et les prix, et même pour créer un compte
sur le site.
Client : un visiteur ayant déjà créé un compte sur le site, il a le droit de suivre le processus d’achat
taches concernant les articles, les clients, les commandes, et la gestion de payement et de livraison.
Le client
S’authentifier
Consulter le catalogue
Rechercher un article
Gérer le panier
Passer la commande
Régler la facture
Gérer le profil
L’administrateur
S’authentifier
Gérer articles pour chaque catalogue
Gérer les comptes
Voir les statistiques
Page 22
CHAPITRE II ETUDE PRELIMINAIRE
Un message représente la spécification d'une communication unidirectionnelle entre les objets qui
transportent de l'information avec l'intention de déclencher une activité chez le récepteur. Cette notion de
message est également tout à fait applicable pour décrire les interactions de plus haut niveau entre les
acteurs et le système.[Roques07]
Pour les acteurs, demandez-vous quels sont les messages qui déclenchent un comportement du
système attendu par l'acteur dans le cadre de son activité. Pour le système, demandez-vous quels sont les
messages émis à l'intention d'un acteur particulier, et qui portent une information utilisée par ce
destinataire.[Roques07]
Le formulaire d’inscription.
Le formulaire d’authentification.
Le compte client.
La facture.
Page 23
CHAPITRE II ETUDE PRELIMINAIRE
Les messages entre le système et les acteurs identifiés précédemment peuvent être représentés de
façon synthétique sur un diagramme, que l'on peut qualifier de diagramme de contexte dynamique en
utilisant un diagramme de communication de la manière suivante: [Roques07]
:A dm i nistr ate u r
1
2
S GA E
4
5
3 6
:V isit eu r :C lie nt
1: Administrateur ► SGAE
Page 24
CHAPITRE II ETUDE PRELIMINAIRE
2: SGAE ► Administrateur
3: Visiteur ► SGAE
Le formulaire d’authentification.
Liste des articles (catalogue).
Les informations concernant l’état du panier.
5: Client ► SGAE
6: SGAE ► Client
Page 25
CHAPITRE II ETUDE PRELIMINAIRE
Nous remarquons que les deux acteurs Client et Visiteur partagent trois cas d’utilisation : ils sont
également acteurs de « Consulter le catalogue », « Rechercher un article », et « Gérer le panier ».UML nous
fournit la solution en permettant de créer un acteur généralisé « Internaute », dont Client et Visiteur seront
des spécialisations.
Nous allons également prendre en compte le système externe de « Paiement sécurisé », nécessaire au
moment du paiement en ligne.
4. Conclusion
Dans ce chapitre, nous avons déterminé les besoins fonctionnels en concéderont le système comme
une boite noire et les besoins opérationnels (techniques), afin d’étudier sa place dans le système métier plus
global de l’entreprise, Nous avons développé un modèle UML de niveau contexte, pour pouvoir établir
précisément les frontières fonctionnelles du système.
Tout ça prépare le terrain pour entamer la conception de notre projet par l’étape de capture des besoins
fonctionnels et de capture des besoins techniques dans le chapitre suivant.
Page 26
Chapitre III
Capture des
besoins
fonctionnels et
techniques
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
1. Introduction
Ce chapitre vient pour compléter l’étude fonctionnelle et technique ébauchée durant l’étude
préliminaire dans le chapitre précédent. L’objectif de la capture des besoins consiste à déterminer ce que le
système doit faire, c.à.d. le « quoi» à fourni aux développeurs une meilleure compréhension des
fonctionnalités du système qu’ils doivent développer, elle comporte deux étapes : la capture des besoins
fonctionnels et la capture des besoins techniques.
Nous sommes
ici
Page 28
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Diagramme de cas
d’utilisation
Cahier des charges
Fiches de description
1. Identifier les
cas d’utilisation
Diagrammes
Package de 2. Décrire les dynamiques
spécification cas d’utilisation
fonctionnelle
3.Organiser les
cas d’utilisation
5. Valider et consolider
Diagrammes de
cas d’utilisation
Traçabilité raffinés
Page 29
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Consulter le catalogue.
Rechercher un article.
Gérer le panier.
Créer un compte.
Gérer le profil.
Passer la commande.
Consulter la facture.
Régler la facture.
S’authentifier.
Gérer les articles pour chaque catégorie.
Gérer comptes.
Voir les statistiques.
En premier lieu, nous donne un aperçu des fonctionnalités futures que doit implémenter le
système. Cependant, il nous faut plusieurs itérations pour ainsi arriver à constituer des cas
d’utilisation complets. D’autres cas d’utilisation vont apparaître au fur et à mesure de la description
de ceux-là, et l’avancement dans le recueil des besoins fonctionnels.
Pour constituer les cas d’utilisation, il faut considérer l'intention fonctionnelle de l'acteur par
rapport au système dans le cadre de l'émission ou de la réception de chaque message. En regroupant
les intentions fonctionnelles en unités cohérentes, on obtient les cas d'utilisation.
Page 30
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Gérer les articles pour chaque Administrateur Emet: Les informations de MAJ d’un article.
catégorie
Reçoit: La nouvelle liste des articles.
Tableau III-2 : La liste des acteurs et des messages par cas d'utilisation du système SGAE
Page 31
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
site d'achat
Consulter le catalogue
Rechercher un article
«extend»
Internaute
Gérer le panier
Créer un compte
«include»
Visiteur Passer la commande
Client
«include»
Consulter la facture S'authentifier
«i nclude»
Gérer le profil
«extend»
«acteur»
Régler la facture systeme de paiement
«include»
Gérer les comptes
«incl ude»
Administrateur Gérer les articles pour chaque catégorie
«i nclude»
Voir les statistiques
Page 32
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Une description détaillée : des prés conditions au déclenchement du cas d’utilisation doivent être
spécifiées, un scénario nominal décrivant celui-ci additionné à des scénarios alternatifs et
d’exceptions.
Les diagrammes : plusieurs diagrammes vont apparaitre pour apporter une compréhension
additive au cas d’utilisation.
Sommaire d’identification
Acteur Visiteur/Client
Description
Pré condition /
Page 33
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Arrêt Ce cas d’utilisation est terminé lorsque la consultation est terminée ou annulée.
Post condition /
Sommaire d’identification
Acteur Visiteur/Client
Description
Enchaînements
Enchaînement(a) : rechercher un article.
- L’acteur demande une recherche simple ou multicritère.
- Le système affiche le formulaire de recherche.
- L’acteur saisit les données nécessaires.
Enchaînement(b) : Valider les informations saisies
- L’acteur valide les informations saisies.
- Le système vérifie la validité des informations.
S’il y a des erreurs, déclenche [Exception1].
Exception1 Un message d’erreur est afficher sur l’écran avise l’acteur que les informations
saisies non valide (article non disponible).
Page 34
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Sommaire d’identification
Acteur Visiteur/Client
Description
Pré condition /
Exception1 - Un message d’erreur est afficher sur l’écran avise le client (Votre
panier est vide) .
Arrêt Ce cas d’utilisation est terminé lorsque la mise à jour est terminée.
Page 35
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Sommaire d’identification
Acteur Visiteur.
Description
Pré condition /
Sommaire d’identification
Page 36
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Acteur client
Description
Exception1 Un message d’erreur est affiché avise le client que les informations saisies non
valides (champ vide, informations erronées, etc.).
Arrêt Lorsque la modification est terminée ou annulée.
Sommaire d’identification
Acteur client
Description
Page 37
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Exception1 Un message d’erreur est affiché avise le client que les informations saisies non
valides (champ vide, informations erronées, etc.).
Arrêt Lorsque la commande est créée ou annulée.
Sommaire d’identification
Acteur client
Description
Page 38
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Post condition /
Sommaire d’identification
Description
Page 39
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Exception1 Un message d’erreur est affiché avise le client le système de paiement détecte que
les informations sur la carte sont incomplètes ou erronées
Sommaire d’identification
Titre S’authentifier.
But Permet de saisir les informations (login, mot de passe) des compte clients ou
administrateurs du site.
Description
Page 40
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Post condition /
Sommaire d’identification
Acteur administrateur
Description
Page 41
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Sommaire d’identification
Acteur Administrateur
Description
Page 42
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Sommaire d’identification
Acteur Administrateur
Description
Page 43
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Sommaire d’identification
Acteur Administrateur
Description
Page 44
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Sommaire d’identification
Acteur Administrateur
Description
Exception1 Un message d’erreur est afficher sur l’écran avise l’administrateur que la liste des
compte est vide.
Post condition /.
Sommaire d’identification
But Permet de voir les différentes statistiques qui concernent les commandes (les
achats).
Page 45
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Acteur administrateur
Description
Post condition /.
Tableau III -3: Description textuelle des cas d'utilisation fonctionnels du système SGAE
La description textuelle des cas d’utilisation est indispensable, car elle seule permet de
communiquer facilement et précisément avec les utilisateurs. En revanche, le texte présent des
désavantages puisque il est difficile de montrer comment les enchainements se succèdent, il est donc
recommander de compléter la description textuelle par un ou plusieurs diagrammes d’UML (diagramme
d’activité, diagramme d’état transition, diagramme de séquence, et diagramme de collaboration).
Nous avons choisi le diagramme de séquence par ce qu’il est facilement compris, il représente les
interactions entre objets en précisant la chronologie des échanges des messages.
Page 46
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
: SGAE
: Internaute
demande de consulter le catalogue
: SGAE
: Internaute
demander une recherche simple ou multicritère.
verification
Page 47
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
:SGAE
: Internaute
demande l'accès au panier
afficher l'état de panier(Chaque article sélectionné est présenté sur une ligne)
mettre à jour son panier (modifier les quantités, ajouter ,retirer articles).
vérification
:SGAE
: visiteur
demander de créer un compte.
vérification
ALT
[ si une erreur] afficher un message d'erreur
Page 48
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
:S G A E
: C lie n t
REF
S 'a u the n tif ie r
d em a n d e de co n s u lt er s o n pr of il
af f i ch e r le p r o f il c lie nt
vé r if i ca ti o n
A LT
[s i u n e erreu r] a ff ic he r u n m es s a g e d 'er r e u r
[s in o n ] a f fic he r un m es s a g e d e c o nf ir m a ti on
:S G A E
: cl ie n t
RE F
S ' a u t h e n t if ie r
RE F
G é r e r le p a n ie r
d e m an d e d e p as s e r u n e c o m m an d e .
af f i ch e r le f o r m u l ai r e .
s a is ir le s in f o r m a tio n s n é c e s s a ir e s e t v a l i d er l a s a is ie .
v é r i f ic a t io n
[ s in o n ] af f i c h e r l a l is te d e s c o m m a n d e s
Page 49
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
: SGAE
: c lie nt
REF
Passer la comm ande
aff ic her la f acture ave c les dif fére nte s informations concer nant les a rtic les,
le s prix unita ir es e t le m ontant tota l.
: SG A E
: c lie nt
RE F
P asser la c o mm an d e
ch o isir u n e f acture .
d em an d er de v alid e r le p aiem en t
v ér if ica tio n
Page 50
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
:SGAE
: client / administrateur
demande de s'authentifier
verification
ALT
[si une erreur] afficher un message d'erreur
Page 51
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
: SGAE
: administrateur
REF s'authentifier
ALT
REF
ajouter
REF
modifier
REF
supprimer
MAJ enregistrée
Page 52
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
:SGAE
: administrateur
REF
s'authentifier
vérification
Page 53
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
:SGAE
: administrateur
REF
S'authentifier
vérification
Page 54
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
:SGAE
: administrateur
REF
S'authentifier
:SGAE
: administrateur
REF
Sauthentifier
Page 55
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
:SGAE
: administrateur
REF
Sauthentifier
sélectionner un choix.
Tableau III -4: Diagramme de séquence système des cas d'utilisation fonctionnels du système SGAE
Diagramme d’activité :
Pour documenter les cas d’utilisations, nous avons choisi le diagramme de d’activités, car il
permet de consolider les enchaînements de la fiche textuelle, comme nous l’avions représenté
informellement. Ce diagramme est également très utile en cas d’actions parallèles. De plus, les
utilisateurs le comprennent aisément, car il ressemble à un organigramme traditionnel. Il permet enfin
d’identifier d’un seul coup d’œil la famille des scénarios d’un cas d’utilisation qui décrivent toutes les
réactions du système. Il suffit en effet de dessiner les différents chemins du diagramme d’activité qui
passent par toutes les transitions entre actions.
Page 56
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
« page»
page d'accueil
d e m a n de u n e rec h erc h e
« pa g e »
la b ar e d e re ch ce rch e
s ais ir l es d o n n ée s n éc es s ai res .
i n co rre cte
c o rrec t e
« pa ge »
l a lis t e d es ar ti c le s rec h erc h ées
Page 57
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
d e m a nd e l ' ac c è s a u p a n i e r .
« p a ge »
l a p a g e d e p a n ie r
m e t t r e à j o u r l e p a n i e r ( m o di f i e r l e s q ua n ti t é s ,r et ir e r,
o u a j o u t er q ue l qu e s ar ti c l e s .)
« p a ge »
la p ag e d u p a n i er
« pa ge »
le for mulaire d'inscr iption
inc orrec te
c or recte
« pa ge »
un m essage "com pte c réer "
Page 58
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
s 'a u t h e n t if ie r
d e m a n d e de c o ns u l t e r le s i n fo r m a t io n s de p ro f il .
« p a ge »
l a p a g e p ro f i l
m o d i f i e r le s i n f o r m a t io n s .
in co rr ect e
c or r e c te
« p a ge »
la p a g e p ro f i l
s ' a u t h e n t if ie r
d e m a nd e d e p a s s e r u n e c o m m a n d e .
« p a ge »
l e fo rm ul a ir e d 'u n e c o m m a n d e
s a i s i r e t v a l i de r le s i n fo rm at io n s n é c e s s ai re s
i n c o rre c t e
c or rec te
« p a ge »
l a li s t e d e s c o m m a n d e s
Page 59
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
s'authentifier
« page »
la listes des factures existes
« page »
la facture avec les différentes informations concernant les articles,
les prix unitaires et le montant total.
Page 60
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
s'authentifier
« page »
la liste des factures
incorrecte
correcte
« page »
un message "facture est réglée "
Page 61
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
d em an d er de s'a u th e n tifier
« p ag e»
la p ag e d 'a u th e n tifica tion .
inc or rec te
c o rre cte
« p ag e»
la p ag e v o u lu
s 'au t h en tif ie r
« pa ge »
le fo r mu lai re d 'aj o ut
in c or rec te
c or rec te
« pa ge »
la l is t e d es a rt ic le s
Page 62
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
s 'au th en t if ie r
d e ma n d er d e mo d ifi er u n a rtic le
« pa g e»
la li stes d es a rtic le s
sel ec tio n n er u n a rt ic le p o ur le m o d if ie r
« p a ge »
le fo rm u la ir e d e m o dific atio n
in c or rec te
c or rec te
« p a ge »
l a liste d es ar tic le s
Page 63
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
s ' a u t h e n t if ie r
de m a n d e r de s u p p ri m e r u n a rt i c l e .
« p a ge »
l a l is t e d e s a r ti c le s.
c h o i s i r u n a r t i c l e p o u r l e s u p p r im e r .
« p a ge »
l a l is t e d e s a r ti c le s
s'au th en tif ie r
de ma n d er au s y s tèm e d e g ér er l es c o mp t es .
« p a ge »
l a li s te d e s co m pte s.
sél ec tio n n er u n co m p t e p o u r le c o ns u lt er o u b i en le b lo q u er
« p a ge »
la no u v e ll e li st e d es c o mp t es
Page 64
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
s'authentifier
« page »
les critères des choix.
sélectionner un choix.
« page »
la liste des statistiques.
Tableau III -5: Diagramme d’activité des cas d'utilisation fonctionnels du système SGAE
Cette phase va préparer la modélisation orientée objet en aidant à trouver les classes principales du
futur modèle statique d’analyse. La technique utilisée pour identifier les classes candidates est la suivante :
Chercher les noms communs importants dans les descriptions textuelles des cas d’utilisation.
Vérifier les propriétés « objet » de chaque concept (identité, propriétés, comportement), puis
définir ses responsabilités.
2.3.1. Définition :
Une responsabilité est une sorte de contrat, ou obligation, pour une classe. Elle se place à un
Page 65
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
niveau d’abstraction plus élevé que les attributs ou les opérations. On formalise ensuite ces concepts
métier sous forme de classes et d’associations rassemblées dans un diagramme statique pour chaque cas
d’utilisation.
Ces diagrammes préliminaires sont appelés « diagrammes des classes participantes », n’ont pas
pour objectif d’être complet. Ils servent uniquement à démarrer la découverte des classes du modèle
d’analyse. [Roques07]
Catalogue
Catégorie
Article
Panier
Commande
Facture
Client
Administrateur
Role
LigneCommande
Page 66
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
La classe : Catalogue
Catalogue Responsabilités :
- Connaitre ses catégories (liste des catégories).
- Gérer la liste des catégories.
La classe : Catégorie
Catégorie Responsabilités :
- Connaitre ses articles (liste des articles).
- Gérer la liste des articles.
La classe : Article
Article Responsabilités :
- Connaitre ses informations (code, nom, prix).
- Gérer articles(ajouter, supprimer, modifier un article).
- Rechercher un article.
La classe : Panier
Panier Responsabilités :
- Connaitre ses informations (articles sélectionnées).
- Mettre à jour le panier (leur contenu).
Page 67
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
La classe : Commande
Commande Responsabilités :
- Passer une commande.
- Connaitre ses informations (numéro commande, date…).
- Connaitre l’état d’une commande.
La classe : Facture
Facture Responsabilités :
- Connaitre ses informations (montant total).
- Régler la facture.
La classe : Client
Client Responsabilités :
- Connaitre ses informations (login, motpass, nom, prénom
…).
- Gérer le profil
La classe : Administrateur
Administrateur Responsabilités :
- Connaitre ses informations (login, motpass, nom, prénom
…).
Page 68
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
La classe : Role
Role Responsabilités :
- Connaitre ses informations (rôle client, rôle
administrateur)
La classe : LigneCommande
LigneCommande Responsabilités :
- Connaitre ses informations (code, la quantité)
Consulter catalogue
« dialogue» « controle»
Ecran d'accueil consulter catalogue « entité»
Catalogue
codeCtategorie:int
nomCategorie:string
Consulter()
Internaute Annuler()
Page 69
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Interna ute
« dialogue »
E cra n re cher cher ar ticle
m otC lé:string
R eche rcher ()
Annuler()
R ec herche r ( )
A nnuler ()
« entité»
Article
c odeArticle:int
de signationArtic le :string
de sc riptionA rticle:str ing
pr ix:double
qua ntiteStock:int
photo:string
e ta t :str ing
da te :date
Page 70
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Gérer le panier
internaute
« dialogue»
Ecran gérer le panier
Ajouter()
Retirer ()
Modifier()
« controle»
« dialogue» « dialogue»
gérer le panier
Ecran message d'errreur Ecran message de
confirmation
Ajouter()
Retirer ()
Modifier()
Verifier()
« entité»
Panier
codePanier:int
montantTotal:double
nbrArticles:int
Page 71
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Créer un compte
Client
« dialogue»
Ecran formulaire d'inscription
login:string
motPass:string
nomClient :string
prenomClient :string
adressClient :string
emailClient :string
telClient :string
n_cartebancaire : int
Inscrir ()
Annuler ()
Inscrir ()
Annuler ()
« entité»
Client
codeClient:int
login:string
motPass:string
nomClient :string
prenomClient :string
adressClient :string
emailClient :string
telClient :string
n_cartebancaire : int
Page 72
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
« entité»
Administrateur
codeAdmin:int
login :string
motpass :string
nomClient :string
prenomAdmin :string
adressAdmin :string
emailAdmin:string
telAdmin:string
P a s ser co m m a nde
C ie n t
« d i alo g u e»
E c ran p as s er co m m an d e
P a s s er ( )
A nn u l e r ()
« d i a l o g ue » « c o n t ro le » « d ia lo g u e »
E c r a n m e s s a g e d ' e rr e u r p a s se r c o m m a n d e E c ran m es s ag e d e
c o n f ir m a t i o n
P a s s er ( )
A n nu l er ()
« e n t it é »
C o m m an d e
c o d e C o m m an d e : i n t
e t a tC o m m a nd e : s t r in g
d a teC o m m an d e :d a te
m on t an tT o tal e : in t
Page 73
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Consulter la facture
Client
« dialogue»
Ecran Consulter la facture
« dialogue» « dialogue»
« controle» Ecran message de
Ecran message d'erreur
Consulter la facture confirmation
consulter()
« entité»
Facture
codeFacture :int
Page 74
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Régler la facture
Client
« dialogue»
Ecran régler facture
« dialogue» « dialogue»
« controle» Ecran message de
Ecran message d'erreur régler facture confirmation
Régler()
« entité»
Facture
codeFacture :int
Page 75
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Ajouter un article
Administrateur
« dialogue»
Ecran ajouter un article
designationArt:string
descriptionArt:string
pri x:double
qantiteStok:int
photo:string
etat : int
date: date
« controle»
ajouter un article
« dialogue» « dialogue»
Ecran message d'erreur Ecran message de
confirmation
Ajouter ()
Annuler ()
« entité» « entité»
Article Catégorie
codeArticle:int codeCategorie:int
designationArt:string nomCategorie:string
descriptionArt:string
pri x:double
qantiteStok:int
photo:string
etat : string
date : date
1
1..*
Page 76
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Administrateur
« dialogue»
Ecran modifier un article
designationArt:string
descriptionArt:string
pri x:double
qantiteStok:int
photo:string
etat : string
date : date
Modifier()
Annuler ()
« controle» « dialogue»
« dialogue»
modifier un article Ecran message de
Ecran message d'erreur
confirmation
Modifier()
Annuler ()
« entité» « entité»
Article Catégorie
codeArticle:int codeCategorie:long
designationArt:string nomCategorie: string
descriptionArt:string
pri x:double
qantiteStok:int
photo:string
etat : string
date : date
1
1..*
Page 77
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Supprimer un article
« dialogue»
Ecran supprimer un article
« controle»
codeArticle : int supprimer un article « dialogue»
designationArticle: string Ecrans message de
descriptionArticle: string confirmation
pri x:double
qantiteStok:int
photo:string Supprimer ()
Administrateur etat : string Annuler ()
date : date
Supprimer ()
Annuler ()
« entité»
Article
codeArticle : int
designationArticle: string
descriptionArticle: string
pri x:double
qantiteStok:int
photo:string
etat : string
date : date
Page 78
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Client
« dialogue» « entité»
Ecran gérer le profil Client
« dialogue»
Ecran message d'erreur codeClient:i nt
codeCl ient:i nt logi n: stri ng
logi n: stri ng mot Pass: stri ng
mot Pass: stri ng nomClient :string
nomCl ient : stri ng prenomClient :string
prenomClient : string adressClient :string
adressClient :string emailClient :string
emailClient :string telClient :s tring
telClient :s tring n_cartebancaire : int
n_cartebancaire : int
Gérer()
« controle»
gérer le profil
Gérer()
annuler()
« dialogue»
Ecran message de
confirmation
Page 79
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Administrateur
« dialogue»
Ecran voir les statistique
« controle»
voir les statistique
Consulter()
Annuler ()
1 0..*
concerne
Tableau III -7: Les diagrammes de classes participantes pour tous les cas d'utilisations
Page 80
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Logiciel: sert à exprimer les différentes parties du système par des composants d’exploitation et
leurs organisations par des modèles de spécification logicielle.
Pour la réalisation de cette étape nous allons suivre le processus suivant :
Spécification techniques du point de vue matériel.
Spécification d’architecture.
Élaboration du modèle de spécification logicielle.
Organisation en couches du modèle de spécification.
La démarche de capture des besoins techniques est illustrée dans la figure qui suit :
Configuration
Matérielle
Cahier des charges
Style d’architecture
en tiers
1. Capture des spécifications
techniques
3. Spécification
Logicielle détaillée
Page 81
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
techniques. [Roques07]
Le matériel à mettre dans un système dépend de :
Style d’architecture en niveaux: qui spécifie le nombre de niveaux géographiques et
organisationnels où vont se situer les environnements d’exécution du système. L’architecture
peut être à deux niveaux, à trois niveaux, ou multi niveaux dans une organisation plus complexe.
[Roques07]
Contraintes techniques: peuvent se manifester de différentes manières :
- La sécurité.
- La disponibilité
- La performance. [Roques07]
Page 82
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
L'application réalisée repose sur une architecture client/serveur de 3 tiers. L'architecture 3 tiers est
composée de trois niveaux :
1. Le client (navigateur web): le demandeur de ressources.
2. Le serveur d'applications (appelé aussi middleware "niveau intermédiaire"): il est chargé de
fournir la ressource mais faisant appel à un autre serveur.
3. Le serveur de données : fournissant les données au serveur d’applications.
Dans notre travail, notre choix porte sur « Mozilla Firefox » comme navigateur Web, un serveur
d’applications « Tomcat Appache» et le serveur de base de données « MySQL ».
C’est à cette étape que l’on va se référer aux cas d’utilisation techniques. Un cas d'utilisation
technique est un cas qui ne produit aucune valeur fonctionnelle (métier) mais fournit des services
techniques à l’exploitant, c.à.d. la personne qui utilise le cas. Des exemples de services techniques sont la
Page 83
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
L’exploitant: il s’agit d’un acteur au sens d’UML, qui bénéficie des services techniques du
système. L’utilisateur classique d’une application est dans ce sens un exploitant carin bénéfice
au moins du service de connexion à l’application.
Le cas d’utilisation technique : un cas d’utilisation technique est destiné à l’exploitant, c’est
une séquence d’action produisant une valeur ajoutée opérationnelle ou purement techniques.
[Roques07]
Page 84
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
Intention C’est le mécanisme qui empêche la mise à jour simultanée d’une même entité par
plusieurs utilisateurs.
Action Empêche la mise à jour simultanée.
Intention L’utilisateur doit se connecter, s’authentifier et être reconnue par le système à travers
le mot de passe.
Le modèle de spécification logicielle est cependant trop sommaire pour permettre une
spécification technique détaillé, Dans ce contexte, il est difficile de pouvoir préciser de manière détaillé les
comportements techniques attendus, si l’on n’organise pas la spécification suivants les différentes
responsabilités de traitement. [Roques07]
Couche logicielle :
Une couche logicielle représente un ensemble de spécification ou de réalisation qui
respectivement expriment ou mettent en œuvre un ensemble de responsabilité techniques et
homogènes pour un système logiciel. [Roques07]
Les couches s’empilent en niveaux pour couvrir des transformations logicielles successives, de
Page 85
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
sorte que la couche d’un niveau ne puisse utiliser que les services des couches des niveaux inférieurs.
[Roques07]
Présentation : Restitue les données à l’utilisateur, et transforme ses actions en événement
de l’application.
Application : représente les objets de contrôle et pilote les règles de l’application.
Métier : Représente les objets du métier et implémente leurs règles de gestion.
Accès aux données : Restitue les représentations métier à partir du moyen de stockage.
Stockage des données : Assure la persistance des données. [Roques07]
Présentation
Application
Métier
DAO
Stockage des
données
Page 86
CAPTURE DES BESOINS FONCTIONNELS ET
CHAPITRE III TECHNIQUES
4. Conclusion
La capture des besoins fonctionnels joue un rôle essentiel dans le cadre d’une part, de compléter les
recueils initiales des besoins opérés pendant l’étude préliminaire, et de l’autre part, elle donne une première
vue pour le prochain chapitre concernant l’analyse afin d’identifier les classes du modèle statique qui
présentent une des approches orientées objets.
La capture des besoins techniques couvre, par complémentarité avec celle des besoins fonctionnels,
toutes les contraintes qui ne traitent ni de la description de métiers des utilisateurs, ni de la description
applicative.
Page 87
Chapitre IV
Analyse
CHAPITRE IV l’ANALYSE
1. Introduction
L’étape d’analyse est entamée à la suite de l’étape de capture des besoins fonctionnels, Elle est
située sur la branche gauche du processus 2TUP.
Dans ce chapitre là on va traiter la phase de l’analyse objet du système SGAE, en suivant les
étapes suivantes :
Le découpage en catégorie
Le développement du modèle statique,
Le développement du modèle dynamique.
La figure qui suit illustre la situation de l’étape d’analyse dans le processus 2TUP :
Nous sommes
ici
2. Découpage en catégories
Le découpage en catégories constitue la première activité de l’étape d’analyse, Cette phase utilise la
notion de package pour définir des catégories de classes d’analyse et découper le modèle UML en blocs
logiques les plus indépendants possibles.
Une catégorie consiste en un regroupement logique de classes à forte cohérence interne et faible
couplage externe. [Roques07]
Page 89
CHAPITRE IV l’ANALYSE
class model
«Category»
Catalogue «Category»
Role
+ Catalogue
+ Catégori e
+ Article
+ Panier + Role
+ Commande + Client
+ Li gneCommande + Admini strateur
+ Facture
Page 90
CHAPITRE IV l’ANALYSE
C lien t
Role Ad ministrate ur
avoir a voir 1
1..* 1 1
1
Catalogue
Panier
1
«from catalogue»
Client 1
appartient
1..*
Catégorie
1
concerne
Appartient
0..* 1..*
Article
Commande
0..* 1..*
1
a voi r
Facture
Li gneCommand e
Page 91
CHAPITRE IV l’ANALYSE
class model
«Category»
Catalogue «Catego ry»
Role
+ Catalogue
+ Catégorie
+ Article «import»
+ Role
+ Panier
+ Client
+ Commande
+ Administrateur
+ LigneCommande
+ Facture
Fiches de description
des cas d’utilisation Diagramme de
Cahier des
classe candidates
1. Affiner les
classes
2. Affiner les
associations
Diagramme de classes
complétés 3. Ajouter les
attributs Diagrammes de
4. Ajouter les classes optimisés
opérations
5. Optimiser avec
la généralisation
Page 92
CHAPITRE IV l’ANALYSE
Les classes identifiées lors de l’étude des cas d’utilisations sont simplement des classes
candidates pour l’analyse objet, il convient désormais de les examiner de manière détaillé, d’en éliminer
certaines, ou au contraire d’en ajouter d’autre. [Roques07]
Les associations représentent des relations conceptuelles entre les classes. On peut également dire
qu’elles impliquent des responsabilités en termes de navigation, la navigation dans un modèle statique
représente la capacité à obtenir des informations en parcourant les associations entre les classes. On peut
donc considérer les associations comme porteuses d’une partie fondamentale de la structure
statiques des classes.
Affiner les associations convient de les valider, les préciser, en éliminer, et en ajouter. Il s’agit
d’une activité, consiste également à utiliser deux notions complémentaires fournies par UML,
l’agrégation et la composition, qui sera complétée grâce à l’identification des attributs. [Roques07]
Page 93
CHAPITRE IV l’ANALYSE
Class Role
Ad ministrate ur
Client Role c odeA dmin
l ogi n
codeC lient 1
login
1..* avoir codeR ole :i nt 1 avoir 1 m ot pass
nomRole : stri ng nomA dmin
motPa ss prenomA dmin
nom Clie nt a dre ssA dmin
pre nom Clie nt e ma ilA dm in
adr essCl ient t elA dmin
ema ilCli ent
telC lient
n_c artebanca ir e
cla s s C a ta l o g ue
av o ir
1
C a t alo g ue
1
P a n ier
co d e Pa n ier : in t
« fr om ca t a lo g ue » n b rA r tic les :i n t
C lien t m o n ta n tT ot ale :d o ub le
1
ap p a rtie n t
1 ..*
C a té g o rie
1 c od e C a teg or ie : i n t
n o m Ca teg o r ie : stri ng
co n ce rn e
1
A p p artien t
0. .*
1..*
C o m m a nd e A r ticle
co de Ar tic le :in t
c o d eCo m m a n de :i n t desi gna tio nA rt icle : str in g
1 e tat Co m m an d e : str in g 0 ..* 1 . .*pr ix :d o ubl e
da teC om m and e : d ate qu an ti teS tock :in t
m o nta n tT o tal e :do u b le ph o to :by et
et at :st ring
av o ir dat e : da te
Page 94
CHAPITRE IV l’ANALYSE
Diagramme de cas
d’utilisation
Fiches de description
des cas d’utilisation
La liste de 2. Formaliser
scénarios les scénarios
Diagrammes
3. Construire les d’états
diagrammes d’états
Diagrammes
d’itérations 4. Valider le
modèle dynamique
Page 95
CHAPITRE IV l’ANALYSE
Consulter catalogue
Consulter le catalogue()
Con sulter ()
Resultat
: Ecran catalogue. Afficher la page Resultat
demandée()
Afficher la page
demandée()
Page 96
CHAPITRE IV l’ANALYSE
Rechercher un article
: Ecran formulai re de
recherche
Afficher le formulaire de
recherche()
Afficher le formulaire de
recherche()
ALT Resultat
[ Si artile n'existe pas]
:Ecran message d'erreur
Create()
Afficher message d'erreur()
[ sinon]
:Liste des articles Afficher liste articles()
Page 97
CHAPITRE IV l’ANALYSE
Gérer le panier
Accès au panier()
: Ecran panier
Vérification
AL T
ALT [si MAJ est correcte]
Resultat
: Ecran pan ier Afficher le panier()
[sinon]
: Ecran message d'erreur Resultat
Page 98
CHAPITRE IV l’ANALYSE
Créer un compte
: Visiteur
Inscrire()
:Ecran inscription
Affi che l e formulaire d'inscription().
vérification : Client
ALT Creat e ()
ALT Resultat
[si une erreur]
:Ecran message d'erreur
Create()
Afficher un message d'erreu r()
[sinon] Enregistrer
Resultat
:Ecran message de confirmation
Create()
Afficher un message de confirmation()
Page 99
CHAPITRE IV l’ANALYSE
Passer la commande
: Client
REF
S'authentifier
Passer la commande()
:Ecran formulaire
Affiche le formulaire
Affiche le formulaire()
ALT Create()
[sinon] Enregistrer
: Ecran message confirmation Resultat
Create()
Afficher un message de
confirmation()
Page 100
CHAPITRE IV l’ANALYSE
Consulter la facture
REF
Passer la commande
Consulter la facture()
Résultat
: Ecran détaille
Afficher détail sur la facture()
Page 101
CHAPITRE IV l’ANALYSE
Régler la facture
: Client
: Ecran Interface : Controle régler :Facture
la facture
REF
Consulter la facture
Régler la facture()
Selectionner ()
Vérification
ALT Selectionner ()
Envoyer ()
« actor »
ALT systeme externe
[informations correctes] Autorisaton de paiement
Résultat
: Ecran message de confirmation
Affiche un message Create()
"facture reglée"
[sinon] Résultat
: Ecran message d'erreur Create()
Page 102
CHAPITRE IV l’ANALYSE
s'authentifier
Authentifier()
Authentifier(login,motPasse)
Vérification
Afficher ()
Afficher ()
[sinon]
Page 103
CHAPITRE IV l’ANALYSE
Gérer le profil
: client
REF
s'authentifier
Choisir profil()
: profil client
vérification
ALT
Modifier ()
ALT
Resultats
:Ecran message de confirmation
Create()
Afficher()
Resultats
:Ecran message d'erreur
Create()
Afficher()
Page 104
CHAPITRE IV l’ANALYSE
Ajouter un article
REF
S'au thentifier
Ajouter un article()
[sinon]
Page 105
CHAPITRE IV l’ANALYSE
Modifier un article
: Administrateur
REF
S'authentifier
modifier un article().
Choisir un article(codeArt)
Choisir un article(codeArt)
Choisir un article()
:Ecran page de modification
Résultat
Afficher page de modification ()
modifier()
Modifier(designationArt,descriptionArt,prix,quantitéStock...)
vérification
ALT modifier ()
[si bien modifie] Enregistrer
: Ecran message de confirmation
Resultat
Create()
Afficher()
[Sinon]
: Ecran message d'erreur Create()
Afficher()
Page 106
CHAPITRE IV l’ANALYSE
Supprimerun article
: Administrateur
REF
S'authentifier
Supprimer un article()
Choisir un article()
Supprimer un article()
Supprimer un article(codeArt)
Supprimer(codeArt)
Afficher()
Page 107
CHAPITRE IV l’ANALYSE
::Ecran gérer les articles :Ecran ajouter un article :Ecran modifier article :Ecran supprimer un article
:Administrateur
REF S'authentifier
Gérer articles()
Afficher operations()
REF
Ajouter un article
[si modifier]
REF
Modifier un article
[si supprimer]
REF
Supprimer un article
Page 108
CHAPITRE IV l’ANALYSE
:Commande :Client
::Ecran Interface : Controle voir
statistique
:Article
:Administrateur
REF
S'authentifier
Voir statistiques ()
Voir statistiques ()
Voir statistiques()
Page 109
CHAPITRE IV l’ANALYSE
REF
S'authentifier
Gérer un compte()
Choisir un compte()
Resu ltat
:Ecran message de confirmation
Create()
Afficher ()
5. Conclusion
Dans ce chapitre nous avons présenté l’analyse objet du système, les classes issues des besoins
fonctionnels sont regroupées en catégories pour organiser le modèle structurel d’analyse. Ce modèle
nécessite un travail d’analyse détaillée de la structure des classes. Celui-ci est considéré comme une base
pour le développement du modèle statique et dynamique. Nous allons décrire dans le chapitre suivant la
conception du notre système.
Page 110
Chapitre V
Conception
CHAPITRE V CONCEPTION
1. Introduction
La phase de conception se déroule pendant trois étapes qui sont la conception générique qui est une
étape de la branche droite, du processus en Y, et les deux étapes de la branche milieu du processus qui
sont la conception préliminaire, c’est l’étape où s’effectue la fusion des études fonctionnelles et techniques.
et la conception détaillé qui vient juste après est une activité qui s’inscrit dans l’organisation définie par la
conception préliminaire. [Roques07]
Générique,
préliminaire, et
détaillée
2. Conception générique
2.1. Définition :
La conception générique est située dans la branche droite du processus 2TUP, c’est la
deuxième activité de la branche technique, elle consiste à développer la solution qui répond aux
spécification techniques présentées à l’étape de capture des besoins techniques. La conception générique
s’appuie sur le développement de frameworks répondant aux spécifications techniques. L’organisation
en architecture technique puis en composants doit ensuite répondre à des objectifs de réutilisation, de
fabrication et de déploiement. [Roques07]
Page 112
CHAPITRE V CONCEPTION
Le modèle logique de conception technique est organisé par package de classe qui représente les
frameworks développés pour résoudre les problèmes purement techniques. Nous utilisons pour spécifier
les concepts de Framework technique le stéréotype « Technical Framework ». Un certain nombre de
Framework ont donc été développés, qui servent à simplifier l’utilisation de telle ou telle technologie, les
plus connus sont : (Spring, Jsf, Hibernate, …).
Pour notre projet, on utilise les framework Spring et Hibernate, afin de simplifier le développement
de la présentation et le contrôle de notre application, en respectant le pattern MVC2, qui est le modèle
recommandé pour les applications J2EE. (Spring , Hibernate et MVC sont déjà détaillé dans le chapitre
I).
Design pattern :
Les design patterns ou modèles de conception décrivent des organisations pratiques de classes
objets. Ces organisations résultent souvent d'une conception empirique, le concepteur objet tente de
faciliter la réutilisation et la maintenance du code. On peut donc concevoir un modèle d'application
comme une forme d'organisation transposable à plusieurs applications. [W11]
Page 113
CHAPITRE V CONCEPTION
« Technical framework »
Noyau présentation
« Technical framework »
Noyau applicatif
« Technical framework »
Noyau Présentation: Le noyau présentation définit les classes, les interfaces et les
mécanismes de base pour réaliser l’affichage d’un objet.
Noyau Applicatif: Le noyau d’application charge les modèles de fonctionnement et contrôle
les commandes d’une application en utilisant les classes métier.
Noyau sécurité : Le noyau sécurité définit les stratégies de contrôle et d’authentification
nécessaire pour protéger le système. Il est composé des niveaux de sécurité suivants:
La sécurité côté SGBDR : chaque utilisateur se voit attribuer un ensemble de
privilèges se rapportant à l’exploitation du système.
La sécurité côté applicatif : se traduit par la définition de comptes user (login/mdp)
pour tous les utilisateurs du système avec la possibilité de changer de mot de passe.
Noyau métier : Définit les éléments permettant d’identifier les objets métier et de définir
leurs attributs caractéristiques.
Noyau d’accès aux données : Définit les mécanismes de chargement, de sauvegarde, de mise
à jour et de recherche des objets. [Roques07]
Page 114
CHAPITRE V CONCEPTION
3. Conception préliminaire
3.1. Définition :
La conception préliminaire est certainement l’étape la plus délicate du processus 2TUP car Elle
représente le cœur. A cette étape on va effectue la fusion des études fonctionnelles et techniques, La
conception préliminaire est avant tout affaire d’organisation ; elle appuie sur les points de vue de
spécification fonctionnelle et structurelle de l’analyse, mais également sur les Frameworks de la
conception technique. [Roques07]
«d ep loy »
Se rve
Seruvreur
ba se d ed do
b a se e dn n éée
o nn e( M
(mYS QL )
y s ql)
Ba
B ase
s e de
d e ddoonné
nn ée
e M
(mYySQ
s qlL
)
JV M
N a v ig at eur w e b(c hr om e,m o zila . .. )
C o u che p erc is te nc e C o u ch e a b stra ct io n
(H iber na te ) (Sp ri ng )
C o uc he m et ie r C o uc he pr és en ta ti o n
( Ja v a ) (J sp)
Page 115
CHAPITRE V CONCEPTION
4. Conception détaillé
4.1. Définition:
L’étape de conception détaillé est la dernière étape de la conception, dans cet étape les
concepteurs construisent les classes par la conception des attributs, des opérations, et faire aussi la
conception des associations, ensuite ils construisent les différentes tables de l’application.
4.1.1. Concevoir les attributs et les opérations:
La conception des attributs consiste principalement à définir le type des attributs identifiés en
analyse, Pour chaque attribut on donne leur type, qui est en général un type de base, pour
concevoir ou documenter une méthode, UML met à notre disposition toute la palette des
diagramme du modèle dynamique, nous avons basé sur le diagramme de séquence réalisé dans
l’étape d’analyse.
class Role
Client Administrateur
Role
codeClient : int codeAdmin : int
login : string codeRole : int login : string
motPasse : string nomRole : string
nomClient : string motPasse : string
nomAdmin : string
prenomClient : string
avoir prenomAdmin : string
email : string 1..* 1 avoir email : string
telephone : string 1 1 telephone : string
adresseClient : string adresseAdmin: string
sexe : string + Creer()
dateNaiss : date sexe : string
n_cartebancaire : int dateNaiss : date
+ Creer()
+ Creer()
+ Consulter()
+ Modifier()
1..*
Page 116
CHAPITRE V CONCEPTION
Catalogue
1
Panier
1 codePanier : int
montantTotale : double
«from catalogue» 1 nbrArticles : int
Client
apparti ent
+ Creer()
1..* + Consulter()
+ ModifierEtatPanier()
Categorie
codeCategorie : int
nomCategorie: string
1
+ Creer()
concerne
0..* 1
Appartient
Commande
1
1..*
codeCommande : int
etatCommande : string Article
dateCommande : date codeArticle : int
montantTotale : double designationArticle : string
1 0..* 1..* descriptionArticle : string
prix : double
quantiteStock : int
+ Creer()
photo : byte
+ Consulter()
etat : string
+ Passer() date : date
avoir LigneCommande
codeLigneCmd : int + Creer()
quantite : int + Ajouter()
Facture + Modifier()
+ Supprimer()
codeFacture : int
+ Rechercher()
+ creer()
1
+ creer()
+ consulter()
Page 117
CHAPITRE V CONCEPTION
1..* Panier
codePanier : int
Client
montantTotale : double avoir
codeClient : int nbrArticles : int
login : string 1 avoir 1 1
motPasse : string
nomClient : string
prenomClient : string
Catalogue + Creer()
email : string
telephone : string + ModifierEtatPanier()
adresseClient : string + Consulter()
sexe : string
dateNaiss : date
n_cartebancaire: int
1
+ Creer()
+ Consulter() Role
+ Modifier()
codeRole:int
1
NomRole:string
appartient
1
+ Creer()
concerne 1..*
concerne Categorie
- codeCategorie : int
0..* - nomCategorie : string
Commande 1
+ Creer()
codeCommande : int
etatCommande : string
dateCommande : date 1
1 avoir
1
1
+ Creer() appartient
Administrateur
+ Consulter()
1..*
+ Passer() codeAdmin:int
Article login :string
0..* 1..* motPasse:string
codeArticle : int nomAdmin:string
avoir designationArt icle: string prenomAdmin:string
descriptionArticle : string email : string
prix : double telephone : string
quantiteStock : int adresseAdmin: string
LigneCommande photo : byte sexe : string
Facture
etat : string
codeFacture:int codeLigneCmd : int date : date 1
montantTotale : double quantite : int + Creer()
+ Creer()
+ Ajouter()
+ Creer() + Modifier()
+ Creer() + Supprimer()
+ Consulter() + Rechercher()
1 + Regler()
Une association ayant une multiplicité « 0 - * » ou « 1 - * » : La transformation est faite par l’ajout
en qu’en tant qu’attribut simple de la clé de la classe situé du coté de multiplicité 0 ou1, dans la classe
située du coté de la multiplicité *.
Page 118
CHAPITRE V CONCEPTION
Une association ayant une multiplicité « * - * » et les classes associations : cette association dans le
diagramme de classe se traduit par une relation supplémentaire ayant pour clé, la concaténation des clés
primaires des classes connectés à l’association chaque attributs devient clé étrangère, les attributs de la
classe association doivent être ajouté à la nouvelle relations, ces attributs ne sont ni clé primaire, ni clé
étrangère.
Une association ayant une multiplicité « 1 - 1 » : dans ce cas d’association il faut ajouter un attribut
de type clé étrangère dans la relation dérivée de la classe ayant la multiplicité minimale égale à un. Cette
règle permet d’éviter les valeurs nulles dans la base de données.
La traduction des associations de notre système va illustrer dans les figures suivantes :
Méthode1 : Créer une relation avec tous les attributs des classes (la super classe et les sous-
classes), et il faut ajouter un attribut pour distingue le type des objets.
Méthode2 : Créer une relation pour chaque sous classe, chaque relation se compose des attributs
génériques et d’attributs spécifiques.
Méthode3 : Créer une relation par classe et des associations.
Ca talo gu e Ca tégorie
C a té g o rie A rtic le
1 - c on tie n t : C a ta lo g ue 1 - c ontient : Caté gori e
C a té g orie Ar ticle
Page 119
CHAPITRE V CONCEPTION
Commande C lient
LigneCommande Panier
LigneCommande 0..* 1
- LigneCommande:Article - c oncer ne : C lie nt
- LigneCommande: Commande c onc erne
1..*
1
Article P anier
Commande Facture
0..* 1
- concerne : Client - concerne : Commande
concerne con cerne
1 1
Client Facture
Role Role
1 1
- concerne:Administrateur - concerne: Client
concerne concerne
1 1
Role Role
Page 120
CHAPITRE V CONCEPTION
class catalogue
Article
Commande Categorie
codeArticle : int
codeCategorie : int designationArticle : string
codeCommande : int nomCategorie : string descriptionArticle : string
etatCommande : string contient : Catalogue prix : double
dateCommande : date quantiteStock : int
montantTotale : double + Creer()
photo : byte
concerne : Client etat : string
+ Creer() date : date
Catalague contient : Categorie
+ Consulter()
+ Passer()
+ Creer()
+ Ajouter()
Client + Modifier()
codeClient : int + Supprimer()
login : string + Rechercher()
motPasse : string Facture
nomClient : string
codeFacture : int
prenomClient : string Administrateur
concerne : Commande
email : string
telephone : string codeAdmin : int
adresseClient : string + Creer() login : string
sexe : string + Consulter() motPasse : string
dateNaiss : date + Regler() nomAdmin : string
n_cartebancaire : int prenomAdmin : string
email : string
telephone : string
Panier
+ Creer() adresseAdmin: string
+ Consulter() codePanier: int sexe : string
+ Modifier() nbrArticles: int dateNaiss : date
montantTotale : double
concerne : Client + Creer()
+ Creer()
LigneCommande + Consulter()
+ ModifierEtatPanier() Role
quantite : int
LigneCommande : Article codeRole: int
LigneCommande :Commande nomRole: string
concerne :Administrateur
concerne :Client
+ Creer()
Page 121
CHAPITRE V CONCEPTION
Hibernate permet d’assurer et de faciliter la persistance des objets d'une application, en réalisant lui-
même la création de ces objets et les traitements de remplissage de ceux-ci en accédant à la base de données.
Il propose aux développeurs des méthodes d’accès aux données plus efficaces par l’utilisation des requêtes
HQL (Hibernate Query Langage) qui peut donc réduire le temps de développement.
Hibernate est très populaire notamment à cause de ses bonnes performances et de son ouverture à de
nombreuses bases de données (MySQL, DB2, Oracle…). Qui assure la portabilité des applications.
5. Conclusion
La phase de conception prend en compte les choix d’architecture technique retenue pour le
développement et l’exploitation du système. Elle vise à trouver des solutions informatiques et techniques
pour mettre en œuvre et construire le système analysé au cours des phases précédentes.
Il nous reste qu’une dernière étape qui est la phase de réalisation qu’on va l’aborder dans le chapitre
suivant.
Page 122
Chapitre VI
Implémentation
CHAPITRE VI L’IMPLEMENTATION
1. Introduction
Dans le cadre de ce dernier chapitre, nous allons présenter brièvement la structure, les différents outils
et technologies de programmation utilisée pour l’implémentation et la réalisation de notre application web.
Et par la suite nous allons présenter quelques interfaces de notre système.
Le langage Java a la particularité principale d'être portable sur plusieurs systèmes d'exploitation tels que
Windows, Mac OS ou Linux. De nombreux types de programmes peuvent être réalisés avec Java telle que
les sites web dynamiques, avec J2EE (Java 2 Enterprise Edition, maintenant JEE), etc. [W12]
Servlet :
Une servlet est en réalité une simple classe Java, qui reçoit une requête HTTP envoyée depuis navigateur,
effectue des traitements et renvoie la réponse. [W14]
JSP :
Java Server Page est une technique Java qui permet de générer dynamiquement du code HTML.
Elle mélange la puissance de Java côté serveur et la facilité de mise en page d’HTML côté client. [W15]
JPA :
Java Persistence API permet fait la correspondance entre le modèle de données relationnel et le
modèle objet de la façon la plus facile possible. [W16]
Page 124
CHAPITRE VI L’IMPLEMENTATION
JSTL :
JSP Standard Tag Library c’est un ensemble de balises personnalisées (Custom Tag), elle permet
d’éviter l’utilisation de code Java dans les pages JSP et de réduire la quantité de code à écrire ainsi que
rend le code des pages JSP plus lisible. [W17]
spring :
Spring est un framework open source JEE pour les applications n tiers, dont il
facilite le développement et les tests. Il est considéré comme un conteneur dit «
Léger », c’est-à-dire une infrastructure similaire à un serveur d’applications J2EE.
[W18]
Hibernet :
Hibernate est une solution open source du type ORM (Object Relational Mapping)
qui permet de faciliter le développement de la couche persistance d'une
application. Il permet donc de représenter une base de données en objets Java et
vice-versa. [W9]
CSS:
Cascading Style Sheets est un langage informatique utilisé sur l'internet pour mettre en forme les
fichiers HTML ou XML. CSS est un le langage de décoration d’une page web. [W19]
Javascript :
Le Javascript est un langage de script incorporé dans un document HTML. Historiquement il s'agit
même du premier langage de script pour le Web. Ce langage est un langage de programmation qui
permet d'apporter des améliorations au langage HTML en permettant d'exécuter des commandes du côté
client, c'est-à-dire au niveau du navigateur et non du serveur web. [W20]
Page 125
CHAPITRE VI L’IMPLEMENTATION
Le serveur Tomcat
Apache Tomcat est un conteneur web libre de servlets et JSP Java EE. Issu du projet
Jakarta, c'est un des nombreux projets de l’Apache Software Foundation. Il
implémente les spécifications des servlets et des JSP du Java Community Process, est
paramétrable par des fichiers XML et des propriétés, et inclut des outils pour la
configuration et la gestion.[W22]
Il comporte également un serveur HTTP. Il peut être utilisé en autonomie avec son propre serveur web
ou en collaboration avec d’autres. [W22]
MYSQL :
Le SGBD MySQL est supporté par un large éventail d’outils. MySQL est surtout
installé pour les applications Web. Ce SGBD est solide, libre, gratuit, est utilisé par de
grands groupes spécialisés dans l’internet. [W23]
Pacestar UML Diagrammer est une alternative à d'autres programmes qui aident les programmeurs,
ingénieurs système, ou d'autres professionnels pour créer des diagrammes UML. Il est livré avec un
grand nombre de fonctionnalités, ainsi que des options de personnalisation et incluent tous les outils
nécessaires pour aider les utilisateurs des schémas de conception à des fins diverses.
Page 126
CHAPITRE VI L’IMPLEMENTATION
L’interface d’accueil
Page 127
CHAPITRE VI L’IMPLEMENTATION
L’interface panier
Page 128
CHAPITRE VI L’IMPLEMENTATION
L’interface d’authentification
Page 129
CHAPITRE VI L’IMPLEMENTATION
5. Conclusion
Dans ce dernier chapitre nous avons présenté tout ce qui est lié au développement de notre application.
Nous avons parlé des différents outils et choix technologiques utilisés dans l’implémentation des différents
composants. Le chapitre est clôturé par une description détaillée des interfaces graphiques de notre
application. Il ne reste qu’à conclure ce projet dans la section suivante.
Page 130
Conclusion
générale
Conclusion Générale
À travers ce projet, nous nous sommes intéressés de conçu et réalisé une application
web de gestion des achats en ligne. Une étude a été réalisée, en récoltant les informations
nécessaires. Ce projet a contribué à améliorer nos compétences dans plusieurs domaines. Il
nous a permis de nous perfectionner en améliorant nos connaissances en conception et en
programmation. Nous avons appliqué au maximum possible les règles de base permettant
d'avoir une application performante.
Nous avons utilisé le langage UML pour la modélisation du système en suivant les étapes
du processus (2 TUP). Au niveau du développement de l’application, nous avons utilisé
l'architecture JEE (Jsp, servelet, modèle MVC, etc.) basée sur la souplesse de Java, qui est une
plate-forme très puissante, elle intègre différents outils qui facilitent le développement des
applications d’entreprise par l’utilisation des frameworks Spring et Hibernate. Pour le
déploiement nous avons utilisé le serveur web Tomcat, et le SGBD MYSQL pour la base de
données.
Malgré ce qui a été fait, ce travail n’est pas encore terminé il peut être enrichi par
d’autres fonctionnalités telles que le paiement en ligne, une boîte de messagerie, etc. Enfin,
nous espérons que ce modeste mémoire soit un modèle pour les autres étudiants et que sa
lecture a été agréable et claire.
Page 132
Bibliographies
Les Ouvrages
[Roques07] : Pascal Roques & Frank Vallée : « UML en action de l’analyse des besoins à la
conception en Java » édition Groupe Eyrolles, 2007.
[Pascal_web 07] : Pascal Roques : « Les cahiers du programmeur UML2 modélisé une
application Web » édition Groupe Eyrolles, 2007.
Les Mémoires
[M1] « Conception et réalisation d’une application web pour l’achat, la vente et la location
des immobiliers en ligne»
[Mémoire préparé En vue de l’obtention du diplôme de Master, Année Universitaire
[M3] « Conception et réalisation d’une application web pour une agence immobilière»
[Mémoire préparé En vue de l’obtention du diplôme de Master, Année Universitaire
Web graphies
[W01]:http://elearning.univjijel.dz/elearning/pluginfile.php/3915/mod_resource/content/1/Pol
ycopi%C3%A9-Boukraa_SIMA.pdf.
[ W02] :http://slideplayer.fr/slide/181812/.
[W03]:http://www.commentcamarche.net/contents/j2ee/j2ee-intro.php3.
[W04]:http://www.jmdoudoux.fr/java/dej/chap-j2ee-javaee.htm.
[W1]:https://fr.wikipedia.org/wiki/Application_web.
[W2]: https://www.sofracs.com/creation-application-web-mobile
[W3] :https://fr.wikipedia.org/wiki/Architecture_trois_tiers
[W4]:http://www.commentcamarche.net/contents/j2ee/j2ee-intro.php3(j2ee).
[W5]:http://javaj2ee-firststeps.blogspot.com/.
[W6]:http://www.jmdoudoux.fr/java/dej/chap-frameworks.htm#frameworks-4.
[W7]:http://wiki.ouieuhtoutca.org/doku.php?id=design_patterns.
[W8]:http://wpetrus.developpez.com/java/struts/data/tutorial_struts.pdf.
[W9]:http://www.jmdoudoux.fr/java/dej/indexavecframes.htm.
[W10]:
http://diuf.unifr.ch/drupal/sites/diuf.unifr.ch.drupal.softeng/files/teaching/studentprojects/gille
r/download/report.pdf.
[W11]: http://abrillant.developpez.com/tutoriel/java/design/pattern/introduction/.
[W12] :https://fr.wikipedia.org/wiki/Java_(langage)
[w 13] :https://openclassrooms.com/courses/apprenez-a-programmer-en-
java?utm_source=google&utm_medium=cpc&utm_term=search&utm_campaign=397812015
[W14] : https://openclassrooms.com/courses/creez-votre-application-web-avec-java-ee/la-
servlet
[W15]: http://litis.univ-lehavre.fr/~duvallet/enseignements/Cours/JEE/COURS-JSP-4p.pdf
[W16] : http://spoonless.github.io/epsi-b3-javaee/12_jpa_part1.html
[W17] :
https://archive.org/stream/PHPMySQLAvecFlash8/Les%20cahiers%20du%20programmeur%
20Java%20EE%205_djvu.txt
[W18] :https://fr.wikipedia.org/wiki/Spring_(framework)
[W19] :http://glossaire.infowebmaster.fr/css/
[W20]:http://www.commentcamarche.net/contents/577-javascript-introduction-au-langage-
javascript#qu-est-ce-que-le-javascript
[W21] :http://glossaire.infowebmaster.fr/html/
[W22] :https://quentinv.gitbooks.io/installation-de-tomcat-sur-
debian/content/presentation_tomcat.html
[W23] :http://toubkalit.com/chapitre/Rapport_de_conception.pdf
Résumé
Mots clés: UML, 2TUP, java EE, Tomcat, JSP, Servlet, Spring, Hibernate, etc.
Abstract
Our project focuses on the study, design and implementation of a web application
for online shopping and the opportunity to present items in an online store available for
everyone.
For this project we used the UML modeling language based on the 2TUP process.
For the implementation of our web application, we used the Web java programming
language (Jsp, Servelet, …), with the use of the framework spring, that implements the
MVC2 model, and the framework hibernate to implement the data access layer.
Keywords: UML, 2TUP, JAVA, java EE, Tomcat, JSP, Servlet, Spring, Hibernate, ...
اﻟﺘﻠﺨﯿﺺ
وذﻟك ﺑﺎﻻﻋﺗﻣﺎد ﻋﻠﻰ، ﺗﮭدف اﻟﺷرﻛﺔ اﻟﯾوم ﻟﺗﺳﯾﯾر أﻧﺷطﺗﮭﺎ ﺑطرﯾﻘﺔ أوﺗوﻣﺎﺗﻛﯾﺔ،ﻣن أﺟل ﺗﺣﺳﯾن اﻷداء
.ﺗﻛﻧوﻟوﺟﯾﺎ اﻻﻋﻼم اﻻﻟﻲ
ﻟﻠﺗﺳوق ﻋﺑر اﻻﻧﺗرﻧت و إﻣﻛﺎﻧﯾﺔ ﻋرضJEE ﺗﺻﻣﯾم وﺗﻧﻔﯾذ ﺗطﺑﯾﻘﺔ وﯾب، ﯾرﻛز ﻣﺷروﻋﻧﺎ ﻋﻠﻰ دراﺳﺔ
. اﻟﺳﻠﻊ ﻓﻲ ﻣﺗﺟر اﻓﺗراﺿﻲ ﯾﻛون ﻓﻲ ﻣﺗﻧﺎول اﻟﺟﻣﯾﻊ
، ﻟﺗﻧﻔﯾذ ﺗطﺑﯾﻘﺔ اﻟوﯾب. 2TUP ﻛﻠﻐﺔ ﻧﻣذﺟﺔ ﺑﺎﻻﻋﺗﻣﺎد ﻋﻠﻰ ﻋﻣﻠﯾﺔUML ﻣن أﺟل اﻧﺟﺎز ھذا اﻟﻣﺷروع اﺳﺗﻌﻣﻠﻧﺎ
ﻣن اﺟل ﺗطﺑﯾق اﻟﻧﻣوذجSpring ﻣﻊ اﺳﺗﺧدام إطﺎر,( اﻟﺦ،Servelet ،JSP) اﺳﺗﺧدﻣﻧﺎ ﻟﻐﺔ اﻟﺑرﻣﺟﺔ ﺟﺎﻓﺎ اﻟﺧﺎﺻﺔ ﺑﺎﻟوﯾب
. ﻟﺗﻧﻔﯾذ طﺑﻘﺔ اﻟوﺻول إﻟﻰ اﻟﺑﯾﺎﻧﺎتHibernate واﻹطﺎر،MVC2
UML, 2TUP, java EE, Tomcat, JSP, Servlet, Spring,Hibernate, … : اﻟﻜﻠﻤﺎت اﻟﻤﻔﺘﺎﺣﯿﺔ