Developpement D'un Système D'affichage de Prix À Base D'étiquette Électronique Dans Un Espace Commercial

Projet de Fin des Etudes
Developpement d’un système

d’affichage de prix à base d’étiquette
électronique dans un espace
commercial
Réalisé par
Ali El Dhibi & Hichem Mounadi
Encadré par
Mr. Najib Bel Habib (encadreur industriel)
Mlle. Mouna Garai (Encadreur académique)
Soutenu le
xx.yy.zzzz
Dedication, cite from a famous person, or whatever you like
(optional)
Dédicaces
Au terme de nos études nous dédions ce travail
A Nos parents
Qui peuvent trouver dans ce travail l’expression de nos profondes reconnaissances

Pour leurs sacrifices, leurs conseils et leurs encouragements tout au long de mos
études.
A Nos frères
A Nos sœurs
A Dhehibi Sofiane
A Tous nos amis
Pour toute affectation qu’ils nous ont toujours apporté.
Espérant que Dieu protège tous ceux qui nous ont aidé de prés ou de loin pour la
la réalisation de ce projet
Remerciement
Au terme de ce travail nous avons l’honneur d’exprimer nos vifs et chaleureux
remerciements à tous les enseignats d’ISET Médenine qui ont contribué à notre
formation et pour les quels nous gardons un excellent souvenir.
Nous tenons en particulier à exprimer nos profondes gratitude pour :
Notre encadreur académique Mlle. Mouna Garai pour l’orientation, la confiance,

la patience qui ont constitué un apport considérable sans lequel ce travail n’aurait
pas pu être mené au bon port.
En outre, nous adressons nos sincères remerciements pour Nos remerciements

s’étendent également à Mr. Mr Nejib Belhabib gérant de la société
“NEWITECH” pour ses bonnes explications qui nous ont éclairé le chemin de la
recherche et sa collaboration avec nous dans l’accomplissement de ce modeste
travail.
Enfin, nous présentons nos gratitudes aux membres de jury qui ont pris la peine
d’évaluer ce travail.
Table des matières
1 Introduction générale 5
2 Contexte générale du projet 7

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Présentation de l’entreprise d’accueil . . . . . . . . . . . . . . . . . . 7
2.2.1 Mission et Activités . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Outils de conduite de projet . . . . . . . . . . . . . . . . . . . 9
2.3.4 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . 11
2.3.5 Estimation des extrants et intrants . . . . . . . . . . . . . . . 11
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Analyse du projet 13
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Etude fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3 Collecte des besoins fonctionnels . . . . . . . . . . . . . . . . . 14
3.2.4 Diagramme de Cas d’utilisation complet . . . . . . . . . . . . 22
3.3 Etude technique du projet . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Spécification technique (vision materielle) . . . . . . . . . . . 23
3.3.2 Détails techniques du matériels utilisés . . . . . . . . . . . . . 24
3.3.3 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . 30
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Conception détaillée 33
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Le modèle dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Le diagramme de séquence . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Le modèle statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
i
Table des matières Table des matières
5 Codage et test 43
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Codage et test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.1 Environnement logiciel et matériel . . . . . . . . . . . . . . . . 43
5.2.2 Réalisation de la couche présentation . . . . . . . . . . . . . . 46
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Conclusion générale 57
Bibliographie 59
ii
Table des figures
2.1 Sigle de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Les phases du projet selon processus en Y . . . . . . . . . . . . . . . 10
3.1 Etiquette papier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . 15
3.3 Diagramme de contexte dynamique . . . . . . . . . . . . . . . . . . . 15
3.4 Le CU “Gérer les produits” . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Cas d’utilisation gérer étiquette . . . . . . . . . . . . . . . . . . . . . 20
3.6 Diagramme de Cas d’utilisation complet . . . . . . . . . . . . . . . . 22
3.7 Architecture générale du projet . . . . . . . . . . . . . . . . . . . . . 24
3.8 Composants d’une étiquette RFID . . . . . . . . . . . . . . . . . . . . 25
3.9 Interface d’une étiquette électronique . . . . . . . . . . . . . . . . . . 25
3.10 Transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Antenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.12 Architecture logicielle du système . . . . . . . . . . . . . . . . . . . . 29
3.13 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Diagramme de séquence “Modifier produit et affichage” . . . . . . . . 34

4.2 Diagramme de séquence “vérification étiquette” . . . . . . . . . . . . 35
4.3 Diagramme de séquence “modification affichage” . . . . . . . . . . . . 36
4.4 Diagramme de séquence “ Ajouter prouduit ” . . . . . . . . . . . . . 37
4.5 diagramme d’activité "S’authentifier" . . . . . . . . . . . . . . . . . . 38
4.6 Diagramme d’activité ” Modifier l’affichage” . . . . . . . . . . . . . . 39
4.7 Diagramme d’activité ”Ajouter Produit” . . . . . . . . . . . . . . . . 40
4.8 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1 Interface modification sur les étiquettes . . . . . . . . . . . . . . . . . 47

5.2 Etiquette électronique . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Interface d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 Ajout produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.6 Interface de modification produit . . . . . . . . . . . . . . . . . . . . 50
5.7 supprimer produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.8 Importer les données . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.9 Interface consultation . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.10 Interface ajouter étiquette . . . . . . . . . . . . . . . . . . . . . . . . 52
5.11 Interface supprimer étiquette . . . . . . . . . . . . . . . . . . . . . . . 53
1
Table des figures Table des figures
5.12 Interface modification étiquette . . . . . . . . . . . . . . . . . . . . . 53

5.13 Interface d’acceuil étiquette . . . . . . . . . . . . . . . . . . . . . . . 54
5.14 Interface display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.15 Interface ID-Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.16 Interface Group Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.17 Interface signal test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2
Liste des tableaux
2.1 Tableau comparatif de quelques méthodologies de developpement . . 10
2.2 Descriptions des extrants . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Descriptions des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 17
3.3 Description du cas d’utilisation “s’authentifier” . . . . . . . . . . . . 17
3.4 Description du cas d’utilisation “Gérer les produits” . . . . . . . . . 18
3.5 Description des sous Cas d’utilisation du CU “Gérer les produits” . . 19
3.6 Description du cas d’utilisation “Gérer les étiquettes électroniques” . 19
3.7 Description des sous CU du CU “Gérer les étiquettes électroniques” . 21
3.8 Description du cas d’utilisation “Mettre à jour les informations” . . . 22
3.9 Forces dans l’architecture logicielle . . . . . . . . . . . . . . . . . . . 28
4.1 Liste des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1 Carecteristique de Transceiver . . . . . . . . . . . . . . . . . . . . . 45

5.2 Carecteristiques d’étiquette . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Les caractéristiques de RF KEY . . . . . . . . . . . . . . . . . . . . 46
3
Résumé Au cours de ce stage, nous avons développer une application d’un système
d’affichage de prix à base d’étiquette électronique dans un espace commercial, pour
cela nous avons suivi un processus de modélisation simplifié à base de langage orienté
objet UML (Langage de modélisation unifié).
Cette application permet d’éviter les problemes de système existant dans un espace
commercial, et de faciliter la gestion de prix sans aucune intervention humaine.
mot-clé
étiquette électronique, switch, Antenne.
Summary During this stage, we developed an application of a price display system

based on electronic tag in a commercial space, for that we followed a simplified
modeling process based on the object-oriented language UML ( Unified Modeling
Language ).
This application allows to avoid the problems of the existing system in a commercial
space, and facilitate the management of prices without any human intervention.
keyword
electronic tag, switch, Antenna
4
1 Introduction générale
La technologie d’identification par radiofréquence RFID (Radio Frequency Identi-
fication) représente une innovation majeure et nouvelle permettant la « gestion de
l’objet ». L’ampleur et les conséquences sont au moins comparables à celles de la
micro informatique, d’Internet ou de la téléphonie mobile.
L’identification par tag RFID est donc bien plus qu’une amélioration des méthodes
de marquage des objets. Il s’agit d’une nouvelle approche de gestion de l’information
offrant un gisement de productivité et de différentiation inédits.
Dans ce cadre, l’étiquette RFID va devenir le support privilégié de stockage des
informations qui pourront être lues et mises à jour sans aucune intervention humaine.
La RFID prendra toute sa place dans la panoplie d’outils de communication qui
permettront de décharger l’opérateur humain de la majeure partie du traitement
des informations pour se concentrer sur celles qui nécessitent son arbitrage.
Notre projet consiste à développer une application logicielle permettant de détecter
tout changement de prix et répercuter les modifications (prix de vente, prix au litre
ou kilo, contenance et unité de contenance) automatiquement dans tous les rayons
sur les étiquettes électroniques, via un transceiver déjà installés. Cette application
doit être en mesure de communiquer le logiciel de gestion commerciale qui y existe.
Le présent rapport est guidé par le plan suivant :
– Le premier chapitre, « contexte générale de projet », se compose en deux parties.
En première partie, nous présenterons le cadre de notre stage de projet de fin
d’étude à savoir l’organisme de la société NEWITEC. En la deuxième partie,
nous décrirons le sujet sur lequel portera notre PFE. Par conséquence, nous nous
proposerons la méthodologie correspond à notre projet qui est la méthodologie en
Y (2TUP).
– Le deuxième chapitre est intitulé « Analyse de projet ». D’aprés la méthodologie
choisie, ce chapitre décrira les deux branches (gauche et droite) de la méthodologie
2TUP. Dans une preumière partie, nous aborderons la branche gauche par la
présentation des études fonctionnelles. La branche droite qui présente une étude
technique du projet sera détaillée en deuxième partie.
– Dans le troisième chapitre, nous allons intéressé aux diagrammes de conception
dynamique, telle que le diagramme de séquence et le diagramme d’activités, et
statique, telle que le diagramme de classe.
– Le dernier chapitre « Codage et test », s’intéressa à la partie réalisation. Cette
réalisation est le résultat de l’étude préalable et de la conception. Au cours de ce
5
Chapitre 1 Introduction générale
dernier, nous décrirons l’environnement de développement de ce projet. Ensuite,

nous présenterons quelques exemples d’interfaces de l’application réalisée.
Enfin, nous clôturons ce projet par une conclusion générale dans laquelle nous ex-
posons quelques perspectives futures.
6
2 Contexte générale du projet
2.1 Introduction
Dans ce premier chapitre on va essayer de présenter notre projet ainsi que l’entreprise
d’accueil.
Ce chapitre est composé de deux sections : Dans la première section, nous donnons
un bref aperçu sur l’entreprise d’acceuil, à savoir NEWITEC, son organisation et
son domaine d’activité. La deuxième section sera consacrée à la présentation du
projet<< E-Label >>. La dernière section sera dédiée à une description détaillée
du projet, ses objectifs ainsi que la démarche adoptée pour le mener à bien.
2.2 Présentation de l’entreprise d’accueil
Figure 2.1: Sigle de l’entreprise
Opérant dans le domaine des Technologies de l’Information et de la Communica-

tion (TIC), la société tunisienne NEWITEC est spécialisée dans la conception, la
réalisation et le développement de tout procédé et application industrielle en télé-
communications incluant l’aspect matériel (Hardware) et logiciel (Software).
2.2.1 Mission et Activités

2.2.1.1 Mission
Depuis sa création, la société NEWITEC s’est forgée un nom dans le développe-

ment et l’adaptation de solutions softwares d’interfaçage entre différents systèmes
7
Chapitre 2 Contexte générale du projet
de transmission et de commutation de voix et de données. De telles solutions en-

globent entre-autres le développement de passerelles de communications normalisées
(signalisation SS7, SIP SIGTAN...).
2.2.1.2 Objectifs Activités
NEWITEC a contribué activement dans des projet ambitieux, aux côtés de grands
noms internationaux tels que : EURIWARE-France (filiale du groupe COGEMA),
FERMA (Groupe INTERTECHNIQUE) et Halys Filiale de Dassault. Aujourd’hui,
soucieuse de garder sa position de précurseur dans le domaine technologique et
de faire briller davantage son image de marque, elle compte confirmer son champ
d’expertise dans des domaines d’actualité tels que la mobilité M2M et les systèmes
embarqués.
NEWITEC s’investit également dans la conception et le prototypage de solutions
sur-mesure (aspect matériel et logiciel) pour le développement du système d’infor-
mation de tout type d’entreprise, en vue d’assurer une meilleure efficacité de son
système de gestion et minimiser les charges telles que la gestion de flottes pour les
entreprises dotées d’un parc automobile important. Une expérience pilote GPS a
été déjà entamée avec le Ministère de l’Agriculture dans le cadre du projet "suivi et
contrôle de l’activité du secteur de la pêche dans le Golfe de Gabès moyennant les
technologies de communications satellitaires" pour la préservation de nos ressources
maritimes. Les tests grandeur nature qui ont été accomplis en utilisant le système
de communication par satellite THURAYA ont donné satisfaction...
En conclusion, NEWITEC opère sur les activités suivantes :
– L’axe réseau
– L’axe système d’information
– L’innovation technologique
– Le développement du marché du web
2.3 Présentation du projet
2.3.1 Contexte
De nos jours, la technologie d’identification par radiofréquence RFID (Radio Fre-

quency Identification) représente une innovation majeure et nouvelle permettant la
« traçabilité des objets ». L’identification par tag RFID est donc bien plus qu’une
amélioration des méthodes de marquage des objets. Il s’agit d’une nouvelle approche
de gestion de l’information offrant un gisement de productivité et de différentiation
inédits.
8
2.3.2 Objectif du projet
Le projet consiste à développer une application logicielle permettant l’affichage en

temps réel du prix dans les magasins de distribution : lié à une base de donnée et
permettant de détecter tout changement de prix pour répercuter les modifications
(prix de vente, prix au litre ou kilo, contenant et unité de contenance) automati-
quement dans tous les rayons sur les étiquettes électroniques, via des antennes déjà
installés. Cette application doit être conçue pour les centres commerciaux et doit
être en mesure de communiquer avec le logiciel de gestion commerciale existant.
2.3.3 Outils de conduite de projet
L’adéquation du projet au processus de développement peut largement affecter le

sort d’un projet informatique. Donc un mauvais choix du processus de développe-
ment peut conduire un projet à l’échec. Par conséquent, afin de pouvoir choisir le
cycle adéquat nous avons tout d’abord dressé un tableau comparatif de quelques
cycles potentiels :
– RUP(Rationnal Unfied Process)
– Cycle en V
– XP(Extrême Programming)
– 2TUP(Two Track Unified Process) est appelé encore Y
D’après le tableau Tableau 2.1, seul 2TUP propose un intérêt pour la gestion de la
complexité technique. Or notre projet fait lui aussi large place à technologie (RFID,
Etiquette électroniques, antennes, etc.) ce qui implique l’élimination du risque tech-
nologique
Les trois autres n’y attachent pas grande attention. En effet, RUP propose plutôt
un cadre complet pour la conduite de projet, mais n’attache pas trop d’importance
pour le développement lui-même.
Le cycle en V quant à lui, permet de maîtriser le développement à travers les véri-

fications à la fin des phases, mais il n’offre toujours pas de gestion de la complexité
technique.
Quant à XP elle est beaucoup plus adaptée à des projets de petites taille et de plus
des activités telles que l’estimation, la planification , s’avèrent être très difficiles à
réaliser ce qui est non acceptable pour un projet tel que le notre.
Il s’avère donc incontestablement que c’est effectivement 2TUP qui est le plus ap-
proprié à notre projet. Ci après une illustration représentant les grandes phases de
la méthode Two Track Unified Process.
9
Processus Description Avantages Inconvénients
RUP RUP est à la fois une Propose des modèles • Coûteux à

personnaliser
méthodologie de de documents, et des
• Très axé processus,
conduite et de canevas pour des
au détriment du
développement de projets types
développement : peu
projets et un outil prêt
de place pour le code
à l’emploi
et la technologie
V Chaque phase en Préparation des phases • Obligation de
définir la totalité des
amont de la de vérification au
besoins au départ
production du logiciel moment de l’Analyse
• Validation
prépare la phase et de la Conception
fonctionnelle tardive
correspondante de
vérification en aval de
la production du
logiciel
XP Tout l’accent est mis • Adaptée à des • Difficultés lorsque la
projets de petites maintenance doit être
sur les bonnes
tailles et sur de petites faite par une autre
pratiques de la équipes équipe
programmation avec • Pousse à l’extrême • Difficultés de
un déroulement par les principes simples planification ,
itérations courtes et de programmation d’estimation de
gérées collectivement charge, d’implication
de l’équipe
2TUP S’articule autour de Fait une large place à Ne propose pas de
l’architecture la technologie et à la documents types
gestion du risque
Table 2.1: Tableau comparatif de quelques méthodologies de developpement
10
Figure 2.2: Les phases du projet selon processus en Y
Il convient aussi de noter que le rapport est adjacent à la méthode 2TUP. En effet,
nous retrouvons la plupart des phases de la méthode comme suit :
1. La branche gauche (fonctionnelle) : capitalise la connaissance du métier de
l’entreprise. Elle constitue généralement un investissement pour le moyen et le
long terme. Les fonctions du système d’information sont en effet indépendantes
des technologies utilisées. Cette branche comporte deux étapes ; i)La capture
des besoins fonctionnels, qui produisent un modèle des besoins focalisé sur le
métier des utilisateurs et ii) L’analyse.
2. La branche droite (architecture technique) : capitalise un savoir-faire tech-
nique. Elle constitue un investissement pour le court et moyen terme. Les
techniques développées pour le système peuvent l’être indépendamment des
fonctions à réaliser. Cette branche comporte deux étapes : i) La capture des
besoins techniques et ii) La conception générique.
3. La branche du milieu (conception et réalisation) : à l’issue des évolutions du
modèle fonctionnel et de l’architecture technique, la réalisation du système
consiste à fusionner les résultats des 2 branches. Cette fusion conduit à l’ob-
tention d’un processus en forme de Y comme il montre le figure Figure 2.2.
Cette branche comporte quatre étapes suivantes : i) La conception prélimi-
naire, ii) La conception détaillée, iii) Le codage et iv) L’intégration.
2.3.4 Langage de modélisation
Le processus 2TUP s’appuie sur UML tout au long du cycle de développement, car
les différents diagrammes de ce dernier permettent de part leur facilité et clarté, de
bien modéliser le système à chaque étape [1].
UML se définit comme un langage de modélisation graphique et textuel destiné à
comprendre et décrire des besoins, spécifier, concevoir des solutions et communiquer
des points de vue. UML unifie à la fois les notations et les concepts orientés objet.
Il ne s’agit pas d’une simple notation, mais les concepts transmis par un diagramme
ont une sémantique précise et sont porteurs de sens au même titre que les mots d’un
langage, c’est pour ça qu’UML est présenté parfois comme une méthode alors qu’il
ne l’est absolument pas [1].
2.3.5 Estimation des extrants et intrants
2.3.5.1 Extrants
1. Un code source avec des commentaires de l’application doit être livré.

2. Un script de génération de la base de données.
3. Documentation :sous format électronique (PDF , Word).
11
4. Manuel d’utilisation qui détaille les différents tâche et facilite l’utilisation de

produit.
5. Fiche technique (Conception UML bien détaillée) :
– Diagramme Use Case
– Diagramme de Classe
– Diagramme de Séquence
– Diagramme de déploiement
– Diagramme de contexte (statique et dynamique)
Extrant Description
Code source Contient le code complet l’application avec des commentaires explicatifs
Base de données Contient le script de l’importation de la base de données
Description technique détaillée des étapes d’installation et de mise en
Fiche Technique
place du réseaux.
Manuel d’utilisation Initier et faciliter l’accès aux différents services offerts par l’application
Table 2.2: Descriptions des extrants
2.3.5.2 Intrants
1. Ressources humaines : 2 techniciens.

2. Ressources matérielles : 2 PC portables, Switch, Antennes, Etiquettes.
2.4 Conclusion
Durant ce premier chapitre qui vise à situer le contexte général du projet, nous
avons commencé par la présentation de l’entreprise d’accueil en termes de culture
et de missions. Ensuite, nous avons présenté le projet en étalant ses objectifs, et
ses bénéfices escomptés, la conduite du projet que nous avons adopté pour le mener
efficacement, à travers le cycle de développement choisi, et le planning élaboré. Il faut
tout de même noter que les prochains chapitres de ce rapport, s’inspirent fortement
du processus de développement en Y adopté.
12
3 Analyse du projet
3.1 Introduction
Comme le suggère le cycle de développement en Y, le présent chapitre sera consacré,

à l’analyse fonctionnelle et technique du projet. Ainsi, la première section traite
l’étude fonctionnelle du projet, où nous prêtons attention à la capture de besoins
fonctionnels que nous traduisons en spécifications, projetées ensuite en langage UML
à travers les diagrammes des cas d’utilisation. La seconde section est consacrée à
l’étude technique de projet. Nous présentons en premier lieu, l’architecture adoptée
pour développer le projet en expliquant la notion de l’architecture logicielle et les
exigences techniques qu’il doit assurer. En deuxième lieu, nous proposons une vision
générale sur la solution logicielle adaptée.
3.2 Etude fonctionnelle
Le cycle de développement opté propose une phase d’analyse séparée en deux branches
parallèles à savoir l’étude fonctionnelle et l’étude technique du projet. Cette section
traite et l’étude fonctionnelle de façon séparée à l’étude technique pour des raison
relatif à l’organisation du rapport.
L’objectif de la branche fonctionnelle du processus Y est la capture des spécifications
et des contraintes fonctionnelles. Cette étude focalise sur le métier indépendamment
de toute technologie, et essaye d’adapter le plus possible le système avec les besoins
des utilisateurs.
3.2.1 Etude de l’existant
Pour pouvoir créer un projet performant, nous devons passer par une étape d’étude
de l’existant pour nous collaborer à suggérer une conception évolutive à notre projet.
En effet, dans cette partie nous allons essayer de donner un aperçue sur l’existant,
cette étude va nous aider à accumuler des idées pour pouvoir trouver une solution
convenable qui répond aux différents besoins de l’utilisateur.
13
Chapitre 3 Analyse du projet
Description du système actuel L’étiquette papier est une moyenne d’identifica-

tion du produit. Elle contient les informations propres au produit comme son prix,
son nom, son code a barre, etc. Pour faire une mise à jour de l’affichage des prix on
procède au changement physique de l’étiquette d’affichage. (Figure Figure 3.1 )
Figure 3.1: Etiquette papier
3.2.2 Critique
Après une exploration de l’environnement actuel, nous dresserons la liste des dys-
fonctionnements du système actuel :
– Les codes barres et les étiquettes en papier permettaient l’identification mais ne
permettaient pas la mise à jour des données
– Quelque fois les prix ne sont pas conformes entre les étiquettes papier et les caisses.
– Certaines fois le produit ne comporte pas une étiquette papier.
– Perte de temps lors de la mise en place des étiquettes papier.
3.2.3 Collecte des besoins fonctionnels

La spécification des besoins va nous permettre d’avoir une meilleure approche des
utilisateurs, des fonctionnalités et de la relation entre les deux. Elle sera sous forme
de cas d’utilisation.
Pour cela nous allons procéder ainsi :
1. Identification des acteurs du nouveau système.
2. Elaboration des diagrammes de contexte
3. Identification des cas d’utilisations.
4. Description des cas d’utilisations.
3.2.3.1 Les acteurs
Un acteur réfère à une mission et à des responsabilités assumées par des entités
externes au système étudié. Ces entités (utilisateur, dispositif matériel ou autre
système) interagissent directement avec le système étudié. L’étude de la typologie
des acteurs du système à conduit à la classification décrite dans(Tableau 3.1) :
14
Acteur Type Description

Responsable Humain Représente une personne qualifiée qui peut :
- Ajouter un (des) produit(s)
- Consulter la liste des produits
- Modifier le prix d’un produit
- Supprimer un (des) produit(s)
Système de gestion Système - Envoie les mis à jour
- Enregistre les modifications dans la base des données
Table 3.1: Identification des acteurs
3.2.3.2 Diagrammes de contexte statique et dynamique

– Diagramme de contexte statique
Nous commençons, en premier lieu, par une modélisation par acteur afin de cerner
tous les services que le système offrira à ses utilisateurs. Le schéma Figure 3.2 pré-
sente le diagramme de contexte statique. Ce diagramme représente les acteurs du
projet de façon structurée.
Figure 3.2: Diagramme de contexte statique
– Diagramme de contexte dynamique

Un diagramme de contexte dynamique représente les messages échangés entre le
système d’information et les acteurs (sous le diagramme apparait chaque message
avec les attributs qu’il contient). Le schéma Figure 3.3 présente le diagramme de
contexte dynamique.
Figure 3.3: Diagramme de contexte dynamique
15
Légendes 1 :
1. demande d’accès
2. acceptation ou refus d’authentification.
3. demande de modification des informations du produit.
4. informations modifiées.
5. demande d’une mis à jour.
6. mis à jour effectuée
7. demande de modification d’affichage.
8. affichage modifié.
3.2.3.3 Identification des Cas d’utilisation par ses acteurs
Les cas d’utilisation (CUs) permettent de représenter le fonctionnement du système

vis-à-vis de l’utilisateur : c’est donc une vue du système dans son environnement
extérieur [2].
La localisation des cas d’utilisation au premier temps offre la compréhension de la
fonctionnalité du système. Pour cette raison, la description de chaque cas d’utili-
sation est nécessaire pour facilité la modélisation des diagrammes. En effet le dia-
gramme des cas d’utilisation sert à raffiner les fonctionnalités principales que le
système doit assurer.
L’identification des cas d’utilisation, nous donne un aperçu des fonctionnalités futur
que le système doit l’implémenter. Cependant, il nous faut plusieurs itérations pour
arriver à constituer des cas d’utilisations complets. A fin de constituer les cas d’uti-
lisations, il faut considérer l’intention l’émission et la réception de chaque message.
1) S’authentifier :
– Intention : s’authentifier au l’interface.
– Action : consulter l’interface d’accueil.
2) Gérer le produit :
– Intention : gérer le produit.
– Action : consulter, ajouter, modifier et supprimer.
3) Gérer les étiquettes électroniques :
– Intention : gérer les étiquettes.
– Action : vérifier, modifier, ajouter et consulter
4) Mettre à jour les informations :
– Intention : mise à jour des informations.
– Action : mettre à jour des informations et enregistrer les modifications.
Considérons 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 use case recherchés (Tableau 3.2).
16
Cas d’utilisation Acteur Messages émis/Reçus par les acteurs

S’Authentifier Responsable Emet : login et mot de passe
Reçue : l’interface d’accueil
Gérer les produits Responsable Emet : Créer, modifier et supprimer un (des) produit(s)
Reçu : Les données concernant un (des) produit(s)
Gérer les étiquettes Responsable Emet : envoi des informations
Reçue : mise à jour effectué
Mettre à jour les modifications Système de gestion Emet : les modifications des informations enregistrées dans
la base de donnée
Reçu : la validation des modifications recommandées/les
informations mises à jours par notre application.
Table 3.2: Descriptions des cas d’utilisation
3.2.3.4 Description détaillée de cas d’utilisation
Afin de mieux comprendre un fonctionnement d’un Cas d’utilisation, nous allons

présenté une fiche descriptive pour chaque cas d’utilisation qui englobe les informa-
tions suivantes :
– Un sommaire d’identification : qui résume la propriété des cas d’utilisations.
– Des pré-conditions au début de chaque cas d’utilisation doivent être marqué.
– Un scénario nominal expliquant le cas d’utilisation en sujet.
– Un (des) scénarios d’exception
1) Cas d’utilisation : “S’authentifier”
cette cas d’utilisation est répresentée dans Tableau 3.3
Fiche Descriptive du CU : “S’authentifier”
Sommaire
Titre : S’authentifier
Acteur : Responsable
Objectif : ce cas d’utilisation est utilisé pour identifier l’utilisateur
Précondition : Néant
Scenario nominal
1. Le cas d’utilisation débute quand le responsable va utiliser l’application.
2. Le système valide les informations saisies, en cas d’erreur il exécute Exception1. Sinon l’interface
d’accueil de l’application s’affiche en accordant les privilèges.
Exception1
Le système affiche le message « Login et/ou mot de passe non valide ! ! » et lui donne la main pour
réessayer une autre fois
Post condition : L’utilisateur est authentifié

Table 3.3: Description du cas d’utilisation “s’authentifier”
17
2) Cas d’utilisation : “Gérer les produits”

Le cas d’utilisation “Gérer les produits” est répresentée dans Tableau 3.4
Fiche Descriptive du CU : “Gérer les produits”
Sommaire
Titre : Gérer les produits
Objectif : ce cas d’utilisation est utilisé pour gérer les informations produits (ajouter, supprimer et modifier
les informations relatives à un produit).
Table 3.4: Description du cas d’utilisation “Gérer les produits”
Le Cas d’utilisation “Gérer les produits” est assez volumineux c’est pourquoi nous
avons décidé de le découper en sous Cas d’utilisation comme il est illustré dans
(Figure 3.4).
Figure 3.4: Le CU “Gérer les produits”
Le responsable prend en charge la gestion des produits telle que l’ajout d’un nouveau
produit, la modification des informations d’un produit ainsi la suppression d’un
produit.Tableau 3.5
3) Cas d’utilisation : “Gérer les étiquettes électroniques”
Ce cas d’utilisation est répresentée dans Tableau 3.6.
18
Titre Ajouter produit Supprimer produit Modifier les

Sommaire informations du
produit
Acteur Responsable Responsable Responsable
Objectif Ajouter un (des) Supprimer un (des) Modifier les
produit(s) produit(s) informations d’un
(des) produit(s)
Précondition Responsable Responsable Responsable

authentifié authentifié authentifié
Scenario nominal 1. Le responsable 1. le responsable ouvre 1. le responsable ouvre

consulte la liste de l’anglet d’ajout. l’anglet de
produit. 2. Le responsable modification.
2. Le responsable saisie les informations 2. Le responsable
saisie l’ID du produit du nouveau produit et saisie l’ID du produit
à supprimer. valide l’action d’ajout. à modifier.
3. Le responsable 3. le système mis à 3. Le responsable
supprime le produit jour les informations modifie les
(automatiquement et modifie l’affichage informations.
l’étiquette propre à ce de l’étiquette ajoutée. 4. Le système mis à
produit se supprime.
4. le systéme imprime jour les données et
4. Le système de
gestion mis à jour les l’étiquette contenant modifie l’affichage de
données (Produits + les informations l’étiquette.
Etiquette).
statiques (nom du
5.Le responsable se
produit, son code à
déplace pour éliminer
barre...).
l’étiquette.
Exception1 Pas d’exception ID Produit inexistant ID Produit inexistant
Post condition Un (des) produit(s) Un (des) produit(s) (des) information(s)

ajouté(s) supprimé(s) modifiée(s)
Table 3.5: Description des sous Cas d’utilisation du CU “Gérer les produits”
Fiche Descriptive du CU : “Gérer les étiquettes électroniques”
Sommaire
Titre : Gérer les étiquettes électroniques
Objectif : ce cas d’utilisation est utilisé pour gérer les étiquettes (vérifier, modifier,
ajouter et consulter ).
Table 3.6: Description du cas d’utilisation “Gérer les étiquettes électroniques”
Le Cas d’utilisation “Gérer les étiquettes électroniques” est assez volumineux. Par
conséquent, nous avons choisi de le découper en sous Cas d’utilisation comme il est
illustré dans(Figure 3.5).
19
Figure 3.5: Cas d’utilisation gérer étiquette
Le responsable prend en charge la gestion des étiquettes telle que la vérification

de son état (actif/inactif), consultation des informations d’une étiquette (prix. . . ),
modification d’affichage de l’étiquette suite a une modification des informations d’un
produit et une mise a jour. Ainsi l’ajout d’une nouvelle étiquette suite à un ajout
de produit. Tableau 3.7
4) Cas d’utilisation : “Mettre à jour les informations” détaillé par Tableau 3.8 ” :
20
Titre Vérifier Consulter les Modifier Ajouter une Supprimer

l’état informations l’affichage étiquette une
d’étiquette des étiquettes étiquette
Précondition Responsable Responsable Produit modifié Responsable Responsable
authentifié authentifié + Mise à jour authentifié + authentifié
effectuée Ajout d’un + produit
nouveau produit supprimé
Scenario 1. Le 1. Le 1. Le responsable 1. le responsable 1. le
responsable responsable ouvre l’anglet de ouvre l’anglet responsable
nominal
ouvre l’anglet ouvre l’anglet de modification. d’ajout. ouvre
de vérification. consultation 2. Le système 2. Le responsable l’anglet de
2. Le d’information. modifie saisie les suppression.
responsable 2. Le l’affichage. informations du 2. Le
saisie l’ID de responsable nouveau responsable
3. Le système
l’étiquette à saisie l’ID de étiquette. élimine
vérifier l’étiquette à mis à jour les l’étiquette.
consulter. 3. Le système mis
3. le système informations 3. Le
3. Le système à jour les
vérifie l’état affiche les modifiées. système mis
informations
d’étiquette informations
à jour les in-
d’étiquette suite d’étiquette.
puis l’affiche à une formations.
communication
au responsable.
à l’intermidiaire
de Transceiver
et de l’antenne.
4. le systéme
imprime
l’étiquette
contenant les
informations
statiques (nom
du produit, son
code à barre...).
Exception1 ID étiquette ID étiquette Etiquette Etiquette mal Produit n’a
introuvable introuvable inactive attribuée ! pas
supprimé
Post Etiquette Informtation affichage modifiée Etiquette ajoutée Etiquette
condition verifiée consultée eliminée
Table 3.7: Description des sous CU du CU “Gérer les étiquettes électroniques”
21
Fiche Descriptive du CU : “Mettre à jour les informations”
Sommaire
Titre : Mettre à jour les informations
Acteur : système de gestion
Objectif : ce cas d’utilisation permet de mettre à jour des informations relatives aux produits.
Précondition : le responsable modifie une (les) information (s) du produit
Scenario nominal : ce cas d’utilisation commence lorsque il y’a une modification au niveau des
informations relatives aux produits
1. Le responsable s’authentifie
2. Le responsable ouvre l’anglet de modification des informations de produit
3. Le responsable saisie l’ID de produit à modifier
4. Le responsable modifie les informations du produit
5. Le système mis a jour les informations modifiées ( base de données entreprise + base de données
application)
6. Le système modifie l’affichage
Exception1
Le système affiche le message « Login et/ou mot de passe non valide ! ! » et lui donne la main pour
réessayer une autre fois
Post condition : : les informations sont mises à jour

Table 3.8: Description du cas d’utilisation “Mettre à jour les informations”
3.2.4 Diagramme de Cas d’utilisation complet
22
Figure 3.6: Diagramme de Cas d’utilisation complet
3.3 Etude technique du projet
Figure 3.6 représente l’ensemble des cas d’utilisation de notre système. En effet, Ce
diagramme montre les quatre cas d’utilisation principals à savoir l’authentification,
gestion des produit, mise à jour des informations et enfin la gestion des étiquettes.
Cette partie traite de manière générale la recensement des besoins techniques. Cette
phase sert de complément à la collecte des besoins fonctionnels. L’idée vectrice à ce
niveau tourne autour de la relève des différentes contraintes qui ne sont ni descrip-
tives du métier des utilisateurs, ni descriptives d’un point de vue applicatif ou d’un
quelconque processus métier.
Nous pouvons résumer cette partie à travers les questions qui vont suivre :
– Quel sont les moyens technologiques dont nous disposons pour afin de mettre en
oeuvre l’application ?
– Avons nous suffisamment de bagages techniques afin d’assurer la totalité des be-
soins fonctionnels énoncés ?
– Où et Comment allons nous déployer notre application par rapport au système
d’information existant ?
Cette phase est primordiale dans la mesure où elle permet de déterminer les risques
technologiques qui peuvent exister. Pour ce faire nous devrons connaitre à priori
le système matériel et les outils stratégiques choisis dans un premier temps, et en
second essor nous allons extraire les contraintes non fonctionnelles afin de dresser un
modèle d’analyse technique.Nous détaillerons par la suite les composantes ce modèle
mais pour l’instant l’une des choses à savoir à propos de ce modèle est qu’il s’exprime
sur deux axes :une spécification logicielle et une structure matérielle exploitable.
Pour ce faire un certain nombre de diagrammes ( Déploiement ,Composant ,etc. . . )

seront mis en jeu. Cette étape s’achève avec la découverte et l’élimination des pro-
blèmes d’ordre technologique mis en jeu. Cette étape s’achève avec la découverte et
l’élimination des problèmes d’ordre technologique mis en jeu.
3.3.1 Spécification technique (vision materielle)
L’objectif de la branche technique du processus Y est de recenser les contraintes et

les choix techniques et matériels dimensionnant la conception du système. Le but
est d’éviter les risques techniques et les problèmes que l’application pourrait rencon-
trer comme les problèmes d’intégration, d’interopérabilité, d’évolution. Ainsi, nous
présenterons tout d’abord l’architecture réseau générale comme il montreFigure 3.7.
23
Figure 3.7: Architecture générale du projet
3.3.2 Détails techniques du matériels utilisés
Tout d’abord nous vous présenterons les détails techniques du matériels avec lequels
nous travaillons et par la suite nous passerons au détail logiciel.
3.3.2.1 Etiquette électronique
Définition
C’est une étiquette équipée d’une puce électronique, elle est représentative d’un
produit, elle remplace l’étiquette papier sur les rayons dans les grandes surfaces,
moyennes surfaces et pharmacies. Elle permet la mise à jour à distance des prix sans
aucune intervention humaine dans les rayons [3].
Composant d’une étiquette électronique
Une étiquette électronique est constituée d’une puce et d’une antenne comme il
montre dansFigure 3.8. La puce contient un espace mémoire, permettant de stocker
différentes informations (en fonction du type d’étiquette) dont un identifiant unique
(un code produit électronique) qui permet d’identifier l’objet sur lesquels est collée
l’étiquette électronique [3].
24
Figure 3.8: Composants d’une étiquette RFID
L’étiquette, en polycarbonate soudé, se compose de plusieurs zones d’affichage pré-

sentées dansFigure 3.9 :
– Une zone principale pour l’affichage du prix.
– Une zone pour l’affichage du prix au litre ou au kilo.
– Une zone libre (stock restant, qté vendue, code EAN...).
Figure 3.9: Interface d’une étiquette électronique
Il existe 3 familles d’étiquettes électroniques :

– Les étiquettes passives : ne nécessitent pas de source d’énergie en dehors de celle
fournie par les lecteurs au moment de leur interrogation.
– Les étiquettes semi-passives : équipées d’une batterie, mais n’émettent pas de
signal (réponse à une requête comme les étiquettes passives).
– Les étiquettes actives : équipées d’une batterie, capables d’émettre un signal et
être lues sur de longues distances, avec une mémoire allant jusqu’à 10 Kbits.
Ces étiquettes actives ne dépassent pas 10 ans d’âge. Elles sont fournies vierges
et pourront être écrites plusieurs fois, effacées, modifiées et lues. Le nombre de
répétition de ces opérations peut dépasser les 500 000 ou 1 million [3].
25
Comment fonctionne ? L’ordinateur central envoie automatiquement la mise à

jour des prix sur l’ordinateur dédié à l’application (et installé dans le magasin) en
même temps qu’il l’envoie aux caisses. Ce fichier, une fois traité, est transmis à
l’émetteur qui envoie selon sa technologie :
– Par ondes Radio Basse Fréquence (38,4 KHz)
– Par infrarouge
– Par ondes radio Haute Fréquence (2,4 GHz)
Les mises à jour de prix ou des informations vers les étiquettes correspondantes.
L’étiquette est bidirectionnelle : le signal passe dans les deux sens, du système in-
formatique magasin vers l’étiquette et inversement. « Cela nous permet de savoir à
tout moment quelles sont les étiquettes actives et celles qui ont un problème ».
Pourquoi s’équiper d’étiquettes électroniques ?

– Automatise les changements de prix dans votre magasin
– Garantie la concordance des prix entre les caisses et les rayons
– Alignement des prix avec la concurrence immédiate
– Réoriente le personnel vers le client et le commerce
– Image de marque de l’enseigne dynamisée - Connaissance du stock (quantité en
stock, quantité en attente et date de livraison)
– Zone dédiée à l’animation commerciale (Remise, Promo, Ancien prix, Soldes...)
3.3.2.2 Transceiver (Switch)
Il envoie les informations par un système radio aux étiquettes, cette équipement est
représenté dansFigure 3.10.
Figure 3.10: Transceiver
3.3.2.3 Antenne
L’antenne Figure 3.11 est un câble relié à l’emetteur par un conducteur ,il est gé-
neralement installé sur le plafond de l’accumulateur. le concevoir d’une antenne est
un travail trés professionnelle.
Pour le vrai utilisation, quatres étapes doivent êtres suivies :
26
– Les ingénieures étudient la dispositif du magazin

– Faire une conception du boucle
– Essais
– Ajuster
Figure 3.11: Antenne
3.3.2.4 Réseaux RFID
RFID (Radio Frequency Identification) en français « identification par radio fré-

quence » cette technologie permet d’identifier un objet, d’en suivre le cheminement
et d’en connaître les caractéristiques à distance grâce à une étiquette émettant des
ondes radio, permet la lecture des étiquettes même sans ligne de vue directe et peut
traverser de fines couches de matériaux (peinture, neige, etc.).
3.3.3 Architecture logicielle

Une architecture logicielle exprime un schéma d’organisation structurel et fonda-
mental pour les solutions logicielles. Elle fournit un jeu de sous-systèmes prédéfinis,
spécifie leurs responsabilités et inclut les rôles et les instructions générales pour
organiser les relations entre eux. Car, sans une bonne architecture, un système d’in-
formation est difficile à comprendre, prédire, gérer et optimiser. Les buts d’une
architecture sont la compréhension du système étudié en définissant ses limites et la
gestion de sa croissance [4].
3.3.3.1 Exigence de projet
L’architecture logicielle du projet, subit un certain nombre de forces (buts et contraintes)

comme la portabilité et la maintenance. En effet, il faut définir les grands objectifs
techniques de la future architecture, c’est-à-dire de bien prendre en compte l’en-
semble des forces qui vont s’exercer sur le futur système ainsi que la puissance de
27
chacune d’entre elles. Nous avons donc défini les objectifs techniques que son archi-
tecture doit assurer, comme il est décrit dans(Tableau 3.9) :
Objectifs Descriptions
Fiabilité Nécessité d’exécuter les fonctions attendues avec la précision

requise.
Disponibilité Le système doit être en permanence à la disposition de ses

utilisateurs
Evolutivité Il doit être possible d’étendre le système
Réutilisabilité Il doit être possible de réutiliser certains modules du système

Table 3.9: Forces dans l’architecture logicielle
3.3.3.2 Architecture logicielle du projet
Parmi les différentes façons de structurer une architecture, la mieux adaptée et maî-
trisée en informatique est l’approche par couches [2]. Une couche (Layer en anglais)
est une division logique et horizontale d’un système qui fournit une abstraction par-
ticulière du système aux couches supérieures. Tableau 3.9Chaque couche possède
des responsabilités spécifiques. Dans une structuration par couches, les couches in-
férieures prennent en charge des responsabilités qui offrent un socle de base pour les
couches supérieures, permettant d’abstraire celles-ci de problématiques qui ne les
concernent pas [5].
Ainsi, nous avons adopté un découpage en quatre couches(Figure 3.12) .
28
Figure 3.12: Architecture logicielle du système
– Couche présentation : Ou interface homme machine, elle correspond à la partie

de l’application visible et interactive avec l’utilisateur.
– Couche application : Son principal but est de fournir des services spécifiques à
la couche Présentation. Ces services correspondent aux règles du métier définies
lors de la phase d’analyse. Elle prend en charge les aspects de contrôle des cas
d’utilisation [4].
– Couche métier : Représente le cœur de l’application. Elle correspond à la partie
fonctionnelle de l’application, celle qui implémente la " logique ", et qui décrit les
opérations que l’application opère sur les données en fonction des requêtes des
utilisateurs, effectuées au travers de la couche présentation.
– Couche mapping : Cette couche est certainement l’une des plus importantes. C’est
ici que nous trouvons les fonctionnalités de base qui offrent les mécanismes de
conversion objet/relationnel à travers les getters et les setters. Les classes consti-
tuant cette couche sont générées par ODBC [4].
– Couche stockage : Cette couche est responsable du stockage physique de données.
Elle assure le support transactionnel. En ce qui concerne notre système, cette
couche se basera sur le modèle relationnel. La base de données est générée à
partir d’un script SQL généré lui-même à partir du modèle physique de données
29
[4].
Au niveau du code java, le développeur manipule des classes et utilise des requêtes
avec le langage SQL. Les actions effectuées sur les instanciations de classes sont
répercutées sur les tables de la base de données.
3.3.3.3 Solution logicielle adaptée
Java comme un language :
Le langage Java est un langage de programmation informatique orienté objet créé par
James Gosling et Patrick Naughton, employés de Sun Microsystems, avec le soutien
de Bill Joy (cofondateur de Sun Microsystems en 1982), présenté officiellement le 23
mai 1995 au SunWorld.
ODBC comme un middleware : Au niveau de la liaison entre l’application et la

base de données on utilise un middleware de type ODBC (Open Database Connec-
tivity). Notre choix est justifié par l’avantage suivant :
– Pas besoin de modifier l’application pour leur permettre accéder à un serveur de
données spécifique. Il suffit que le pilote propre à ce SGBD soit présent aux côtés
de l’application.
SGBD de type MySQL : Nous allons choisir MySQL comme un DGBD car a
des avantages fameuses qui sont :
– Plusieurs moteurs de stockage adaptés aux différentes problématiques, configu-
rable au niveau table.
– Facilité de déploiement et de prise en main.
– Open Source, bien que les critères de licence soient de plus en plus difficiles à
supporter.
3.3.4 Diagramme de déploiement
Selon l’étude technique déjà élaborée, nous proposons dans cette partie le diagramme
de déploiement UML répresenté dansFigure 3.13.
30
3.4 Conclusion
Figure 3.13: Diagramme de déploiement
3.4 Conclusion
Au cours de ce chapitre, nous avons detaillé l’analyse du projet qui est composée
des deux branches parallèles : l’étude foonctionnelle et celle technique du projet.
L’étude fonctionnelle du projet consiste à capturer les besoins fonctionnels en termes
d’acteurs et de fonctionnalités principales, raffinées ensuite en des spécifications
fonctionnelles de nature homogènes et modélisées vers la fin en diagrammes de cas
d’utilisation. L’étude technique du projet a présenté l’architecture logicielle et les
exigences techniques de l’application, la technologie utilisée et le rapport détaillé
des frameworks techniques choisis. Dans le chapitre qui suit, nous présentons la
conception du projet.
31
4 Conception détaillée
4.1 Introduction
Ce chapitre est essentiellement axé sur la phase de conception détaillée comme il
est précisé dans le processus de développement en Y. En effet, l’objectif de cette
étape la phase est de reprendre le modèle d’analyse et le refaire d’une façon plus
raffinée pour en dégager les modèles statique et dynamique. Ainsi nous avons la
partie relative au modèle statique suivie de celle du modèle dynamique.
4.2 Le modèle dynamique

A ce stade nous nous approchons de la fin de la partie analyse de notre projet. Le
modèle dynamique constitue la troisième et dernière activité de l’étape d’analyse.
Normalement elle doit se faire quasi en parallèle avec la modélisation statique mais
nous avons décidé de les présenter de manière séquentielle. Cette activité sera décrite
grâce aux différents diagrammes UML qui mettent en avant la dynamique dans un
projet. Le diagramme de séquence et le diagramme d’activité feront l’objet de cette
section.
4.2.1 Le diagramme de séquence

4.2.1.1 Modification produit et affichage
scénario
1. Le responsable saisie son login et son mot de passe pour s’authentifier au
système.
2. Le responsable passe à vérifier l’état d’étiquette (diagramme vérification éti-
quette).
3. Le responsable consulte le produit à modifier par son ID.
4. Le responsable modifie les informations de produit cherché
5. Le système fait la mise à jour.
6. Le système informe le responsable que la modification d’affichage et la modi-
fication des informations est effectue avec succès.
33
Chapitre 4 Conception détaillée
Figure 4.1: Diagramme de séquence “Modifier produit et affichage”
4.2.1.2 vérification étiquette
Scénario
1. Le système envoie l’ID étiquette vers le Transceiver.
34
2. Le Transceiver envoie l’ID étiquette vers l’antenne.

3. L’antenne envoie un Ping vers l’étiquette.
4. L’étiquette envoie une réponse vers l’antenne.
5. L’antenne envoie un acquittement positive (Ack) vers le Transceiver.
6. Le Transceiver alerte le système que l’étiquette est existe.
7. Le Transceiver alerte le système que l’ID n’existe pas.
Figure 4.2: Diagramme de séquence “vérification étiquette”
4.2.1.3 Modification affichage
scénario
1. Le système fait une sauvegarde dans sa base de données.
2. Le système envoie une requête de mise à jour vers la base des données d’en-
treprise.
3. Le système envoie les informations vers l’étiquette.
4. Le Transceiver envoie les informations vers l’antenne cible.
5. L’antenne envoie les informations modifiées vers l’étiquette cible.
6. L’étiquette envoie une réponse vers l’antenne.
7. L’antenne envoie un acquittement positive vers le Transceiver.
8. Le Transceiver informe le responsable que la modification est effectuée.
35
Figure 4.3: Diagramme de séquence “modification affichage”
4.2.1.4 Ajouter produit
Scénario
1. Le responsable commence à saisire les informations d’authentification (login,

mot de passe).
2. Le responable envoie les informations du produit vers le système.
3. Le système fait une mise à jour de type ”insérer” vers la base des données de
l’entreprise.
4. Le système informe le responsable que l’opération d’ajout est effectue avec

succès.
5. Le responsable imprime l’étiquette.
36
Figure 4.4: Diagramme de séquence “ Ajouter prouduit ”
4.2.2 Diagramme d’activité
Un diagramme d’activité est un cas particulier de diagramme d’état, exprime des

flots d’activités (flots de contrôle) de type procédural, sous la forme d’un graphe
d’activités. Dans ce qui suit, nous étalons les diagrammes d’activités pour quelques
cas d’utilisation dans notre système.
4.2.2.1 Diagramme d’activité “S’authentifier”
Pour accéder à l’application, le responsable doit s’authentifier en entrant son lo-

gin et son mot de passe. Le processus d’authentification peut être résumé dans le
diagramme d’activité suivant :
37
Figure 4.5: diagramme d’activité "S’authentifier"
4.2.2.2 Diagramme d’activité “Modifier l’affichage”
Afin de modifier l’affichage, tout d’abord le responsable doit vérifier l’état d’éti-
quette, siasie l’ID de produit à modifier, puis il passe à la modification des infor-
mations, enfin le système mis à jour les données et il modifie l’affichage de l’éti-
quette.l’opération de modification d’affichage peut être résumée dans le diagramme
d’activité suivant :
38
Figure 4.6: Diagramme d’activité ” Modifier l’affichage”
39
4.2.2.3 Diagramme d’activité “Ajouter Produit”
Afin d’effectuer cette action, le responsable saisie les informations du nouveau pro-
duit, enregistre les données et modifie l’affichage de l’étiquette, enfin il passe à
l’impression d’étiquette. Le processus d’ajout un produit peut être résumé dans le
diagramme d’activité suivant :
Figure 4.7: Diagramme d’activité ”Ajouter Produit”
4.3 Le modèle statique

Le modèle statique ici n’est autre que le diagramme de classe d’analyse. Dans cette
section nous allons élaborer le diagramme de classe CU par CU. Le développement du
modèle statique constitue la deuxième activité de l’étape de la concepton détaillée.
40
4.3 Le modèle statique
Elle se situe sur la branche gauche du cycle en Y.A partir de l’analyse que nous
avons déjà fiate lors de la partie analyse du projet, nous avons dégagé un ensemble
d’entités et de dépendances, cela a été traduit par UML en un diagramme de classes
qui modélise le système réel étudié. Ci dessous le diagramme de classes réalisé :
Figure 4.8: Diagramme de classe
41
Dans ce qui suit nous allons lister la liste de toutes les entités en expliquant le rôle
de chacune(Tableau 4.1) :
Classe Description
Responsable Présentant l’utilisateur qui gère l’application de système.
Produit Présentant l’objet produit qui est identifié par son nom et son ID.
Etiquette Présentant l’objet étiquette qui est identifiée par son ID et son type,
une étiquette est attribué à un seul produit
Connexion Présentant la classe de connexion qui est composée par des méthodes.
ListeDriver Présentant la liste de driver qui assure la communication entre
l’application et la base de données
Transceiver Présentant l’objet Transceiver qui permet l’envoie des informations
vers l’étiquette, cette classe est composé par des méthodes sert
l’opération d’envoie.
Antenne Présentant l’objet antenne, cette classe maintenir la communication
entre le Transceiver et l’étiquette
Table 4.1: Liste des classes
4.4 Conclusion
Après avoir accomplir la conception de notre application, nous allons entamer la par-
tie “codage et test”. Dans le chapitre suivant, nous allons présenter l’environnement
de travail, les outils de développement utilisés, ainsi que quelques imprimes écran
des tests faits pour vérifier que notre système répond bien au cahier des charges.
42
5 Codage et test
5.1 Introduction
Ce chapitre représente la dernière partie dans la réalistion d’application. Cette réa-
lisation est le résultat de l’étude préalable et de la conception. Dans ce présent cha-
pitre nous présenterons l’environnement logiciel et matériel et quelques interfaces de
l’application réalisée.
5.2 Codage et test

Après la phase de conception, nous abordons la phase de codage et tests qui est
la dernière phase de la première itération du processus unifié 2TUP. Il s’agit là de
coder les classes obtenues dans la phase précédente. Ensuite, ces classes sont testées
unitairement en vue d’être intégrées dans le système tout entier. Une fois construit,
le système est prêt pour l’activité de test. Cette activité a pour but de tester le
système fabriqué en implémentation.
5.2.1 Environnement logiciel et matériel
La mise en place de l’architecture logicielle et le choix des outils de travail ont

permis de mettre en place l’architecture applicative du systeme présentés dans le
chapitre précédant. L’implementation de cette architecture est le fruit de la phase de
réalisation. Ainsi, nous présentons dans la suite les outils logiciels et matériel pour
la réalisations des couches applicatives principalement la couche Application et la
couche Données .
5.2.1.1 Environnement de développement
Pour accomplir la fonctionnalité de la couche application, dont son but est de four-
nir des services spécifiques à la couche Présentation, nous avons utiliser l’outil de
développement NetBeans.
NetBeans
43
Chapitre 5 Codage et test
NetBeans est un environnement de développement intégré (EDI), placé

en open source par Sun en juin 2000 sous licence CDDL et GPLv2 (Common De-
velopment and Distribution License). En plus de Java, NetBeans permet également
de supporter différents autres langages, comme Python, C, C++, JavaScript, XML,
Ruby, PHP et HTML. Il comprend toutes les caractéristiques d’un IDE moderne
(éditeur en couleur, projets multi-langage, éditeur graphique d’interfaces et de pages
Web).
5.2.1.2 Environnement logiciel de la couche Données
Pour accomplir la fonctionnalité de la couche Données, responsable du stockage

physique de données, nous avons utiliser le système MySQL.
MySQL
Est un système de gestion de base de données (SGBD). Il est distribué

sous une double licence GPL et propriétaire. Il fait partie des logiciels de gestion de
base de données les plus utilisés au monde1, autant par le grand public (applications
web principalement) que par des professionnels, en concurrence avec Oracle, Informix
et Microsoft SQL Server.
Concernant, la couche Mapping qui se charge de la persistance des objets métier
manipulés par les services est fortement liées aux choix réalisés dans la couche Don-
nées. Ainsi, dans notre application, les classes constituant la couche Mapping sont
générées par ODBC.
5.2.1.3 Autres outils logiciels
Pour la réalisation des diagrammes de conception nous avons exloité le logiciel Sta-
rUml.
StarUml
Est un logiciel de modélisation UML, cédé comme open source par son
éditeur, à la fin de son exploitation commerciale, sous une licence modifiée de GNU
GPL. Ce logiciel gère la plupart des diagrammes spécifiés dans la norme UML 2.0.
Pour la rédaction du rapport actuel, nous avons utilisé l’outil LYX.
44
5.2 Codage et test
LYX
LYX est un logiciel libre WYSIWYM sous licence GNU GPL pour
la création de documents LATEX. À la différence des éditeurs de texte courants, LYX
n’est pas tout à fait WYSIWYG. Le résultat de l’impression d’un document n’est
pas identique à ce qui est affiché à l’écran. Le logiciel LYX a été conçu pour que
l’utilisateur n’ait pas à sa charge la mise en page, et qu’il puisse se concentrer sur
le contenu du texte et sur la structure du document. Les concepteurs de LYX ont
développé le logiciel afin qu’il obéisse à la règle WYSIWYM selon laquelle ce que
vous voyez (à l’écran) est ce que vous voulez dire.
5.2.1.4 Environnement matériel
Selon l’architecture générale Figure 3.7 du projet placée dans le deuxième chapitre
trois composants sont nécessaires :
2.1.2.1 le Transceiver (Switch) Cet équipement permet l’envoie des informa-

tions vers les étiquettes, les caractéristiques de cet Switch seront représenter dans
(Tableau 5.1)
Nom de modèle NE-4110S

Adresse MAC 00 :90 :E8 :18 :A7 :6F
Adresse IP 192.168.1.254
Numéro de série 2448
Version firmware 4.1 Build 07061517
EtherNet Communication avec un câble Ethernet
Antenne ANT1 et ANT2
Source de courant AC100~240V, 50/60HZ
Table 5.1: Carecteristique de Transceiver
2.1.2.1 l’étiquette électronique Se sont déplacer dans les rayons, dans les quelles
les informations seront affichées, les caractéristiques de l’étiquette seront représentées
dans (Tableau 5.2)
45
Taille 88mm*44mm*13mm
Poids 37g
Source de courant Batterie de durée de vie 3-5 ans
LCD Taille : 22*65.5mm
Table 5.2: Carecteristiques d’étiquette
2.1.2.1 RF KEY Est un équipement contrôleur qui permet la mis à jour automa-
tique de l’étiquette, la vérification de son état et son identification. Les caractéris-
tiques de RF KEY seront représentées dans (Tableau 5.3)
Taille 140mm*67mm*25mm
Poids 154g
Batterie 2*AA/1.5V
LCD Taille :45mm*45mm
Table 5.3: Les caractéristiques de RF KEY
5.2.2 Réalisation de la couche présentation
Dans ce qui suit, nous présentons quelques imprime écrans de notre application. Les
interfaces servent surtout à exposer les fonctionnalités offertes par l’application et
sont considérés comme un point de départ pour d’éventuelles améliorations.
5.2.2.1 Les interfaces de simulation
Nous proposons de passer par une étape de simulation afin de minimiser le risque
d’erreur, aussi, cette simulation a été proposer en raison de la retard de reponse du
fournisseur.
Interface modification sur les étiquettes La modification d’affichage de l’éti-

quette se réalise dans deux étapes ( Figure 5.1 ) :
– Le test de connexion avec le serveur (Transceiver réellement).
– La modification d’affichage de l’étiquette.
46
5.2 Codage et test
Figure 5.1: Interface modification sur les étiquettes
Interface étiquette
(Figure 5.2) présente une étiquette électronique.
Figure 5.2: Etiquette électronique
exemple d’une simulation
L’exemple ce dessous présente l’opération de modification sur une étiquette par

simulation.
47
interface de modification étiquette modifiée
5.2.2.2 Les interfaces de l’application
Le premier imprime écran (voir Figure 5.3 ) présente l’interface d’authentification .

Interface d’authentification
Figure 5.3: Interface d’authentification
Interface d’acceuil
Aprés la validation de l’authentification l’interface d’acceuil (Figure 5.4) s’affiche.
Dans cette interface trois menus sont accessibles qui sont :
– Gestion produit.
– Gestion étiquette.
– Importer les données.
48
5.2 Codage et test
Figure 5.4: Interface d’acceuil
Gestion produit
cet menu est composée par trois sous menus qui sont :
– Ajout d’un produit.
– Modification d’un produit.
– Suppression d’un produit.
Ajout d’un produit
La (Figure 5.5) illustre l’interface qui permet l’ajout d’un nouveau produit dans la
base des données tout en lui affecter une étiquette pour afficher le prix en public.
Figure 5.5: Ajout produit
interface de modification produit
49
l’interface de modification (Figure 5.6) permet de modifier les informations d’un

produit déjà ajouté dans la base de données. Pour trouver le produit à modifier,
l’utilisateur a deux choix :
– Recherche par l’identifiant produit.
– Recherche par l’étiquette propre.
Figure 5.6: Interface de modification produit
Interface supprimé produit

l’interface supprimé produit (Figure 5.7) permet de supprimer un produit de la base
des données.
Figure 5.7: supprimer produit
50
5.2 Codage et test
Interface importer les données
L’interface, présentée par la (Figure 5.8), permet d’obtenir le contenu d’une base de
données sous forme d’un fichier palt. L’importation des données s’effectue en trois
étapes :
– Parcours de la liste de drivers.

– Teste de la connexion avec le serveur (serveur base de données d’un espace com-
mercial).
– Importation de la base des données.
Figure 5.8: Importer les données
Gestion étiquette
Ce menu est composé par quatres sous menus qui sont :
Inetrface consultation
Cette interface (Figure 5.9) permet de consulter la liste des étiquettes
51
Figure 5.9: Interface consultation
Interface ajouter étiquette

Cette interface (Figure 5.10) permet d’ajouter une étiquette dans la base des don-
nées.
Figure 5.10: Interface ajouter étiquette
Interface supprimer une étiquette

Cette interface (Figure 5.11) permet de supprimer une étiquette de la base de don-
nées, après avoir choisir l’ ID correspondant.
52
5.2 Codage et test
Figure 5.11: Interface supprimer étiquette
Interface modifier une étiquette

Cette interface (Figure 5.12) permet de modifier les informations d’une étiquette.
Figure 5.12: Interface modification étiquette
Un retard du livraison du CD qui contient les drivers (fichier DLL) par le four-
nisseur, nous a poussé à se contenter par un test de performance du matériels par
une application de démonstration. Cette application est composé par les interfaces
suivantes :
53
Interface acceuil étiquette

l’interface présentée par la (Figure 5.13) est l’interface d’acceuil étiquette.
Figure 5.13: Interface d’acceuil étiquette
Interface display
L’interface Display (Figure 5.14) permet de :
– Choisir le model d’étiquette.
– Envoyer les informations vers l’étiquette.
– Modifier l’affichage de l’étiquette.
Figure 5.14: Interface display
Interface Set-ID
Cette interface (Figure 5.15) permet de :
54
5.2 Codage et test
– Définir un nouvel identificateur.

– Vérifier un identificateur.
– Enregistrer un identificateur.
Figure 5.15: Interface ID-Set
Interface Group-Set
Cette interface (Figure 5.16) permet de :

– Définir un groupe d’étiquette.
– Vérifier les identificateurs.
– Enregistrer un groupe d’étiquette.
Figure 5.16: Interface Group Set
Interface signal test
cette interface (Figure 5.17 ) permet de :

– Vérifier l’état d’étiquette.
55
Figure 5.17: Interface signal test
5.3 Conclusion
Dans ce dernier chapitre, nous avons donné une idée sur l’activité d’implémentation
par la présentation de nos interfaces. Nous clôturons notre travail par une conclusion
générale qui synthétise notre projet.
56
6 Conclusion générale
Notre mission a consisté en l’étude, l’analyse, la conception et la mise en place d’un
système de communication radio fréquence qui permet de maintenir en permanence
des informations a jour.
Pour réaliser ce projet, nous avons adopté le processus de développement en Y
(2TUP). Nous avons commencé par une étude de l’existant avant d’aborder les deux
branches fonctionnelle et technique du cycle de développement. Au terme de ces deux
branches, nous avons établi une architecture fonctionnelle et logicielle répondant aux
besoins et aux exigences du système. Lors de la phase de la conception, nous avons
présenté les différents diagrammes UML pour mieux maîtriser la communication
entre les différents objets du projet. Enfin, nous avons pu réaliser et mettre notre
solution.
Dans un environnement encourageant et actif, le projet développé au profil de la
sociètè NEWITEC constitue une solution complète et fiable pour une communi-
cation avec une base de données interrogeable, afin d’afficher et mettre à jour les
informations reltives aux produits commercialisés.
Pour finir, nous sommes certains que ce stage au sein de la société a été une occasion
pour épanouir nos capacités de communication dans un environnement professionnel
et que c’est une expérience très enrichissante sur tous les domaines.
Certes, notre application ne prend pas fin avec l’achèvement du projet mais elle
reste ouverte à des éventuelles extensions qui s’adaptent à la croissance du domaine
d’activité de la société, tel qu’une meilleure gestion et suivi de développement des
logiciels. Pour assurer une meilleure protection à notre application et justement pour
protéger notre Base de données nous allons chercher en futur à développer un logiciel
de sécurité qui va réaliser cette tâche.
57
Bibliographie
[1] P. ROQUES and F. VALLEE, UML en action, 2004, no. 380.
[2] G. Booch, J. Rumbaugh, and I. Jacobson, The Unified modeling Language User
Guide, 1999, no. 482.
[3] Rfid (radio frequency identification). [Online]. Available : http://www.
commentcamarche.net/contents/rfid/rfid-intro.php3
[4] D. Harras and M. E. M. Benyahiya, Automatisation du processus de livraison
des applications au sein du projet SI INWI, 2011.
[5] S.Svartz, Processus de développement Objet, 2001.
59

Developpement D'un Système D'affichage de Prix À Base D'étiquette Électronique Dans Un Espace Commercial

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Developpement D'un Système D'affichage de Prix À Base D'étiquette Électronique Dans Un Espace Commercial

Transféré par

Droits d'auteur :

Formats disponibles

Projet de Fin des Etudes

Developpement d’un système

Qui peuvent trouver dans ce travail l’expression de nos profondes reconnaissances

A Tous nos amis

Pour toute affectation qu’ils nous ont toujours apporté.

Nous tenons en particulier à exprimer nos profondes gratitude pour :

Notre encadreur académique Mlle. Mouna Garai pour l’orientation, la confiance,

En outre, nous adressons nos sincères remerciements pour Nos remerciements

2 Contexte générale du projet 7

3.1 Etiquette papier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Diagramme de séquence “Modifier produit et affichage” . . . . . . . . 34

5.1 Interface modification sur les étiquettes . . . . . . . . . . . . . . . . . 47

5.12 Interface modification étiquette . . . . . . . . . . . . . . . . . . . . . 53

3.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Liste des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Carecteristique de Transceiver . . . . . . . . . . . . . . . . . . . . . 45

Summary During this stage, we developed an application of a price display system

dernier, nous décrirons l’environnement de développement de ce projet. Ensuite,

2.2 Présentation de l’entreprise d’accueil

Figure 2.1: Sigle de l’entreprise

Opérant dans le domaine des Technologies de l’Information et de la Communica-

2.2.1 Mission et Activités

Depuis sa création, la société NEWITEC s’est forgée un nom dans le développe-

de transmission et de commutation de voix et de données. De telles solutions en-

2.2.1.2 Objectifs Activités

2.3 Présentation du projet

De nos jours, la technologie d’identification par radiofréquence RFID (Radio Fre-

2.3.2 Objectif du projet

Le projet consiste à développer une application logicielle permettant l’affichage en

2.3.3 Outils de conduite de projet

L’adéquation du projet au processus de développement peut largement affecter le

Le cycle en V quant à lui, permet de maîtriser le développement à travers les véri-

Processus Description Avantages Inconvénients

RUP RUP est à la fois une Propose des modèles • Coûteux à

2.3.4 Langage de modélisation

2.3.5 Estimation des extrants et intrants

1. Un code source avec des commentaires de l’application doit être livré.

4. Manuel d’utilisation qui détaille les différents tâche et facilite l’utilisation de

1. Ressources humaines : 2 techniciens.

Comme le suggère le cycle de développement en Y, le présent chapitre sera consacré,

3.2 Etude fonctionnelle

3.2.1 Etude de l’existant

Description du système actuel L’étiquette papier est une moyenne d’identifica-

Figure 3.1: Etiquette papier

3.2.3 Collecte des besoins fonctionnels

3.2.3.1 Les acteurs

Acteur Type Description

3.2.3.2 Diagrammes de contexte statique et dynamique

Figure 3.2: Diagramme de contexte statique

– Diagramme de contexte dynamique

Figure 3.3: Diagramme de contexte dynamique

3.2.3.3 Identification des Cas d’utilisation par ses acteurs

Les cas d’utilisation (CUs) permettent de représenter le fonctionnement du système

Cas d’utilisation Acteur Messages émis/Reçus par les acteurs

3.2.3.4 Description détaillée de cas d’utilisation

Afin de mieux comprendre un fonctionnement d’un Cas d’utilisation, nous allons

Fiche Descriptive du CU : “S’authentifier”

Objectif : ce cas d’utilisation est utilisé pour identifier l’utilisateur

1. Le cas d’utilisation débute quand le responsable va utiliser l’application.

Post condition : L’utilisateur est authentifié

2) Cas d’utilisation : “Gérer les produits”

Fiche Descriptive du CU : “Gérer les produits”

Titre : Gérer les produits