|
Plateformes de services intégrés pour mobiles( Télécharger le fichier original )par Djibril GUEYE Université Cheikh Anta Diop de Dakar - Diplôme d'Ingénieur de Conception 2008 |
Chapitre 5 : Conception de la plateformePour mener à bien la conception, nous allons mettre en pratique la démarche simplifiée présentée à la page 29, pour les deux services, en partant des besoins spécifiés dans le chapitre précédent.
La première maquette est une interface de choix. A ce niveau, l'utilisateur peut choisir de sauvegarder ses données, de les restaurer ou de paramétrer la période de sauvegarde. La deuxième maquette résulte du choix de l'option paramétrage en 1. A partir de cette interface l'utilisateur peut choisir d'automatiser la sauvegarde de son répertoire soit automatiquement après l'ajout d'un contact soit périodiquement. Il peut aussi revenir sur le mode manuel dans lequel il déclenche lui-même l'opération. Dans la troisième maquette, l'utilisateur est invité à confirmer l'opération de sauvegarde ou à l'annuler. A l'issue de l'opération, un message de succès est affiché à l'écran : c'est la dernière maquette. 2. Fiche descriptive de cas d'utilisation Nom : Effectuer une sauvegarde de données Objectif : A partir d'un terminal mobile, l'utilisateur pourra effectuer la sauvegarde de ses données personnelles dans un serveur distant. Identification des acteurs
Tableau 5 : Acteurs du service Sauvegarde de données Préconditions Disponibilité du réseau Application installée au niveau du terminal client Scénarii : Afficher un menu (client) Choisir un service de sauvegarde (utilisateur) Afficher une demande de confirmation (client) Confirmer la demande (utilisateur) Initialiser client (client) Initialiser serveur (serveur) Sauvegarder données (client) Envoyer accusé (serveur) Notifier utilisateur (client) Post conditions : La base de données du serveur de sauvegarde est à jour Variantes et cas d'erreurs : En 4. Annulation de la demande : l'application affiche le menu principal En 6. Le serveur ne répond pas à l'initialisation du client, le cas se termine En 7. Les données n'existent pas sur le mobile ou les données ne sont pas bien récupérées : l'application affiche un message d'erreur, le cas se termine. Identification des cas d'utilisation
Tableau 6 : Identification des CU du service de sauvegarde
Figure 26 : Diagramme de CU SOS PIN
Figure 27 : Modèle du domaine SOS PIN
Figure 28 : Diagramme de classes participantes SOS PIN
Figure 29 : Diagramme de séquence SOS PIN
Figure 30 : Diagramme d'activités SOS PIN
Figure 31 : Diagramme d'interactions SOS PIN
Figure 32 : Diagramme de classes de conception SOS PIN II. Le service de billetterie dématérialisée
Figure 33 : Maquette MTicket - portail web Le portail web d'achat se divise en 5 zones : 4 latérales et une centrale. En 1, la zone centrale présente une image des événements pris en compte par l'application. L'utilisateur peut cliquer sur une image pour accéder aux informations détaillées de l'événement correspondant et éventuellement acheter un ticket : ces dernières options sont accessibles dans la zone centrale de la maquette numéro 2.
Figure 34 : Maquette MTicket - portail USSD Ces maquettes définissent l'ordre chronologique du déroulement de l'achat d'un ticket à partir d'un détaillant. Dans la première, s'effectue le choix du service. Ensuite sont choisis l'événement et la catégorie pour lesquels le ticket est acheté. En fin le numéro de téléphone du destinataire du ticket est renseigné. Nom : Acheter du crédit à partir du portail web Objectifs : l'acheteur pourra réserver un ticket qui sera envoyé par MMS sur un mobile précisé Identification des acteurs :
Préconditions : L'acheteur se présente devant le portail Scénarii : Le système affiche l'écran accueil du portail L'acheteur choisit l'événement sur lequel porte son achat Le système présente un formulaire L'acheteur remplit le formulaire et valide Le SP contrôle le paiement Le système vérifie la compatibilité du client Le système génère un ticket Le système envoie le ticket sous forme de MMS au client Postconditions : Le ticket sous forme de code barres s'affiche sur le terminal client Variantes : En 4. l'acheteur ne valide pas le formulaire : le cas se termine En 5. le solde de l'acheteur est insuffisant pour la transaction : le cas se termine En 6. le client est incompatible : un message est envoyé au terminal client ; le cas se termine Identification des cas d'utilisation
Figure 35 : Diagramme CU MTicket
Figure 36 : Modèle du domaine MTicket
Figure 37 : Diagramme de classes participantes MTicket
Figure 38 : Diagramme de séquence MTicket
Figure 39 : Diagramme d'activités MTicket
Figure 40 : Diagramme d'intéractions MTicket
Figure 41 : Diagramme de classes de conception |
|
