3.2 Architecture
fonctionnelle de la plateforme
Cette architecture pour des raisons de clarté a
été éclatée en 02 suivant les grandes orientations
du projet : l'état QoS et les mesures Radio.
3.2.1 Architecture de
d'établissement de l'état QoS
Il est retrouvé dans cette architecture les
différents modules allant du rapatriement de données
jusqu'à la génération des alertes (et/ou d'un fichier de
reporting) ce en passant par le calcul et la sauvegarde des indicateurs de
performances auxquels sont associés les outils informatiques ayant
permis leur réalisation. La figure ci-dessous laisse transparaitre le
fonctionnement de l'application, qui tente d'imiter celui du serveur NPA,
sources des données exploitables de RNO.
Figure 26 :
architecture fonctionnelle de l'état QoS
Avant de planifier cet ensemble de taches, une synchronisation
minutieuse doit être définie afin d'éviter tout aléa
de fonctionnement. La figure ci-dessous en est une solution envisageable.
Figure 27 : lot
principal
La mise en cascade de tous ces lots garantie une
exécution conforme des uns à la suite des autres.
Désormais, la planification ne présente plus de danger
d'asynchronisme. Il est utilisé à cette fin l'assistant de
planification comme présenté ci-contre:
Figure 28 : assistant
de planification
Dans cet environnement où est abritée notre
application, le rendu des informations sur les indicateurs ou sur les alertes
du réseau, est assuré sur tous les jours précédent
le jour où sont effectuées les requêtes dans les tables de
la base de données. De même, il est possible depuis une page Web,
via PHP, de générer un reporting sur les semaines
préalablement choisies sur l'interface.
3.2.2 Architecture des mesures Radio
Les principaux échanges sont faits entre l'utilisateur
(sur l'interface), le serveur des mesures enregistrées sous forme
d'images, et la base de données des échantillons et des
commentaires y afférant. L'organisation architecturelle est la
suivante
Serveur APACHE
Base de données des échantillons et des
commentaires
Serveur de mesures
:
Intranet
Figure 29 :
architecture fonctionnelle des mesures Radio
Au besoin l'utilisateur interroge :
ü soit le serveur de mesures pour la visualisation ou
l'enregistrement d'un type de mesure ;
ü soit la base de données pour le tracé de
l'évolution des échantillons ou le suivi des états de
couverture et de qualité des sites déjà
évalués en mesure Radio.
Cette base de données a une configuration qui permet
tant de gérer l'archivage des mesures que l'enregistrement des
échantillons et le suivi des sites. Le modèle relationnel des
tables ci-dessous en font une illustration appropriée:
Figure 30 : conception
de la base de données des mesures Radio
L'élément partagé par ces 02 plateformes
est l'interface Web, qui assiste l'utilisateur à la confection de ces
requêtes. Un intérêt particulier y sera accordé dans
la partie suivante pour une démonstration de son utilisation.
|
Chapitre
3 :
RESULTATS ET COMMENTAIRES
|
|
Cette partie est exclusivement consacrée à la
présentation et à l'utilisation efficace de l'interface Web de
l'application développée. C'est le seul moyen de communication
entre un utilisateur de l'intranet et les bases de données des alertes
(ou des indicateurs) et le serveur de mesure. Son exploitation dépend du
profil de l'utilisateur connecté.
Profil utilisateur
|
Droits
|
Restrictions
|
Ingénieur - admin
|
· d'effectuer des actions d'optimisation sur des
cellules à indicateurs dégradés et de les
enregistrer;
· d'ajouter de nouvelles cellules dans la table
de localisation de l'ensemble des cellules du réseau ;
· d'insérer, modifier ou supprimer des
commentaires sur les états QoS hebdomadaires ;
· de générer des rapports sous
format Excel d'état QoS ;
· de gérer les comptes utilisateurs
(modifier profil, supprimer,...) ;
· de consulter les projets préalablement
ajoutés par les techniciens de mesure;
· de consulter l'état de couverture et de
qualité des sites parcourus en mesure Radio.
|
· ajouter un nouveau projet de mesure et des
échantillons correspondants ;
· supprimer des fichiers de mesure.
|
|