1. IV.2.2.1.3. MySQL
Le Système de Gestion de Bases de Données utilisé pour la gestion et le stockage des données dans le
cadre de la mise en oeuvre du prototype final est MySQL dans sa version 5.1. Le logiciel MySQL est
un serveur de base de données SQL très rapide, multi-thread, multi utilisateurs et robuste. Il est destiné
aux missions stratégiques, aux systèmes de production à forte charge, et à l'intégration dans des
logiciels déployés à grande échelle. MySQL est une marque déposée de MySQL AB.
Les principaux concurrents de MySQL sont : PostgreSQL, Microsoft SQL Server, et Oracle. Ainsi,
le choix de ce Serveur de Bases de Données a été particulièrement orienté par un certain nombre
d'avantages qu'il offre aux développeurs. En effet, par rapport aux autres SGBD cités, MySQL est un
logiciel intégrant un haut degré de portabilité, de sécurité et constitue un système de sauvegarde assez
évolué avec utilisation optimale de ressources.
IV.2.2.2. Les outils de développement
La mise en oeuvre du serveur d'applications USSD a nécessité un certain nombre de plateformes. Ces
derniers garantissent au serveur un haut niveau de sécurité, une couche d'accès au données, une bonne
qualité des services et rendent ce module maintenable et réutilisable. Ces plateformes sont les
suivantes :
Mémoire de Fin d'Etudes d'Ingénieur de Conception en Informatique : ENSP, JUIN 2008 DONFACK
Cédric Pérez Page 46
IV.2.2.2.1. J2EE.
J2EE (Java Platform Enterprise Edition) est une plateforme fortement orientée serveur pour le
développement et l'exécution d'applications distribuées. Elle est composée de deux parties essentielles
:
? un ensemble de spécifications pour une infrastructure dans laquelle s'exécutent les
composants écrits en java : un tel environnement se nomme serveur d'application.
? un ensemble d'API qui peuvent être obtenues et utilisées séparément. Pour être utilisées,
certaines nécessitent une implémentation de la part d'un fournisseur tiers.
J2EE permet une grande flexibilité dans le choix de l'architecture de l'application en combinant les
différents composants. Ce choix dépend des besoins auxquels doit répondre l'application mais aussi
des compétences dans les différentes API de J2EE. L'architecture d'une application se découpe
idéalement en au moins trois tiers :
? la partie cliente : c'est la partie qui permet le dialogue avec l'utilisateur. Elle peut être composée
d'une application standalone, d'une application web ou d'applets.
? La partie métier : c'est la partie qui encapsule les traitements (dans des EJB ou des JavaBeans).L
? a partie donnée : c'est la partie qui stocke les données.
IV.2.2.2.2. J2ME

2. Historiquement, Sun a proposé plusieurs plateformes pour le développement d'applications sur des
machines possédant des ressources réduites, typiquement celles ne pouvant exécuter une JVM (Java
Virtual Machine) répondant aux spécifications complètes de la plateforme J2SE (Java Platform
Standard Edition).
? JavaCard : pour le développement sur des cartes à puces
? EmbeddedJava :
? PersonnalJava : pour le développement sur des machines possédant au moins 2mo de mémoire
Mémoire de Fin d'Etudes d'Ingénieur de Conception en Informatique : ENSP, JUIN 2008 DONFACK
Cédric Pérez Page 47
J2ME (Java Platform Micro Edition) est utilisé essentiellement dans le cadre de notre travail pour
réaliser les tests.
IV.2.2.3. Analyse du serveur d'applications
? Les acteurs du système o La passerelle :
Elle est responsable du déclenchement des processus. Elle envoie la requête sous forme de fichier
XML (eXtended Markup Language.) au serveur d'applications et attend une réponse .
o Le SGBD
C'est le gestionnaire des données de notre serveur.
? Les fonctionnalités du système.
o ReceptionRequete.
o TraitementRequete.
Mémoire de Fin d'Etudes d'Ingénieur de Conception en Informatique : ENSP, JUIN 2008 DONFACK
Cédric Pérez Page 48
o EnvoieResultat.
? Le diagramme des cas d'utilisation

3. Figure 21: Diagramme des cas d'utilisations Serveur d'applications
IV.2.2.4. Conception du serveur d'applications
? Description des classes. o ReceptionCode
Cette classe, responsable de la réception de la requête sous forme de message XML, récupère
l'information nécessaire et l'envoie pour traitement
Mémoire de Fin d'Etudes d'Ingénieur de Conception en Informatique : ENSP, JUIN 2008 DONFACK
Cédric Pérez Page 49
o LesServicesOfferts
Cette classe ne peut pas être instanciée (IL n'existe pas d'objets qui lui est directement lié.). Aussi, elle
contient les informations liées à tous les services notamment le codeServices ; ainsi que les méthodes.
o EnvoieCode
Cette classe, responsable de l'envoie du résultat, converti d'abord en MessageXML. o ServicesA
Cette classe représente un service bien défini dans le système. Elle contient toutes les informations
relatives à ce service donné.
? Le diagramme de classes.
Figure 22: Diagramme des classes du serveur d'applications

4. Mémoire de Fin d'Etudes d'Ingénieur de Conception en Informatique : ENSP, JUIN 2008 DONFACK
Cédric Pérez Page 50
? Les diagrammes de séquences.
o ReceptionRequete
Figure 23: Diagramme de séquence RéceptionRequete.
o TraitementRequete
Figure 24: Diagramme de sequence TraitementRequete
o EnvoieResultat.

5. Figure 25: Diagramme de sequence EnvoieResultat.
Mémoire de Fin d'Etudes d'Ingénieur de Conception en Informatique : ENSP, JUIN 2008 DONFACK
Cédric Pérez Page 52
IV.2.2.5. Test du serveur d'applications USSD.
Ce travail n'a pas pu être testé dans sa totalité à cause de certains manquements notamment la carte
d'extension. Qu'à cela ne tienne, un projet de déploiement de notre travail est prévu pour le mois
d'Août. Cela garantit l'existence du matériel nécessaire. Toutefois, ce projet a eu deux grands points
d'énormes difficultés à savoir le déploiement d'OpenSS7 et la mise en oeuvre du server USSD. La
plateforme ayant été installée correctement, notre prototype consistera à montrer que notre serveur
d'applications USSD fonctionne normalement.