Version actuelle datée du 26 février 2014 à 13:37

Présentation du projet

Objectif

Le but de ce projet est de réaliser un prototype de paiement sans contact utilisant la technologie RFID. En effet, les produits seront très bientôt tous équipés de tags RFID et le but serait donc que nous utilisions donc les multiples avantages qu'offre donc la technologie RFID pour faciliter l'encaissement d'un client (Validation du panier, paiement, etc...).

L'objectif de ce projet serait donc de simuler le passage d’un client en caisse, avec une détection automatique du panier.

Nous tenons à préciser qu'aucune proposition de solution ne nous a été faite concernant ce projet. Donc nous sommes partis totalement de zéro et nous étions force de proposition (c'était à nous de proposer la solution qui allait correspondre le plus à leurs besoins).

Voici une vidéo dont on s'est inspiré pour proposer notre solution: http://www.youtube.com/watch?v=eob532iEpqk

Matériel requis

• Un portique
• Une tablette

Gestion du projet

Semaine 1

Cette semaine a été consacré au choix des projets

Semaine 2

Prise de contact avec notre tuteur entreprise, planification d'une réunion et début de réflexion sur le sujet

Semaine 3 (Première Réunion)

Première réunion (Mercredi 25/09/2013) avec notre tuteur entreprise. Lors de cette réunion une présentation détaillée du projet a été effectuée ainsi que leurs attentes par rapport à nous. Aussi, on nous a fait savoir que le plus important était d'abord dans un premier temps de proposer un scénario d'encaissement qui soit innovant et adapté. Et c'est dès lors que le scénario sera validé que nous commencerons le développement (codage).

Semaine 3 (Deuxième Réunion)

Deuxième réunion (Lundi 30/09/2013) avec notre tuteur entreprise et un responsable chargé de la RFID en magasin. Le but de cette réunion était de nous parler du fonctionnement de la RFID en magasin, de l'utilisation qu'ils en font actuellement, afin de voir nous comment on peut exploiter ce qui existe déjà pour notre solution. En outre, lors de cette 2e réunion nous avons proposé notre premier scénario qui était d'équiper les chariots de lecteurs RFID et d'un écran, comme çà dès qu'un client dépose son produit dans le chariot, le produit est directement affiché sur l'écran. Mais ce scénario a été rejetté déjà parce que c'était très coûteux d'équiper tous les chariots ou paniers de tous les magasins de lecteurs RFID et d'écran.

Semaine 4 à Semaine 7

Durant ces semaines, nous avons pris notre temps pour trouver un scénario adapté et innovant. nous avons donc dans un premier temps fait une analyse de besoins afin de clairement savoir tout ce dont nous aurions besoin dans le processus d'encaissement (en nous mettant à la place du client). Nous avons d'abord penser faire une application android qui permettrait au client de scanner directement les produits avec son téléphone et payer directement sur l'appli, mais nous avons très vite oublié cette piste car nous nous sommes rendu compte que les téléphones ne comportaient pas de lecteur RFID actuellement. Il était donc impossible de scanner un produit avec son téléphone portable.

Après maintes recherches nous avons finalement trouvé un scénario convenable en utilisant le principe des portiques de sécurité. En fait le client passe avec ses produits devant un premier portique celui ci scan ses produits et sa carte de fidélité ( à ce niveau on récupère l'id du client et l'id des produits). Ensuite le scan lance la création d'un panier web dans lequel ses produits seront rangés. Ce panier pourra éventuellement être consulté par le client sur son mobile. Ensuite nous avons réfléchi sur l'aspect paiement (Validation du panier). nous nous sommes dit que nous distinguerons deux types de clients(simples clients et clients premium). Pour les simples clients ils devront régler leurs achats avant de sortir du magasin tandis les clients premium auront la possibilité de sortir du magasin sans régler leurs achats et régler peut-être plus tard sur l'application (web ou mobile).

Une fois le cahier des charges et les spécifications fonctionnelles rédigées, nous avons pris RDV avec notre tuteur entreprise afin de proposer la solution et la faire valider.

Semaine 8 (Troisième Réunion)

Troisième réunion (Mercredi 30/10/2013) avec notre tuteur entreprise. Le but de cette réunion était de présenter notre scénario, d'expliquer toutes les différentes démarches du scénario ainsi que toutes les fonctionnalités pour pouvoir savoir à la fin si la solution sera validé ou pas. Nous avons donc présenté notre scénario, et nous avons eu quelques questions et remarques dessus. Et finalement la solution a été validée avec quelques petites modifications. A l'issu de cette réunion, il était donc question que nous fixions un RDV avec un responsable expert en RFID chez entreprise qui s'occupe des portiques, pour savoir comment nous aurions à travailler et le matériel qui pourra être mis a notre disposition. Et nous devions prépare une présentation powerpoint assez explicite pour lui présenter le scénario déjà.

Semaine 9

Préparation de la prochaine réunion, Réalisation du powerpoint de présentation de notre scénario.

Spécifications fonctionnelles du projet (Fichier en cours de modification): Fichier:Spec Fonc.pdf

Semaine 10 (Quatrième Réunion)

Quatrième réunion (Vendredi 15/11/2013) avec notre tuteur entreprise. Le but de cette réunion était de présenter notre scénario, afin qu'il puisse non seulement donner son avis, mais aussi nous aider sur la méthode de réalisation ainsi que pour le matériel à utiliser. A la fin de cette réunion il a été conclu que vu le temps qu'il nous restait, il n'était pas possible de réaliser complètement toute la solution que nous proposions. Il nous a donc proposé de nous concentrer et de nous limiter uniquement sur la partie "lecture des tags RFID et l'envoie des données sur le web" car la détection à 90% reste encore à l'heure d'aujourd'hui un challenge majeur.

Une prochaine réunion a été envisagée afin de rencontrer les fournisseurs de portiques pour voir comment avoir un portique mais aussi pour savoir quel protocole pourrait être utilisé pour communiquer entre le portique et le serveur web.

Semaine 10 à 14

Lors de ces semaines nous avons essayer de réaliser l’architecture fonctionnelle du projet:

Digramme de déploiement

Architechture Fonctionnelle

Nous avons aussi commencer le développement de l'application web pour le panier du client en J2EE. L’architecture technique sera réalisé très bientôt.

Réalisation de l'application WEB J2EE

Choix d'implémentation

Le choix du modèle MVC

modèle MVC

Nous avons choisi de respecter le modèle MVC pour réaliser notre application car une architecture MVC cherche à séparer trois choses : le Modèle, les Vues et les Contrôleurs. Les contrôleurs permettent de répondre aux actions de l'utilisateur. Chaque contrôleur est associé à une vue : cette dernière permet uniquement de présenter des informations à un utilisateur. Bien entendu, l'information renvoyée est dépendante des actions d'entrées de l'utilisateur. Les traitements sont réalisés par le modèle (la logique métier).

Etant donné que nous cherchons à mettre en œuvre une architecture MVC via un environnement J2EE, on peut donc faire les rapprochements suivants :

• Un contrôleur est implémenté sous forme de servlet Java.
• Le modèle consiste en l'implémentation de la logique métier du site Web.
• Chaque vue est implémentée via une JSP.

Diagramme de classes

Développement: niveau EJB

La technologie J2EE repose sur la notion de Bean, implémentée sous forme de classes Java, ces objets particuliers, gérés par le container et stockés dans la base de données, sont de 2 types: les entity Bean (persistants) et les Session beans (relatifs au contexte d’utilisation).

les entity beans

Un Bean entité aura comme annotation « @Entity ». La clef primaire est définie par une annotation « @Id ». Voici la liste des beans qui constituent la structure du site :

Pour chaque clé primaire, on assigne une propriété de génération et d’auto incrémentation. (L’annotation sera @GeneratedValue).

les sessions beans

L'accès aux Entity Beans est réalisé à travers un entity manager. Cet entity manager sera accessible par un bean session sans état. Nous avons utilisé deux sessions bean : « ClientManager » pour décrire les méthodes utilisés par un client et « AdminManager » pour décrire les méthodes utilisées par un administrateur. Ces deux sessions bean sont « stateless ». Le bean « ClientManager » possède trois méthodes principales tandis que le bean « AdminManager » possède huit méthodes principales tous les deux définies par des interfaces @remote et @local.Voici la liste des sessions beans qui constituent la structure du site:

Les 2 sessions Bean sont utilisées pour accéder aux beans depuis un client local. Tout au long de notre projet, seules les interfaces locales seront utilisées.Les beans stateless vont utiliser un objet entity Manager afin de manipuler les entités. Pour cela, il y a utilisation de la nouvelle fonctionnalité des EJB 3.0 : l'injection de ressource ou "dependency injection".

@PersistenceContext( unitName = « JPADB »)
protected EntityManager em;

L'annotation « @PersistenceContext » va être analysée par le conteneur et la variable « entityManager » va être initialisée. Ensuite, il suffit d'appeler des méthodes sur cette variable. Ce n'est plus au développeur de rechercher la variable, il demande au conteneur.

NB : L’ajout en base de données se fait en créant des beans et en les persistant au travers de l’entity manager.Lorsqu’on veut par contre récupérer une information en base de données, il y a interrogation de l'entity manager en effectuant une requête en base grâce à l’annotation « @NamedQuery ».

les relations

Les relations que nous avons définit entre nos entités constituent un élément clef des EJB, elles permettent de définir au sein de la base de données des relations entre les beans qui y sont enregistrés. Ces relations ont été définies dès la conception du projet et font partie intégrante de la structure de la base de données. Nous allons principalement utiliser dans notre projet la relation « @onetomany - @manytoone»

Voici un schéma symbolisant les différentes relations entre nos EJB

Développement: niveau WEB

Nous avons décidé de scindé notre interface web en deux :

• Le back office ou interface administrateur, qui permettra à l’administrateur du site d’effectuer certaines mise à jour comme le rajout de nouveaux produits en base de données.
• Le front office ou interface client, qui permettra au client après connexion d’accéder à son compte, de visualiser ses commandes et de valider ses achats.

Ces interfaces sont donc respectivement outillées par les sessions-beans AdminManager et ClientManager déjà décrites plus haut.

Le back office (Interface Administrateur)

Cette interface est constituée de la servlet AjouterPanier.java, de la JSP ajouterproduit.jsp et de l’objet métier ProduitForm.java

Interface Administrateur

<br\> Il s’agit d’un formulaire qui permet à l’administrateur du site de rajouter des produits en base de données en renseignant leurs attributs. (Nom, epc et description) Il permet aussi d’afficher les messages d’erreurs ou de succès comme le montre le schéma ci-dessous:

Interface Administrateur avec erreur

<br\><br\><br\><br\><br\><br\><br\><br\><br\><br\> concernant notre modèle, c’est lui qui permet effectivement de rajouter de nouveaux produits en base de données en se basant sur les méthodes décrites dans la session-beans adminManager. Il vérifie que notre rajout se passe bien et s’occupe aussi de la vérification des champs du formulaire : c’est-à-dire savoir si tous les champs de la JSP sont correctement remplis lors du « submit », savoir si on n’est pas en train de rentrer deux fois les mêmes produits en base de données. Il permet aussi de générer les messages d’erreurs ou de succès en cas d’erreur ou de succès de l’ajout en base de données. voici ci-dessous les méthodes dont nous avons eu besoin: