AVERTISSEMENT. D'autre part, toute contrefaçon, plagiat, reproduction encourt une poursuite pénale. LIENS

Transcription

1 AVERTISSEMENT Ce document est le fruit d'un long travail approuvé par le jury de soutenance et mis à disposition de l'ensemble de la communauté universitaire élargie. Il est soumis à la propriété intellectuelle de l'auteur. Ceci implique une obligation de citation et de référencement lors de l utilisation de ce document. D'autre part, toute contrefaçon, plagiat, reproduction encourt une poursuite pénale. illicite Contact : ddoc-memoires-contact@univ-lorraine.fr LIENS Code de la Propriété Intellectuelle. articles L Code de la Propriété Intellectuelle. articles L L

2 Master I2E2I Faculté des sciences et technologies BP VANDOEUVRE LES NANCY Université de Lorraine Faculté des Sciences et Technologies Master Ingénierie Electrique Electronique et Informatique Industrielle Spécialité «Electronique embarquée et microsystème» Année universitaire 2013/2014 Etude des réseaux cellulaires et implémentation d une application de sauvegarde du répertoire téléphonique Mémoire présenté par «Fakheur Rachid» Soutenu le 12/09/2014 Stage effectué à l entreprise SILT TELECOM GRIM 86, Rue KHODJA Khaled, Tizi Ouzou, Algérie Tuteur industriel : Si Teyeb Ammar Bâtiment 1er cycle - Boulevard des Aiguillettes - B.P VANDŒUVRE-LES-NANCY CEDEX Téléphone : Télécopie :

3 Sommaire Avant-propos.... Remerciements.... Présentation de la société.... Introduction... 1 I. Etude des réseaux cellulaires :... 2 I.1. Principes des architectures des réseaux cellulaires :... 2 I.1.1. Concept cellulaire :... 2 I.1.2. Réutilisation de fréquences :... 2 I.2. Structure générale d un réseau GSM :... 3 I.2.1. Le sous système radio (BSS) :... 3 I.2.2. Le Sous système réseau (NSS) :... 4 I.2.3. Sous-système d exploitation et de maintenance (OSS) :... 5 II. Etude et analyse de l application :... 6 II.1. Étapes de la conception :... 6 II.1.1.Description du langage UML :... 6 II.2. Expression fonctionnelle des besoins :... 7 II.3. Les cas d utilisations :... 8 II.3.1. Cas d utilisation 1 : Gestion compte... 8 II Cas d utilisation 2 : Gestion du répertoire II.4. Diagramme de séquence : III. Conception de l application III.1. Topologie générale : III.2.Architecture générale de l application : III.2.1. L application clientes (SaveRep) : III.2.2. L application serveur : III.3. Conception de l application SaveRep : III.3.1. Conception du Serveur : III.3.2. Conception du Client (application SaveRep) : III.4. Responsabilités des classes : III.4.1.Côté serveur : III.4.2.Côté client : III.5. Conception de la base de données : IV. Test partiel de l application :... 22

4 IV.1. Le protocole de communication : IV.1.1. Description du langage XML (extensible Markup Language) : IV.1.2. DTD (Document Type Définition) : IV.2. Exemples d utilisation : IV.2.1. Opération de souscription au service SaveRep : IV.2.2. Opération de mise à jour : IV.2.3. Opération de récuperation du répertoire téléphonique : IV.2.4. Opération de modification du mot de passe : IV.3.Test partiel des classes réalisés de l application : Conclusion Bibliographie :.... Annexe :....

5 Avant-propos Ce rapport est issu de mon stage de fin d étude que j ai réalisé dans le cadre de l obtention du Diplôme Master 2 électronique embarquée et microsystème dont les enseignements sont dispensés à l université de lorraine. Au cours de ce stage que j ai effectué au sein de la société SILT TELECOM GRIM entre mai et septembre 2014, j ai eu pour mission de développer une application JAVA pour usage de la téléphonie mobile à capacité réduite qui permettra aux abonnés d un opérateur téléphonique de sauvegarder et de mettre à jours leurs répertoires téléphoniques dans l optique de les récupérer au besoin.

6 Remerciements Je tiens, en ces quelques mots, à adresser mes sincères remerciements à mon encadreur M. SI TAYEB AMMAR, pour sa disponibilité, suggestions et remarques et surtout pour sa confiance, mise en moi tout au long de mon stage. Je tiens également à exprimer mes vifs remerciements au gérant de la société SILT TELECOM, M. GRIM MOULOUD pour m avoir permis de passer mon stage au sein de son entreprise. Je remercie également toute personne qui m a aidé de prés ou de loin à réaliser ce travail. sœur, ainsi que toute ma famille.. Je dédie ce modeste travail à mes parents, mes frères et ma

7 Présentation de la société SILT TELECOM GRIM est une société spécialisée dans la réalisation des réseaux Téléphonique, ainsi que l installation des standards téléphonique de toutes capacités, de marque : Panasonic, Intel bras, Samsung, Alcatel,...etc. Le siège social de la société se trouve à l adresse suivante : 86, Rue Khodja Khaled, à Tizi Ouzou (Algerie). SILT TELECOM GRIM est homologuée par l école nationale des PTT (Agrément du ministère des PTT N o 192/99 en l année 1999) Au début, l activité de l entreprise consiste principalement en le raccordement des abonnés en partenariat avec ALGERIE TELECOM. En 2001, l entreprise a élargie son champ d activité en se lançant dans la téléphonie privée (Standard téléphonique). En 2003, elle a enrichi sa gamme d activité en optant pour l installation des réseaux informatiques. En 2007, suite à la demande croissante du marché dans le domaine de l électricité industriel, elle s est lancée dans le raccordement des armoires électrique (courant faible et courant fort). Actuellement, la société emploi 12 salariés et fait appel parfois aux sous-traitants dans ces grands projets.

8 Introduction Introduction Le monde des communications mobiles, en particulier celui des réseaux cellulaires, a sans doute beaucoup gagné des avancés technologiques accomplies et de la miniaturisation des équipements électroniques en général et de la télécommunication en particulier. Cette technologie de miniaturisation prend l allure d une course effrénée de recherche de compromis entre le poids, la puissance et la longévité des sources d énergie (batteries). Ajouter à cela, l augmentation des débits offerts par les réseaux cellulaires, ce qui a permis la naissance de nouveaux services à même d intéresser les utilisateurs dont le nombre est en constante augmentation. Pour fidéliser une clientèle, les opérateurs des réseaux cellulaires cherchent toujours à proposer de nouveaux services qui répondent aux besoins de leurs clientèles. Notre travail s insert dans cet optique. Il consiste à concevoir et à implémenter un service de sauvegarde et de récupération du répertoire téléphoniques. En effet, le répertoire téléphonique est devenu l'une des fonctions les plus importantes pour de nombreux utilisateurs. Perdre leur téléphone ou se le faire voler peut être extrêmement contrariant, puisqu'ils risquent de perdre tous les numéros et contacts qui y sont stockés. Il n'y a rien de plus problématique pour un utilisateur de téléphone mobile que de perdre sa base de données de contacts, qu'elle soit stockée sur une carte SIM ou directement sur un téléphone. Le service ou l application qu on va développer (SaveRep) permettra aux abonnés d un opérateur téléphonique de sauvegarder et de mettre à jours leurs contacts dans le but de les récupérer au besoin. 1

9 Chapitre I : Etude des réseaux cellulaires I. Etude des réseaux cellulaires : Dans ce chapitre nous allons faire une brève description des réseaux cellulaires. I.1. Principes des architectures des réseaux cellulaires : I.1.1. Concept cellulaire : Les réseaux cellulaires modernes se sont organisés autour du principe de cellule. Chaque cellule est desservie par une station de base qui assure le rôle d un intermédiaire entre l infrastructure fixe du réseau et les utilisateurs situés à l intérieur de la cellule. Ainsi, une cellule peut être définie comme étant l étendu géographique couvert par une station de base et où le signal transmis est d une qualité acceptable à tout point de la cellule [1]. I.1.2. Réutilisation de fréquences : Le principe de réutilisation de fréquence consiste à l allocation de la même gamme de fréquences à des cellules qui sont suffisamment distancées pour éviter les effets des interférences comme illustré dans la figure 1. C est grâce à ce principe fondamental, qu un opérateur peut augmenter le nombre d utilisateur de son réseau [2]. Figure 1 : Réutilisation de fréquences 2

10 Chapitre I : Etude des réseaux cellulaires I.2. Structure générale d un réseau GSM : Le réseau GSM est organisé autour de trois sous système : 1. Le sous-système radio. 2. Le sous-système réseau. 3. Le sous-système opérationnel ou d exploitation et de maintenance. Figure 2 : Architecture d un réseau GSM On présente dans ce qui suit une brève description de ses sous système. I.2.1. Le sous système radio (BSS) : Le sous système radio regroupe tous les équipements impliqués plus ou moins directement avec la transmission sur l interface air, et qui prennent à leur charge la gestion de la partie radiocommunication avec les terminaux du réseau. Il est composé des éléments suivants : MS (Mobile Station), ou station mobile : C est la partie mobile du BSS, et qui est à la possession de l utilisateur. Le téléphone et la carte SIM (Subscriber Identity Module) sont les deux éléments auxquels un 3

11 Chapitre I : Etude des réseaux cellulaires utilisateur à directement accès. Ces deux éléments suffisent à réaliser l ensemble des fonctionnalités nécessaires à la transmission. BTS (Base Transceiver Station), ou station de base : C est le point d accès des MS au réseau GSM. Les BTS se matérialisent sous la forme d antenne (émetteur/récepteur) pilotant une ou plusieurs cellules. Elles ont pour charge d assurer l accès radio des mobiles se trouvant sous leur couverture BSC (Base Station Contrôleur), ou contrôleur de BTS : Les BSC, sont des contrôleurs de BTS. Un BSC standard peut contrôler environ 60 BTS. Le BSC a pour rôle de gérer les stations de bases qui lui sont connectées, ainsi que le contrôle d admission des appels, la gestion des handovers [3]. I.2.2. Le Sous système réseau (NSS) : Si le sous système radio gère l accès à l interface réseau, le sous système réseau, ou NSS (Network SubSystem) prend à sa charge l acheminement des données à l intérieur du réseau cœur ainsi que l interconnexion avec les réseaux publics ou privés, auxquels est rattaché le réseau mobile. Le sous-système réseau gère en outre l établissement des appels et la mobilité des abonnés, et pour cela il est doté des équipements suivants : MSC (Mobil service Switching Center) : Le MSC, ou commutateur du service mobile, est un commutateur dont la fonction est de gérer toutes les communications avec les mobiles et d assurer la commutation entre les abonnés du réseau mobile et ceux du réseau commuté public (RTC). Il assure en outre les fonctions de gestion de la mobilité, ainsi que la localisation des abonnés [3]. Le HLR (Home Location Register) : Le HLR, ou l enregistreur de localisation nominale, est une base de données dans laquelle sont stockées toutes les informations relatives aux abonnés d un PLMN. Ces informations sont de deux types : 4

12 Chapitre I : Etude des réseaux cellulaires Des informations statiques, telles que les identités IMSI((International Mobile Subscriber Identity) et les numéros courants des abonnés. Des informations dynamiques, ayant relation avec la localisation des abonnés, telle que la localisation courante des abonnés (c'est-à-dire, la référence du VLR de la zone où se trouve chaque abonné. Le VLR (Visitor Location Register) : Le VLR, ou base de données de localisation des visiteurs, est une base de données dans laquelle sont stockées dynamiquement les informations relatives à la mobilité des abonnés. Elle contribue à la localisation des abonnés en déterminant la dernière zone de localisation connue de ces derniers. Une zone de localisation qui n est rien d autre qu un sous-ensemble de cellules ou se trouve l abonné. AUC (Authentification Center), centre d authentification : C est une base de données contenant tous les codes PIN des cartes SIM, ainsi que des algorithmes de chiffrement qui lui permet de réaliser les opérations d identifications et d authentification des abonnés lorsque ces derniers tentent d accéder au réseau,il est chargé de vérifier l'identité des utilisateurs [4]. I.2.3. Sous-système d exploitation et de maintenance (OSS) : Il englobe tout ce qui est en relation avec la maintenance et l exploitation du réseau, qu il réalise au travers de ses centres d exploitation et de gestion OMC (Operating and Maintenance Center), à travers lesquels, l opérateur du réseau veille au bon fonctionnement de son système. Comme son nom l indique, l OSS (Operating Support Subsystem), assure deux fonctions principales : La gestion administrative ou commerciale du réseau, qui consiste à gérer les abonnés (création, modification, suppression), et la facturation du trafic généré par ces derniers. La gestion technique, concerne toutes les opérations de maintenances et de mise à niveau des équipements du réseau que ce soit au niveau matériel ou logiciel. 5

13 Chapitre II : Etude et Analyse de l application II. Etude et analyse de l application : II.1. Étapes de la conception : Pour mener à bien ce projet, on a eu recours au langage de modélisation unifié UML (Unified Modeling Language) pour modéliser et représenté graphiquement l application à développer. II.1.1.Description du langage UML : C est un langage graphique par représentation orienté objet pour modéliser le système objet. Il utilise une notation graphique commune (graphe) et des relations visuelles [5]. Les étapes nécessaires pour la conception de l application sont données par les diagrammes de la figure suivante : Identification des acteurs Identification des activités Le diagramme des cas d utilisation Diagramme des séquences Le diagramme des classes Figure 3 : Etapes de la conception 6

14 Chapitre II : Etude et Analyse de l application II.2. Expression fonctionnelle des besoins : Pour décrire les besoins des futurs utilisateurs nous avons fait recours aux digrammes des cas d utilisation d UML. Les cas d utilisation constituent un moyen de recueillir et de décrire les besoins des acteurs du système (les grandes fonctions). Ils permettent de représenter le fonctionnement du système vis-à-vis de l utilisateur [6]. Chaque cas d utilisation doit être documenté pour qu il n y aucune ambigüité concernant son déroulement et ce qu il recouvre précisément et traité tout les cas existant. Notre application (SaveRep) dégage deux cas d utilisation majeurs que nous représentons par le diagramme des cas d utilisation global illustré dans la figure ci-dessous. Système SaveRep <<extend> > Inscription au service Gestion compte <<extend>> Annuler Inscription 1 0 <<extend> > Changer mot de passe Récupération du répertoire <<include>> <<include>> <<include>> Authentification Gestion répertoire Mise à jour du répertoire <<include>> Figure 4 : Diagramme des cas d utilisation global 7

15 Chapitre II : Etude et Analyse de l application II.3. Les cas d utilisations : Les divers cas d utilisation ainsi que les scénarios possible qui correspondent à ces cas d utilisation sont donnés comme suit : II.3.1. Cas d utilisation 1 : Gestion compte Trois scénarios peuvent être considérer : Inscription au service, annuler l inscription au service et changer mot de passe. Scénario 1.1 «Inscription au service» : Objectif : Permettre à l abonné d adhérer au service. Acteur concerné : Usager du réseau (abonné). Pré Conditions : - être abonné du PLMN (Réseau Mobile Terrestre Publique) offrant le service. - avoir installé l application SaveRep. Scénario nominal : 1- Cocher le bouton radio qui correspond à la fonction d inscription. 2- Saisir le nom d utilisateur (user name). 3- Saisir le mot de passe (password). 4- Envoyer la demande d inscription. Scénario alternatif : - Nom utilisateur existe déjà : Le système réaffiche le formulaire de saisie et indique les erreurs détectées. -L utilisateur corrige les erreurs. -Le cas d utilisation reprend à l action 2 du scénario nominal. Scénario 1.2 «Modifier mot de passe» : Objectif : permettre à l utilisateur de modifier son mot de passe. Acteur concerné : usager du réseau (abonné). Scénario nominal : 1- Cocher le bouton radio qui correspond à la fonction de changement de mot de passe. 2- Saisir le nom d utilisateur (user name). 8

16 Chapitre II : Etude et Analyse de l application 3- Saisir l ancien mot de passe (password). 4- Saisir le nouveau mot de passe. Scénario alternatif : 1- Erreur de saisie lors de la saisie du nom d utilisateur ou du mot de passe : -Le système réaffiche le formulaire de saisie et indique les erreurs détectés. -L utilisateur corrige les erreurs. -Le cas d utilisation reprend à l action 2 ou 3 du scénario nominal selon que l erreur de saisie soit dans le nom d utilisateur ou dans le mot de passe. 2- Le nouveau mot de passe est identique avec l ancien : -Le système réaffiche le formulaire de saisie et indique les erreurs détectés. -L utilisateur corrige les erreurs. -Le cas d utilisation reprend à l action 4 du scénario nominal. Scénario 1.3 «Annuler l inscription au service» : Objectif : permettre à l utilisateur de relancer à son adhérence au service. Acteur concerné : usager du réseau (abonné) Pré conditions : - Etre déjà souscrit au service. Scénario nominal : 1- Cocher le bouton radio qui correspond à la fonction d annulation d adhérence au service. 2- Saisir le nom d utilisateur (user name). 3- Saisir le mot de passe (password). 4- Appuyer sur le bouton OK. Scénario alternatif : - Erreur de saisie lors de la saisie du nom d utilisateur ou du mot de passe : -Le système réaffiche le formulaire de saisie et indique les erreurs détectés. -L utilisateur corrige les erreurs. -Le cas d utilisation reprend à l action 2 ou 3 du scénario nominal selon que l erreur de saisie soit dans le nom d utilisateur ou dans le mot de passe. 9

17 Chapitre II : Etude et Analyse de l application II Cas d utilisation 2 : Gestion du répertoire Pour la gestion du répertoire deux cas scénarios peuvent être considérés : Récupération du répertoire et la mise à jour du répertoire. Scénario 2.1 «mise à jour du répertoire téléphonique» Objectif : Permettre à l abonné de sauvegarder et de mettre à jour son répertoire téléphonique. Acteur concerné : Usager du réseau (abonné). Pré Condition : - Etre souscrit au service SaveRep. Scénario nominal : 1- Cocher le bouton radio qui correspond à la fonction de sauvegarde du répertoire. 2- Saisir le nom d utilisateur (user name). 3- Saisir le mot de passe (password). 4- Envoyer la demande pour sauvegarder le répertoire. Scénario alternatif : 1- Erreur de saisie lors de la phase d authentification : Le système réaffiche le formulaire de saisie et indique les erreurs détectées. -L utilisateur corrige les erreurs. - Le cas d utilisation reprend à l action 2 ou 3 du scénario nominal selon que l erreur de saisie soit dans le nom d utilisateur ou dans le mot de passe. 2- Erreur d accès au répertoire local : Le système affiche un message d erreur en indiquant son type et réaffiche la fenêtre principale pour permettre à l utilisateur de refaire l opération. -Le cas d utilisation reprend à l action 1 du scénario nominal. Scénario 2.2 «récupération du répertoire» : Objectif : Permettre à l abonné de récupérer son répertoire téléphonique. Acteur concerné : usager du réseau (abonné). 10

18 Chapitre II : Etude et Analyse de l application Scénario nominal : 1- Cocher le bouton radio qui correspond à la fonction de récupération du répertoire. 2- Saisir le nom d utilisateur (user name). 3- Saisir le mot de passe (password). Envoyer la demande de récupération du répertoire. Scénario alternatif : 1- Erreur de saisie lors de la phase d authentification : Le système réaffiche le formulaire de saisie et indique les erreurs détectées. 2- Erreur d accès au répertoire local : Le système affiche un message d erreur en indiquant son type et réaffiche la fenêtre principale pour permettre à l utilisateur de refaire l opération. II.4. Diagramme de séquence : Le diagramme de séquence permet une représentation graphique temporelle des interactions entre les classes ainsi que la chronologie des messages (fonctions) échangés entre les classes et avec les acteurs. La durée d exécution de chaque entité (fonction) est représentée verticalement. Les échanges de messages sont représentés horizontalement [7]. Les figures ci-dessous suivantes représentent les diagrammes de séquence qui illustrent les interactions entre les classes et les fonctions opérer pour réaliser chaque service composant l application de sauvegarde du répertoire téléphonique. 11

19 Chapitre II : Etude et Analyse de l application GUI authentific ationcation Compte message Demande Inscription() Inscription () Créer Code XML () Modifier Mot De Passe() Retour Info Envoyer Demande Inscription() Résultat de l opération Authentification Demande Authentification Demande Informations () Remise d info Contrôle Saisie () opt Gestion d erreur Affichage erreur Affichage erreur Authentification OK Annuler Inscription() Send MSG(nouveau mot de passe) Résultat de l opération Authentification Demande Authentification Demande Informations() Remise d info Contrôle saisie() opt Gestion d erreur Affichage erreur Affichage erreur Authentification OK Send MSG(annuler l inscription) Résultat de l opération Figure 5 : Diagramme de séquence de la gestion du compte 12

20 Chapitre II : Etude et Analyse de l application GUI Authentifica tion Mise à jour Parsse ur Com pte Cont act message Mise a Jour Rep() Authentification Demande Authentification() Remise Demande Informations() d informations Contrôle saisie() opt Gestion d erreur Affichage erreur Affichage erreur Authentification OK Importer Répertoire local() Accès Répertoire local () opt Erreur d accès au RepTél affichage erreur affichage erreur Répertoire local Importer Ancien Répertoire () Traitement fichier XML Ancien Répertoire Parser File() Resultat Parsage Comparer Répertoire () Loop [Contact. existe] Résultat comparaison Comparer Contacts() Résultat comparaison Exporter Répertoire To Téléphone (PIM) Send MSG(nouveau répertoire) Figure 6 : Diagramme de séquence de la gestion du répertoire «mise à jour» 13

21 Chapitre II : Etude et Analyse de l application GUI authentification RecRépertoire parseur Gestion compte message Demande Récupération Rep() Authentification Demande authentification() Contrôle saisie() Demande Informations() Remise d informations opt Gestion d erreur Affichage erreur Affichage erreur Authentification OK Demande Récupération Répertoire () Générer requête Générer Code XML() Retour de la Requête RepResultat1 Exporter Répertoire To Téléphone (PIM) Send MSG() Traitement fichier XML RepRésultat2 Parser File() Resultat Parsage Afficher Repértoire() Affichage Repértoire Affichage Repértoire Figure 7 : Diagramme de séquence de la gestion du répertoire «Récupérer répertoire» 14

22 Chapitre III : Conception de l application III. Conception de l application III.1. Topologie générale : Vu que l application SaveRep est destinée à fonctionner sur un réseau cellulaire. On utilisera pour sa mise en place un matériel qui représente respectivement les différents équipements intervenants dans une infrastructure réseau cellulaire réelle. Pour cela, on aura besoin des équipements suivant : Une application serveur pour traiter les requêtes qui lui sont destinées par les applications clientes (l application SaveRep). Une application BTS qui sera le point d accès au réseau par lequel les terminaux mobiles accèdent au serveur. Cette application BTS sera équipée d une interface sans fil pour la connexion avec la partie serveur et d une interface bluetooth (JSR-082) pour la connexion avec le téléphone portable abritant la partie cliente (l application SaveRep). Terminal mobile (téléphone portable) : Pour les clients, nous avons opté pour un téléphone mobile de marque Sony Ericsson, dont le modèle est le K800i qui est muni de la MIDP 2.0 (Mobile Information Device Profile), de la JSR-082 et de la JSR-075. Figure 8 : Topologie général de l application 15

23 Chapitre III : Conception de l application III.2.Architecture générale de l application : L application implémentant le service proposé s articule sur une architecture de type client/serveur. Elle est organisée sous forme de deux applications III.2.1. L application client (SaveRep) : Elle prend à sa charge de constituer une interface permettant à l utilisateur d accéder au service. Elle est implémentée sur des terminaux mobiles. Elle peut réaliser les opérations suivantes : - inscription au service SaveRep. - envoyer le répertoire téléphonique. - mettre à jour le répertoire téléphonique. - récupérer le répertoire sauvegardé chez l opérateur. - modifier le mot de passe. - annuler l inscription au service. III.2.2. L application serveur : L application serveur quant à elle, prend à sa charge de traiter les requêtes qui lui sont envoyées par les applications clientes en vue de répondre et de réaliser les différentes fonctions proposées par le service et qui sont véhiculées par des requêtes. Elle exploite une base de données pour réaliser les opérations suivantes : - authentification des abonnés. - enregistrer un répertoire téléphonique. - envoyer un répertoire téléphonique. - mettre à jour un répertoire téléphonique. - mettre à jour les paramètres de sécurité des abonnés. 16

24 Chapitre III : Conception de l application III.3. Conception de l application SaveRep : III.3.1. Conception du Serveur : La partie serveur du système est un package composé des classes illustrées sur le diagramme des classes de la figure 9 ci-dessous. Serveur GestionnaireBD Main () Reception Requêtes() Répondre aux requêtes () Interroger BD() GénérateurRequête Générateur Requête () Figure 9 : Diagramme de classe du serveur Le diagramme de classe permet de spécifier la structure et les relations entre les objets dont le système est composé : il spécifie qui sera à l'œuvre dans le système pour réaliser les fonctionnalités décrites par les diagrammes des cas d'utilisation [8]. III.3.2. Conception du Client (application SaveRep) : Dans cette partie, l application cliente est une midlet implémentée sur des périphériques de la téléphonie mobile intégrant la plate-forme Java et la technologie Bluetooth. Le diagramme de classes est illustré sur la Figure 10 suivante : 17

25 Chapitre III : Conception de l application SaveRep public void startapp( ) public void pauseapp( ) public void commandaction() Authentification Répertoire getrep() getcontact(i) Authentification () Compte user name : string password : string exporttofile() importfromfile(striring) parseur() GenererCodeXML() Message sendmsg() receivemsg() Inscription() Annuler Inscription() Modifier Mot De Passe() RécupérationRep MiseàJourRep contact -ident : String -nom : String -telmobile : String.. +getident() +getnom() +gettel(int Type) +setident(string) +comparto(contact) exportertotelephone() recrep() ImporterRepLoc () CompareTo(Contact) Figure 10 : Diagramme de classe du client 18

26 Chapitre III : Conception de l application III.4. Responsabilités des classes : III.4.1.Côté serveur : L application côté serveur a pour responsabilité principale, le traitement des requêtes en provenance des clients, et la gestion d une base de données contenant les informations des clients. Elle ce compose principalement des classes suivantes : Serveur : Réalise des tâches de réinitialisation. Elle s occupe de lancer le serveur et de se mettre en attente des connexions clientes. Générateur de requête : S occupe de générer, en fonction des besoins utilisateur, les requêtes d interrogation de la base de donnée et de traduire les réponses sous un format compréhensible par l application cliente. Gestionnaire BD (base de donnée): Se contente de la gestion de la base de données en exécutant les requêtes qui lui sont formulées. III.4.2.Côté client : L application cliente (SaveRep) a pour rôle d offrir une interface graphique permettant à l abonné de lancer une des fonctionnalités proposées et de réaliser les tâches nécessaires, en vu de répondre aux besoins des utilisateurs. Pour ce faire, l application cliente est organisée principalement par les classes suivantes : SaveRep : Gère l interface graphique et réagit aux sollicitations des clients. Repertoire : Offre les fondements de base pour la gestion du répertoire téléphonique. Elle donne naissance à deux classes : RécupérationRép et MiseàJourRép qui s occupent respectivement de prendre en charge les fonctions de récupération et de mise à jour du répertoire téléphonique. Authentification : Gère l authentification des clients. Message : Prend en charge les messages à envoyer et ceux reçus. 19

27 Chapitre III : Conception de l application III.5. Conception de la base de données : Dans cette phase de notre travail on s intéresse à la description des règles de gestion pour définir la manière de concevoir la structure de la base de données en utilisant un modèle conceptuel : Le modèle relationnel Le modèle relationnel permet de structurer les données à stocker dans la base de données, il représente la base de données comme un ensemble de tables. Le schéma relationnel de la base de donnée est donné par : Abonné (nom_utilisateur, mot_de_passe). Contact (nom_utilisateur, identifiant_du_contact, tel_mobile, tel_home, tel_ fax, tel_ work, tel_ other). Donc la base de données à concevoir est constituée de deux tables : 1. La table abonné. 2. La table contact. les champs des tables : 1. Table abonné : Nom champ du Type données de Nom_utilisateur Chaine de caractères mot_de_passe Chaine de caractères description Identifiant de l utilisateur Mot de passe de l utilisateur Tableau 1 : Table des abonnés 20

28 Chapitre III : Conception de l application 2. Table contact : Nom du champ Type de données Description Nom_utilisateur Chaine da caractères Identifiant de l abonne a qui appartient le contact identifiant_du_contact Chaine da caractères Identifiant du contact dans le téléphone tel_mobile Entier Numéro mobile du contact tel_home Entier Numéro de maison du contact tel_ fax Entier Numéro de fax du contact tel_ work Entier Numéro travail du contact tel_ other Entier Un autre numéro du contact Tableau 2 : Table des contacts 21

29 Chapitre IV : Test Partiel de l application IV. Test partiel de l application : IV.1. Le protocole de communication : On donne dans ce qui suit la structure des informations générées par les clients et traiter par le serveur. C est des informations structurées en utilisant le langage à balisage extensible XML. IV.1.1. Description du langage XML (extensible Markup Language) : Le XML est un langage de balisage, qui définit un ensemble de règles syntaxiques pour la présentation structurée de l'information. Il est aussi bien utilisé pour le stockage de documents que pour la transmission de données entre applications. il s'agit d'un langage orienté texte et formé de balises qui permettent d'organiser les données de manière structurée. Ce langage, permet de faciliter l'échange d'information et donne la possibilité de créer de nouvelles balises [9]. IV.1.2. DTD (Document Type Définition) : Le rôle d'une DTD est de définir précisément la structure d'un document XML. Elle déclare les normes de validité du document XML, elle définit entre autre l ordre d apparition et d imbrication des éléments et des attributs.elle permet aussi de déclarer de nouvelle balise et de spécifier des contraintes sur celle-ci. 22

30 Chapitre IV : Test Partiel de l application La DTD qu on a utilisé dans ce travail est donnée comme suit : <?xml version="1.0"?> <!DOCTYPE protocole SYSTEM "protocole.dtd"> <protocole> <!ELEMENT saverep (newpassword, operation*) > <!ATTLIST saverep user ID #REQUIRED password ID #REQUIRED service CDATA ( ) 1 > <!ELEMENT newpassword (#PCDATA)> <!ELEMENT operation (contact+)> <!ATTLIST operation type (+ - ~)> <!ELEMENT contact (nom, telephone*)> <!ATTLIST contact Id ID > <!ELEMENT nom (#PCDATA)> <!ELEMENT telephone (#PCDATA) > <!ATTLIST telephone Typetel (mobile work home fax other ) mobile > </protocole> IV.2. Exemples d utilisation : On présente dans ce qui suit des exemples de codes XML, tel qu ils sont envoyés ou reçus par l application dans différents cas de figures. 23

31 Chapitre IV : Test Partiel de l application IV.2.1. Opération de souscription au service SaveRep : On utilise pour l illustration de cette opération un répertoire qui contient deux contacts. <?xml version = "1.1"?> <saverep user = "rachid", password = "5891", service = 1 > <operation type = + > <contact id = 001 > <nom> madjid </nom> <telephone typetel = mobile > </telephone> <telephone typetel = worke > </telephone> <telephone typetel = home > </telephone> <telephone typetel = fax > </telephone> <telephone typetel = other > </telephone> </contact> <contact id = 002> <nom>rachid</nom> <telephone typetel = mobile > </telephone> <telephone typetel = worke > </telephone> <telephone typetel = fax > </telephone> </contact> </operation> </saverep> 24

32 Chapitre IV : Test Partiel de l application IV.2.2. Opération de mise à jour : Avant d effectuer cette opération on a réalisé sur le répertoire de notre téléphone les deux opérations suivantes : modifier le contact «id=001» et enregistrer un nouveau contact. <?xml version = "1.1"?> <saverep user = "rachid", password = "5891", service = 2 > <operation type = ~ > <contact id = 001 > <telephone typetel = mobile > </telephone> <telephone typetel = worke > </telephone> <telephone typetel = home ></telephone> <telephone typetel = fax ></telephone> <telephone typetel = other ></telephone> </contact> </operation> <operation type = + > <contact id = 003 > <nom>djamel</nom> <telephone typetel = mobile > </telephone> <telephone typetel = other > </telephone> </contact> </operation> </saverep> IV.2.3. Opération de récuperation du répertoire téléphonique : <?xml version = "1.1"?> <saverep user = "rachid", password = "5891", service = 3 > </saverep> 25

33 Chapitre IV : Test Partiel de l application IV.2.4. Opération de modification du mot de passe : <?xml version = "1.1"?> <saverep user = "rachid", password = "5891", service = 4 > <newpasword> fakheur</ newpasword > </saverep> IV.3.Test partiel des classes réalisés de l application : Vu que je n ai pas terminé la programmation de l ensemble des classes de l application, j ai pas pu tester l application. Par ailleurs, j ai pu développer quelques classes de l application à savoir la classe de l interface graphique (GUI),de la gestion de compte, de la gestion du répertoire,des contacts ainsi que l application serveur nécessaire pour le test de notre application. A cet effet on va juste d illustrer les fenêtres affichées lors de l exécution des classes dont j ai pu programmer. La figure suivante représente la fenêtre d exécution de la classe LoginScreen invitant l abonné à s authentifier en introduisant un nom utilisateur et un mot de passe. Figure 11 : Fenêtre d affichage de la classe LoginScreen 26

34 Chapitre IV : Test Partiel de l application Une fois l authentification est faite avec succès. L application affiche la figure suivante qui représente une fenêtre qui offre à l abonné la possibilité de choisir entre deux opérations : Gestion de répertoire et Gestion du compte. L abonné fait ainsi son choix en sélectionnant gestion répertoire ou gestion de compte en appuyant ensuite sur OK. Figure 12 : Fenêtre d affichage de la classe sauvegarde du répertoire La fenêtre suivante s affiche une fois qu on sélectionne le service gestion de répertoire de la figure 12. Cette fenêtre invite l abonné à choisir le service qu il souhaite lancer en sélectionnant sauvegarder le répertoire ou récupérer son répertoire téléphonique. Figure 13 : Fenêtre d affichage de la classe gestion du répertoire 27

35 Chapitre IV : Test Partiel de l application La fenêtre suivante s affiche une fois qu on sélectionne le service gestion du compte de la figure 12. Cette fenêtre invite l abonné à choisir le service qu il souhaite lancer parmi les choix affichés sur la fenêtre. Figure 13 : Fenêtre d affichage de la classe gestion du compte 28