Prototypage d'un systeme d'identification et protection anti-vol des ouvrages d'une bibliotheque en utilisant les puces RFID: Cas de la bibliotheque de l'UCBC

CONCLUSION PARTIELLE

Ce chapitre nous a permis d'énoncer la méthodologie utilisée, les différentes techniques en fin de permettre au lecteur de comprendre aisément les démarches que nous avons utilisées pour la réalisation de ce travail, nous en avons également profité de parler d'une manière ou d'une autre des différents outils et langages de programmationque nous allons utiliser par la suite.

Chapitre IV : PROCESSUS DE CONCEPTION DU SYSTEME

Napoléon a dit : « un schéma vaut mille mots », il n'était pas développeur mais il avait raison. Etant donné que les différentes généralités, méthodologies et présentations de l'existant ont été abordées dans la partie précédente, celle-ci va présenter les caractéristiques du système à concevoir et chercher à donner une solution informatique pour pallier au problème de gestion et sécurité des ouvrages de la bibliothèque de l'UCBC.

La modélisation consiste à créer une représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse. Ce type de méthode est appelé analyse.^29(*)

IV.1. BESOINSTECHNIQUES

IV.1.1 Besoinstechniques de la partie logicielle

La gestion de documents : l'application stockera les données relatives aux documents, ces données préenregistrées dans la base de données doivent être utilisées lors du processus de retrait et remise des documents.

Le parcours de catalogue : l'application devra disposer d'un moyen facile de parcours des ouvrages de la bibliothèque, cette fonctionnalité sera disponible à tous les lecteurs avant qu'ils partent sur les étagères de livres. Les lecteurs devront alors s'identifier avant de consulter le catalogue ; Les recherches des livres seront faites sur base des mots clés ; noms des ouvrages, auteurs ou autres paramètres selon les configurations faites dans l'application ;

L'envoi des SMS : les messages SMS seront envoyés aux lecteurs ayant empruntés les livres et dépasser le délai des jours requis pour la possession des ouvrages. Pour ce cas, il sera juste question d'envoyer un message court sans beaucoup de détails.

L'envoi des E-mails : dans l'objectif de rester en permanente communication avec les fidèles lecteurs de la bibliothèque, les messages électroniques suffisamment détaillés seront envoyés aux lecteurs pour rappeler les emprunts expirés et leurs notifier lorsque les nouveaux livres sont acquis et disponible à la bibliothèque.

L'administration : elle sera réservée aux gestionnaires de la bibliothèque, cet espace contiendra donc :

· La gestion des utilisateurs : cet espace permettra d'ajouter, modifier, de supprimer les utilisateurs ou d'attribuer les droits et privilèges à ceux-ci.

· L'espace pour la mise à jour des données des lecteurs de la bibliothèque.

· Les configurations : le paramétrage des informations nécessaire pour communication du modem, de la carte Arduino ainsi que d'autres paramètres essentiels du logiciel et autres systèmes connexes.

· D'autres points seront ajoutés au fur et à mesure que le système sera en train d'évoluer mais surtout sur base de nouveaux besoins ressenti dans la même structure.

IV.1.2 Besoin technique de la partie Matérielle

Identification d'un lecteur pour le prêt d'un livre : on fait passer la carte d'identité auprès du lecteur RFID, le code de la carte est envoyé au système pour vérification, une fois reconnue, on peut maintenant passer à l'étape suivante qui est celle d'identifier le livre à retirer ; il sied de signaler que les cartes d'étudiants comme de service de l'UCBC utilisent la technologie RFID par le fait qu'elles contiennent des puces RFID incorporés.

Identification d'un livre pour l'acquisition : une fois le livre est placé dans une zone bien précise et qu'il est prêt à être retiré de la bibliothèque, le système doit envoyer un code identifiant ce livre au SIGB pour l'enregistrement automatique du prêt ;

Détection d'un livre volé : si le livre est dans une zone bien précise (au préalable devant la porte mais restant encore à l'intérieur du bâtiment de la bibliothèque) a été retiré en passant par un processus légal, c'est-à-dire emprunté légalement, il n'y a pas de souci ; néanmoins, si le livre n'est pas passé par une voie légale, il doit être détecté par le système mis à la porte.

Signalisations : la détection d'un livre faisant objet du vol déclenchera une alerte lumineuse puis sonore, pour ainsienvoyerles détails du livre à un écran du gestionnaire de la bibliothèque.

Le retrait ou l'emprunt du livre pourra se faire soit automatiquement (sans intervention du gestionnaire de la bibliothèque) soit manuellement (avec l'intervention du gestionnaire)

IV.2. CONCEPTION DU SYSTEME

IV.2.1 Méthodes de conception

Dans le processus de réalisation d'un système informatique, la conception est une étape qui permet de créer une solution à partir des nécessités présentées lors de l'analyse des besoins fonctionnelles.

Il nous est important de préciser les différentes méthodes de conception que nous utiliserons dans la conception de notre système mais avant d'y arriver, Une méthode de conception sert à formaliser les étapes initiales du développement d'un système afin de rendre ce dernier plus fidèle aux besoins soulevés par le client (ici, les besoins fonctionnels précités).

Nous utiliserons UML pour trouver une solution informatique au problème d'identification et sécurité des livres dans la bibliothèque. Pour adapter UML à un domaine particulier ou encore mieux à une problématique spécifique, UML est reparti en différents profils, ces profils mettent en jeu le concept central de stéréotype, ce dernier est une sorte d'étiquette nommée que l'on peut coller sur tout élément d'un modèle UML^30(*). Parmi les profiles UML citons :

- MARTE (Modeling and Analysis of Real Time and Embedded Systems) : c'est un profil d'UML 2 pour la modélisation et l'analyse des systèmes temps réels embarqués, il a été conçu de manière à utiliser des techniques d'analyse variée. MARTE comprends trois modèles temporels différents : le temps réel (chronométrique), le temps logique et le temps logique synchrone, il propose également un modèle de description des plates-formes d'exécution, élément essentiel des systèmes en temps réel embarqués.^31(*)

- Soc (System on a Chip) : c'est un profil UML 2 pour la spécification des systèmes électroniques, il fournit les capacités tel que: la représentation hiérarchique de modules et Channel, les rôles de modules et l'information transférée entre modules en utilisant un seul type de diagramme.^32(*)

- Sys ML : adoptée par l'OMG en juillet 2006, il ajoute un certain nombre de concept à UML, il reparti ses diagrammes en trois groupes dont : les diagrammes comportementaux, un diagramme transverse et les diagrammes structurels.^33(*)

Cette représentation met en relation les différentes entités et les constituants du système. Il existe deux grandes familles des langages de modélisation OMG (Object Management Group)^34(*):

- La famille DSL (Domain Specific Langage) : en français, la modélisation pour les domaines spécifiques, c'est le cas de langages LwCCM, UML Profil for Soc, MARTE.

- La famille GPL (General Purpose Langage) : elle regroupe tous les langages de modélisation pour les objectifs généraux. C'est par exemple le cas des langages UML2, Sys ML, CCM et etc.

IV.2.2 Conception du système

Pour la conception de notre système nous utiliserons UML ; ce dernier se définit comme un langage de modélisation graphique et textuel qui est destiné àdécrireet comprendre des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.^35(*) Avec UML, il ne s'agit pas seulement d'une simple notation graphique parce que les concepts que transmettent les différents diagrammes UML ont une sémantique et sont automatiquement porteurs de sens au même titre que les mots d'un langage.^36(*)

UML a connu diverses évolutions, dans sa version 2, il propose treize diagrammes qui peuvent être utilisés dans la description d'un système. Ces diagrammes sont regroupés en deux grands ensembles dont :

- Les diagrammes structurels et

- Les diagrammes comportementaux.

- Les diagrammes structurels :

Ils sont au nombre de 6. Le but de l'ensemble de ces diagrammes est de représenter l'aspect technique du système^37(*).

- Diagramme de classe : Ce diagramme représente la description statique du système en intégrant dans chaque classe la partie dédiée aux données et celle consacrée aux traitements ; il montre les briques de base statique. C'est le diagramme pivot de l'ensemble de la modélisation d'un système.
- Diagramme d'objet : ce diagramme permet la représentation d'instances des classes et des liens entre instances.
- Diagramme de composant (modifié dans UML 2) : Ce diagramme représente les différents constituants du logiciel au niveau de l'implémentation d'un système.

- Diagramme de déploiement (modifié dans UML 2) : Ce diagramme décrit l'architecture technique d'un système avec une vue centrée sur la répartition des composants dans la configuration d'exploitation.
- Diagramme de paquetage (nouveau dans UML 2) : Ce diagramme donne une vue d'ensemble du système structuré en paquetage. Chaque paquetage représente un ensemble homogène d'éléments du système (classes, composants...).
- Diagramme de structure composite (nouveau dans UML 2) : Ce diagramme permet de décrire la structure interne d'un ensemble complexe composé par exemple de classes ou d'objets et de composants techniques. Ce diagramme met aussi l'accent sur les liens entre les sous-ensembles qui collaborent.

Il est Noter que depuis la version UML 2.3, il existe déjà le 14 ème diagramme, ce dernier est encore très confidentiel, c'est le diagramme de profil. Il est aussi classé parmi les diagrammes structurels.^38(*)

- Les diagrammes comportementaux :

Ces diagrammes représentent la partie dynamique d'un système réagissant aux événements et permettant de produire les résultats attendus par les utilisateurs. Avec UML, pour ce grand ensemble, Sept diagrammes sont proposés dont :
- Diagramme des cas d'utilisation : Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans l'analyse d'un système.
- Diagramme d'état-transition (machine d'état) : Ce diagramme montre les différents états des objets en réaction aux événements.
- Diagramme d'activités (modifié dans UML 2) : Ce diagramme donne une vision des enchaînements des activités propres à une opération ou à un cas d'utilisation bien précis. Il permet aussi de représenter les flots de contrôle et les flots de données.
- Diagramme de séquence (modifié dans UML 2) :Ce diagramme permet de décrire les scénarios de chaque cas d'utilisation en mettant l'accent sur la chronologie des opérations en interaction avec les objets.
- Diagramme de communication (anciennement appelé collaboration) : Ce diagramme est une autre représentation des scénarios des cas d'utilisation qui met plus l'accent sur les objets et les messages échangés.
- Diagramme global d'interaction (nouveau dans UML 2) : Ce diagramme fournit une vue générale des interactions décrites dans le diagramme de séquence et des flots de contrôle décrits dans le diagramme d'activités.
- Diagramme de temps (nouveau dans UML 2) : Ce diagramme permet de représenter les états et les interactions d'objets dans un contexte où le temps a une forte influence sur le comportement du système à gérer.

Notre travail ayant 2 grandes parties (la partie matérielle et la partie logicielle), pour une facile représentation et pour des raisons de lisibilité et compréhension aisée du système, nous regrouperons les diagrammes en 2, le premier groupe concerne les diagrammes importants de la partie logicielle et le second décrit au mieux les diagrammes de la partie matérielle.

IV.2.2.1 Conception du système logiciel

IV.2.2.2.1 Diagramme de cas d'utilisation

Un acteur est une entité (personne ou objet ou encore système) qui agit sur le système. Il a donc une influence dans l'aspect fonctionnel du système. Dans ce dernier, pour notre cas, les acteurs qui interviennent sont, en effet, le gestionnaire de la bibliothèque, l'administrateur, les lecteurs (Etudiants ou staffs), le système d'identification RFID (Lecteurs RFID) et le Modem.

Figure 1:Diagramme de cas d'utilisation partie Logiciel

Un système est un ensemble de composants inter relié qui interagissent les uns avec les autres d'unemanière organisée pour accomplir une finalité commune (NASA 1995).Le diagramme de cas d'utilisation pour le système d'identification des ouvrages se présente de la manière suivante :

IV.2.2.2.2 Diagramme d'activité

Les diagrammes d'activités permettent de déterminer des traitements à priori séquentiels. Ils offrent un pouvoir d'expression très proche des langages de programmation objet: spécification des actions de base (déclaration de variables, affectation etc.), structures de contrôle (conditionnelles, boucles), ainsi que les instructions particulières à la programmation orientée objet (appels d'opérations, exceptions etc.).^39(*)

Le diagramme d'activité concerne le comportement interne des opérations ou des cas d'utilisation,

a. Diagramme d'activité du cas «Consulter le catalogue»

Figure 1:Diagramme d'activité du cas "Consulter Catalogue"

Commentaire :

Pour consulter le catalogue, le lecteur doit se connecter, une fois connecté, il peut alors consulter les livres en faisant une recherche selon différentsparamètres. La recherche faite donne l'idée sur l'emplacement même du livre, ainsi il pourra alors se décider de prendre le livre ou non selon que le livre est disponible ou non disponible. Si sa recherche n'a pas abouti à sa faveur, c'est-à-dire s'il n'a pas trouvé le livre recherché ; le catalogue va se recharger.

b. Diagramme d'activité du cas «Retirer le livre »

Figure 1: Diagramme d'activité du cas "Retirer Livre"

Commentaire :

Pour retirer un livre, le lecteur doit d'abord scanner sa carte puis le livre, si ces informations sont correctes, alors le retrait sera enregistré ; au cas où le livre veut sortir de la bibliothèque sans passer par ce canal, un message sera envoyé à l'écran du gestionnaire de la bibliothèque, ce message sera suivi du déclenchement de l'alerte lumineuse mais aussi sonore.

IV.2.2.2.3 Diagramme de séquence

Le diagramme de séquence définit deux concepts principaux : celui d'objet et celui de message échangé entre deux objets. Une interactionpermet d'identifier plusieurs objets et de représenter les messages qu'ils s'échangent.^40(*)

Voici quelques diagrammes de séquences de cas plus ou moins pertinents du système :

a. Figure 1:Diagramme de séquence du cas "consulter catalogue"

Diagramme de séquence du cas «Consulter le catalogue»

Commentaire :

Pour que le lecteur puisse consulter le catalogue :

- Il doit s'identifier ;

- Le lecteur RFID va scanner sa carte puis envoyerau système le code lu,

- Le système à son tourvérifie les identités(code) reçus et les compare à ce qui sont préalablement enregistrées ;

- Au cas où les identités sont correctes ; le système affiche le catalogue au lecteur.

b. Figure 1: Diagramme de séquence du cas Retirer Livre

Diagramme de séquence du cas «Retirer le livre»

Commentaire : Apres avoir parcouru le catalogue, les livres sont affichés, une fois le lecteur retire le livre de l'étagère, lorsqu'ilveut enregistrer l'emprunt, il doit scanner et le livre, et sa carte, dans le cas oùle livre ou la carte ne sont pas reconnus, un message d'erreur d'identification doit être visualisé à l'écran du gestionnaire de la bibliothèque.

IV.2.2.2.4 Diagramme de classe

Le diagramme de classe est l'un des diagrammes structurels qu'offre UML, il montre la structure interne du système mais aussi, modélise les concepts du domaine d'application ainsi que les concepts internes créés dans le cadre de l'implémentation d'une application.Une classe décrit un groupe d'objets ayant les mêmes propriétés (attributs),
même comportement (opérations), et une sémantique commune (domaine de définition).^41(*)

Figure 1: Diagramme de classe de la partie logiciel

IV.2.2.2.5 Passage du diagramme de classe en Base de données

UML n'offre pas les tables (structure des données) voilà pourquoi il est impérieux de passer par quelques règles dans le but de passer du diagramme de classes ci haut présenté en différents modèles qu'offre MERISE (Méthode d'Etude et de Réalisation Informatique pour les Systèmes d'Entreprise), dans le but de constituer notre base de donnée pour le stockage de nos différentes données qui seront utilisées par notre système.

Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE, quant à elle, est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques.^42(*)

Pour passer du diagramme de classe au modèle relationnel, voici quelques règles ci-après qui doivent être prises en compte :

Règle 1 : la présence de la cardinalité ( ?..1) d'un côté de l'association :

Pour cette règle ;

§ Chaque classe se transforme en une table ;

§ Chaque attribut de classe se transforme en un champ de table ;

§ L'identifiant de la classe qui est associée à la cardinalité (?..1) devient laclé étrangère de l'autre classe.

Règle 2 : La présence de ( ?..N) de deux côtés de l'association :

Pour ce genre de cas, on procède comme suit :

§ Chaque classe se transforme en une table ;

§ Chaque attribut de classe se transforme en un champ de table ;

§ L'association se transforme en une table. Cette table a comme champs l'identifiant de chacune des deux classes, plus d'éventuels autres attributs.

Règle 3 : Présence d'une généralisation ;

Lorsqu'il s'agit d'un cas de généralisation. Plusieurs méthodes sont possibles, parmi ces dernières voici celle qui nous parait plus clair et, selon nous, facile à utiliser. Pour ce faire on doit alors :

§ Créer une table avec tous les attributs des classes

§ Ajouter un attribut pour distinguer les types des objets

a. Base de données

Le modèle logique de données permet de décrire les structures de données (Relations, entités, clés primaires, clés étrangères,) utilisées dans une application.

Dans la suite, les relations (?, n) - (?, n) donneront naissance à une nouvelle table, alors que les relations du type (?, n) - (1,1) verront les clés reportées de l'autre côté.

S'appuyant sur notre deuxième outil de modélisation (WinDev 17),nous avons réalisé notre base des données en utilisant le SGBDRHyperFileSQL qui est intégré à notre outil de développement (WinDev 17) pour ainsi traduire nos classes dans un langage de définition de données. L'analyse de notre système dans notre outil de développement nous a amené à produire la figure suivante :

Figure 1: Modèle Logique de données.

b. Requêtes SQL

Dans le but de ressortir avec la base de données adaptée à notre système de gestion de base de données HyperFile SQL, nous allons générer les codes de création de la base de données en utilisant WinDev. Mais alors, après cette génération, les codes SQL fournis sont en Annexe B.

IV.2.2.2 Conception du système Matériel

IV.2.2.2.1 Diagramme de cas d'utilisation

Après analyse du besoin, pour ce travail, du point de vue matériel, les cas d'utilisations disponible sont :

- La détection d'un livre à la porte : un lecteur RFID est placé à la porte dans le but de détecter un livre qui sort de la bibliothèque illicitement ;

- L'identification des livres« tagués » : pour retirer un livre, ce dernier devras passer par une zone rayonnée par un lecteur RFID, pour son identification ;

- L'enregistrement du cas de tentative de vol : une fois le lecteur RFID de la porte détecte un livre qui tente à être volé, il envoie l'image au serveur et postes du gestionnaire de la bibliothèque ensuite enregistre le cas de tentative de vol ;

- L'identification de la carte du lecteur : tous les lecteurs doivent se munir de leurs cartes, celles-ci sont scannées avant tout retrait et/ou remise des livres, elles sont de même dotées des puces de la technologie RFID ;

- L'activation de la lampe de signalisation : lorsqu'un livre est détecté volé ; ce fait active une lampe de signalisation.

- L'activation de l'alarme sonore : vu que les bibliothécaires peuvent être préoccupés par diverses occupations au sein de la bibliothèque, l'opération de vol de livre enclenche également une alerte sonore pour que, l'attention soit encore beaucoup plus attirée.

Les acteurs relatifs à ces cas d'utilisations sont donc :

· Le lecteur RFID_Carte_Livre : pour l'identification des livres prêt au retrait mais aussi les cartes des différents lecteurs de la bibliothèque ;

· Le Lecteur RFID du portique : pour la détection des livres volés ;

· La lampe de signalisation : pour la signalisation à chaque détection d'un livre ou carte;

· Le serveur (système externe) : pour l'enregistrement des tentatives de vol d'ouvrages mais aussi des éléments relatifs aux livres et lecteurs ;

· Le haut-parleur: pour l'alerte sonore lors du cas de vol ;

Figure 1:Diagramme de cas d'utilisation de la partie matérielle

Ce diagramme de cas d'utilisation pour la partie matérielle se présente alors de la manière suivante :

IV.2.2.2.2 Diagramme d'activité

Figure 1:Diagramme d'activité du cas activer alarme

A chaque cas d'utilisation correspond un diagramme d'activité ; pour notre cas, voici un de ces diagrammes le plus pertinent : le diagramme d'activité du cas « Activer Alerte »

IV.2.2.2.3 Figure 1:Diagramme de séquence du cas activer alarme

Diagramme de séquence, cas « activer alarme »

* ²⁹ DI GALLO Fréderic, Méthodologie des systèmes d'information-Merise, 2000-2001, page5

* ³⁰Pascal Roques, Modélisation de systèmes complexes avec SysML, 2015, Page 11

* ³¹ Idem

* ³²Idem

* ³³Idem

* ³⁴MARTE: A New Standard for Modeling and Analysis of Real-Time and Embedded Systems

* ³⁵ Pascal Roques, Modélisation de systèmes complexes avec SysML, 2015, Page 7.

* ³⁶ Idem

* ³⁷ David et Joseph Gabay, UML2 Analyse et conception, Page 26

* ³⁸ Pascal Roques, Modélisation de systèmes complexes avec SysML, 2015, Page 7.

* ³⁹Modélisation UML : Diagramme d'activité, https://fr.wikiversity.org/wiki/Mod%C3%A9lisation_UML/Le_diagramme_d%27activit%C3%A9, visité le 06/04/2017 à 12h35

* ⁴⁰Xavier Blan & Isabelle Mounier, UML2 pour les développeurs, 64P

* ⁴¹ JOSEPH & DAVID GABAY, UML 2 Analyse et conception, Page 33

* ⁴² Pierre Gérard, MERISE Modélisation des systèmes d'informations, 2004-2005, page 18