Miniprojet POO [PDF]

Zitiervorschau

UVT

[Mini Projet En Programmation Orientée Objet] Conception et réalisation d’une application de gestion des BTS d’un centre radio GSM

Fawel Sofien & Marnaoui Mohamed Taher

Mini-projet Orientée Objet

N2TR 2013/2014

Table des matières Introduction Générale ............................................................................................................................. 5 I-

Présentation Générale ..................................................................................................................... 6 1-

Introduction ............................................................................................................................ 6

2-

Description de l’existant ......................................................................................................... 6

3-

Critique de l’existant ............................................................................................................... 7

4-

Solution proposée .................................................................................................................... 7

5-

Notion de base d’un système radio GSM ................................................................................ 7

6-

Conclusion............................................................................................................................... 8

II-

Spécification des besoins ............................................................................................................. 9

1-

Introduction ............................................................................................................................ 9

2-

Etude des besoins..................................................................................................................... 9

2-1 Besoins Fonctionnels ............................................................................................................... 9 3-

Les diagrammes de cas d’utilisation...................................................................................... 10

3-1 Présentation des acteurs .......................................................................................................... 10 3-2 les diagrammes cas utilisation ................................................................................................. 11 III-

Conception ................................................................................................................................ 15

1-

Introduction .......................................................................................................................... 15

2-

L'architecture globale du système ......................................................................................... 15

2-1 Architecture simple tiers........................................................................................................ 15 2-2 Architecture client/serveur .................................................................................................... 16 2-3 Architecture trois tiers ............................................................................................................ 16 2-4 Spécification d’architecture ................................................................................................... 17 2-5 Division en paquetage ............................................................................................................. 18 3-

Conception de niveau données ............................................................................................. 19

3-1 Description des classes ............................................................................................................ 19 3-2

Diagramme de classe ....................................................................................................... 23

3-3 Les Diagrammes de séquences ............................................................................................ 23 3-4 4-

Les Diagrammes d’activité ............................................................................................. 26 Conception du niveau présentation ...................................................................................... 29

4-1 Modèle de navigation .............................................................................................................. 29

Faouel Soufien&Mohamed Taher Marnaoui

Page 2

Mini-projet Orientée Objet

N2TR 2013/2014

4-2 Charte graphique .................................................................................................................... 29 5- conclusion .................................................................................................................................. 30 IV-

Réalisation ................................................................................................................................. 31

1-

Introduction .......................................................................................................................... 31

2-

Environnement de travail ..................................................................................................... 31

2-1 Environnement matériel ......................................................................................................... 31 2-2 Environnement logiciel ........................................................................................................ 31 3-

Captures d’encrant ................................................................................................................ 32

4-

Conclusion............................................................................................................................. 38

Conclusion Générale ............................................................................................................................. 39

Faouel Soufien&Mohamed Taher Marnaoui

Page 3

Mini-projet Orientée Objet

N2TR 2013/2014

Figure 1: Architecture réseau GSM ................................................................................................ 8 Figure 2:Diagramme cas d'utilisation "Authentification".............................................................. 11 Figure 3:Diagramme cas Utilisation "Gérer Utilisateur"............................................................... 12 Figure 4:Diagramme cas utilisation raffine .................................................................................. 14 Figure 5:Architecture Simple tiers ............................................................................................... 15 Figure 6: Architecture 2-tiers ...................................................................................................... 16 Figure 7: Architecture 3-tiers ...................................................................................................... 17 Figure 8: Modèle MVC ................................................................................................................ 18 Figure 9:Division en paquetages ................................................................................................. 18 Figure 10:Diagramme de classe ................................................................................................... 23 Figure 11:Diagramme de séquence " Authentification"................................................................ 24 Figure 12:Diagramme de séquence "ajouter utilisateur" .............................................................. 25 Figure 13:Diagramme de séquence "Modifier Utilisateur " .......................................................... 26 Figure 14:Diagramme d'activité «Authentification » .................................................................... 27 Figure 15:Diagramme d'activité "Ajouter Utilisateur" .................................................................. 28

Faouel Soufien&Mohamed Taher Marnaoui

Page 4

Mini-projet Orientée Objet

N2TR 2013/2014

Introduction Générale L’évolution technologique dans le monde des télécommunications se fait à grands pas. Ainsi l’apparition des nouvelles technologies se fait à une grande cadence, surtout pour les systèmes de télécommunication mobile. De nos jour la norme GSM, représente le système de télécommunication mobile le plus étendue et le plus utilisé à travers le monde. Dans un monde où de plus en plus de documents sont produits ou diffusés en mode numérique, la numérisation des documents dans les classeurs administratifs est en croissance dans les organisations depuis plus de 25 ans. Nous vivons une époque où l’automatisation des systèmes d’information devient une politique qui est de plus en plus adopté dans de nombreux établissements. En effet, cette politique assure une accélération et plus de précision lors du traitement de l’information. Elle permet également une circulation plus rapide et plus sûre de l’information. C’est dans ce contexte que s’inscrit ce mini projet. En faite ce travail a pour but de concevoir et réaliser une application simple et efficace qui facilite la manipulation des différentes informations sur les composantes du réseau GSM. Pour arriver au résultat exempté nous allons deviser ce travail en quatre parties. La première partie s’intéressera a une étude théorique de quelque notion de base d’un système radio GSM (BTS, TRX, BCCH…), une deuxième partie s’intéressera des spécifications des besoins. La troisième partie sera consacré a la conception de l’application et enfin une partie de réalisation de l’application.

Faouel Soufien&Mohamed Taher Marnaoui

Page 5

Mini-projet Orientée Objet

I-

N2TR 2013/2014

Présentation Générale 1- Introduction Dans le but de représenter la structure et le fonctionnement du système et de

déterminer clairement les principaux pas à suivre afin de proposer un meilleur aspect pour la réalisation de ce travail, une étude de l’existant s’avère alors nécessaire. Cette étude est d’une grande utilité dans la fixation des nouveaux apports à intégrer pour améliorer les qualités de service. Dans ce chapitre, on fera une étude de l’existant en indiquant ses limites, puis la solution proposé et ces objectifs et enfin une petite étude théorique de quelque notion de base d’un réseau GSM.

2- Description de l’existant L’unité Radio GSM présente l’une des principales unités technique de Tunisie télécom puisqu’elle gère un très grand nombre d’équipements radio tel que les BSC et les BTS. Et vu le nombre croissant des équipements ainsi que leur diversités (marque, types…), la gestion de leur documentation devient de plus en plus difficile. En effet, lorsqu’un agent veut consulter la documentation d’un équipement, il doit chercher manuellement l’information dans un grand nombre de classeur et des fichiers Excel. Ces documentations peuvent être :  Documentation technique du matériel installé (BSC/BTS) archivés dans les classeurs qui contiennent les informations suivantes : site (nom de l’emplacement du BTS), DIP (Digital Path), SNT (Switch network Terminal), device, position, salle, version, destination.  Documentation de la mise en service : stockée dans des fichiers Excel contenant les informations suivantes : Site, RXOTG (nom du BTS au niveau BSC), BCCH (canal qui peut servir à la diffusion d’information générale), CGI (identificateur de la cellule), date de mise en service, configuration et position transmission.

Faouel Soufien&Mohamed Taher Marnaoui

Page 6

Mini-projet Orientée Objet

N2TR 2013/2014

3- Critique de l’existant D’après l’étude de l’existant certaine limites peuvent être dégagées :  Dispersion des ressources : elle se présente sous la forme d’un problème de récupération des données donc la recherche d’une information est très longue  Manque de flexibilité étant donné que la recherche se fait manuellement  Perte des données avec le temps.

4- Solution proposée Pour assurer la rapidité et le gain de temps et la flexibilité des données, nous nous proposons de réaliser un outil de gestion de la documentation de l’unité radio GSM. Nous nous intéressons à introduire une application qui vis à atteindre les objectifs suivants :  Organiser les différentes informations sous forme d’une base de données numérique au lieu d’un support papier.  Faciliter la recherche des données sur la structure de liaison BTS/BSC.  Guider l’agent dans les déplacements : donner les informations sur les positions géographiques, et les informations sur les supports physiques d’architecture BTS/BSC.  Réduire le temps de recherche d’information.  La gestion des données de BSC qui nous permet de contrôler chaque BSC et connaitre les informations qui lui sont relatives ainsi que le nombre de BTS qu’ils contrôlent et la gestion des données des BTS

5- Notion de base d’un système radio GSM L’objectif d’un système radio téléphonique est de permettre l’accès au réseau téléphonique mobile à partir d’un terminal portatif sur un territoire étendu. Le réseau GSM est composé de trois sous ensembles :

Faouel Soufien&Mohamed Taher Marnaoui

Page 7

Mini-projet Orientée Objet

N2TR 2013/2014

-

Sous système radio « BSS » : Base Station Subsystem

-

Sous système réseau « NSS » : Network Switching Subsystem

- Sous système d’exploitation et de maintenance Subsystem.

« OSS » : Operation

Figure 1: Architecture réseau GSM

Pour notre travail nous nous intéresserons qu’au parti BSS qui contient principalement les BTS et les BSC : BTS : La BTS ou « Base Tranceiver Station »est une antenne placé dans une zone géographique bien déterminé dite « cellule », où chaque cellule dispose d’un BTS et un seul. Elle consiste en un ou un ensemble d’émetteurs récepteurs appelés TRX (Transmission/ Reception Unit) et leur antenne. BSC : Le BSC ou Base Station Controller assure le contrôle d’un ou plusieurs BTS et se communique avec elle par le biais de l’interface A-bis. Le BSC est l’organe « intelligent » du BSS, chargé à la gestion des ressources radio.

6- Conclusion Ce chapitre a été consacré à l’étude de l’existant en précisant ces limites. Nous avons aussi présenté notre solution en indiquant ces objectifs. Dans ce qui suit nous entament la phase des spécifications des besoins.

Faouel Soufien&Mohamed Taher Marnaoui

Page 8

Mini-projet Orientée Objet

II-

N2TR 2013/2014

Spécification des besoins

1- Introduction L’une des principales étapes de cycle de vie d’une application est l’extraction des différents besoins attendus du système. L’étape de spécification des besoins est conçue pour la détermination des différentes fonctionnalités. D’abord, on présentera une étude des besoins fonctionnels qui conduisent à l’élaboration des diagrammes des cas d’utilisation permettant de détailler les scénarios possibles que peuvent réaliser les différents acteurs, ensuite on citera les besoins non fonctionnels qui sont en fait les exigences de l’application.

2- Etude des besoins 2-1 Besoins Fonctionnels Une étude détaillée du système permet de dégager les différents besoins fonctionnels suivants : Gestion des BSC Ajouter BSC : lors de l’installation physique d’un nouveau BSC, l’agent peut ajouter les différentes informations du BSC dans la base. Modifier BSC : modifier les informations relatives à un BSC. Supprimer BSC : L’utilisateur peut supprimer un BSC Chercher : permet de chercher une information concernant les BSC. Gestion des BTS Ajouter BTS : lors de l’installation physique d’un nouveau BTS, l’agent peut ajouter les différentes informations du BTS dans la base. Modifier BTS : permet de faire la mise à jour des informations relatives à un BTS Supprimer BTS : permet de supprimer un BTS Chercher : permet de chercher une information concernant les BTS.

Faouel Soufien&Mohamed Taher Marnaoui

Page 9

Mini-projet Orientée Objet

N2TR 2013/2014

Gestion d’utilisateurs Permet au administrateur d’ajouter, modifier et de supprimer des utilisateurs. Permet aussi à l’administrateur la gestion des droits d’accès Gestion des Jonctions Ajouter Jonction : permet d’ajouter une jonction Modifier Jonction : permet de faire la mise à jour des informations relatives à une jonction Supprimer Jonction: permet de supprimer une jonction Chercher : permet de chercher une information concernant les jonctions. 2-2 Besoins non fonctionnels Plusieurs besoins opérationnels sont à tenir en compte dans notre application :  Fiabilité : les informations fournies par l’application doivent être fiables.  Solution ouverte et évolutive : l’application peut être améliorée par l’ajout d’autres modules tel que (l’analyse des mesure traçage d’une carte, etc…).  Sécurité : l’accès aux informations n’est possible qu’après vérification des privilèges des droits d’accès.  Journalisation: Garder l'historique des actions réalisées par les utilisateurs.  Convivialité et ergonomie : l’application doit fournir une interface conviviale et simple pour tout type d’utilisateur

3- Les diagrammes de cas d’utilisation 3-1 Présentation des acteurs Les diagrammes des cas d'utilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d'un système logiciel. Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. C’est une unité significative de travail. Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs, ils interagissent avec les cas d'utilisation. Faouel Soufien&Mohamed Taher Marnaoui

Page 10

Mini-projet Orientée Objet

N2TR 2013/2014

Dans notre application il existe deux acteurs : Administrateur : Création des comptes utilisateurs, attribuer les droits d’accès. En plus les opérations des gestions de la base de données Utilisateur : La gestion de la base de données 3-2 les diagrammes cas utilisation Diagramme cas utilisation Authentification Dans un souci de la sécurisation de l’information,

avant d’effectuer une tâche

quelconque, tous les utilisateurs du système doivent s’identifier en saisissant leurs identificateurs (Login, Password) respectifs.

Connection

NewClass

S'authentifier

Figure 2:Diagramme cas d'utilisation "Authentification"

Sommaire d’identification Titre : But :

Authentification Permettre à tout utilisateur de s’authentifier et de se connecter au système.

Résumé :

l’utilisateur saisie les informations nécessaires pour s’authentifier, le système vérifie ses informations (login, mot passe et privilège) et le redirige vers son espace selon son droit d’accès. Tous les utilisateurs

Acteur : Description des enchainements Pré conditions

Post condition

Tout utilisateur doit posséder un compte avec un login, un mot de passe et un privilège.

Redirection de l’utilisateur vers son environnement adéquat selon son privilège.

Scénario principal 1. L’utilisateur s’authentifie puis valide. 2. Le système vérifie les informations fournies. 3. Le système redirige l'utilisateur vers son espace. Enchainements alternatifs E1: Champ invalides 1. Le système affiche un message d’erreur 2. L'utilisateur remplit le formulaire d’authentification de nouveau. E2: Champ vides 1. Le système recharge la page d’authentification. Faouel Soufien&Mohamed Taher Marnaoui

Page 11

Mini-projet Orientée Objet

N2TR 2013/2014

2. L'utilisateur remplit le formulaire d’authentification de nouveau.

Diagramme cas utilisation Gestion Utilisateurs

Ajouter

Administrateur

supprimer

Gestion utilisateur

Modifier

Chercher S'authentifier

Figure 3:Diagramme cas Utilisation "Gérer Utilisateur"

Sommaire d’identification Titre : But :

Gérer Utilisateur Permettre à l’administrateur de Gérer les utilisateurs

Résumé :

L’administrateur saisie les informations nécessaires pour s’authentifier, le système vérifie ses informations (login, mot passe et privilège) et le redirige vers son espace il choisi de gérer les utilisateurs il peut effectuer les opérations suivante : -Chercher utilisateur depuis la liste -supprime utilisateur -modifie Utilisateur -ajoute utilisateur Administrateur

Acteur : Description des enchainements Pré conditions

Post condition

Tout Administrateur doit posséder un compte avec un login, un mot de passe un

L’utilisateur choisie l’interface gérer utilisateurs

Auteur(Administrateur) 1. L’administrateur sélectionne l’interface gérer utilisateur

Système

2. Le système affiche la liste des utilisateurs.

3. l’opération choisie est « ajouter » 5. l’administrateur saisie les informations relative de l’utilisateur

Faouel Soufien&Mohamed Taher Marnaoui

4. le système invite l’administrateur à remplir le formulaire

Page 12

Mini-projet Orientée Objet 6. l’administrateur demande au système d’enregistrer l’utilisateur

N2TR 2013/2014

7. Le système vérifie la validité des données saisies. 8. Le système enregistre le nouvel utilisateur. 9. Le système informe de la réussite de l'opération d'enregistrement. 10. Le système affiche à nouveau le menu «utilisateur ».

Scénario alternatif A1 : L'opération choisie est « Modifier» 1. L'administrateur consulte liste des utilisateurs. 2. Le système affiche la liste. 3. L'administrateur sélectionne le nom de l'utilisateur à Modifier 4. l'administrateur sélectionne le bouton Modifier 5. le système affiche l'interface de modification 6. l'administrateur effectue les modifications nécessaires. 7. Le système enregistre les modifications nécessaires. A2: L'opération choisie est « Supprimer ». A2.1 : L'administrateur consulte la liste des utilisateurs. A2.2 : Le système affiche l’ensemble des utilisateurs. A2.3 : L'administrateur sélectionne le nom de l'utilisateur cherché. A2.4 : l'administrateur sélectionne le bouton supprimer A2.6 : L'administrateur confirme la suppression de l'utilisateur. A2.7 : Le système informe la réussite de l'opération.

Faouel Soufien&Mohamed Taher Marnaoui

Page 13

Mini-projet Orientée Objet

N2TR 2013/2014

Diagramme cas utilisation raffine

Ajouter

Supprimer

Modifier

gestion utilisateurs Adminstrateur Chercher

Ajouter BSC Spprimer BSC





Modifier BSC

Gestion BSC

Cherche BSC Athentifier

Gestion BTS Ajouter BTS





Modifier BTS

supprimer BTS Utilisateur

Chercher BTS

Ajouter Jonction



supprimer Jonction

Gestion Jonctions

Modifier Jonction

Chercher Jonction

Figure 4:Diagramme cas utilisation raffine

Conclusion La spécification des besoins est une étape primordiale dans le cycle de vie d’une application, elle nous assure une bonne vision du système à mettre en place. Ceci nous permet de dégager les différents choix conceptuels ensuite l’élaboration des différents diagrammes. Pour ce fait, le chapitre suivant présentera l’aspect conceptuel, ainsi que l’aspect design de notre mini-projet.

Faouel Soufien&Mohamed Taher Marnaoui

Page 14

Mini-projet Orientée Objet

N2TR 2013/2014

III- Conception 1- Introduction La conception est la phase la plus importante dans le cycle de développement d’un projet. C’est un processus créatif qui vise à minimiser l’effort du développement. Nous commençons tout d’abord par la conception architecturale et nous passons dans un second lieu à une conception plus détaillée.

2- L'architecture globale du système L’expression des besoins techniques implique également le choix d’architecture. Ce choix est crucial puisqu’il intervient dans l’évolutivité du système, le temps de développement, le coût et les performances. Il existe plusieurs types d’architecture : 2-1 Architecture simple tiers La conception de l’application est élaborée de manière à fonctionner sur un ordinateur unique. En fait, tous les services fournis par l'application résident sur la même machine et sont inclus dans l'application. Toutes les fonctionnalités sont donc comprises dans une seule couche logicielle

Figure 5:Architecture Simple tiers

Faouel Soufien&Mohamed Taher Marnaoui

Page 15

Mini-projet Orientée Objet

N2TR 2013/2014

2-2 Architecture client/serveur Architecture 2-tiers appelée 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 d’une part et le «serveur de données» qui fournit le service d'autre part. Nous aurons donc la base de données qui sera délocalisée sur un serveur dédié appelé le serveur de données qui fournira les données à exploiter.

Figure 6: Architecture 2-tiers

2-3 Architecture trois tiers Cette architecture physique est assez semblable à l’architecture client/serveur, mais en plus des « clients» et du serveur de données évoquées plus haut, un serveur d'application intervient comme un troisième tiers. En effet, les machines clientes, Egalement appelées «clients légers» ne contiennent que l'interface de l'application de manière qu’elles déchargées de tout traitement En effet, le traitement est ainsi assuré par le serveur d'application, qui sert de liaison entre l'interface applicative et les données localisées au niveau du serveur de données.

Faouel Soufien&Mohamed Taher Marnaoui

Page 16

Mini-projet Orientée Objet

N2TR 2013/2014

Figure 7: Architecture 3-tiers

Afin de concevoir notre application, nous avons opté l’architecture simple-tiers Elle représente la solution la plus adaptée à notre système car notre système est simple et n’a pas besoins d’une architecture technique complexe ainsi que notre base de données n’est pas une base de donnée distribué. 2-4 Spécification d’architecture Sur le plan logique ; notre architecture (simple-tiers) est mise en œuvre suivant le modèle MVC (Modèle Vue Contrôleur) L'architecture Modèle/Vue/Contrôleur (MVC) est une façon d'organiser une interface graphique d'un programme. Elle consiste à distinguer trois entités distinctes qui sont, le modèle, la vue et le contrôleur ayant chacun un rôle précis dans l'interface. Dans l'architecture MVC, les rôles des trois entités sont les suivants : Rôle du Modèle : Le modèle contient les données manipulées par le programme. Il assure la gestion de ces données et garantit leur intégrité. Dans le cas typique d'une base de données, c'est le modèle qui la contient. Rôle de la vue : La vue fait l'interface avec l'utilisateur. Sa première tâche est d'afficher les données qu'elle a récupérées auprès du modèle. Sa seconde tâche est de recevoir tous les actions de l'utilisateur (clic de souris, sélection d'une entrées, boutons, …). Ses différents événements sont envoyés au contrôleur.

Faouel Soufien&Mohamed Taher Marnaoui

Page 17

Mini-projet Orientée Objet

N2TR 2013/2014

Rôle du contrôleur : Le contrôleur est chargé de la synchronisation du modèle et de la vue. Il reçoit tous les événements de l'utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle et ensuite avertit la vue que les données ont changé pour que celle-ci se mette à jour. Certains événements de l'utilisateur ne concernent pas les données mais la vue. Dans ce cas, le contrôleur demande à la vue de se modifier.

Figure 8: Modèle MVC

2-5 Division en paquetage

contrôleur

interface

Figure 9:Division en paquetages

Faouel Soufien&Mohamed Taher Marnaoui

Page 18

Modèle

Mini-projet Orientée Objet

N2TR 2013/2014

3- Conception de niveau données 3-1 Description des classes Le diagramme de classes exprime l’aspecte statique du système en termes de classes et de relations entre ces classes. Il nous permet de présenter la structure interne du système et d’organiser le travail de développeur. Nous avons utilise dans notre diagramme de classe les concepts suivant :  Classe : une classe est une description abstraite (condensée) d’un ensemble d’objets similaires du point de vue de leur structure (attributs), leur comportement (opérations) et leurs relations à l’extérieur (association).  L’association:

une

association

exprime

une

connexion

sémantique

bidirectionnelle entre classes. C’est une abstraction des liens qui existent entre les objets instances des classes associées. Classe utilisateur : contient tous les informations concernant les utilisateurs de notre application, bien que les méthodes associées. Attributs

Méthodes

Nom

Type

Description

Id_utilisateur

Numérique

Identifiant de l’utilisateur (clé primaire)

nom_utilisateur Texte

Le nom de l’utilisateur du compte

mot_Passe

Texte

Le mot de passe du compte

Nom

Texte

Le nom de l’utilisateur

Prénom

Texte

Le prénom de l’utilisateur

modifier ()

Modifier les coordonner d’un utilisateur

supprimer ()

Supprimer un utilisateur de la liste

ajouter ()

Ajourer un utilisateur a la liste

Chercher ()

Chercher un utilisateur de la liste

Faouel Soufien&Mohamed Taher Marnaoui

Page 19

Mini-projet Orientée Objet

N2TR 2013/2014

Classe Privilège : elle spécifie les privilèges des utilisateurs, s’agit il d’un administrateur ou bien d’un technicien. Tous les privilèges sont regroupés dans cette classe. Le jour où l’administration a besoin d’intégrer un nouvel privilège, il est possible de l’ajouter facilement sans changer la structure de la base de données.

Attributs

Nom

Type

Description

id_privilege

Numérique L’identifiant du privilège (clé primaire)

Méthodes

libelle_privilege

Texte

Le libelle du privilège

Ajouter_privilege()

Ajouter un nouvel privilège

Modifier_privilege()

Modifier un privilège.

Supprimer_privilege() Supprimer un privilège Classe Etat_Privilège : cette classe contient les états du privilège. Il peut être actif ou bien bloqué. On peut ajouter, modifier ou supprimer un état selon son identifiant (Id_etat_privilege).

Attributs

Nom

Type

Description

id_etat_privilege

Numérique

L’identifiant de l’état du privilège (clé primaire)

Méthodes

libelle_etat_privilege

Texte

Libelle de l’état du privilège

Ajouter_privilege()

Ajouter un nouvel état privilège

Modifier_privilege()

Modifier état privilège.

Supprimer_privilege() Supprimer état privilège

Faouel Soufien&Mohamed Taher Marnaoui

Page 20

Mini-projet Orientée Objet

N2TR 2013/2014

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

Attributs

Nom

Type

Description

RXOTG

String

Identifiant d’une BTS (clé primaire)

Méthodes

Site

String

Position géographique

jonction

String

Position de la jonction

BCCH

numérique

Canal de diffusion

Cell

String

Nom de cellule

CGI

String

Identifiant de la cellule

DIP

String

Identifiant de la liaison

DMS

Date

Date de mise en service

config

numérique

Configuration du BTS

type

Numérique

Type du BTS

Ajouter ()

Ajouter BTS

Modifier ()

Modifier BTS

Supprimer ()

Supprimer BTS

Consulter ()

Consulter BTS

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

Attributs

Nom

Type

Description

Id_BSC

String

Identifiant d’une BSC (clé primaire)

Méthodes

type

String

type du BSC

Version

Numérique

Version du BSC

Ajouter ()

Ajouter BSC

Modifier ()

Modifier BSC

Supprimer ()

Supprimer BSC

Consulter ()

Consulter BSC

Classe Jonction : cette classe contient les informations de différentes liaisons du centre radio

Faouel Soufien&Mohamed Taher Marnaoui

Page 21

Mini-projet Orientée Objet

Attributs

N2TR 2013/2014

Nom

Type

Description

Id_Jonction

String

Identifiant d’une jonction (clé primaire)

Dip

string

Nom de la jonction

dev

string

Les devices d’un DIP

Ext_A

string

l’extrémité A de la jonction

Ext_B

string

l’extrémité B de la jonction

Pos_RADIO

string

Position de la jonction dans la réglette Radio

Pos_TR

string

Position de la jonction dans la réglette Transmission

Méthodes

Ajouter ()

Ajouter Jonction

Modifier ()

Modifier Jonction

Supprimer ()

Supprimer jonction

Consulter ()

Consulter jonction

Faouel Soufien&Mohamed Taher Marnaoui

Page 22

Mini-projet Orientée Objet

N2TR 2013/2014

3-2 Diagramme de classe

Figure 10:Diagramme de classe

3-3 Les Diagrammes de séquences Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation UML. On montre ces interactions dans le cadre d'un scénario d'un diagramme des cas d'utilisation.

Faouel Soufien&Mohamed Taher Marnaoui

Page 23

Mini-projet Orientée Objet

N2TR 2013/2014

Contrôleur

Interface

: Administrateur

Modéle

1.demande d'authentification ETQ1: Formulaire de connexion

2.Formulaire vide 3.Remplire Formulairle:log,pw 4.envoi des données() 5.Verifier les champs 6.Afficher message d'erreur

envoi de la requete select log,pw

* si les données sont invalide & retour ETQ1 8.Resultat 9.Acceder menu general 10.Afficher menu general

Figure 11:Diagramme de séquence " Authentification"

Lorsque un utilisateur souhaite accéder à sa session, une page d'accueil lui sera affichée, dans laquelle saisit ses propres coordonnées d'authentification (login et mot de passe).par la suite le système procède a la vérification 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 réintroduire ses coordonnées. Ce processus de vérification ce répétera autant de fois que l'utilisateur communique des informations erronées.

Faouel Soufien&Mohamed Taher Marnaoui

Page 24

Mini-projet Orientée Objet

N2TR 2013/2014

Contrôleur: Gestion utilisateur

Interface : Gestion utilisateur

: Administrateur

Modéle : Gestion utilisateur

1.demande Formulaire d'ajout d'utilisateur ETQ1: Liste des Utilisateur

2.Formulaire vide 3.Remplire Formulaire 4.envoi des données() 5.Verifier les champs 6.Afficher message d'erreur

7.envoi de la requete insert()

* si les données sont invalide & retour ETQ1 8.Repondre() 9.Afficher nouvelle liste 10.message de succés

Figure 12:Diagramme de séquence "ajouter utilisateur"

Lorsque un Administrateur souhaite ajouter un utilisateur, il choisi l’interface ajouter utilisateur, il rempli le formulaire, après validation l’utilisateur sera ajouter à la base de donnée avec succès si non un message d’erreur sera affiché.

Faouel Soufien&Mohamed Taher Marnaoui

Page 25

Mini-projet Orientée Objet

N2TR 2013/2014

Interface : Gestion utilisateur

: Administrateur

Contrôleur: Gestion Utilisateur

Modéle :Gestion d'Utilisateur

1.Choisir utilisateur à Modifier ETQ1: Liste des Utilisateur

2. envoyer la demande 3.Acceder à la page de modification 4.Afficher formulaire de modification

5.Remplir formulaire et valider

6.envoi des données() 7.Verifier les champs 8.signal une errreur

9.envoi de la requete Update()

* si les données sont invalide & retour ETQ1 10.Repondre() 11.Afficher la nouvelle liste 12.message de succé

Figure 13:Diagramme de séquence "Modifier Utilisateur "

Lorsque un Administrateur souhaite Modifier un utilisateur, il choisi l’utilisateur à modifier, l’interface affiche le formulaire de modification, il rempli le formulaire, après validation l’utilisateur sera modifier et stocker dans la base de donnée avec succès si non un message d’erreur sera affiché. 3-4 Les Diagrammes d’activité Les diagrammes d’activités mettent l’accent sur les activités, leurs relations et leurs impacts sur les objets. Il indique la part prise par chaque objet dans l'exécution de l'application. En d’autres termes, le diagramme d'activités est une représentation proche de l'organigramme. Il nous permet de voir le comportement interne du système.

Faouel Soufien&Mohamed Taher Marnaoui

Page 26

Mini-projet Orientée Objet

N2TR 2013/2014

Demande de Connexion

Afficher formulaire de connexion

retour pour essayer une autre fois

Inserer (Login et mot de passe)

Verification de Données

si login & mot de passe valide si login & mot de passe invalides Message d'erreur

Message d'erreur

Afficher menu general selon privilége

Quiter

Figure 14:Diagramme d'activité «Authentification »

Le diagramme d’activité ci-dessus résume le processus d’authentification. L’Acteur doit introduire son login et son mot de passe, une fois les données sont correcte le système doit vérifier le type de compte (Administrateur, Utilisateur). Une fois il est actif, l’Acteur est renvoyé, vers son espace selon ces privilèges.

Faouel Soufien&Mohamed Taher Marnaoui

Page 27

Mini-projet Orientée Objet

N2TR 2013/2014

Choisir l'operation "ajouter Utilisateur"

Formulaire d'ajout

Remplir formulaire

retour pour essayer une autre fois

Verification des champs Retour pour essayer une autre fois

champs non vide

verifier si les données existe déja dans la base

message d'erreur:Champs invalide

si utilisateur existant Utilisateur ajouer avec succés

l'utilisateur existe déja dans la base

Fin

Fin

Figure 15:Diagramme d'activité "Ajouter Utilisateur"

Après l’authentification, l’administrateur peut ajouter un utilisateur. Le système affiche le formulaire d'ajout, les champs doivent être obligatoirement non vides et correcte. L’administrateur doit confirmer l’action pour que le système le prenne en considération et effectue des mises à jour nécessaires. Si l’utilisateur existe déjà dans la base de données un message d’alerte doit afficher. Le diagramme d’ajout ci-dessus résume le processus complet de cette tâche.

Faouel Soufien&Mohamed Taher Marnaoui

Page 28

Mini-projet Orientée Objet

N2TR 2013/2014

4- Conception du niveau présentation La conception graphique est un point important. Son objectif principal est de faciliter l’utilisation de l’application par les utilisateurs. Pour cela, nous nous imposerons certaines contraintes : 4-1 Modèle de navigation La navigation doit être simple, même pour les usagers débutants. Il est donc indispensable que l’usage de l’application ne demande pas des efforts à l’utilisateur. L’utilisation de menu qui répertorie les principales fonctionnalités permet à l‘utilisateur 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 l’utilisateur. C'est-à-dire selon son privilège s’il est administrateur ou utilisateur : Connexion | Gestion Utilisateur | Gestion BSC | Gestion BTS | Gestion des jonctions | A propos

Barre de menu Administrateur

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

Barre de menu utilisateur 4-2 Charte graphique La charte graphique définit l'habillement graphique de la page, notamment les tailles, couleurs et apparences des textes, images et boutons de l’application ainsi que le positionnement relatif des objets.

Faouel Soufien&Mohamed Taher Marnaoui

Page 29

Mini-projet Orientée Objet

N2TR 2013/2014

Afin de donner à l’utilisateur des repères au sein de l’application et de faciliter sa visite, il doit y avoir une cohérence entre les menus. La charte graphique détermine les différentes règles graphiques : - les dimensions des pages - les couleurs à employer (le texte, les liens, les liens actifs, les boutons…) - les styles à employer (famille, taille…) - les types d’images…

5- conclusion Le long de ce chapitre, nous avons essayé de modéliser notre application à l’aide du langage de modélisation UML. Avant d’entamer l’implémentation nous devons définir l’environnement de développement ainsi que les outils de travail, chose qui fera l’objectif du prochain chapitre.

Faouel Soufien&Mohamed Taher Marnaoui

Page 30

Mini-projet Orientée Objet

IV-

N2TR 2013/2014

Réalisation

1- Introduction Après 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 réalisation. La phase de réalisation est considérée comme étant la concrétisation finale de toute la méthode de conception. Nous menons tout d’abord une étude technique où nous décrivons les ressources logicielles utilisées dans le développement de notre projet. Nous présentons en premier lieu notre choix de l’environnement de travail, où nous spécifions l’environnement matériel et logiciel qu‘on a utilisé pour réaliser notre application puis nous détaillons l’architecture, aussi nous présentons quelques interfaces réalisées pour illustrer le fonctionnement de quelques activités du système.

2- Environnement de travail Pour la réalisation de notre application, nous avons eu recours à plusieurs moyens matériels et logiciels : 2-1 Environnement matériel Nous avons utilisé Un ordinateur de marque ASUS, capacité de mémoire est 4GB, capacité de disque est 500 GB, un microprocesseur Intel Core i7, et de Système d’exploitation Windows 7 professionnel. 2-2 Environnement logiciel  Langage de développement Le C++ est un langage de programmation permettant la programmation sous de multiples paradigmes comme la programmation procédurale, la programmation orientée objet et la programmation générique. Le langage C++

Faouel Soufien&Mohamed Taher Marnaoui

Page 31

Mini-projet Orientée Objet

N2TR 2013/2014

n'appartient à personne et par conséquent 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 variété de plateformes matérielles et de systèmes d'exploitation.  Environnement de développement Qt Creator est un environnement de développement intégré multiplateforme faisant partie du framework Qt. Il est donc orienté pour la programmation en C++. Il intègre directement dans l'interface un débogueur, un outil de création d'interfaces graphiques, des outils pour la publication de code sur Git et Mercurial ainsi que la documentation Qt. L'éditeur de texte intégré permet l'auto-complétion ainsi que la coloration syntaxique.  Choix de SGBD : MySQL est un système de gestion de base de données (SGBD). Selon le type d'application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, autant par le grand public (applications web

principalement)

que

par

des

professionnels,

en

concurrence

avec Oracle et Microsoft SQL Server.

3-

Captures d’encrant

Interface d’authentification Cette interface permet aux différents acteurs de s’authentifier pour accéder au menu principale de l’application, après la vérification si leur nom d’utilisateur et le mot de passe existent dans la base de données. Si le mot de passe ou le non utilisateur est faux le système doit afficher un message d’erreur

Faouel Soufien&Mohamed Taher Marnaoui

Page 32

Mini-projet Orientée Objet

N2TR 2013/2014

Interface Menu Cette interface est l’interface principale de notre application

Faouel Soufien&Mohamed Taher Marnaoui

Page 33

Mini-projet Orientée Objet

N2TR 2013/2014

Interface Gestion utilisateur

Cette interface n’est accessible que lorsque l’acteur est Administrateur, il permet d’ajouter de supprimer de modifier ou chercher un utilisateur dans la liste.

Interface Ajout utilisateur

C’est l’interface pour ajouter un utilisateur

Faouel Soufien&Mohamed Taher Marnaoui

Page 34

Mini-projet Orientée Objet

N2TR 2013/2014

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

Interface Ajout BSC : Cette interface permet d’ajouter un BSC

Faouel Soufien&Mohamed Taher Marnaoui

Page 35

Mini-projet Orientée Objet

N2TR 2013/2014

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

Interface ajouter BTS

Cette interface permet d’ajouter un BTS

Faouel Soufien&Mohamed Taher Marnaoui

Page 36

Mini-projet Orientée Objet

N2TR 2013/2014

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

Interface ajouter Jonction

Faouel Soufien&Mohamed Taher Marnaoui

Page 37

Mini-projet Orientée Objet

N2TR 2013/2014

Message de Fermeture de l’application

Lien de vidéo démonstration réalisation :

http://youtu.be/p4PmN15pHZY 4- Conclusion La phase réalisation n’est que le résultat des phases précédentes tel que l’étude préalable et la conception détaillée pour aboutir à l’étape de programmation qui permet l’interconnexion avec la base de données.

Faouel Soufien&Mohamed Taher Marnaoui

Page 38

Mini-projet Orientée Objet

N2TR 2013/2014

Conclusion Générale Face à l’expansion rapide des réseaux fixe et ADSL et à l’augmentation de la concurrence, les exigences des utilisateurs sur la qualité des services acquis sont devenues de plus en plus strictes ; et le besoin des opérateurs de se différencier par une meilleure offre de qualité de service et d’augmenter leurs rentabilités est devenu le souci de nombreux organismes de recherche. Notre mini-projet intitulé « Gestion des BTS d’un centre radio GSM » qui consiste à la conception et la réalisation d’une application qui facilite le travail d’un centre Radio GSM En ce qui concerne la démarche, nous avons en premier lieu effectué une phase d’étude des différents outils existants. En deuxième lieu nous avons spécifié notre application pour discerner les fonctionnalités .En troisième lieu, nous avons procédé à sa conception ainsi qu’aux choix technologiques pour sa réalisation. Enfin, nous l’avons mise en œuvre. Il est important à noter que la réalisation de ce mini projet nous a été bénéfique sur tous les plans. Sur le plan technique, ce projet nous a été une bonne occasion pour découvrir le langage C++, Il nous a aussi permis d'apprendre à utiliser l’environnement de développement Qt. Cette application est générique c'est-à-dire qu’elle est extensible et peut être enrichi par d’autre module tel qu’un outil qui permet la collecte des alarmes.

Faouel Soufien&Mohamed Taher Marnaoui

Page 39