Miniprojet POO

[Mini Projet En Programmation Oriente Objet]

Mini-projet Oriente Objet N2TR 2013/2014UVT[Mini Projet En Programmation Oriente Objet]Conception et ralisation dune application de gestion des BTS dun centre radio GSM

Fawel Sofien & Marnaoui Mohamed Taher

Table des matiresIntroduction Gnrale5I-Prsentation Gnrale61-Introduction62-Description de lexistant63-Critique de lexistant74-Solution propose75-Notion de base dun systme radio GSM76-Conclusion8II-Spcification des besoins91-Introduction92-Etude des besoins92-1 Besoins Fonctionnels93-Les diagrammes de cas dutilisation103-1 Prsentation des acteurs103-2 les diagrammes cas utilisation11III-Conception151-Introduction152-L'architecture globale du systme152-1 Architecture simple tiers152-2 Architecture client/serveur162-3 Architecture trois tiers162-4 Spcification darchitecture172-5 Division en paquetage183-Conception de niveau donnes193-1 Description des classes193-2Diagramme de classe233-3 Les Diagrammes de squences233-4Les Diagrammes dactivit264-Conception du niveau prsentation294-1 Modle de navigation294-2 Charte graphique295- conclusion30IV-Ralisation311-Introduction312-Environnement de travail312-1 Environnement matriel312-2 Environnement logiciel313-Captures dencrant324-Conclusion38Conclusion Gnrale39

Figure 1: Architecture rseau GSM9Figure 2:Diagramme cas d'utilisation "Authentification"12Figure 3:Diagramme cas Utilisation "Grer Utilisateur"13Figure 4:Diagramme cas utilisation raffine15Figure 5:Architecture Simple tiers16Figure 6: Architecture 2-tiers17Figure 7: Architecture 3-tiers18Figure 8: Modle MVC19Figure 9:Division en paquetages19Figure 10:Diagramme de classe24Figure 11:Diagramme de squence " Authentification"25Figure 12:Diagramme de squence "ajouter utilisateur"26Figure 13:Diagramme de squence "Modifier Utilisateur "27Figure 14:Diagramme d'activit Authentification28Figure 15:Diagramme d'activit "Ajouter Utilisateur"29

Introduction GnraleLvolution technologique dans le monde des tlcommunications se fait grands pas. Ainsi lapparition des nouvelles technologies se fait une grande cadence, surtout pour les systmes de tlcommunication mobile. De nos jour la norme GSM, reprsente le systme de tlcommunication mobile le plus tendue et le plus utilis travers le monde.Dans un monde o de plus en plus de documents sont produits ou diffuss en mode numrique, la numrisation des documents dans les classeurs administratifs est en croissance dans les organisations depuis plus de 25 ans. Nous vivons une poque o lautomatisation des systmes dinformation devient une politique qui est de plus en plus adopt dans de nombreux tablissements. En effet, cette politique assure une acclration et plus de prcision lors du traitement de linformation. Elle permet galement une circulation plus rapide et plus sre de linformation.Cest dans ce contexte que sinscrit ce mini projet. En faite ce travail a pour but de concevoir et raliser une application simple et efficace qui facilite la manipulation des diffrentes informations sur les composantes du rseau GSM.Pour arriver au rsultat exempt nous allons deviser ce travail en quatre parties. La premire partie sintressera a une tude thorique de quelque notion de base dun systme radio GSM (BTS, TRX, BCCH), une deuxime partie sintressera des spcifications des besoins. La troisime partie sera consacr a la conception de lapplication et enfin une partie de ralisation de lapplication.

I- Prsentation Gnrale 1- IntroductionDans le but de reprsenter la structure et le fonctionnement du systme et de dterminer clairement les principaux pas suivre afin de proposer un meilleur aspect pour la ralisation de ce travail, une tude de lexistant savre alors ncessaire. Cette tude est dune grande utilit dans la fixation des nouveaux apports intgrer pour amliorer les qualits de service. Dans ce chapitre, on fera une tude de lexistant en indiquant ses limites, puis la solution propos et ces objectifs et enfin une petite tude thorique de quelque notion de base dun rseau GSM.2- Description de lexistantLunit Radio GSM prsente lune des principales units technique de Tunisie tlcom puisquelle gre un trs grand nombre dquipements radio tel que les BSC et les BTS. Et vu le nombre croissant des quipements ainsi que leur diversits (marque, types), la gestion de leur documentation devient de plus en plus difficile. En effet, lorsquun agent veut consulter la documentation dun quipement, il doit chercher manuellement linformation dans un grand nombre de classeur et des fichiers Excel.Ces documentations peuvent tre: Documentation technique du matriel install (BSC/BTS) archivs dans les classeurs qui contiennent les informations suivantes: site (nom de lemplacement du BTS), DIP (Digital Path), SNT (Switch network Terminal), device, position, salle, version, destination. Documentation de la mise en service: stocke dans des fichiers Excel contenant les informations suivantes: Site, RXOTG (nom du BTS au niveau BSC), BCCH (canal qui peut servir la diffusion dinformation gnrale), CGI (identificateur de la cellule), date de mise en service, configuration et position transmission.

3- Critique de lexistant Daprs ltude de lexistant certaine limites peuvent tre dgages: Dispersion des ressources: elle se prsente sous la forme dun problme de rcupration des donnes donc la recherche dune information est trs longue Manque de flexibilit tant donn que la recherche se fait manuellement Perte des donnes avec le temps.4- Solution proposePour assurer la rapidit et le gain de temps et la flexibilit des donnes, nous nous proposons de raliser un outil de gestion de la documentation de lunit radio GSM.Nous nous intressons introduire une application qui vis atteindre les objectifs suivants: Organiser les diffrentes informations sous forme dune base de donnes numrique au lieu dun support papier. Faciliter la recherche des donnes sur la structure de liaison BTS/BSC. Guider lagent dans les dplacements: donner les informations sur les positions gographiques, et les informations sur les supports physiques darchitecture BTS/BSC. Rduire le temps de recherche dinformation. La gestion des donnes de BSC qui nous permet de contrler chaque BSC et connaitre les informations qui lui sont relatives ainsi que le nombre de BTS quils contrlent et la gestion des donnes des BTS 5- Notion de base dun systme radio GSMLobjectif dun systme radio tlphonique est de permettre laccs au rseau tlphonique mobile partir dun terminal portatif sur un territoire tendu. Le rseau GSM est compos de trois sous ensembles: Sous systme radio BSS: Base Station Subsystem Sous systme rseau NSS: Network Switching Subsystem Sous systme dexploitation et de maintenance OSS: Operation Subsystem.

Figure 1: Architecture rseau GSM

Pour notre travail nous nous intresserons quau parti BSS qui contient principalement les BTS et les BSC:BTS: La BTS ou Base Tranceiver Stationest une antenne plac dans une zone gographique bien dtermin dite cellule, o chaque cellule dispose dun BTS et un seul. Elle consiste en un ou un ensemble dmetteurs rcepteurs appels TRX (Transmission/ Reception Unit) et leur antenne. BSC: Le BSC ou Base Station Controller assure le contrle dun ou plusieurs BTS et se communique avec elle par le biais de linterface A-bis. Le BSC est lorgane intelligent du BSS, charg la gestion des ressources radio.6- ConclusionCe chapitre a t consacr ltude de lexistant en prcisant ces limites. Nous avons aussi prsent notre solution en indiquant ces objectifs. Dans ce qui suit nous entament la phase des spcifications des besoins.II- Spcification des besoins 1- IntroductionLune des principales tapes de cycle de vie dune application est lextraction des diffrents besoins attendus du systme. Ltape de spcification des besoins est conue pour la dtermination des diffrentes fonctionnalits. Dabord, on prsentera une tude des besoins fonctionnels qui conduisent llaboration des diagrammes des cas dutilisation permettant de dtailler les scnarios possibles que peuvent raliser les diffrents acteurs, ensuite on citera les besoins non fonctionnels qui sont en fait les exigences de lapplication.2- Etude des besoins2-1 Besoins FonctionnelsUne tude dtaille du systme permet de dgager les diffrents besoins fonctionnels suivants :Gestion des BSCAjouter BSC: lors de linstallation physique dun nouveau BSC, lagent peut ajouter les diffrentes informations du BSC dans la base.Modifier BSC: modifier les informations relatives un BSC.Supprimer BSC: Lutilisateur peut supprimer un BSCChercher: permet de chercher une information concernant les BSC.Gestion des BTSAjouter BTS: lors de linstallation physique dun nouveau BTS, lagent peut ajouter les diffrentes informations du BTS dans la base.Modifier BTS: permet de faire la mise jour des informations relatives un BTSSupprimer BTS: permet de supprimer un BTS Chercher: permet de chercher une information concernant les BTS.Gestion dutilisateursPermet au administrateur dajouter, modifier et de supprimer des utilisateurs. Permet aussi ladministrateur la gestion des droits daccs Gestion des JonctionsAjouter Jonction: permet dajouter une jonctionModifier Jonction: permet de faire la mise jour des informations relatives une jonctionSupprimer Jonction: permet de supprimer une jonction Chercher: permet de chercher une information concernant les jonctions.2-2 Besoins non fonctionnelsPlusieurs besoins oprationnels sont tenir en compte dans notre application : Fiabilit : les informations fournies par lapplication doivent tre fiables. Solution ouverte et volutive : lapplication peut tre amliore par lajout dautres modules tel que (lanalyse des mesure traage dune carte, etc). Scurit : laccs aux informations nest possible quaprs vrification des privilges des droits daccs. Journalisation: Garder l'historique des actions ralises par les utilisateurs. Convivialit et ergonomie : lapplication doit fournir une interface conviviale et simple pour tout type dutilisateur 3- Les diagrammes de cas dutilisation 3-1 Prsentation des acteursLes diagrammes des cas d'utilisation sont des diagrammes UML utiliss pour donner une vision globale du comportement fonctionnel d'un systme logiciel. Un cas d'utilisation reprsente une unit discrte d'interaction entre un utilisateur (humain ou machine) et un systme.Cest une unit significative de travail. Dans un diagramme de cas d'utilisation, les utilisateurs sont appels acteurs, ils interagissent avec les cas d'utilisation.Dans notre application il existe deux acteurs:Administrateur: Cration des comptes utilisateurs, attribuer les droits daccs. En plus les oprations des gestions de la base de donnesUtilisateur: La gestion de la base de donnes3-2 les diagrammes cas utilisationDiagramme cas utilisation AuthentificationDans un souci de la scurisation de linformation, avant deffectuer une tche quelconque, tous les utilisateurs du systme doivent sidentifier en saisissant leurs identificateurs (Login, Password) respectifs.

Figure 2:Diagramme cas d'utilisation "Authentification"Sommaire didentification

Titre:Authentification

But:Permettre tout utilisateur de sauthentifier et de se connecter au systme.

Rsum:lutilisateur saisie les informations ncessaires pour sauthentifier, le systme vrifie ses informations (login, mot passe et privilge) et le redirige vers son espace selon son droit daccs.

Acteur:Tous les utilisateurs

Description des enchainements

Pr conditions

Post condition

Tout utilisateur doit possder un compte avec un login, un mot de passe et un privilge.Redirection de lutilisateur vers son environnement adquat selon son privilge.

Scnario principal

1. Lutilisateur sauthentifie puis valide.2. Le systme vrifie les informations fournies.3. Le systme redirige l'utilisateur vers son espace.

Enchainements alternatifs

E1: Champ invalides1. Le systme affiche un message derreur2. L'utilisateur remplit le formulaire dauthentification de nouveau.E2: Champ vides1. Le systme recharge la page dauthentification.2. L'utilisateur remplit le formulaire dauthentification de nouveau.

Diagramme cas utilisation Gestion Utilisateurs

Figure 3:Diagramme cas Utilisation "Grer Utilisateur"Sommaire didentification

Titre:Grer Utilisateur

But:Permettre ladministrateur de Grer les utilisateurs

Rsum:Ladministrateur saisie les informations ncessaires pour sauthentifier, le systme vrifie ses informations (login, mot passe et privilge) et le redirige vers son espace il choisi de grer les utilisateurs il peut effectuer les oprations suivante:-Chercher utilisateur depuis la liste-supprime utilisateur-modifie Utilisateur-ajoute utilisateur

Acteur:Administrateur

Description des enchainements

Pr conditions

Post condition

Tout Administrateur doit possder un compte avec un login, un mot de passe un Lutilisateur choisie linterface grer utilisateurs

Auteur(Administrateur)Systme

1. Ladministrateur slectionne linterface grer utilisateur

3. lopration choisie est ajouter

5. ladministrateur saisie les informations relative de lutilisateur6. ladministrateur demande au systme denregistrer lutilisateur

2. Le systme affiche la liste des utilisateurs.

4. le systme invite ladministrateur remplir le formulaire

7. Le systme vrifie la validit des donnes saisies. 8. Le systme enregistre le nouvel utilisateur. 9. Le systme informe de la russite de l'opration d'enregistrement. 10. Le systme affiche nouveau le menu utilisateur .

Scnario alternatif

A1 : L'opration choisie est Modifier 1. L'administrateur consulte liste des utilisateurs. 2. Le systme affiche la liste. 3. L'administrateur slectionne le nom de l'utilisateur Modifier4. l'administrateur slectionne le bouton Modifier5. le systme affiche l'interface de modification6. l'administrateur effectue les modifications ncessaires.7. Le systme enregistre les modifications ncessaires. A2: L'opration choisie est Supprimer . A2.1 : L'administrateur consulte la liste des utilisateurs. A2.2 : Le systme affiche lensemble des utilisateurs. A2.3 : L'administrateur slectionne le nom de l'utilisateur cherch. A2.4 : l'administrateur slectionne le bouton supprimer A2.6 : L'administrateur confirme la suppression de l'utilisateur. A2.7 : Le systme informe la russite de l'opration.

Diagramme cas utilisation raffine

Figure 4:Diagramme cas utilisation raffineConclusionLa spcification des besoins est une tape primordiale dans le cycle de vie dune application, elle nous assure une bonne vision du systme mettre en place. Ceci nous permet de dgager les diffrents choix conceptuels ensuite llaboration des diffrents diagrammes. Pour ce fait, le chapitre suivant prsentera laspect conceptuel, ainsi que laspect design de notre mini-projet.III- Conception1- IntroductionLa conception est la phase la plus importante dans le cycle de dveloppement dun projet. Cest un processus cratif qui vise minimiser leffort du dveloppement. Nous commenons tout dabord par la conception architecturale et nous passons dans un second lieu une conception plus dtaille. 2- L'architecture globale du systmeLexpression des besoins techniques implique galement le choix darchitecture. Ce choix est crucial puisquil intervient dans lvolutivit du systme, le temps de dveloppement, le cot et les performances. Il existe plusieurs types darchitecture:2-1 Architecture simple tiers La conception de lapplication est labore de manire fonctionner sur un ordinateur unique. En fait, tous les services fournis par l'application rsident sur la mme machine et sont inclus dans l'application. Toutes les fonctionnalits sont donc comprises dans une seule couche logicielle

Figure 5:Architecture Simple tiers

2-2 Architecture client/serveur Architecture 2-tiers appele aussi architecture client lourd/serveur. Elle est assez simple dans sa mise en uvre. Ce type d'architecture est constitu uniquement de deux parties : le client lourd demandeur de service dune part et le serveur de donnes qui fournit le service d'autre part. Nous aurons donc la base de donnes qui sera dlocalise sur un serveur ddi appel le serveur de donnes qui fournira les donnes exploiter.

Figure 6: Architecture 2-tiers2-3 Architecture trois tiersCette architecture physique est assez semblable larchitecture client/serveur, mais en plus des clients et du serveur de donnes voques plus haut, un serveur d'application intervient comme un troisime tiers. En effet, les machines clientes, Egalement appeles clients lgers ne contiennent que l'interface de l'application de manire quelles dcharges de tout traitementEn effet, le traitement est ainsi assur par le serveur d'application, qui sert de liaison entre l'interface applicative et les donnes localises au niveau du serveur de donnes.

Figure 7: Architecture 3-tiersAfin de concevoir notre application, nous avons opt larchitecture simple-tiers Elle reprsente la solution la plus adapte notre systme car notre systme est simple et na pas besoins dune architecture technique complexe ainsi que notre base de donnes nest pas une base de donne distribu.2-4 Spcification darchitectureSur le plan logique ; notre architecture (simple-tiers) est mise en uvre suivant le modle MVC (Modle Vue Contrleur)L'architectureModle/Vue/Contrleur(MVC) est une faon d'organiser une interface graphique d'un programme. Elle consiste distinguer trois entits distinctes qui sont, lemodle, lavueet lecontrleurayant chacun un rle prcis dans l'interface.Dans l'architecture MVC, les rles des trois entits sont les suivants:Rle du Modle: Le modle contient les donnes manipules par le programme. Il assure la gestion de ces donnes et garantit leur intgrit. Dans le cas typique d'une base de donnes, c'est le modle qui la contient.Rle de la vue: La vue fait l'interface avec l'utilisateur. Sa premire tche est d'afficher les donnes qu'elle a rcupres auprs du modle. Sa seconde tche est de recevoir tous les actions de l'utilisateur (clic de souris, slection d'une entres, boutons, ). Ses diffrents vnements sont envoys au contrleur.Rle du contrleur: Le contrleur est charg de la synchronisation du modle et de la vue. Il reoit tous les vnements de l'utilisateur et enclenche les actions effectuer. Si une action ncessite un changement des donnes, le contrleur demande la modification des donnes au modle et ensuite avertit la vue que les donnes ont chang pour que celle-ci se mette jour. Certains vnements de l'utilisateur ne concernent pas les donnes mais la vue. Dans ce cas, le contrleur demande la vue de se modifier.

Figure 8: Modle MVC

2-5 Division en paquetage

Figure 9:Division en paquetages

3- Conception de niveau donnes3-1 Description des classes Le diagramme de classes exprime laspecte statique du systme en termes de classes et de relations entre ces classes. Il nous permet de prsenter la structure interne du systme et dorganiser le travail de dveloppeur. Nous avons utilise dans notre diagramme de classe les concepts suivant : Classe : une classe est une description abstraite (condense) dun ensemble dobjets similaires du point de vue de leur structure (attributs), leur comportement (oprations) et leurs relations lextrieur (association). Lassociation: une association exprime une connexion smantique bidirectionnelle entre classes. Cest une abstraction des liens qui existent entre les objets instances des classes associes. Classe utilisateur: contient tous les informations concernant les utilisateurs de notre application, bien que les mthodes associes.

AttributsNomType Description

Id_utilisateurNumriqueIdentifiant de lutilisateur (cl primaire)

nom_utilisateurTexteLe nom de lutilisateur du compte

mot_PasseTexteLe mot de passe du compte

NomTexteLe nom de lutilisateur

PrnomTexteLe prnom de lutilisateur

Mthodesmodifier ()Modifier les coordonner dun utilisateur

supprimer ()Supprimer un utilisateur de la liste

ajouter ()Ajourer un utilisateur a la liste

Chercher ()Chercher un utilisateur de la liste

Classe Privilge : elle spcifie les privilges des utilisateurs, sagit il dun administrateur ou bien dun technicien. Tous les privilges sont regroups dans cette classe. Le jour o ladministration a besoin dintgrer un nouvel privilge, il est possible de lajouter facilement sans changer la structure de la base de donnes.


id_privilegeNumriqueLidentifiant du privilge (cl primaire)

libelle_privilegeTexteLe libelle du privilge

MthodesAjouter_privilege() Ajouter un nouvel privilge

Modifier_privilege() Modifier un privilge.

Supprimer_privilege() Supprimer un privilge

Classe Etat_Privilge : cette classe contient les tats du privilge. Il peut tre actif ou bien bloqu. On peut ajouter, modifier ou supprimer un tat selon son identifiant (Id_etat_privilege).


id_etat_privilegeNumriqueLidentifiant de ltat du privilge (cl primaire)

libelle_etat_privilegeTexteLibelle de ltat du privilge

MthodesAjouter_privilege() Ajouter un nouvel tat privilge

Modifier_privilege() Modifier tat privilge.

Supprimer_privilege() Supprimer tat privilge

Classe BTS : cette classe contient les informations techniques dune BTS, partir de cette classe un acteur peut ajouter, supprimer, modifier et consulter une BTS


RXOTGStringIdentifiant dune BTS (cl primaire)

SiteStringPosition gographique

jonctionStringPosition de la jonction

BCCHnumriqueCanal de diffusion

CellStringNom de cellule

CGIStringIdentifiant de la cellule

DIPStringIdentifiant de la liaison

DMSDateDate de mise en service

confignumriqueConfiguration du BTS

typeNumrique Type du BTS

MthodesAjouter () Ajouter BTS

Modifier () Modifier BTS

Supprimer () Supprimer BTS

Consulter ()Consulter BTS

Classe BSC : cette classe contient les informations techniques dune BSC, partir de cette classe un acteur peut ajouter, supprimer, modifier et consulter une BSC


Id_BSCStringIdentifiant dune BSC (cl primaire)

typeStringtype du BSC

Version Numrique Version du BSC

MthodesAjouter () Ajouter BSC

Modifier () Modifier BSC

Supprimer () Supprimer BSC

Consulter ()Consulter BSC

Classe Jonction : cette classe contient les informations de diffrentes liaisons du centre radio


Id_JonctionStringIdentifiant dune jonction (cl primaire)

Dipstring Nom de la jonction

devstringLes devices dun DIP

Ext_Astringlextrmit A de la jonction

Ext_Bstringlextrmit B de la jonction

Pos_RADIOstringPosition de la jonction dans la rglette Radio

Pos_TRstringPosition de la jonction dans la rglette Transmission

MthodesAjouter () Ajouter Jonction

Modifier () Modifier Jonction

Supprimer () Supprimer jonction

Consulter ()Consulter jonction

3-2 Diagramme de classe

Figure 10:Diagramme de classe3-3 Les Diagrammes de squencesLes diagrammes de squences sont la reprsentation graphique des interactions entre les acteurs et le systme selon un ordre chronologique dans la formulation UML. On montre ces interactions dans le cadre d'un scnario d'un diagramme des cas d'utilisation.

Figure 11:Diagramme de squence " Authentification"Lorsque un utilisateur souhaite accder sa session, une page d'accueil lui sera affiche, dans laquelle saisit ses propres coordonnes d'authentification (login et mot de passe).par la suite le systme procde a la vrification des informations introduites, si le login et le mot de passe sont valides sa session lui sera alors ouverte, sinon un message d'erreur est affich le sollicitant de rintroduire ses coordonnes. Ce processus de vrification ce rptera autant de fois que l'utilisateur communique des informations errones.

Figure 12:Diagramme de squence "ajouter utilisateur"

Lorsque un Administrateur souhaite ajouter un utilisateur, il choisi linterface ajouter utilisateur, il rempli le formulaire, aprs validation lutilisateur sera ajouter la base de donne avec succs si non un message derreur sera affich.

Figure 13:Diagramme de squence "Modifier Utilisateur "Lorsque un Administrateur souhaite Modifier un utilisateur, il choisi lutilisateur modifier, linterface affiche le formulaire de modification, il rempli le formulaire, aprs validation lutilisateur sera modifier et stocker dans la base de donne avec succs si non un message derreur sera affich.3-4 Les Diagrammes dactivitLes diagrammes dactivits mettent laccent sur les activits, leurs relations et leurs impacts sur les objets. Il indique la part prise par chaque objet dans l'excution de l'application. En dautres termes, le diagramme d'activits est une reprsentation proche de l'organigramme. Il nous permet de voir le comportement interne du systme.

Figure 14:Diagramme d'activit Authentification Le diagramme dactivit ci-dessus rsume le processus dauthentification. LActeur doit introduire son login et son mot de passe, une fois les donnes sont correcte le systme doit vrifier le type de compte (Administrateur, Utilisateur). Une fois il est actif, lActeur est renvoy, vers son espace selon ces privilges.

Figure 15:Diagramme d'activit "Ajouter Utilisateur" Aprs lauthentification, ladministrateur peut ajouter un utilisateur. Le systme affiche le formulaire d'ajout, les champs doivent tre obligatoirement non vides et correcte. Ladministrateur doit confirmer laction pour que le systme le prenne en considration et effectue des mises jour ncessaires. Si lutilisateur existe dj dans la base de donnes un message dalerte doit afficher. Le diagramme dajout ci-dessus rsume le processus complet de cette tche.4- Conception du niveau prsentationLa conception graphique est un point important. Son objectif principal est de faciliter lutilisation de lapplication par les utilisateurs. Pour cela, nous nous imposerons certaines contraintes :4-1 Modle de navigationLa navigation doit tre simple, mme pour les usagers dbutants. Il est donc indispensable que lusage de lapplication ne demande pas des efforts lutilisateur. Lutilisation de menu qui rpertorie les principales fonctionnalits permet lutilisateur de minimiser son effort mental.La barre de menu principale, qui est un menu horizontal statique est compos de:

Connexion| Gestion Utilisateur| Gestion BSC| Gestion BTS| Gestion des jonctions| A propos

La barre de menu changera selon lutilisateur. C'est--dire selon son privilge sil est administrateur ou utilisateur:


Barre de menu Administrateur


Barre de menu utilisateur4-2 Charte graphiqueLa charte graphique dfinit l'habillement graphique de la page, notamment les tailles, couleurs et apparences des textes, images et boutons de lapplication ainsi que le positionnement relatif des objets.Afin de donner lutilisateur des repres au sein de lapplication et de faciliter sa visite, il doit y avoir une cohrence entre les menus. La charte graphique dtermine les diffrentes rgles graphiques:- les dimensions des pages - les couleurs employer (le texte, les liens, les liens actifs, les boutons) - les styles employer (famille, taille) - les types dimages5- conclusion Le long de ce chapitre, nous avons essay de modliser notre application laide du langage de modlisation UML. Avant dentamer limplmentation nous devons dfinir lenvironnement de dveloppement ainsi que les outils de travail, chose qui fera lobjectif du prochain chapitre.

IV- Ralisation1- Introduction Aprs avoir labor la conception de notre application, nous abordons dans ce chapitre le dernier volet de ce rapport, qui a pour objectif d'exposer la phase de ralisation.La phase de ralisation est considre comme tant la concrtisation finale de toute la mthode de conception.Nous menons tout dabord une tude technique o nous dcrivons les ressources logicielles utilises dans le dveloppement de notre projet. Nous prsentons en premier lieu notre choix de lenvironnement de travail, o nous spcifions lenvironnement matriel et logiciel quon a utilis pour raliser notre application puis nous dtaillons larchitecture, aussi nous prsentons quelques interfaces ralises pour illustrer le fonctionnement de quelques activits du systme.2- Environnement de travailPour la ralisation de notre application, nous avons eu recours plusieurs moyens matriels et logiciels :2-1 Environnement matrielNous avons utilis Un ordinateur demarque ASUS, capacit de mmoireest 4GB, capacit de disqueest 500 GB, un microprocesseurIntel Core i7, et de Systme dexploitation Windows 7 professionnel. 2-2 Environnement logiciel Langage de dveloppement Le C++ est un langage de programmation permettant la programmation sous de multiples paradigmes comme la programmation procdurale, la programmation oriente objet et la programmation gnrique. Le langage C++ n'appartient personne et par consquent n'importe qui peut l'utiliser sans besoin d'une autorisation ou obligation de payer pour avoir le droit d'utilisation.C++ est l'un des langages de programmation les plus populaires, avec une grande varit de plateformes matrielles et de systmes d'exploitation. Environnement de dveloppement Qt Creator est un environnement de dveloppement intgr multiplateforme faisant partie du framework Qt. Il est donc orient pour la programmation en C++.Il intgre directement dans l'interface un dbogueur, un outil de cration d'interfaces graphiques, des outils pour la publication de code sur Git et Mercurial ainsi que la documentation Qt. L'diteur de texte intgr permet l'auto-compltion ainsi que la coloration syntaxique. Choix de SGBD:MySQLest unsystme de gestion de base de donnes(SGBD). Selon le type d'application, sa licence estlibreoupropritaire. Il fait partie des logiciels de gestion debase de donnesles plus utiliss au monde, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avecOracleetMicrosoft SQL Server.3- Captures dencrantInterface dauthentificationCette interface permet aux diffrents acteurs de sauthentifier pour accder au menu principale de lapplication, aprs la vrification si leur nom dutilisateur et le mot de passe existent dans la base de donnes. Si le mot de passe ou le non utilisateur est faux le systme doit afficher un message derreur

Interface MenuCette interface est linterface principale de notre application

Interface Gestion utilisateurCette interface nest accessible que lorsque lacteur est Administrateur, il permet dajouter de supprimer de modifier ou chercher un utilisateur dans la liste.

Interface Ajout utilisateurCest linterface pour ajouter un utilisateur

Interface Gestion BSCCette interface permet la gestion des BSC, on peut ajouter, modifier ou supprimer un BSC

Interface Ajout BSC:Cette interface permet dajouter un BSC

Interface Gestion BTSCette interface permet la gestion des BTS ajout, Modification et Suppression

Interface ajouter BTSCette interface permet dajouter un BTS

Interface Gestion JonctionsCette interface permet la gestion des jonctions, ajouter, supprimer ou modifier jonction

Interface ajouter Jonction

Message de Fermeture de lapplication

Lien de vido dmonstration ralisation: http://youtu.be/p4PmN15pHZY4- ConclusionLa phase ralisation nest que le rsultat des phases prcdentes tel que ltude pralable et la conception dtaille pour aboutir ltape de programmation qui permet linterconnexion avec la base de donnes.

Conclusion Gnrale Face lexpansion rapide des rseaux fixe et ADSL et laugmentation de la concurrence, les exigences des utilisateurs sur la qualit des services acquis sont devenues de plus en plus strictes ; et le besoin des oprateurs de se diffrencier par une meilleure offre de qualit de service et daugmenter leurs rentabilits est devenu le souci de nombreux organismes de recherche.Notre mini-projet intitul Gestion des BTS dun centre radio GSM qui consiste la conception et la ralisation dune application qui facilite le travail dun centre Radio GSMEn ce qui concerne la dmarche, nous avons en premier lieu effectu une phase dtude des diffrents outils existants. En deuxime lieu nous avons spcifi notre application pour discerner les fonctionnalits .En troisime lieu, nous avons procd sa conception ainsi quaux choix technologiques pour sa ralisation. Enfin, nous lavons mise en uvre.Il est important noter que la ralisation de ce mini projet nous a t bnfique sur tous les plans. Sur le plan technique, ce projet nous a t une bonne occasion pour dcouvrir le langage C++, Il nous a aussi permis d'apprendre utiliser lenvironnement de dveloppement Qt.

Cette application est gnrique c'est--dire quelle est extensible et peut tre enrichi par dautre module tel quun outil qui permet la collecte des alarmes.

Faouel Soufien&Mohamed Taher MarnaouiPage 38

Documents

Miniprojet POO